HDTenEightyP/NetNews huggingface dataset:
From: wilcox@cmns.think.com
Newsgroups: comp.lang.lisp.mcl
Subject: _numtostring
Date: 14 Aug 92 21:45:10 GMT
Original-To: berger@soe.berkeley.edu
Original-Cc: info-mcl@cambridge.apple.com

I found a couple of bugs in the function float-to-string that I sent out
earlier. Specifically, it did not work well for negative numbers or numbers
which were slightly less than integers. Here's a revised version:

;;; this function needs a better name
(defun round-significand (number fractional-digits)
  "Round the significand for display."
  (if fractional-digits
    (let ((divisor (expt 10 (- fractional-digits))))
      (* (round number divisor) divisor))
    (values number)
    ))

;;; this is a fast alternative to format for floating-point numbers
;;; with no exponent
(defun float-to-string (number fractional-digits)
  "Converts a floating-point number to a string, ~
   with a given number of digits following the decimal point."
  (multiple-value-bind (integral fractional)
                       (truncate (round-significand number fractional-digits))
    (let ((int-string (integer-to-string integral)))
      ;; dont mess around with fractions if you dont have to
      (if (zerop fractional-digits)
        (concatenate 'string int-string ".")
        (let* ((fract-int (* (expt 10 fractional-digits)
                             ;; use abs because truncate signs the remainder
                             (abs fractional)))
               (fract-string (integer-to-string fract-int))
               ;; pad fraction with enough zeros to separate it from decimal
               (pad-string (make-string (- fractional-digits (length fract-string))
                                        :initial-element #\0)))
          (concatenate 'string int-string "." pad-string fract-string)
          )))))
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: cell-select in sequence-dialog-items
Date: 20 Aug 92 19:42:15 GMT
Original-To: info-mcl@cambridge.apple.com

>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)

A very common gotcha.

Unfortunately, this has been true and known to the MCL developers since AT
LEAST MACL 1.3.2.  My advice is to just go ahead and bastardize
view-click-event- handler...

UNLESS you think you really are going to use program action to select or
deselect cells.  At that point, believe me, you are better off writing your
own sequence-dialog-item.  Unfortunately, I did it the other way and regret
it every time something comes up that has to be changed for the classes
involved.

WARNING:  There are *other* methods that are for "external use only".  A
colleague claims to have seen some sort of indication as to which were
which in the documentation at some time, but I make no claims as to the
truth-value of this statement as I avoid reading docs as much as possible. 
:-)

I am unsure at this point which methods these are, but I seem to recall
having serious fights with:

cell-select/cell-deselect (problems you noted above.)
cell-position (I wanted to draw a deck of cards in fan-fold;  should be
simple)
cell-size?  (I'll be damned if I can remember how this screwed up.)
view-[de]activate-event-handler
(it frames[inverts] the rect of the selected cells;  I contend that should
be
 done by draw-cell-contents for modularity.)
view-click-event-handler or cell-select also call invert-rect directly on
the "internal double-secret" versions of cell-position and cell-size. 
Thus, if you want custom drawing of a sequence-dialog-item, you're in for a
real interesting time.

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.

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.
 
"TANSTAAFL" Rich lynch@ils.nwu.edu
From: Thomas_E_Morgan@cup.portal.com
Newsgroups: comp.lang.lisp.mcl
Subject: MCL 2.0 a
Date: 15 Aug 92 02:13:16 GMT
Distribution: usa
Organization: The Portal System (TM)

I need more of the MOP than MCL 2.0 can be made to provide, 
and can't run 1.3.2.
  
Before I go out and get myself a new machine and a new LISP, I 
thought to  try and get PCL to run under 2.0.

I've made a number of easy to figure out changes, 
but am now up to the part where PCL needs implementation
specific support for funcallable instances.

I've looked at the uuvector discussion in the reference and at the 
additional sources on the CD, but haven't found enough info to 
revise the low level functions to support funcallable instances.  
Basically, I need to be able to be able to tell that something I can 
funcall is a funcallable instance, and to be able to replace 
the value of the function, while preserving 'eqness'  of the 
funcallable instance.  Anybody know how?

Failing that, it occurs to me I might be able to use the MCL 
funcallable CLOS objects, to hold up the PCL equivalent.

To make that work, I'd need to know how to change the value of the 
function that MCL keeps for a funcallable instance.

Any advice or good counsel?

   ...Tom M
From: frege@eecs.umich.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Function CCL::STRUCTURE-SLOT-NAMES undefined.
Date: 13 Aug 92 15:14:09 GMT
Original-To: bill@cambridge.apple.com
Original-Cc: info-mcl@cambridge.apple.com

Thanks for the code. I will try working with it.

- Young-pa So
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Interfacing to I/O boards
Date: 13 Aug 92 17:04:11 GMT
Full-Name: Bill St. Clair
Original-To: John Doleac <jd05@gte.com>
Original-Cc: info-mcl

>I am using GW's MacADIOS I/O board to interface to sensors and 
>motors which are part of a control algorithm testbed.  I want to 
>call C functions compiled using Symantec's Think C development
>system.  These C functions are used to get data from sensors and
>to give commands to motors.
>
>The manual tells how to use foreign function calls for code
>compiled by MPW.  This does not work for Think C.  Can anyone
>recommend a way to overcome this problem?
>
>I asked this question at MacWorld last week in Boston.  No one in 
>the Apple booth knew much about LISP nor could they provide
>any recommendations for hardware interfaces for this kind of
>application.  The most consistent recommendation I got for 
>interfacing to sensors and motors from a mac was to use a 
>serial connection to a PC outfitted with a good I/O board.  The
>PC could be used as a co-processor.
>
>If using a serial connection to a PC is a good solution, can 
>anyone recommend examples of protocols I can use?

Straz told you about Guillaume Cartier's package.
I have a few more comments.

I see no reason to use a PC as a co-processor unless your real-time
constraints are such that one processor cannot handle the load.
In this case, you'll need the PC to do more than toggle bits on an
interface card. You've already said you have an I/O board that does the
job, Why buy another computer?

Depending on the size of the Think C functions that interface to
the I/O board, you may be able to recode them in MCL rather than
using them directly. MCL's memory referencing code is not quite
as fast as Think C's, but you'll probably make up for the speed
difference by eliminating the cross-language calls (not that speed
is an issue here: we're talking about differences in microseconds,
and motors only notice differences in milliseconds).

Of course, if your Think C code is large, then recoding will not be
cost-efficient, and you'll want to use Guillaume Cartier's package.

It's very likely that your real-time constraints will be such that
you can't afford to wait for MCL to garbage collect. You'll need to
be careful from the beginning to write code that does not cons.
Peter Norvig's book, "Paradigms of Artificial Intelligence Programming",
has a short section about this, and people on info-mcl can help you
with specifics as they arise. Ashok Khosla has been writing a paper
about optimization techniques for Lisp in general and MCL in particular,
which he should be posting soon. It includes information on where
DYNAMIC-EXTENT declarations will prevent heap consing in MCL.

Enjoy!

-Bill
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Apply
Date: 12 Aug 92 16:40:11 GMT
Full-Name: Bill St. Clair
Original-To: Denis R Howlett <drh@world.std.com>
Original-Cc: info-mcl

>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? ...

It IS bad form to use EVAL. You should realize that by saying
(apply '(lambda (...) ...) ...), you were implicitly calling EVAL
(or COMPILE). Closures will often solve your problem:

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

Then you can leave your dispatching code as (funcall attached-function window).
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Is this a bug or am I just not understanding applying Wood?
Date: 13 Aug 92 17:23:30 GMT
Full-Name: Bill St. Clair
Original-To: cornell@freya.cs.umass.edu
Original-Cc: info-mcl

>Bill: I think the definition of set-slot-value-in-both-worlds
>(repeated below) is buggy. I'm pretty sure the second WHEN should use
>slot-value, not p-slot-value. (P-slot-value does nothing if its arg is
>not a pptr).
>
>matt
>
>    (defun wood::set-slot-value-in-both-worlds (pheap instance slot-name value)
>      (let ((in-memory (wood::in-memory-p instance))
>	    (on-disk (wood::on-disk-p pheap instance)))
>	(when on-disk
>	  (setf (p-slot-value on-disk slot-name) value))
>	(when in-memory
>	  (setf (p-slot-value in-memory slot-name) value))) ;should be slot-value
>      value)

You're right, though this code should work since (setf p-slot-value)
simply calls (setf slot-value) if the instance is not a PPTR.

Well, that's what it was supposed to do, but (setf p-slot-value)
had a bug as well. Here's a patch:

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

; setf-p-slot-value-patch.lisp
;
; (setf (p-slot-value instance slot) value)
; now calls (setf slot-value) when instance is not a PPTR.

(in-package :wood)

(let ((*warn-if-redefine* nil))

(defun (setf p-slot-value) (value p slot-name)
  (if (pptr-p p)
    (let* ((pheap (pptr-pheap p))
           (disk-cache (pheap-disk-cache pheap))
           (pointer (pptr-pointer p)))
      (multiple-value-bind (slots index)
                           (dc-%slot-vector-and-index disk-cache pointer slot-name)
        (unless slots
          (dc-slot-missing disk-cache pointer slot-name '(setf p-slot-value)))
        (multiple-value-bind (v imm?) (%p-store pheap value)
          (setf (dc-%svref disk-cache slots index imm?) v)
          (if imm?
            v
            (pptr pheap v)))))
    (setf (slot-value p slot-name) value)))

)
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: init file
Date: 13 Aug 92 19:17:58 GMT
Original-To: info-mcl@cambridge.apple.com (Macintosh Common Lisp)

>GatorMail-Q                   init file
>MCL question/problem:
>
>When I start up MCL 2.0 by double-clicking the application icon, the init.lisp
>file does not automatically load like the documentation says it should.
>
>I also had this problem with MCL 2.0b1 but I thought it was just a early
>release bug. To fix it I put a function on the *lisp-startup-functions* list to
>load the init file and then saved the image.
>
>Is there something I could be doing wrong, or is this the way it is for some 
>reason?
>
>Keith Diefendorff
>email:      keithd@oakhill.sps.mot.com
>Applelink:  MOT.KD
>phone:      512-891-3219
>fax:        512-891-3818

If you use SAVE-APPLICATION to save the state of a running MCL
application, you have to be aware that it takes a keyword argument
named :INIT-FILE which defaults to NIL (meaning don't load any
init file).

What you want is probably:
(SAVE-APPLICATION "FooBar" :init-file "init").

Signed:
The SAVE-APPLICATION specialist! :-)

*********************************************************************
* 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: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: BUG:  Second sequence doesn't scroll
Date: 17 Aug 92 19:52:55 GMT
Original-To: info-mcl@cambridge.apple.com

Anybody remember a bug where the second of two sequence-dialog-items in
different sub-views of a window wouldn't scroll?

This is in 2.0 final, but maybe I missed a patch...

Demo of bug:

(make-instance 'dialog
  :window-title "Try the far right scroll bar."
  :view-subviews
  (list
    (make-instance 'view
      :view-position #@(4 4)
      :view-subviews
      (list (make-instance 'sequence-dialog-item 
              :view-size #@(30 60)
              :table-hscrollp nil
              :table-sequence '(1 2 3 4 5 6))))
    (make-instance 'view
      :view-position #@(50 4)
      :view-subviews
      (list (make-instance 'sequence-dialog-item
              :view-size #@(30 60)
              :table-hscrollp nil
              :table-sequence '(1 2 3 4 5 6))))))

#|
'Case it's relevant:
  Quadra 700,
  System 7.0.1  ,
  with Tune-Up ^(or is that what that option-8 dot means?)
  Inits:
    MacTCP
    SuperClock
    Remote
|#
"TANSTAAFL" Rich lynch@ils.nwu.edu
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: delistifying lists...
Date: 17 Aug 92 20:09:04 GMT
Full-Name: Steve Strassmann
Original-To: Luke Hohmann <hohmann@csmil.umich.edu>
Original-Cc: info-mcl

>Date: Mon, 17 Aug 92 07:49:04 -0400
>From: Luke Hohmann <hohmann@csmil.umich.edu>
>To: info-macl@cambridge.apple.com
>Subject: delistifying lists...
>
>
>I needed a function to "delistofy" lists. Here is the function I wrote
>and some sample runs. My question to you is: can you submit a faster/better/
>cleaner/more robust version of this function? THANKS!
>
>? (defun delistify (l)
>  (cond ((null l) nil)
>        ((atom l) l)
>        ((listp (car l))
>         (delistify (append (car l) (cdr l))))
>        (t
>         (cons (delistify (car l))
>               (delistify (cdr l))))))
>
>delistify
>? (delistify '(1 2 3))
>(1 2 3)
>? (delistify '((1 2 3) 4 5 6))
>(1 2 3 4 5 6)
>? (delistify '(1 2 3 (4 5 6)))
>(1 2 3 4 5 6)
>? (delistify '((1 2 3) 4 5 6 ((7 8 9))))
>(1 2 3 4 5 6 7 8 9)
>? 
>
>  -- Luke

 This is called "flatten" in most lisp textbooks. There's an excellent
discussion in Norvig's "Paradigms of AI Programming" (chapter 10.4,
page 328) of why the APPEND version is inefficient.

Here's what most people will write. Due to the APPEND (which
always copies its first arg) it can cons O(N^2) cells on
an input with N atoms.

(defun flatten (input)
  (cond ((null input) nil)
        ((atom input) (list input))
        (t (append (flatten (first input))
                   (flatten (rest input))))))


Here's a more efficient version:

(defun flatten (input &optional accumulator)
  (cond ((null input) accumulator)
        ((atom input) (cons input accumulator))
        (t (flatten (first input)
                    (flatten (rest input) accumulator)))))
From: crawford@cs.uchicago.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Is AutoDoubler OK with MCL?
Date: 15 Aug 92 04:42:33 GMT
Distribution: na
Organization: University of Chicago  AI Lab

In article <199208040848.AA11748@halcyon.com> jwbaxter@halcyon.halcyon.com
writes:
>
>    In the info-mcl archives on the MCL 2.0 CD was an unanswered (by the
>end of the archive period) question about whether AutoDoubler is safe to
>use with MCL.  By definition, older versions of both MCL and AutoDoubler
>were involved in the query.  At the moment, I have the MCL application
>marked "Do Not Compress", but I'm letting AutoDoubler compress everything
>else in the MCL folder.
>    Are there any known conflicts between AutoDoubler (1.0.7) and MCL (2.0
>Final)?  Thanks.
>
>--------------
>John W. Baxter   jwbaxter@halcyon.com   My incorrect opinions are my
>own...someone else probably supplied my one correct opinion.
>I'd really rather be sailing.
>

I'm not experiencing any conflicts at all with having AD 1.0.7 compress
everything in the MCL 2.0-Final folder.  The application runs normally, the
Help-map works, and opening and loading files works fine.  (I used to have
problems only with the earlier patches/betas, especially 2.0b1p3).  BTW, I'm
running on a IIci with System 7.0 w/ Tune-Up 1.1.1, along with several cdevs
and extensions.

Paul
From: frege@eecs.umich.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Function CCL::STRUCTURE-SLOT-NAMES undefined.
Date: 12 Aug 92 15:00:55 GMT
Original-To: info-macl@cambridge.apple.com


When apropos'd STRUCTURE-SLOT-NAMES exists in COMMON-LISP-USER package.
However, I can't use it in MCL 2.0. How do I access the function?

- Young-pa So
  EECS Dept.
  The University of Michigan
  (frege@crim.eecs.umich.edu)
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: using Sequence-dialog-items
Date: 13 Aug 92 19:47:47 GMT
Original-To: info-mcl@cambridge.apple.com (Macintosh Common Lisp)

>I have a quick question, I'm trying to use a "sequence-dialog-item"
>(as provided by the Interface Tool's palette).  The problem comes
>when I try to figure out which cell the user has clicked in (i.e. 
>which cell is selected).  While some of the table-dialog-item's 
>methods work for this class (i.e. table-dimensions), other very
>important ones (such as  cell-select, cell-selected-p, and 
>cell-deselect) don't.  Although the docs indicate that this 
>class is derived from table-dimensions, I can't figure out an 
>easy way to query it to find which item is selected (let alone
>responding to a double click)
>
>      Jeffrey

The method you need are:

SELECTED-CELLS     (page 232)
DIALOG-ITEM-ACTION (page 194)
DOUBLE-CLICK-P     (page 392)

*********************************************************************
* 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: ppm1@cec2.wustl.edu (T. Paul McCartney)
Newsgroups: comp.lang.lisp.mcl
Subject: Packages & Performance
Date: 21 Aug 92 21:58:14 GMT
Return-Path: <ppm1@cec2.wustl.edu>
Original-To: info-mcl@cambridge.apple.com


Today, I encountered an unusual performance difference in my program due to
packages.  I'm not sure why, and I was hoping someone could explain it to me:

My program has two packages, call them A and B.  The actual code that I ran
existed in package A.  I have been running the code in package A from a single
function call in package B.

Now the weird part.  When I have the Listener in package B (i.e. by typing
and entering (in-package :B)), my program takes a certain amount of time
to run.  When I have the Listener in package A, the program only takes
62% of the time than before.  This is obviously highly significant.

The program in package A does use about a dozen symbols from package B, but
not in a major way.  Other than that, there is no communication between them.

Thanks,

- Paul
From: Jim.Redelfs@macnet.omahug.org (Jim Redelfs)
Newsgroups: comp.lang.lisp.mcl
Subject: Comp.Lang.Lisp.Mcl Message Area
Date: 20 Aug 92 17:29:56 CST
Reply-To: jim.redelfs@macnet.omahug.org
Organization: Macnet Omaha
Followup-To: comp.lang.lisp.mcl

  
This is the "Comp.Lang.Lisp.Mcl" message area.  Please confine discussion to
Macintosh LISP topics.

Messages in this area are relayed to numerous other systems.

Observe the numbers in the upper-left corner.  The FIRST number indicates the
current message.  The second number indicates the HIGHEST (last) message
available in this area.  If you would like to catch-up to the LAST message
available, enter its number at the next prompt.

MacNet Omaha Subscribers may post messages here and are encouraged to do so!

JR                              Jim Redelfs
                              System Operator
From: nrb!keunen@relay.EU.net (Vincent Keunen)
Newsgroups: comp.lang.lisp.mcl
Subject: double messages
Date: 12 Aug 92 07:42:00 GMT
Reply-To: nrb!keunen@relay.EU.net
Original-To: info-mcl@nrbmi2.ia.nrb.be


    Date: Tue, 11 Aug 1992 05:19+0200
    From: sdobbs@trivia.coginst.uwf.edu

    Is anyone else getting all messages from info-mcl twice?  For the last 2
    days I have received duplicates of all messages.  Is there a problem
    somewhere?

Actually I do.  I didn't notice very quickly because my Symbolics
MacIvory's mailer automatically deletes duplicate messages upon arriving
in my reader... I love that Genera stuff...

vk
===============================================================
Keunen Vincent                  Network Research Belgium
R&D, Software Engineer          Parc Industriel des Hauts-Sarts
keunen@nrb.be                   2e Avenue, 65
tel: +32 41 407282              B-4040 Herstal
fax: +32 41 481170              BELGIUM
===============================================================