[M3devel] [M3commit] CVS Update: cm3

[Jay]

If old compiler can't build m3core, such as if old compiler predates LONGINT.
You already know this.
Are we "past" such compilers?
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:51:08 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3


Why do you not build in the following order to get a new compiler?  (You may need to downgrade Compiler.tmpl for use with an old compiler so that you don't get a mismatch between m3core and libm3, but otherwise the following sequence should work).

m3core
libm3
sysutils
m3middle
m3objfile
m3linker
m3back
m3front
m3quake
cm3

On 12 Jan 2009, at 18:25, Jay wrote:


The compiler uses sysutils. The first pass builds against an old package store, which might not have sysutils at all, if it is that old. Again, once new m3core is around, no problem.I could/should have put in the m3core change and just waited on the sysutils change, rather than go ahead and do the quake stuff, and we can do that now (or your change that moots it, which I haven't looked into yet). I was browsing the docs and it appears there is an "import_pkg" directive for like, copying in a package contents, instead of linking. That might also solve this. I found that relatively late and never looked into it.  - Jay

From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:19:55 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Not true.  sysutils should be built against the m3core with which it will be linked.   I don't think this is correct.



On 12 Jan 2009, at 17:58, Jay wrote:


To bootstrap I believe.  - Jay

From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 17:53:02 +1100CC: jkrell at elego.de; m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3Why does sysutils need to be compatible with both old and new versions of m3core?




On 12 Jan 2009, at 17:39, Jay wrote:

ThreadPosix is basically unaffected -- I never provided user threads on Cygwin. I guess it got a slight reduction regarding DoesWaitPidYield, but its SchedulerPosix implementation was unchanged. The code in ThreadPosix is similar to but different than ThreadPThread.It is possible they could be merged but it wasn't trivial so I left ThreadPosix alone.  > You are smearing implementation details across multiple files and directories You really think it is bad to have SchedulerPosix implemented in a small separate file?On top of what happens to be common implementation details of ThreadPThread.m3 and ThreadWin32.m3? ThreadPScheduler.m3 is just basically three functions: IOWait, IOAlertWait, XIOWaitPlus the little internal utility, UTimeFromTime, the one liner DoesWaitPidYield, and non-trivial functions nested in XIOWait: TestFDS, CallSelect. I mean, you know, an alternative is to copy out very large chunks of ThreadWin32.m3 and ThreadPThread.m3 and merge them into ThreadCygwin.m3. That would be worse imho. "Directories" hardly. Or I can try debugging cygwin pthreads again.  - Jay

CC: jkrell at elego.de; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:46:54 +1100You are smearing implementation details across multiple files and directories.  Up until now, ThreadPThread has been nicely self-contained, and captured all the basic pieces of the thread implementation.  Also, how does all of this fit with the ThreadPosix implementation?



On 12 Jan 2009, at 12:19, Jay wrote:


btw, I don't think it's that hairy, I merely split it into two or three files, and added interfaces so they can reuse code with each other. Movement between files is hard to track though (depending on version control, but with all I've used). The SchedulerPosix implementation moved to ThreadPScheduler.m3.What is shared between it and ThreadPThread/Win32.m3 is ThreadInternal.i3, which maybe should be in ThreadF.i3, though that's exposed outside m3core, and ThreadInternal.i3 includes a variable. I can try again to debug Cygwin pthreads though.  - Jay> From: hosking at cs.purdue.edu> To: jkrell at elego.de> Date: Mon, 12 Jan 2009 11:03:33 +1100> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] [M3commit] CVS Update: cm3> > Jay,> > Can you remind me again why Cygwin was unable to use pthreads? It > seems you have introduced a bunch of hair into the PTHREADS > implementation to deal with broken Cygwin pthreads. As many of us > have already pointed out, Cygwin should be a port that tries as much > as possible to be like a standard POSIX platform (pthread-based) as > opposed to a weird Windows/POSIX hybrid.> > I have a bunch of code that will be going into the PTHREADS base that > I am now at a loss to integrate with the changes you have made.> > Help!> > -- Tony> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090112/5c72f570/attachment-0002.html>