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 pr