[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

I think there is a straightforward fix for old compilers that can't  
compile LONGINT: define LongRep.T = INTEGER.  Most everything should  
compile from there.  That's what I recall doing to upgrade my compiler  
to handle LONGINT.  LONGINT is not used anywhere else in m3core, so  
nothing depends on it working.

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

> 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.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 18:51:08 +1100
> CC: jkrell at elego.de; m3devel at elegosoft.com
> Subject: 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.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 18:19:55 +1100
> CC: jkrell at elego.de; m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Not 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.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 17:53:02 +1100
> CC: jkrell at elego.de; m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
> Why 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, XIOWait
> Plus 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.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> Date: Mon, 12 Jan 2009 12:46:54 +1100
>
> You 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/a9760d15/attachment-0002.html>