HDTenEightyP/NetNews huggingface dataset:
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: CLIM-MCL(final)
Date: 13 Aug 92 15:44:09 GMT
Full-Name: Steve Strassmann
Original-To: Peter Forster <Forster@informatik.uni-stuttgart.de>
Original-Cc: info-mcl

>From: Peter Forster <Forster@informatik.uni-stuttgart.de>
>Date: Thu, 13 Aug 92 16:35:06 +0200
>To: Info-MCL@Cambridge.Apple.COM
>Subject: CLIM-MCL(final)
>
>
>A half year ago we got CLIM 1.0 from ILA for our MAC. This week we
>installed the MAC 2.0 (final version) and recognize that CLIM 1.0
>could not be installed with MAC 2.0, because the binary type of the
>clim files is different of the binary type of  MAC 2.0 (final
>version). Where can we get the new CLIM upgrade for MCL 2.0?
>
>Thanks in advance
>
>	Peter Forster

There is a fully functional demo version of CLIM 1.0 (binaries)
on the MCL 2.0 CD-ROM - maybe this will be helpful in the interim.

>PS: The mail-address bug-clim@ila.com is dead

The machine ila.com is still on the net, so maybe sending mail to
postmaster@ila.com will help.
From: epl@luwish.zko.dec.com ("Ed Luwish -- Far Fig Newton!")
Newsgroups: comp.lang.lisp.mcl
Subject: Desperately seeking Error 7
Date: 17 Aug 92 12:34:32 GMT
Original-To: info-mcl%cambridge.apple.com@inet-gw-1.pa.dec.com
Original-Cc: epl@luwish.zko.dec.com
X-Mts: smtp

I have been trying for days to get MCL V2.0 to work.  Here's the story:

0.  I have a IIci with 4MB of RAM, running System 7.0.0 + Tuneup.  I use Init
	Manager (Baseline Publishing) to control my INITs.  MCL 2.0b1 ran on
	it with no trouble.  I use virtual memory {14MB) and do not use 32-bit
	mode.

1.  I copied the MCL 2.0 folder from the final-edition CDROM.  I put ptable
	into the correct folder (even though it isn't needed).  I rebooted the
	system.  The ptable icon came up x-ed out (which it should).  I then
	double-clicked the MCL 2.0 icon, and after a lot of disk activity I get
	a DS Bomb - "MCL 2.0" Error Type 7.

2.  I tried it without inits, except for Init Manager.  Same problem.

3.  I tried it without ANY startup code (booting with shift key pressed) and
	MCL came up, but with insufficient memory, since virtual memory is
	apparently one of the startup resources.

4.  I replaced Init Manager with Apple's Extension Manager V1.6.  Same problem.

5.  I removed the Syquest disk that had my copy of MCL 2.0, and double-clicked
	the original on the CDROM.  Same problem.

There are a few more things I need to try, but they get increasingly intrusive
to my configuration.  Before I move all the INITs to a non-system folder,
replace all the System files, or add more real memory, I will ask you all a
couple of questions:

What is an Error Type 7?
Are there known problems with defective CDROMs?  (I could try extracting MCL
from the virtual floppies).
Are there known INIT problems, or problems with 7.0.0 + Tune-up?
Do I need 7.0.1 or 7.1.0 beta?
Why do I ask so many questions?

Please help me before I dust off my C++ compiler :-)

Ed
Newsgroups: comp.lang.lisp.mcl
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: Does CLIM use Mac UI Widgets?
Keywords: CLIM, Mac UI Widgets
Organization: Northern Telecom Inc, Mountain View, CA
Date: Thu, 13 Aug 1992 01:05:45 GMT

Regarding CLIM for MCL, does anyone know if it uses Mac user
interface widgets or does it implement cooresponding widgets
from scratch? Other implementations of CLIM that I've seen have
taken the latter approach. Thanks

Chuck Irvine
Northern Telecom
ames!ntmtv!irvine
From: moon (David A. Moon)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: LISP - Oracle
Date: 20 Aug 92 22:15:42 GMT
Full-Name: David Moon
Original-To: cfry@MIT.EDU (Christopher Fry)
Original-Cc: Bruce Lester <72110.1107@CompuServe.COM>, info-mcl@cambridge.apple.com,
        kgrant@us.oracle.com

> Date: Tue, 18 Aug 92 15:05:20 EST
> From: cfry@MIT.EDU (Christopher Fry)
> 
> Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
> I'm not sure what Apple's plans are but please join me in encouraging
> Apple to cooperate here. In particular, a standard FFI to C code
> might go a long way toward writing useful portable utilities like an SQL
> interface.

