[Openmcl-devel] OpenMCL future

[Barry Perryman]

Gary,

Do you have anywhere a document on the web site that contains the list of 
the things that needs to be done?

Maybe something like this would help people decide what they think they can 
get involved with and help focus the development effort.

Barry


>From: Gary Byers <gb at clozure.com>
>To: Sven Van Caekenberghe <sven at beta9.be>
>CC: <openmcl-devel at clozure.com>
>Subject: Re: [Openmcl-devel] OpenMCL future
>Date: Fri, 6 Sep 2002 06:34:09 -0600 (MDT)
>
>
>
>On Fri, 6 Sep 2002, Sven Van Caekenberghe wrote:
>
> > Gary,
> >
> > In one of your response you said '... the plan is to phase them in over
> > the next few OpenMCL
> > releases (details forthcoming; if anyone's curious, ask.) ...'. So here
> > are some questions:
> >
> > What are the details for the next few openmcl releases ?
>
>I'm not sure of exactly what'll happen when.  It is very likely that
>0.14 will use "cooperatively scheduled POSIX threads" (POSIX threads
>with locks+sempaphores so that a lisp scheduler can control their
>execution) and a number of low-level architectural changes (deep-binding
>of special variables, more-per-thread context kept on a per-thread
>basis, etc.) that address many of the issues related to migrating to
>native threads.  The adoption of native (preemptively scheduled) threads
>will raise lots of other issues (in the GC and elsewhere), so I want
>to sort of do this incrementally.
>
>There are still known areas of ANSI incompatibility (ED isn't defined,
>logical pathname translations maintain case-sensitivity when they
>shouldn't, some conditions that're signaled are generic when the
>spec requires something more specific) and there are almost certainly
>unknown areas: I've never gone through the entire spec, generated
>test cases for everything, and tried to ensure that it passed.  I'd
>guess that the number of discrepancies that this would find are few
>and minor, but at this point that's just a guess.
>
>There are other areas of missing functionality (MOP support, or as
>much of the MOP as can be supported without impacting performance)
>and I think that some performance improvements (the compiler's
>handling of unboxed arithmetic, at least in constrained cases) can
>be accomplished in the short term.
>
>The quantity and quality of available documentation could both
>be improved.  Writing a really comprehensive manual is probably
>a long-term project (and would ideally involve the participation
>of people competent to do so.)  What's there could be better organized
>and in some cases (the "internals" document) needs to be brought up
>to date.
>
>I'd like to be able to improve the Cocoa demo to the point where
>(more) users could enhance it and contribute to its development.  (If
>it got to that point, I'm sure that it would start to improve a lot
>faster.)  I think that it's both important to be able to offer an
>alternative IDE for people not comfortable/satifisfied with ILISP
>and to develop a framework for delivery of UI-rich applications.
>
>Someone asked me a few weeks ago when I thought that the version number
>should change to 1.0 and the "beta" designation removed.  On the one
>hand, I wouldn't feel entirely guilty about having done so for any
>of the past few releases (I've seen, used, and worked on "released
>products" that were even rougher around the edges); on the other
>hand, I'd like it to continue to have a high degree of fluidity:
>I'd like to feel able to change whatever implementation details
>need changing whenever there's technical motivation to do so.
>
>These are things that I have in mind; I'd certainly be interested
>in hearing other people's ideas.
>
> >
> > Are you the only developer ? Can you keep this up ?
>
>Gail Zacharias worked on sockets, pathnames, streams, and other
>stuff in the last year; several other people have contributed
>examples, bugfixes, and code.
>
>Without going into a lot of detail, I get paid to (among other
>things) work on OpenMCL, and the "other things" are often closely
>related.
>
> >
> > Is the relationship with Digitool like a code split, or will openmcl
> > become the core of MCL like Darwin is for Mac OS X ?
>
>It's currently more like a code split.
>
>Note that Digitool doesn't currently have a released OSX-native MCL,
>and that fact makes it difficult to say much about the issue.
>
>If it were possible to publicly discuss this, it would certainly be
>interesting to do so ...
>
>
> >
> > ;-)
> >
> > Sven
> >
> > --
> > Sven Van Caekenberghe - mailto:sven at beta9.be
> > Beta Nine - software engineering - http://www.beta9.be
> > .Mac - svc at mac.com - http://homepage.mac.com/svc
> >
> >
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
> >
> >
>
>
>_______________________________________________
>Openmcl-devel mailing list
>Openmcl-devel at clozure.com
>http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel