Re: “Prehistoric” MCL

Ralf Stoye <[email protected]>
Newsgroups gmane.lisp.openmcl.devel
Message-ID <[email protected]>
MCL had multithreading long before the OS had it:
It was a cooperative Multithreading build on stack-groups: the compiler 
inserted checks and task-switches; there existed run-reasons and 
arrest-reasons;
you could even adjust how gentle it should be in Multifinder regarding 
other applications (something like *eventloop-ticks-in-background* ? 
(Memory is Fading)
A remarkable piece of Software!
I started with 1.3 when it was delivered by Apple (1988?)
Last Version i bought was 4.2 (PPC i think)
I used fred (the editor) to implement a Software for a historian who had 
to analyse about 100 Interviews, each about 50 Pages. She had a 
hierarchical List of Topics regarding different aspects of the live of 
these persons and could assign these topics to pieces of these 
textdocuments and thanks to freds notion of buffer-marks, you could even 
edit the documents without destroing your marked "text-blocks" ; Finally 
an export of a really big Index showing reasons for Arrest, work, 
living, of the victims was created in rtf Format and used to Document 
the History of "Die Frauen von Hoheneck": A group of Woman arrested for 
being not Conform to DDR politics. The created material was used to 
write two Books: one for a historic correct analysation of the Topic (a 
German "Enquete-Kommission"), and a novel about theese People ("Die Spur 
der roten Sphinx"). I learned a lot about german and russian history 
during that work, because the historian was a really smart Person, and i 
learned a lot about using MCL to its limits.
It was really fun to develop in MCL, i never found a replacement :-/

Am 05.03.22 um 17:17 schrieb mikel evins:
> My memory is that the UI framework in Object Lisp and, later, CLOS, 
> was much easier and more convenient to work with than other ways of 
> building classic Mac user interfaces. One reason is that you could 
> build up a UI interactively in real time by evaluating Lisp 
> expressions at the Listener. After the transition to CLOS, you could 
> make a working window that responded appropriately to mouse events by 
> saying
>
>   (make-instance 'window)
>
> I don't remember the exact Object Lisp syntax, but it was similarly 
> simple.
>
> The Mac got threads in System 7, in the form of the Thread Manager. If 
> I remember right, MCL/CCL didn't get thread support until the OpenMCL 
> fork, though you could have used MCL's toolbox interface to talk to 
> the Thread Manager before that.
>
> Before OSX the Mac system was a cooperative multitasking system using 
> what is nowadays called green threads.
>
>> On Mar 5, 2022, at 1:18 AM, Tim McNerney <[email protected]> wrote:
>>
>> Thanks for pointers to the “digital orphans” web museums.
>> Which brings me back to my other question…
>> Some of us remember that building a “well behaved GUI” for the Mac 
>> was a pain to code.
>> Did ObjectLisp and successors make this any easier with their OOness?
>> Could I implement widgets that responded to mouse clicks “on their own,”
>> or was there always editing of the dreaded “main event loop” for each 
>> new widget?
>> Some examples, if handy, would be good fodder for conversation.
>> Lastly, when did MacOS get full-fledged threads?
>> Or, since I’m taking to MCL devs, when did CCL start supporting threads?
>>
>> --Tim
>>
>>> On Mar 4, 2022, at 13:23, Jeremy Jones <[email protected]> wrote:
>>>
>>> 
>>> Thanks Gene! They appear to have disk images of lots of old stuff.
>>>
>>> They even have MCL 1.3 (pre-CLOS)!
>>> https://macintoshgarden.org/apps/macintosh-allegro-common-lisp
>>>
>>> I've been wanting to play with Object Lisp. A weekend project!
>>>
>>>
>>> On Fri, Mar 4, 2022, 11:37 AM Gene Z. Ragan <[email protected]> wrote:
>>>
>>>     The Macintosh Garden is a nice resource for classic software
>>>     releases.
>>>
>>>     https://macintoshgarden.org/apps/macintosh-common-lisp-20
>>>     https://macintoshgarden.org/apps/pearl-lisp
>>>     https://macintoshgarden.org/apps/macintosh-allegro-common-lisp
>>>     https://macintoshgarden.org/apps/xlisp
>>>
>>>     You may be able to find what you are looking for there.
>>>
>>>     Gene
>>>
>>>>     On Mar 3, 2022, at 10:26 PM, Tim McNerney <[email protected]> wrote:
>>>>
>>>>     Motivated by my recent purchase of a refurbished Mac Classic (*),
>>>>     I am searching for a couple of types of “prehistoric” software.
>>>>     1) 68000 MCL that runs in 4MB of RAM and a tiny B/W screen. (**)
>>>>     2) examples of early Mac apps written in MCL with decent UIs.
>>>>
>>>>     (*) With a BlueSCSI SSD instead of a fragile HDD.
>>>>
>>>>     Is the rumor true that Coral Software delivered a complete
>>>>     Common Lisp
>>>>     compressed onto a single 9cm floppy? (3 1/2”)
>>>>
>>>>     (**) I’m not looking for one of these physical floppies.
>>>>     9cm floppies were notorious, even brand new, of not being
>>>>     archival.
>>>>     Some sort of disk image would be better.
>>>>
>>>>     --Tim
>>>>     _______________________________________________
>>>>     Openmcl-devel mailing list
>>>>     [email protected]
>>>>     https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>     _______________________________________________
>>>     Openmcl-devel mailing list
>>>     [email protected]
>>>     https://lists.clozure.com/mailman/listinfo/openmcl-devel
>>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> [email protected]
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>
> _______________________________________________
> Openmcl-devel mailing list
> [email protected]
> https://lists.clozure.com/mailman/listinfo/openmcl-devel


-- 
STOYE - Networked Solutions
Ralf Stoye
Turmstr. 7
53175 Bonn
+49 163 6920050
[email protected]

_______________________________________________
Openmcl-devel mailing list
[email protected]
https://lists.clozure.com/mailman/listinfo/openmcl-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.