I will just offer my own opinion here, intended to cut the Gordian knot that I 
think prevented foreign function interface standardization in the past, which 
is that the various vendors couldn't agree on the syntax of the Lisp macro 
that declares a foreign function and specifies the types of its arguments and 
result.  The answer is, don't have a Lisp macro for this, make the Lisp 
compiler read C header files instead.  It's not very hard to implement.  This 
is more convenient for the user, too.

The vendors would still have to agree on the mapping of C names and types to 
Lisp.  I have an opinion on that, too, but it's too lengthy to include here.

Feel free to forward this message to other vendors or mailing lists if you 
wish.

These are my personal opinions, not necessarily the opinions of Apple Computer 
nor of the Macintosh Common Lisp product developers.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Lunch Monday?
Date: 17 Aug 92 20:16:17 GMT
Full-Name: Bill St. Clair
Original-To: info-mcl

I seem to recall someone telling me that they had reimplemented
MCL's pop up menus using the new System 7 popUpMenuCDEFProc.
If you are that person, and are willing to donate your code,
please send it to me. Steve Mitchell needs the popUpMenuCDEFProc's
ability to change the menu fonts.

-----
Bill St. Clair
bill@cambridge.apple.com
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: cell-select in sequence-dialog-items
Date: 20 Aug 92 21:50:50 GMT
Full-Name: Bill St. Clair
Original-To: lynch@ils.nwu.edu
Original-Cc: info-mcl

>As much as I like the MCL programming environment, I have to say that
>between the simple-view/view and focusing problems, as well as some serious
>non-modularity (like this);  the various windowing widgets are due for a
>big overhaul.

I have already apologized for the cognitive overload caused by the
simple-view/view stuff.

A lot of the widget problems are due to the fact that MCL uses Mac toolbox controls whenever possible. An advantage of this is that if the standard
appearances of any of these change in the future, MCL will inherit
those changes. The disadvantage is that we also inherit all of their
bugs and can't fix them.

>
>This is not meant as a flame.  The flaws like this have only been found by
>pushing MCL to the limit, but they are there.
>
>PS:  If, perchance, you *do* roll your own sequence-dialog-item, I would
>also recommend that it be a sequence-view (ie subclass of view, not
>dialog-item).  I would also like to see it archived if that would be OK.

We have been considering rewriting table-dialog-items sans Macintosh
list manager for a while. In perfect 20/20 hindsight, this is what I should
have done as part of writing the new Inspector: I ended up doing most
of it but in a non-reuseable manner.

I doubt that anyone here will do a rewrite in the near future, but if
someone else does a reasonable one we'll definitely consider using it
for MCL. At the very least, we'll put it on the next CD. Remember, the
Macintosh list manager has lots of features and MCL's table-dialog-item
uses most of them.
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Mailing list vs News Group
Date: 17 Aug 92 20:00:30 GMT
Original-To: info-mcl@cambridge.apple.com (Macintosh Common Lisp)

A few weeks ago I got access to a usenet news reader
and tried out the comp.lang.lisp.mcl group. After reading
the news for a few weeks, I noticed that some messages
appearing on the news group never make it to the mailing
list. Did anyone else notice the same problem?

*********************************************************************
* Guillaume Cartier                 (514) 844-5294 (maison)         *
* L.A.C.I.M.                        (514) 987-4290 (bureau)         *
* Universite du Quebec a Montreal   (514) 987-8477 (telecopieur)    *
* Montreal, Quebec, Canada          cartier@math.uqam.ca (internet) *
*********************************************************************
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: LISP - Oracle
Date: 18 Aug 92 20:05:20 GMT
Original-To: Bruce Lester <72110.1107@CompuServe.COM>
Original-Cc: info-mcl@cambridge.apple.com, kgrant@us.oracle.com

> I need to generate SQL in MCL 2.0, send it to a remote Oracle database server,
> and parse the result in MCL.  I would like MCL to have control of this entire 
> transaction.
> 
> Has anyone attempted to communicate with Oracle using MCL?
> 
> Did anyone attend Cris Kobryn's "Interfacing Lisp to SQL Databases" tutorial 
> at the "Second International Lisp Users and Vendors Conference"?
I did. Cris Kobryn works at Harlequin. They make a bunch of add-on Common Lisp
software products intended for multiple hardware platforms. 
I don't think they've brought up their SQL interface on the Mac yet.

