[Openmcl-devel] Openmcl-devel Digest, Vol 162, Issue 14

Walker Sigismund w.sigismund at alum.mit.edu
Sun Apr 23 04:58:28 PDT 2017


MORE ON HOW TO RUN MCL

I also have MCL running on Parallels and VMFusion, so virtualisation is perhaps the most practical long-term option.  But you more or less have to have a retail copy of Snow Leopard Server (I got one off eBay) rather than the server (grey disk) version which came with my Mini server,  especially for Parallels.  However for me virtualisation is on standby as I prefer running it on real machines.  For one, it can be tricky getting the virtual machines to use a large window, so that you can have code, the listener and results all comfortably and productively tiled.     

So I prefer to use MCL on a Intel compatible machine rather than an old g4 or g5.  I use one of (1) mini server 2009 Nov (core two duo) (2) an iMac 21" i5 2010 Dec or (3) a MacBook Pro i7 2011 Oct all of which are Intel machines running with Snow Leopard (or Server) using rosetta.  Sometimes the MacBook Pro i7 (four processors) seems to crash on MCL, but a recent clean install of Snow Leopard and MCL seems to work fine.  So if you can find a place that sells Snow Leopard compatible machines using info and sites like these two.

http://www.everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-fully-compatible-intel-macs.html
https://eshop.macsales.com/shop/Apple-Systems/Used/Mac-mini


HOW TO GET THE BEST OF MCL INTO CCL

As to the MCL discussion, it was indeed very useful, memorable and potentially promising, so I would like to keep it going.  

For me the beauty of MCL are FRED (the integrated development environment), the rich set of widgets (buttons, menu items, spreadsheets) and finally the graphics (open a window, draw a line, circle box in this colour and shade, keep track of each chart element so that is clickable...) it makes available to me.  All of these are missing in CCL.  None of those things have been made obsolete or unnecessary by changes in computing as far as I can tell, they are just much harder to implement due to the confusion at OS and graphic level.  Hence however much CCL surpasses MCL in other areas, it is still far behind when it comes to FRED and graphics. 

Graphics was not a problem when MCL came along, because Quickdraw defined all those widgets and graphics in a coherent way for programmers and end users, unlike current OS's.  Personally I think that it is pretty clear from the discussions here about the new graphical layers that that initial completeness and coherence has yet to be surpassed.  I would love for all of you who are capable of programming such tools to reproduce the widgets and tools in Quickdraw as the starting graphical package for CCL.   

Given the link between CCL and MCL it would then make a lot of GUI code easily portable into CCL. 

For example I have tons of pretty cool Charts types including 3d-versions which would easily run on such a library.  I am happy to contribute and partially document how to use it whether at high level (Chart this-data ...) or how to code new types.  I also have lots of statistical and financial tools that also use those widgets.  I imagine many others are like me and have developed tools sets and entire products which others could profit from.

If there are others like me who an contribute MCL tools which sit on top of a graphical CCL, it makes the way forward easier to determine because of the advantages of bringing it all together.  Surely something almost all the tools in quickdraw make sense to reproduce no matter the graphical underpinnings.  As soon as I have access to a graphical LISP library (open a window, draw a line, circle box in this colour and shade, keep track of each so that is clickable…) all of my code should be easy to port and then contribute.  

Or (as Andrew and I have corresponded in the past) perhaps it makes sense for me to contribute the charting code that runs in MCL and for developers to try to get it to run.  

My worry with that is that it might not result in a well-defined graphical layer for CCL that other code code easily use.  It make sense to have a coherent and well designed modern layer like Quickdraw.   Given all the tools people appear to have already developed without defining that layer, I wonder how easy it would be to package up the stuff you have into such a layer?  

Kind regards,

Walker

ps  This is not to downplay FRED.  I would also like a new version of it, so that I can easily keep developing on top of the new graphical CCL rather than stick with MCL on real and virtual machines. 



> On 22 Apr 2017, at 22:44, openmcl-devel-request at clozure.com wrote:
> ...
> Message: 1
> Date: Sat, 22 Apr 2017 17:29:04 -0400
> From: Bo Yao <icerove at gmail.com>
> To: openmcl-devel at clozure.com
> Subject: [Openmcl-devel] An old mac for experience MCL/RMCL
> Message-ID:
> 	<CAM+JFJTHxLGJB0SH3Fak+GC+XG1CWWcq_mvwH-zirwA9=Nz2wA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi Lispers,
> Several days ago here was a long discussion about the power and magic of
> old MCL. I plan to buy a used mac in OSX 10.6 times to run RMCL. After some
> search I found there're working ones with G4 cpu available to run MCL. I'd
> like to ask whether RMCL can provide a full experience as MCL 5.2? Thank
> you.
> -- 
> Sincerely,
> Bo
>> Message: 2
> Date: Sat, 22 Apr 2017 17:44:08 -0400
> From: Andrew Shalit <alms at clozure.com>
> To: Bo Yao <icerove at gmail.com>
> Cc: openmcl-devel at clozure.com
> Subject: Re: [Openmcl-devel] An old mac for experience MCL/RMCL
> Message-ID: <4C37DDF4-C88E-4605-A3DE-A9FA5999E09D at clozure.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Here’s a screen shot of RMCL 5.2.1 running on MacOS 10.6 running in a virtual machine inside VMWare Fusion running on MacOS 10.12.4 running on a MacBook Pro.
> 
> It works fine.  I don’t often have cause to boot it up, but it’s nice to have it when I want it.
> 
> (The moral is: you don’t need an old Mac.  You just need a copy of VMWare Fusion and a copy of Snow Leopard, preferably Snow Leopard Server.)




More information about the Openmcl-devel mailing list