HDTenEightyP/NetNews huggingface dataset:
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Preserving Finder related Infos
Date: 27 Jul 92 14:37:26 GMT
Original-To: info-mcl@cambridge.apple.com (Macintosh Common Lisp)

Hi everyone,

  I want to be able to copy files and directories while
  preserving Finder related infos such as the position on
  screen, the familly, the invisibility bit, etc...

  If any one can put me on the right track, it will save
  me from lots of browsing through Inside Macintosh!

BTW: MCL's copy-file function does not preserve the
     Finder related infos.

Thanks.

*********************************************************************
* 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: djskrien@COLBY.EDU (Dale Skrien)
Newsgroups: comp.lang.lisp.mcl
Subject: toplevel-loop example
Date: 29 Jul 92 15:23:41 GMT
Original-To: info-mcl@cambridge.apple.com

On page 654 in the MCL 2.0 final manual, I am told that you want your
toplevel function to catch aborts if you don't want the listener to appear
with an error message.  Then the manual gives an example that shows what
goes wrong if you don't catch aborts:
? (defun new-top (&aux form)
    (setq form (read))
    (if (eq form 'done)
        (%set-toplevel #'toplevel-loop)
        (print (eval form))))
? (%set-toplevel #'new-top)
? (toplevel)
At this point, if you type a command-period, you are supposed to get an
error
message saying that it can't throw to tag :abort.

However, when I tried this, and typed a command-period, nothing happened. 
The new-top function just ignored the command-period.  Is the manual
correct?  If so, why didn't I get the error message?
Can someone give me a simple modification of the above example that catches
aborts, brings up a message dialog with an error message, and then returns
to the top-level function?
From: paul@vault.WUstl.EDU (Terrance Paul McCartney)
Newsgroups: comp.lang.lisp.mcl
Subject: Drawing color shapes on a monochrome monitor
Date: 29 Jul 92 17:05:32 GMT
Return-Path: <paul@vault.WUstl.EDU>
Original-To: info-mcl@cambridge.apple.com

I've run into a strange problem with color.  My program draws things of a
non-rectangular shape to a yellow background.  I also need to erase those
things without disturbing the rest of the drawing (i.e. the thing to erase
is wrapped around something else which I don't want to erase).  

For the above reason, I did not use erase-rect since it would erase too much.
I simply draw over the shape with the background color (yellow).  This works
fine on a color monitor.  When I run it on a monochrome monitor, the parts
that I erased show up as black, even though the background (yellow) shows
up as white.

It seems pretty screwed up that if you draw something with the background
color, it shows up as a non-background color.  Similar effects can be seen
in grayscale modes.  Is this another bizarre feature of the mac, or is there
some fix to this?

- Paul
From: kieras@engin.umich.edu (David Kieras)
Newsgroups: comp.lang.lisp.mcl
Subject: PROGV mystery explained
Date: 22 Jul 92 15:43:19 GMT
Original-To: kab@cambridge.apple.com
Original-Cc: info-mcl@cambridge.apple.com

Thanks, everybody, for your suggestions, and pointing out that
PROGV doesn't in fact declare anything, and since MCL EVAL runs
everything through COMPILE, of course I get an undeclared free
variable message.  My previous implementations (in UCI Lisp,
Franz, Interlisp-D, Franz Allegro CL) never griped about this
point in this and similar code, since apparently they just
interpreted the form to an EVAL, and the variables in question
were bound at the time.  I guess its like your income tax; just
because you didn't get caught doesn't mean you did it right.

Kim's suggestion to do

    (PROGV SYMBOL-LIST VALUE-LIST
      ...
      (DOLIST (ACTION ACTION-LIST)
        ...   (EVAL `(locally (declare (special ,@symbol-list)) ,ACTION))

works and provides exactly what I had in mind, since declaring
the variables globally special is not my intent. Moreover, it
works fine in my old Franz Allegro CL, which it should.

Kim, your mention that EVAL does COMPILE by default prompts me to
ask about the performance implications.  How much, relatively &
intuitively, am I paying for this?   Would I be better off to
arrange it so that compile is not the default on EVAL?  If so,
what is the switch for it? Is this the same control as for the
toplevel READ-EVAL loop?
From: engber@aristotle.ils.nwu.edu (Mike Engber)
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Difficulty in reading files
Date: 21 Jul 92 14:17:21 GMT
Original-To: markt@dgp.toronto.edu, simmons@cs.utexas.edu
Original-Cc: info-mcl@cambridge.apple.com

>I had a similar problem when building my application. The problem
>arises because the file creator defaults to MCL2 on the save application
>call. The problem sometimes disappears when you reboot.

Yes, remembering to specify something other than "MCL2" when saving the
image (or going in with ResEdit after the fact) avoids the problem.
But...

Sometimes you may want 2 or more different MCL working images around
- and you probably want them all to have "MCL2" as their signature.

In this case, when you double-click an "MCL2" document, the Finder picks
one of these images. It uses a heuristic to pick the image you don't want.
Rebuilding the desktop may or may not help.

If you want to control which image is used, you can use the program
Save A BNDL to "bless" one of the images. It's avail for anonymous
ftp from sumex-aim or from aristotle.ils.nwu.edu (129.105.100.1)
pub/engber/SaveABNDL13.hqx

BTW - Save A BNDL was originally prototyped in MCL. I could make the
MCL source available to interested parties.

-ME
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Getting slot accessors for defclass reconstruction
Date: 22 Jul 92 16:19:46 GMT
Full-Name: Bill St. Clair
Original-To: cornell@freya.cs.umass.edu
Original-Cc: info-mcl

I forgot to require "LISPEQU" to get the definitions for %SLOTD-TYPE,
%SLOTD-INITFORM, and %SLOTD-INITARGS. The code should be:

--------------------------------------------------------------------

; slot-definition-accessors.lisp
;
; More of the AMOP slot definition accessors for MCL 2.0

(in-package :ccl)

(export '(slot-definition-initargs slot-definition-initform
          slot-definition-initfunction slot-definition-type
          slot-readers slot-writers
          accessor-method-slot-definition))

(eval-when (:compile-toplevel :execute)
  (require "LISPEQU"))

(defun maybe-slot-definition-p (thing)
  (let ((sd thing))
    (and (consp sd)
         (consp (setq sd (cdr (the cons sd))))
         (consp (cdr (the cons sd))))))

(defun ensure-slotd (thing)
  (if (maybe-slot-definition-p thing)
    thing
    (require-type thing '(satisfies maybe-slot-definition-p))))

(defmethod slot-definition-initargs ((slotd list))
  (%slotd-initargs (ensure-slotd slotd)))

(defmethod slot-definition-initform ((slotd list))
  (let ((fun-or-form-list (%slotd-initform (ensure-slotd slotd))))
    (if (listp fun-or-form-list)
      (car fun-or-form-list)
      `(funcall ,fun-or-form-list))))

(defmethod slot-definition-initfunction ((slotd list))
  (let ((fun-or-form-list (%slotd-initform (ensure-slotd slotd))))
    (cond ((null fun-or-form-list) nil)
          ((listp fun-or-form-list) 
           (let ((value (car fun-or-form-list)))
             #'(lambda () value)))
          (t fun-or-form-list))))

(defmethod slot-definition-type ((slotd list))
  (or (%slotd-type (ensure-slotd slotd)) t))

; The AMOP defines functions called SLOT-DEFINITION-READERS
; and SLOT-DEFINITION-WRITERS, which take a slot definition
; object as their single argument. MCL does not store the
; class in a slot definition object, so it can't work that way.
(defun slot-readers (class slot-name)
  (let ((res nil))
    (dolist (accessor (%class-get class 'accessor-methods))
      (if (and (eq slot-name (method-slot-name accessor))
               (typep accessor 'standard-reader-method))
        (push (method-name accessor) res)))
    res))

(defun slot-writers (class slot-name)
  (let ((res nil))
    (dolist (accessor (%class-get class 'accessor-methods))
      (if (and (eq slot-name (method-slot-name accessor))
               (typep accessor 'standard-writer-method))
        (push (method-name accessor) res)))
    res))        

(defmethod accessor-method-slot-definition ((method standard-accessor-method))
  (let* ((name (method-slot-name method))
         (class (car (method-specializers method))))
    (or (assq name (class-direct-instance-slots class))
        (assq name (class-direct-class-slots class))
        (error "Can't find slot definition for slot named ~s of ~s"
               name class))))
From: markw@asdi.saic.com (Mark Watson x6816)
Newsgroups: comp.lang.lisp.mcl
Subject: the Wood system
Keywords: Wood
Date: 29 Jul 92 20:14:03 GMT
Organization: SAIC

I tried to compile the Wood system, but my MACL 2.0 final seems to be
missing the required "LAP" compiler files.  I am probably doing something
stupid, but I would appreciate any advice.  Thanks,  Mark.
From: vpv@vipunen.hut.fi (Vesa Valimaki)
Newsgroups: comp.lang.lisp.mcl
Subject: Need help on MIDI Manager programming
Date: 21 Jul 92 11:31:22 GMT
Original-To: info-macl@cambridge.apple.com

Helsinki, 21.07.1992.

Hello,

I am working at CARTES (Computer Arts Centre at Espoo, Finland) on computer
music applications of digital signal processing. I am using MACL 2.0b1. I
would like to use the MIDI Manager services from my own program (reading
MIDI data from other applications, mainly). I found the trap definitions in
the Library:Interfaces folder, but I could not make them work. I'd need
some documentation about the MIDI Manager calls and the meaning of the
parameters, and if someone has used the MACL interface, I'd be very
thankful, if he shared his experiences with me.

I am not subscribed to the list, so please send your answers to the address
given below.

Thank you in advance,

Bye.

Zoltan Janosy
CARTES, Finland

e-mail: vpv@vipunen.hut.fi (c/o Vesa Valimaki)
From: markt@dgp.toronto.edu ("Mark A. Tapia")
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Trying to resize PICT using GWorlds (fwd)
Date: 31 Jul 92 01:05:13 GMT
Original-To: info-mcl-request@cambridge.apple.com
Original-Cc: info-mcl@cambridge.apple.com

Marty Kenner (makenner@mmm.com) writes about problems creating a picture:
 I am again (still?) working on an application making heavy use of PICTs
 and I need to be able to scale a PICT and write it to a file.

  I was trying to do what I do in C -
 
        get source picture from file
        create an offscreen GWorld
        lock its pixels
        cliprect the target rectangle
        draw the source PICT into the target rectangle
        open a new PICT
        copybits the pixmap of the offscreen GWorld onto itself
        close the new PICT and write to file
  ...
  with the result that the picture is damaged and contains garbage 
  (unimplemented commands).

He then mentions that he uses the oodles of utils calls to create the
GWorld and using the call to copy bits.

One solution is to use the pict-svm and resource-svm methods for drawing
scaled versions of pictures (and pict resources).  The code is in oodles-of
utils in the mixin-madness in simple-view-mixins. Another way is to
use the following steps:
	get source picture from file
	cliprect the target rectangle
	create a picture:
	  #_openPicture (with the appropriate rect)
	  #_drawPicture (with the appropriate rect for scaling)
	  #_closePicture
	  return the resulting picture
        write the picture to the file
The resulting picture is a true picture with all of the calls in
place. If you're picture is color you'll have to use the correct
color "window". For an example of a program that saves and restores
portions of the screen bit map, see menu-enhancements.hqx (in
the contrib directory) which contains oou-utils.lisp.

mark
From: djskrien@COLBY.EDU (Dale Skrien)
Newsgroups: comp.lang.lisp.mcl
Subject: ff interface question
Date: 30 Jul 92 16:22:13 GMT
Original-To: info-mcl@cambridge.apple.com

We are currently working on implementing connections from MCL 2.0 to
Digidesign's Motorola 56000-based DSP card and have written a number of
functions in MPW to handle the communication with the card.  We are calling
these functions via MCL's foreign function interface.  At present, we don't
seem to be able to figure out any way to create MCL readable object files
that link MPW library functions with our own code.  As a result, it appears
that we will need to include all relevant MPW library files with whatever
code we distribute (we are planning to distribute our MPW code free of
charge with the code of the lisp environment we've created). Is there any
way around this?

please reply to either jfhallst@colby.edu or djskrien@colby.edu

Thanks!
 
Newsgroups: comp.lang.lisp.mcl
From: Steve Wart <swart@prodigy.bc.ca>
Subject: International Utilities Problems
Organization: PTC Vancouver
X-Useragent: Nuntius v1.0
Date: Mon, 27 Jul 1992 19:12:29 GMT


[Excuse me if this is a repost, but our news server went down during my
first attempt...]

I've been trying to write a function that will display the current date
in one of
three optional formats (the same as those returned by the International
Utilities
function, IUDatePString, in fact).  The following bits of code represent
my attempts
so far:

  ;;
  ;;  The constants $shortDate, $longDate and $abbrevDate are not defined
  ;;  in packages.lisp.

(defconstant $shortDate 0)
(defconstant $longDate 1)
(defconstant $abbrevDate 2)

(defun secs2date (seconds &optional (date-format $shortDate))
  ;;
  ;;  Return a string representing the date of the argument, as specified
  ;;  by the parameter, seconds.  The optional parameter, format, can be
  ;;  given as $shortDate, $longDate, or $abbrevDate, with the default
being
  ;;  $shortDate.
  ;;
  (let ((intlH (#_IUGetIntl (cond ((eql date-format $shortDate) 0)
                                  ((eql date-format $longDate) 1)
                                  ((eql date-format $abbrevDate) 1)
                                  (t (error "Invalid date format: ~S"
date-format))))))
    (with-returned-pstrs ((date-string ""))
      (unwind-protect
        (progn
          (#_IUDatePString seconds date-format date-string intlH)
          (%get-string date-string))
        (#_ReleaseResource intlH)))))

(defun show-date (&optional (date-format $shortDate))
  (let ((s (#_NewPtr 4)))
    (unwind-protect
      (progn
        (#_ReadDateTime s)
        (secs2date (%get-long s) date-format))
      (#_DisposPtr s))))

The problem is that while (show-date $shortDate) returns the expected
result of
"7/27/92", (show-date $longDate) and (show-date $abbrevDate) both return
the
string "72792", not exactly what I had in mind.  Furthermore, when I
change the
dateOrder field in the Intl0Rec to specify ydm, it still returns the
string in
the order dmy.

The _IUTimePString trap works as advertised, but the date routine is
driving me
up a wall.  Does anyone have any idea what the problem is?

Steve Wart
PTC, Vancouver
swart@prodigy.bc.ca
(604) 687-4636
From: wilcox@cmns.think.com
Newsgroups: comp.lang.lisp.mcl
Subject: Need help on MIDI Manager programming
Date: 21 Jul 92 12:13:16 GMT
Original-To: vpv@vipunen.hut.fi
Original-Cc: info-macl@cambridge.apple.com

I am interested in replies to this query as well. Perhaps MIDI is a topic
of wide enough interest that responses could be posted to info-mcl.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: window-hardcopy for fred dialog items
Date: 31 Jul 92 17:36:45 GMT
Full-Name: Bill St. Clair
Original-To: djskrien@COLBY.EDU (Dale Skrien)
Original-Cc: info-mcl

>On page 493 in the manual for MCL 2.0 final, it says that window-hardcopy
>works for Fred windows or Fred dialog items.  However, when I create a
>window with a scrolling-fred-dialog-item (which I assign to a variable x)
>and then call
>  (window-hardcopy x)
>I get an error message:  "No applicable method for args:
>(#<ccl::scrolling-fred-dialog-item #x51E179>) to
>#<standard-generic-function window-hardcopy #x47A396>."
>
>Am I doing something wrong?

As Alice said, window-hardcopy works only for fred-windows.

I have made a patch that makes it work for fred-dialog-items as well.
Ask and I'll send it to you. This patch will probably be part of patch
2 for MCL 2.0 (patch 1 is being beta tested as we speak, er, write).
From: gw@dsl.pitt.edu (gerhard werner)
Newsgroups: comp.lang.lisp.mcl
Subject: advise please
Date: 31 Jul 92 18:21:45 GMT
Original-To: info-mcl@cambridge.apple.com

This is probably so trivial a question that I am embarrassed to ask 
it, but I am stuck: how can one refer to and access an instance of 
an object by creating its name inside a program ? I thought of 
using a format expression which composes the name, but this 
does not work. Any guidance available ?

Thank you. Gerhard Werner.
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: Loading Resources and Xcmd or Xfunction
Date: 26 Jul 92 23:06:05 GMT
Full-Name: Steve Strassmann
Original-To: cchien@gmuvax2.gmu.edu (Chang-Hong Chien)
Original-Cc: info-mcl

>Date: Fri, 24 Jul 92 03:10:10 -0400
>From: cchien@gmuvax2.gmu.edu (Chang-Hong Chien)
>To: info-mcl@cambridge.apple.com
>Subject: Loading Resources and Xcmd or Xfunction
>
>HI.
>Do any one know how to load resouces into lisp programs ?
>Also, Specificly, how it works with Xcmd and Xfunction.
>
>I appreciate any suggestion.
>
>						-Chien


Functions for loading resources are provided in resources.lisp
in the library folder.

Functions for using Hypercard xcmds are in xcmds.lisp,
which is available by ftp from cambridge.apple.com and is
included on the MCL 2.0 cd-rom.
From: aro@aber.ac.uk (Andy Ormsby)
Newsgroups: comp.lang.lisp.mcl
Subject: MCL 2.0 final. When?
Date: 22 Jul 92 10:58:43 GMT
Reply-To: aro@aber.ac.uk (Andrew Ormsby)
Organization: Computer Science Dept. University College of Wales, Aberystwyth

Whatever happened to MCL 2.0 final?  Is it still arriving RSN or has
something bad happenend. Does anyone have it yet? When can I expect
it?

--
Andy Ormsby, aro@aber.ac.uk
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Buffer bug?
Date: 21 Jul 92 14:22:06 GMT
Original-To: info-macl@cambridge.apple.com

>    ? 
>    Buffer #<BUFFER-MARK 0/119> has 119 chars, which are: 
                         ^^^
>    'This )) is (people person 1) bad too.
>    ;This (( is a ) bad ( string, no?
>    ;This is a nice string (people person 1), yes?
>    '.
>    ((IS A) (PEOPLE PERSON 1))          ;correct result
>    ? 
>|#
>
>
>;;;
>;;; Test2: Evaluate following form:
>;;;
>#|
>(let ((buffer (make-buffer)))
>  (buffer-insert buffer "This )) is (people person 1) bad too.
>;This (( is a ) bad ( string, no?
>;This is a nice string (people person 1), yes?
>")
>  (l-lists-in-buffer buffer))
>|#
>;;;
>;;; The result this time was different and *wrong* IMHO:
>;;;
>#|
>? 
>    Buffer #<BUFFER-MARK 119/119> has 119 chars, which are: 
                          ^^^
>    'This )) is (people person 1) bad too.
>    ;This (( is a ) bad ( string, no?
>    ;This is a nice string (people person 1), yes?
>    '.
>    NIL                                 ;*wrong* result!
>    ? 
>|#

buffer-insert apparently destructively modifies its buffer argument to be
at the end of the insert.  [Note the difference in the print-string of the
buffer mark in the two tests.]  While you explicitly use the number 0 and
the buffer size to get all the text in your call to buffer-substring, you
do not do so in your call to buffer-current-sexp.

If you make a new buffer mark at 0 and use *that* in your iteration, you
will almost certainly get the desired results.

Whether buffer-insert *should* or should not modify its buffer argument is
something you will have to take up with the MCL team.  IMHO, it could be
quite useful information to have returned in the modified buffer-mark.

Disclaimer:  I'm making this answer up based just on output and looking at
your code and have little actual experience with buffers and buffer-insert.
"TANSTAAFL" Rich lynch@ils.nwu.edu
From: davew@atqm.advtech.uswest.com ("Dave Wroblewski")
Newsgroups: comp.lang.lisp.mcl
Subject: Typo in mac-file-io.lisp?
Date: 23 Jul 92 08:13:22 GMT
Original-To: info-mcl@cambridge.apple.com


                      Typo in mac-file-io.lisp?
I was trying to work through Bill St. Clair's "my-copy-file" example today in
order
to understand the mac-file-io.lisp code in the Examples folder. Unhappily, it
kept
bombing with error -50 ("parameter error"). 

I found the following lines in the middle of the function FSOpen in
mac-file-io.lisp:

              (%put-long paramBlock 0  $ioPosOffset)
              (%put-word paramBlock $fsAtMark $ioPosOffset)
  
which seemed incorrect, since they simply set the same field to different
values.
I changed them to the following which seems to remove the problem, at least for
Bill's example function:

              (%put-long paramBlock 0 $ioPosOffset)
              (%put-word paramBlock $fsAtMark $ioPosMode)

Was this truly a typo, or is there some incredible subtlety that I am missing?
Also, if this was a known bug, where should I have looked to find it out? I
have 
been reading this mailing list for a month or two and haven't seen any bug
reports
about this...

-David Wroblewski
U S WEST Advanced Technologies
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: Error in my tiny test program
Date: 25 Jul 92 23:19:16 GMT
Full-Name: Steve Strassmann
Original-To: cchien@gmuvax2.gmu.edu (Chang-Hong Chien)
Original-Cc: info-mcl

>From: cchien@gmuvax2.gmu.edu (Chang-Hong Chien)
>Message-Id: <9207250911.AA14774@gmuvax2.gmu.edu>
>To: info-mcl@cambridge.apple.com
>Subject: Error in my tiny test program
>
>Hi, Do anyone can help me to figure out what's wrong in my program.
>The program use the trap _paintroundrect. 
>I try to pass three variables, *height*, *v* and *h* to trap.
>Is there something I miss in this program ?
>
>The source code is :
>;;; "Drop a ball"
>
>(defparameter *w* (make-instance 'window))
>(defvar *v* 1)(defvar *h* 1)(defvar *height* 20)
>(defun visiable() (set-fore-color *w* *red-color*))
>(defun invisiable() (set-fore-color *w* *blue-color*))
>(while (not(< *height* 120))
>(If (oddp *h*) (visiable) (invisiable))
>(rlet((r :rect :top (+ 20 *V*) :left (+ 20 *h*):bottom (+ 30 *V*) :right (+ 30 *h*)))
>          (with-focused-view *w*
>            (#_paintroundrect r 130 130)))
>(setf *v* (+ *v* 31) *h* (+ *h* 51) init-height (+ init-height *v*)))
>(setf init-height 20)
>
>Ps. IN last 5th line at the end is ":right (+ 30 *h*)))
>
>Thanks advance for helping.
>							-Chien
>
>

Here's some code that does what I think you were trying to do...
Some tips:
 1) Try to use local variable (using LET) instead of lots of
    global variables.
 2) Create a function (DROP-BALL) that you can debug, instead 
    of trying to write your code at top level.
 3) I think the NOT in your WHILE test was the culprit here.
 4) You can also use (INCF var amount) instead of
    (SETF var (+ var amount))
 5) Use the indenting features of FRED to make your code more
    readable (use the Tab key and ctrl-option-q)
 6) Use comments to make your code more understandable.
 

;------------
(defparameter *window* (make-instance 'window))

(defun visible (window)
  (set-fore-color window *red-color*))

(defun invisible (window)
  (set-fore-color window *blue-color*))

(defun drop-ball (&optional (window *window*))
  (let ((v 1)               ; vertical position
        (h 1)               ; horizontal position
        (size 10)           ; size of ball
        (height 20))        ; initial height of ball
    (while (< height 120)
      (if (oddp h) 
        (visible window)
        (invisible window))
      (paint-oval window h v (+ h size) (+ v size))
      (setf v (+ v 3) 
            h (+ h 5)
            height (+ height v)))))