At the conference, there was a movement to make some CL industry-wide defacto standards 
for:
CLIM, Foreign Function Interface, and SQL interface. The plan was not to go through
the whole ansi process at this time, but simply have a generally agreed upon spec by the
major Lisp vendors that would permit users to port their code.

Franz, Lucid, Symbolics, and Harlequin seem to be moving in this direction.
I'm not sure what Apple's plans are but please join me in encouraging
Apple to cooperate here. In particular, a standard FFI to C code
might go a long way toward writing useful portable utilities like an SQL
interface.

For interfacing to particular products like Oracle, its likely that more than one
MCL hacker could make use of such code. If the interface code were portable accross
all CL implementations there might even be a market for such code. 
Most likely scenerio is that the company selling the library supports a CL hacker
for doing the interface [typically as part of a project the hacker is doing anyway]
then takes over support and distribution of the interface software. I'd hope the
goal of the company would not be primarily to make money selling the interface code
itself, but rather in gaining more sales for their base product BECAUSE such an
interface was available.

This message is being CC'd to Ken Grant who use to work at my lab [MIT Center for 
Coordination Science] and is now at Oracle. One of my predicessors at CCS wrote a
DAL <-> MCL1  interface whose intended use was with Oracle. Due to the cripling
DAL limitation of only 255 bytes per record, the code isn't very useful. A more direct
interface to Oracle would be.

We can save net work to the benefit of all with the right level of cooperation.
You MCL hackers out there that need SQL interfaces, pipe up!
From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,BDV)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Interfacing to I/O boards
Date: 13 Aug 92 16:20:00 GMT
Original-To: JD05@GTE.COM, INFO-MCL@CAMBRIDGE.APPLE.COM

John,
 
We work in MCL 2.0 and National Instruments' LabView (among other systems), and
would unhesitatingly recommend their products.  They can supply you with a
low-level programming suite called NI-DAQ, which includes good support for MPW
C.  You can thus build data acquisition and control software using the FF
interface (calling NI-DAQ material) or you can use the 'not in RAM' approach to
talk to the boards direct from MCL.  Although we have not yet brought the two
together in a project, I suspect that we will be doing so soon.
 
I would strongly discourage you from solutions based on serial port systems,
unless you require relatively infrequent samples and are happy to work
'remotely' with your data acquisition hardware.  Personally, I find systems
like that create more problems than they solve *unless* the remote device is
doing a lot more than just acquiring the data (e.g. we have one system for
laser Doppler blood flow measurement which has to work via the serial port
really, but the controller for that does all the frequency shift analysis etc.
and delivers processed data to the serial port).
 
Howard.
 
Newsgroups: comp.lang.lisp.mcl
From: lhermens@ren (Leonard Hermens - CS)
Newsgroups: comp.lang.lisp.mcl
Subject: Problem printing to ImageWriter
Date: 13 Aug 92 17:22:32 GMT
Original-To: info-mcl@cambridge.apple.com
X-Mailer: ELM [version 2.3 PL11]


I am experiencing a bomb dialog after printing to the ImageWriter
with my Mac IIx running MCL 2.0 final.  

The senario:
 Launch MCL 2.0
 Open a small, 5-line MCL file.
 Select Page Setup from the File menu.
   Select Portrait mode, no other options
 Dismiss the setup dialog
 Select Print... from the File menu.
   Select Hand Feed, Faster printing.
   Click Print
 Page then prints just fine.
 Select Page Setup again...BOMB  System Error MCL 2.0 bus error
    (Sometimes the bomb dialog appears just by clicking the menubar.)

It does not matter which port, modem or printer; it doesn't seem to
matter whether Appletalk is active or not.

Draft printing does NOT do this, only Better or Faster modes do...

Hardware:
 Mac IIx with Mode32 and 20Meg RAM
 ImageWriter II

Software:
 System 7.0.1 w/Tuner 1.1.1
 ImageWriter driver version 7.0

Any information would be appreciated.  Our application, which prints
carbon-copy forms, is nearing completion, so any information on this
apparent problem would be very much appreciated.

The problem does not (seem to) exist in MCL 2.0b1.

Thank you.
-- 
Leonard Hermens                 lhermens@eecs.wsu.edu
School of Electrical Engineering and Computer Science 
(509)-335-2215            Washington State University
From: kurihara@tansei.cc.u-tokyo.ac.jp (Akira Kurihara)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Support for Accelerated Macs?
Date: 20 Aug 92 18:23:49 GMT
Organization: Computer Centre, University of Tokyo


