Re: What are current plans for RMCL?

Pascal Costanza <[email protected]> writes:

> I'd like to get an idea what the current plans for RMCL are, if
> any. Since the switch to OS X 10.7, there is no default support for old
> PowerPC applications on OS X anymore, so RMCL doesn't work anymore, at
> least not without a major effort. Are there any plans to find a remedy
> for this situation? Or will RMCL effectively become deprecated?

I don't think there's a point to "upgrade" RMCL, that having been done
already with CCL.  That doesn't prevent us to use it in virtual
machines, if we may.

Do you have specific applications running on RMCL?



peter <p2.edoc-gM/[email protected]> writes:

> Perhaps now is a decision point for any sad losers like me who still
> have legacy code and systems that depend upon Carbon (I speak as one
> with a 1983 3600 so I know all about albatrosses, and if you don't
> know what a 3600 is, thank your stars that you still have a hope). 

Well, we're speaking of source code, what's more, written in
lisp. (Ie. with a nice OO layer above the Mac Toolbox).


> Scenario A: try to hunt out old SL supporting boxes

Harder by the day.


> Scenario B: get virtualization of SL going under Lion. 

Eventually a solution.  But I still haven't had all the expected success
with virtual machines.  There are still often problems with the hardware
and applications using it.  (People virtualize the processor and RAM,
ok, but they forget to virtualize the hardware too).


> Scenario C: A quiet chalk line crossed was when Terje moved MCLIDE
> from Carbon to Cocoa.  

That would have to be done to each MCL application.

And perhaps it has been done, or at least for the applications that were
deemed interesting.


So here is my question:  

Is there a lot of left-behind applications?

I can imagine that a few of them were kept on life support on old
computers or on Rosetta with RMCL.  How many of them?


As I see it, there are basically three layers of dependencies.

1- Dependencies on the MacOS Toolbox, embodied by the use of Toolbox
   functions such as #_DrawString, including other FFI operators (rlet,
   wptr, etc).

2- Dependencies on ccl (ie. the package CCL).

3- Dependencies on the "library", ie. the set of classes and functions
   that layer above the MacOS Toolbox, the classes such as MENU, WINDOW,
   SIMPLE-VIEW, etc.


The first dependency is being pulled out from under us, so applications
should move on.  At best, we could provide the Toolbox API as a library
implemented over various targets (cocoa, X, GTK, whatever).  But the
applications would still need to be updated to avoid messing with the
FFI, (and remove the "#_" by the way).

The second dependency might be provided by ccl, but applications might
still want to avoid them (using portability libraries for example).  I
don't know if there are things in CCL that were provided in MCL or RMCL
that are not provided anymore by CCL.

As for the third dependency, I think it is possible to take it from the
sources of RMCL, and implement the lower layer over cocoa (or GNUstep,
X, GTK, whatever).

This would allow porting applications written in MCL or RMCL to CCL and
perhaps other CL implementations, and possibly even to other systems
than MacOSX.



> People like me (at heart a musician, a cellist, so I allow my
> subconscious to communicate with my fingers, leaving my mind free to
> think about design and my end users' living experience), a huge issue
> is losing Fred and replacing it with Hemlock.  For me this is moving
> from the sanity of the concert hall to a teenager's bedroom, my
> instincts clash with so much.

The sources of fred seem to be within the sources of rmcl.  It should be
possible to make them stand alone, with the help of the GUI library.


> I am being far too un-geeky here, but in for a penny ... 

Well, for a little more than a penny ;-)

So that's my question.  How many applications would need such a
modernized library to be ported on current ccl/macosx (or possibly other
current CL and/or other systems)?  How much money could be raised, for
such a work? (perhaps with crowd-founding?)


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.




_______________________________________________
Info-mcl mailing list
Info-mcl-7+gK9HgA2O9Wk0Htik3J/[email protected]
http://digitool.com/mailman/listinfo/info-mcl_digitool.com