>
> 
>    Hi, we have a Mac SE with a Radius 16 Mhz Accelerator, and MCL doesn't
> seem to be comfortable with exotic CPU boards added on the REAL Apple 
MACs.
> 
>    Since I assume there are quite some people out there with accelerator
> boards, will there be any support for those machines?
> 
>    MCL loads and run fine until it begins to evaluate a lot of 
functions....
> and it bombs with System Error #11 -- Something like 68000 Trap Error or
> similar.
> 
>    I guess Garbage Collection and all those things require quite intimate
> relationship with the CPU. But is there any way to make MCL think it is a
> 68020 machine rather than a 68000 machine?
> 
> - Young-pa So (e-mail : frege@crim.eecs.umich.edu)
> 

I have a Mac SE with a Radius 25 Mhz Accelerator. I am using the final 
version
of MCL 2.0 running on system 6.0.7 for about 2 weeks and had no problems on 
it. 

Certainly MCL 2.0b1p3 had some problems when performing GC.

Also, MACL 1.3.2 was fine to me. However, certainly MCL 2.0 runs faster than
MACL 1.3.2.

----

Akira Kurihara
kurihara@tansei.cc.u-tokyo.ac.jp

Newsgroups: comp.lang.lisp.mcl
From: moore@cs.utah.edu (Tim Moore)
Subject: MOP in MCL 2.0
Organization: University of Utah CS Dept
Date: 13 Aug 92 09:44:41

I understand that the MOP as defined in AMOP isn't complete in MCL
2.0. How much MOP is there? Are there plans to implement the full MOP
in the near future?

--
Tim Moore                    moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore
"Wind in my hair - Shifting and drifting - Mechanical music - Adrenaline surge"
	- Rush
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Tear Off Menus
Date: 13 Aug 92 18:12:02 GMT
Original-To: info-mcl@cambridge.apple.com (Macintosh Common Lisp)

I am posting this question for a friend that
doesn't have access to the electronic mail...

Has anyone implemented (or did some work on)
tear off menus in MCL?

Thanks for any tips.

*********************************************************************
* Guillaume Cartier                 (514) 844-5294 (maison)         *
* L.A.C.I.M.                        (514) 987-4290 (bureau)         *
* Universite du Quebec a Montreal   (514) 987-8477 (telecopieur)    *
* Montreal, Quebec, Canada          cartier@math.uqam.ca (internet) *
*********************************************************************
From: mt@media.mit.edu (Michael Travers)
Newsgroups: comp.lang.lisp.mcl
Subject: colored dialog items
Date: 12 Aug 92 19:44:08 GMT
Original-To: info-mcl@cambridge.apple.com
Original-Cc: bug=mcl@cambridge.apple.com
X-Mts: smtp

I'd like to make dialog items on a colored (well, gray) background.
Unforunately the way part-colors are handled on different types of
dialog items are remarkably inconsistent.  Try this:

(setq w (make-instance 'dialog :color-p t))
(set-back-color w *gray-color)
(dolist (c '(check-box-dialog-item static-text-dialog-item
             editable-text-dialog-item sequence-dialog-item
	     radio-button-dialog-item)
   (make-instance c :dialog-item-text "Random" :view-container w
		  :part-color-list '(:body ,*green-color* :frame ,*blue-color*
				     :text ,*red-color*))))

Some of the items end up with a gray background, some end up with a
green background, and (this is the problem) some end up with a white
background.  It doesn't seem possible to get a check-box, for
instance, that has any other background color besides white.

Now, Inside Mac V5 has a nice color plate of a dialog that does this
right, so it's possible in theory.  It seems to require creating
various resources and using special dialog-creation traps that don't
fit into MCL's theory of windows.  I wonder if anybody has taken the
trouble to make this work right, or has some other solution to the
problem.
From: owens@jonquil.uchicago.edu (Christopher Owens)
Newsgroups: comp.lang.lisp.mcl
Subject: cell-select in sequence-dialog-items
Date: 17 Aug 92 16:53:24 GMT
Organization: Dept of Computer Science, The Univ of Chicago

I'm noticing that, contrary to my intuitive expectations,
sequence-dialog-items in MCL 2.0 do not call CELL-SELECT when the user
selects a cell by clicking on it.  Cells become highlighted and added
to the list returned by SELECTED-CELLS, but the CELL-SELECT method
itself does not appear to be called.

I had hoped to specialize an :after method for this generic function
(and for cell-deselect) on a subclass of sequence-dialog-item that
would accomplish the behavior of activating a few buttons when and
only when one or more items in a table were selected.  It seems like
CELL-SELECT and CELL-DESELECT are a more logical place to put this
behavior than on VIEW-CLICK-EVENT-HANDLER, since sometimes cells might
be selected or deselected other than by clicking. (i.e. by typing
characters as in the select file dialog, or by program action)
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Short float arrays
Date: 17 Aug 92 23:03:27 GMT
Full-Name: Bill St. Clair
Original-To: Jim Hurd <71501.1347@CompuServe.COM>
Original-Cc: info-mcl

>>Not necessary. Since SHORT-FLOAT's are immediate objects, storing
>>them in an array with an element-type of T is as good as anything.
>
>Wouldn't arrays of short-floats eliminate some masking of the tag bits?

If MCL's compiler did floating point optimizations (which it doesn't), then
a SHORT-FLOAT array element type would be useful. Your declaration of the
array's type would sometimes allow the compiler to generate better code.

Since the compiler doesn't optimize floating point computations,
a SHORT-FLOAT array element type would actually slow things down.
It would require AREF to translate from array storage format to
immediate short-float format rather than just returning the bits
as they're stored in the array.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: disable the compiler
Date: 17 Aug 92 22:10:17 GMT
Full-Name: Bill St. Clair
Original-To: Peter Forster <Forster@informatik.uni-stuttgart.de>
Original-Cc: info-mcl

>Is it possible to supress the compiler during run-time?
>Our program generates and funcalls lambda-expressions during run-time. The
>consequence in MCL is - that after each lambda generation - the
>compiler is invoked. Calling the compiler wastes a lot of
>run time and consequently the run-time behavior of our application is
>not the best.
>
>Are there any possibilities in MCL to get a better run-time behavior
>for such applications?

(setq *compile-definitions* nil)

or

(defun really-eval (expression)
  (let ((*compile-definitions* nil))
    (eval expression)))

The former will make Forms typed in the Listener or evaluated from
Fred Buffers be evaluated instead of compiled. The latter gives you
more precise control.
From: poeck@informatik.uni-wuerzburg.de (Karsten Poeck)
Newsgroups: comp.lang.lisp.mcl
Subject: record pattern
Date: 16 Aug 92 16:19:20 GMT
Original-To: info-mcl@cambridge.apple.com
Original-Cc: poeck@informatik.uni-wurzburg.de
X-Mailer: ELM [version 2.3 PL0]

to info-mcl@cambridge.apple.com
cc poeck@informatik.uni-wurzburg.de

I am a little bit confused by the different definitions of the record
type
pattern in records.lisp being

(defrecord pattern 
  (variant ((w0 integer)
            (w1 integer)
            (w2 integer)
            (w3 integer))
           ((b0 byte)
            (b1 byte)
            (b2 byte)
            (b3 byte)
            (b4 byte)
            (b5 byte)
            (b6 byte)
            (b7 byte))
           ((bytes (array byte 8)))
           ((array (array :unsigned-byte 8)))))

which is fine for use because we have used the b0 , bn variant in our
program
but which is commented
and the version in 

interfaces:quickdraw.lisp which is

(defrecord (Pattern :handle) (array (array :unsigned-byte 8)))

which definition of pattern is the best one? Is it safe to replace the
definition in quickdraw by the one in records

Karsten Poeck
Universitaet Wuerzburg

poeck@informatik.uni-wurzburg.de
From: drh@world.std.com (Denis R Howlett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Apply
Date: 12 Aug 92 13:40:01 GMT
Original-To: MacLisp Info Line <info-macl@cambridge.apple.com>

I too discovered that apply and funcall don't work for lambda lists any
more and was rather disheartened since a great deal of our user interface
code relies on constructing functions which are then attached to buttons.

Much of this code is created with backquotes so that variables can be
insterted, a simple example might be:

(defun make-menu-items (items)
  (let (menu-items)
    (dolist (item items)
      (push (make-instance ...
                           :attached-function
                           `(lambda (window)
			      (declare (ignore window))
                              (print ',item)))))))

I know the code isn't quite right but you get the idea, each lambda
expression is created at run time.

The solution I have adopted (but don't like) is to make the function
dispatcher more intelligent and do the following:

;; attached-function & window are bound in preceding lines
  (funcall (if (listp attached-function)
              (eval `(function ,attached-function))
              attached-function)
           window)

This allows my dispatcher to deal with all the things that funcall (and
apply used to deal with), but I always thought it was bad form to use eval
in the middle of code? ...

Denis