HDTenEightyP/NetNews huggingface dataset:
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: shiftf
Date: 27 Jan 93 19:51:42 GMT

At 11:31 1/27/93 +0017, Kim Barrett wrote:
>> MCL's shiftf macro produces unneccesary complicated form in the simple
>> cases.  The most frequent use of shift, is probably for simple pointer
>> switching in list structures: Replacing a value while saving the old
>> value.  (The two-argument (place, newvalue) special case of shiftf used
>> to have its own name, swapf)
>> 
>> Here's what MCL's shiftf produces:
>> ? (macroexpand '(shiftf (cddr liste) nil))
>> (LET* ((#:G91 LISTE) 
>>        (#:G89 (MULTIPLE-VALUE-LIST (CDDR #:G91)))) 
>>   (DECLARE (DYNAMIC-EXTENT #:G89)) 
>>   (MULTIPLE-VALUE-BIND (#:G90) NIL 
>>     (PROGN (CCL::SET-CDDR #:G91 #:G90))) 
>>   (VALUES-LIST #:G89))
>> 
>> Here's a simpler expansion suggestion (Allegro 4.1 produces something
>> similar to this):
>> (LET* ((#:G91 LISTE) 
>>        (#:G89 (CDDR #:G91))
>>        (#:G90 NIL))
>>   (CCL::SET-CDDR #:G91 #:G90)
>>   #:G89)
>
>You didn't mention which version of MCL you are using.  SETF and related macros 
>had a lot of work done on them not too long ago.  In MCL2.0p2 (and probably in 
>MCL2.0, but p2 is what I've got in front of me right now) the expansion is
>
>(LET* ((#:G30466 LISTE))
>  (MULTIPLE-VALUE-PROG1 (CDDR #:G30466)
>    (MULTIPLE-VALUE-BIND (#:G30465)
>        NIL
>      (PROGN (SET-CDDR #:G30466 #:G30465)))))
>
>The MULTIPLE-VALUE-BIND with a single variable is trivially transformed into a 
>LET.  If the compiler handling for MULTIPLE-VALUE-PROG! recognizes that CDDR 
>always returns one value and makes the obvious transformation, then compiling 
>this expansion should produce the same code as your simpler expansion, without 
>requiring that the SHIFTF macro (and presumably lots of other similar macros) 
>itself try to optimize the expansion.  The reason for all the 
>multiple-value-mumbles in the expansion is to support multiple-valued place 
>forms (see X3J13 issue SETF-MULTIPLE-STORE-VARIABLES).  Rather than try to make 
>the macros optimize this stuff, its much better to make the compiler smart 
>about some of these special cases where multiple value forms can be transformed 
>into single value forms.  Unfortunately, the compiler doesn't currently seem to 
>know about CDDR being single valued, so things could be a bit better.  But the 
>"bug" is there, not in SHIFTF.

Unpatched MCL 2.0 produces the expansion to which Espen referred. Patch 2
modifies SHIFTF & ROTATEF to produce Kim's better code. Mark announced how to
get patch 2 about a month ago. Ask and I'll resend. I have prepared a patch that
makes the compiler a little bit smarter about turning MULTIPLE-VALUE-PROG1 into
PROG1. In particular, it makes the patch 2 expansion for (shift (cddr liste) nil)
compile into the same code as the Allegro 4.1 expansion. Ask for
"single-value-prog1-patch".
Newsgroups: comp.lang.lisp.mcl
From: gersh@aplpy.jhuapl.edu (John R. Gersh)
Subject: Setting dialog item body color
Keywords: color, check-box, radio-button
Organization: Johns Hopkins University Applied Physics Lab
Date: Wed, 20 Jan 93 21:22:46 GMT



How can one set the body color of a check-box or radio-button dialog item?
(For example, if you want it to look reasonable in a dialog with a
background color.)

(set-part-color <item> :body <new-color>) or initializing with the
equivalent part-color-list has no effect in this case; no matter what you
do, the item keeps a white body color.

I poked around a bit around with ccl::set-control-part-color and
ccl::table-color. It appears that the control color-table is being set
properly, but this doesn't affect the way check-boxes and radio-buttons are
drawn. (Things work just fine in setting text and frame colors.) IM V has a
nice color plate that shows radio buttons and check-boxes with body colors
that match a dialog's background, so it ought to be possible.

What gives? Is there a way to do this? (I've worked out an awfullly kludgy
work-around involving a view-draw-contents that paints the dialog-item and
then calls #_TrackControl to redo the text and frame, but this is only
partially effective for radio-buttons, and there _must_ be a better way.)

[Note: This question was asked in this forum last summer by someone else.
I've searched the mail archives and checked with the original questioner -
it seems never to have been answered.]



---------------------------------------------------------------------
John Gersh                                      John_Gersh@jhuapl.edu
The Johns Hopkins University Applied Physics Laboratory
Johns Hopkins Rd., Laurel, MD 20723		       (301) 953-5503
From: markt@dgp.toronto.edu ("Mark A. Tapia")
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Measuring elapsed CPU time
Date: 21 Jan 93 14:37:15 GMT

On Thu Jan 21 05:07:05 1993, Joung-woo John Kim (joungwoo@mensa.usc.edu)
writes:
   I'm trying to measure teh elasped CPU time during a lisp form has been run.
   ...
   So I tried using builtin function GET-INTERNAL-RUN-TIME as follows,
   but the following function defined by me usually it gives me either 0 or 1 no
   matter how time-consuming task I give it.
John then describes a function of the form:
   (defun CPU-time (form)
   ...
   )
The problem is that the form is evaluated before the body of the
CPU-time function is invoked. If you want to time a function,
you need to convert your function to a macro. The following
macro does what you want


	    
;; monitoring routines for timing
;; execute the form ntimes and give the title to it
(defpackage :timing (:use "COMMON-LISP" "CCL"))
(in-package :timing)

;; Execute form ntimes, optionally garbage collect (:gc t),
;; optionally prints the statistics (:print t), and
;; returns the following values and optionally prints them
;;     title
;;     number of times the form was executed
;;     total cpu time
;;     cpu time less gc time
;;     total gc time
;;     ephemeral gc time
(defmacro form-stats (title form  &key (ntimes 1) (print t) (gc nil))
  (let ((var1 (gensym))
        (tot (gensym))
        (run (gensym))
        (values (gensym))
        (tot-gc (gensym))
        (new-gc (gensym))
        (egc (gensym))
        (new-egc (gensym)))
    `(let (,tot ,run ,values)
       (when ,gc
         (gc))
       (ccl::reset-consing)
       (multiple-value-bind (,tot-gc ,egc) 
                            (gctime)
         (setq ,egc (- ,tot-gc ,egc))
         (setq ,run (get-internal-run-time))
         (dotimes (,var1 ,ntimes)
           ,form)
         (multiple-value-bind (,new-gc ,new-egc)
                              (gctime)
           (setq ,new-egc (- ,new-gc ,new-egc))
           (setq ,tot-gc (- ,new-gc ,tot-gc)
                 ,egc (- ,new-egc  ,egc)
                 ,tot (- (get-internal-run-time) , run)
                 ,run (- ,tot ,tot-gc) 
                 ,run (float (/ ,run internal-time-units-per-second))
                 ,tot-gc (float (/ ,tot-gc internal-time-units-per-second))
                 ,egc (float (/ ,egc internal-time-units-per-second))
                 ,tot (float (/ ,tot ,internal-time-units-per-second)))
           (setq ,values
                 (format nil "~s ~d ~3f ~3f ~3f ~3f",title ,ntimes ,tot ,run  
                         ,tot-gc ,egc))
           (when ,print (format t "~&~a~%" ,values))
           (values ,title ,ntimes ,tot ,run ,tot-gc ,egc)
           )))))
  
? (form-stats "simple loop"
                (loop for i fixnum from 1 to 10000
                      collect i))
"simple loop" 1 1.1 0.13 1.0 1.0
"simple loop"
1
1.15
0.133
1.017
1.017


mark

You can also collect statistics on storage used.
From: Jeffrey.J.Guertin@uwrf.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: calling _Date2Secs
Date: 24 Jan 93 21:44:10 GMT


To:info-mcl@cambridge.apple.com
cc:info-mcl@cambridge.apple.com
Subject:RE: calling #_date2secs
--------

jeffrey,
	i'm very new to this game so i don't know protocal. i've been playing
with your code and calling date2secs since i saw it. your hint was correct;
as written deftrap _date2secs was attempting to put a datetimerec into an
address register and a macptr into the longword set up for seconds.
	
	the following deftrap seems to work. however i'm still getting funny
results with your rlet ie. a return date in 1904. i get correct results when
i step through the same code.

(deftrap _date2secs ((d (:pointer :datetimerec)) (secs (:pointer 
:signed-long)))
   nil
  (:no-trap
   (%put-long secs (ccl:register-trap #xa9C7 :a0 d :d0))))

	have learned much in the proccess.
				
					thanx
					
					igore
From: jmm@contra-aid.lucid.com (Jay Mellman)
Newsgroups: comp.lang.lisp.mcl
Subject: Availability of MacCLIM 1.1 for MCL 2.0
Date: 27 Jan 93 18:41:17 GMT
Distribution: comp.lang.lisp.mcl
Organization: Lucid, Inc.


During the last few months, Lucid and Apple have worked with Illudium
Software to bring MacCLIM to market.  Lucid now provides one-stop
shopping for both MCL 2.0 and MacCLIM 2.0.  Lucid also offers customer
support for both products.  Our plan is to work with Illudium to
product the MacCLIM 2.0 version of software once our own Lucid CLIM
2.0 enters beta test.

For more information and availability, contact "Sales@lucid.com"

Jay Mellman				jmm@lucid.com
Product Marketing Manager		(415) 329-8400
Lucid, Inc.

============

NEWS RELEASE

LUCID JOINS WITH APPLE COMPUTER TO PROVIDE MACINTOSH SOLUTIONS FOR
LISP DEVELOPERS

Menlo Park, CA December 1, 1992:  Lucid, Inc., the leading vendor of
Common Lisp systems for general purpose systems, today announced the
immediate availability of the Common Lisp Interface Manager for
Macintosh computers (MacCLIM), and the availablility of Macintosh
Common Lisp (MCL) from Lucid.  Under its agreement with Apple, Lucid
will package, distribute and support MacCLIM and resell and support
MCL.

CLIM, a Lisp industry graphical toolkit standard, allows users to
write platform-independent user interfaces.  With release 2.0,
expected next year, users can expect functionality that allows an
application written for a Unix workstation running Lucid Common Lisp
to adapt itself automatically to the Macintosh look-and-feel when
compiled under MCL.

"Lucid now offers one-stop shopping for Lisp programmers across even
more platforms," said Bob Kadarauch, President and CEO of Lucid.  "Our
users are including the Macintosh in their development and deployment
plans.  With this agreement and our eight years of experience in
supporting commercial development of advanced systems, we can meet the
needs of our commercial developers more fully."

MacCLIM version 1.1 lists for $495 and MCL for $495.  Customer support
for each product is available at $500 per year and includes future
updates and hotline support.  Apple will continue to offer the
standalone MCL product through its APDA distribution channel, Apple's
source for development tools.

"MacCLIM fills an important need for customers who want to write
Common Lisp programs and have them run on multiple platforms including
the Macintosh," said Harvey Alcabes, MCL Product Marketing Manager at
Apple Computer.  "We're pleased that Lucid is making MacCLIM and MCL
support available to customers."

Lucid, Inc. is an eight-year old UNIX programming tools company with
leading market share in Common Lisp for general purpose computers.
Lucid provides compilers, tools, and programming environments for the
Lisp, C, and C++ developer, including the Energize Programming System
for C and C++.

APDA and Macintosh are registered trademarks of Apple Computer, Inc.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Setting dialog item body color
Date: 21 Jan 93 16:51:38 GMT

At 21:22 1/20/93 +0000, John R. Gersh wrote:
>How can one set the body color of a check-box or radio-button dialog item?
>(For example, if you want it to look reasonable in a dialog with a
>background color.)
>
>(set-part-color <item> :body <new-color>) or initializing with the
>equivalent part-color-list has no effect in this case; no matter what you
>do, the item keeps a white body color.
>
>I poked around a bit around with ccl::set-control-part-color and
>ccl::table-color. It appears that the control color-table is being set
>properly, but this doesn't affect the way check-boxes and radio-buttons are
>drawn. (Things work just fine in setting text and frame colors.) IM V has a
>nice color plate that shows radio buttons and check-boxes with body colors
>that match a dialog's background, so it ought to be possible.
>
>What gives? Is there a way to do this? (I've worked out an awfullly kludgy
>work-around involving a view-draw-contents that paints the dialog-item and
>then calls #_TrackControl to redo the text and frame, but this is only
>partially effective for radio-buttons, and there _must_ be a better way.)
>
>[Note: This question was asked in this forum last summer by someone else.
>I've searched the mail archives and checked with the original questioner -
>it seems never to have been answered.]

The System 7 CDEF appears to use the window's :content color instead of the control's
:body color as the background color when drawing check boxes and radio buttons. This is,
I believe, different than System 6's behavior, though I didn't check that today.
In order to make it look right, I found it necessary to both:

  (set-back-color <window> <color>)
  (set-part-color <window> :content <color>)

For system 6, you may also need:

  (set-part-color <radio button or check box> :body <color>)


-----
Bill St. Clair
bill@cambridge.apple.com
From: lieber@media.mit.edu (Henry Lieberman)
Newsgroups: comp.lang.lisp.mcl
Subject: MCL Operating System
Date: 21 Jan 93 17:30:33 GMT


Actually, an even better idea is to call the MCL application an "init"
and tell people that you have to put it in the Extensions folder
inside the System Folder [no harm in that being there, is there?].
It's only about twice as big as the Quicktime init, and does lots more. 
Then call each fasl file an "application", and marvel at how small the
applications are.

But seriously, folks, why should the "size" of the MCL application
matter at all? If System 7 virtual memory works correctly [and here is
where I may be assuming too much], the virtual memory system should
dynamically decide what you need to keep in memory and what you don't.
Virtual memory is a dynamic "tree shaker", and thus should be able to
do better than any static tree shaker could ever do, and no problems
with EVAL, etc.

Henry Lieberman
From: ph@netcom.com (Peter Hendrickson)
Newsgroups: comp.lang.lisp.mcl
Subject: MCL Operating System
Date: 21 Jan 93 21:33:38 GMT

>Date: Thu, 21 Jan 93 12:30:33 -0500
>From: Henry Lieberman <lieber@media.mit.edu>
>
>Actually, an even better idea is to call the MCL application an "init"
>and tell people that you have to put it in the Extensions folder
>inside the System Folder [no harm in that being there, is there?].
>It's only about twice as big as the Quicktime init, and does lots more. 
>Then call each fasl file an "application", and marvel at how small the
>applications are.

This is the way to go.  Selling people on another init is easy.  Plus,
it avoids the question of why one needs two operating systems, one of
which depends on the other.

Peter Hendrickson
ph@netcom.com
From: ogus@gaulois.berkeley.edu (Arthur E. Ogus)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Packaging MCL
Summary: Guidelines for sizes?
Date: 25 Jan 93 19:10:02 GMT
Organization: U.C. Berkeley Math. Department.
NNTP-Posting-Host: gaulois.berkeley.edu

Can anyone recommend guidelines for setting the size resources in a
standalone application created in MCL?  And how about the detailed
settings for the stack and heap, as described in the release
documentation?  I would like to set everything so as to make as small
a partition as possible but still to run safely, and I have no idea at
all how to do it.
From: markt@dgp.toronto.edu ("Mark A. Tapia")
Newsgroups: comp.lang.lisp.mcl
Subject: Timing stats
Date: 21 Jan 93 15:19:30 GMT

Please remove the call to (ccl::reset-consing) in the previous message
in the definition of the form-stats macro.
mark
From: RPHDYKST@idbsu.idbsu.edu (Dewey Dykstra)
Newsgroups: comp.lang.lisp.mcl
Subject: Save-Application Help
Date: 22 Jan 93 20:29:52 GMT


We are developing some software using MCL 2.0.  Recently I was able to do a
save-application on a PowerBook 180 using the following

(save-application "pathname" :size 8192)

It took about 2.5 mins to complete its task and would reload and be ready to
run in about 20 sec.  (Powerbook had virtual memory running with sufficient
allocation for this.)

I was on the road at the time and did the above to make a presentation.  When I
got home I tried the same thing on a Quadra 950, but I keep getting an error of
type -605 when I try to run the application which has been saved.  I have tried
both Cache settings on the Quadra, made sure that the :size for the saved appli
cation matches that of the lisp which created the application, made sure that
no other applications were loaded before lisp when I made the application or
when I tried to open the saved application.  It seems to have no problems
saving the application, its just that something about the saved application
is bad.

How can I get this to work on the Quadra 950??  Will I have similar problems
on a Quadra 700 or a IIci?  Please send any helpful comments to me at my
address above as I am not a regular on info-mcl.

Second question:  We find that it takes a long time for our system to compile.
In particular we have two parts which are 200 - 300 K which contain functions
that are created.  Is there anything we can do to speed up the compiling pro-
cess?  Again, please send any helpful comments to my e-mail address above.

Thanks in advance for your help.

Dewey Dykstra
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Porting to MCL: Package problems
Date: 28 Jan 93 16:05:01 GMT

At 11:24 1/28/93 +0000, Ranson wrote:
>IN-PACKAGE was changed incompatibly in the 2nd version of Common Lisp. The
>problem is there, not in MCL. In this version, the argument of IN-PACKAGE is
>not evaluated. To increase portability, use keywords:
>
>(in-package :tms)
>
>     Daniel.

MCL comes with a CLtL1 compatibility package. It doesn't make everything
work exactly as in CLtL1, but it does provide the LISP & USER packages
(CLtL2 renames these to COMMON-LISP & COMMON-LISP-USER), and provides
CLtL1 versions of LISP:IN-PACKAGE, LISP:FUNCTIONP, and LISP:CHAR-BITS &
friends. You might try evaluating the following two forms before loading
your code:

(require "LISP-PACKAGE")
(in-package :user)
From: mdavis@media.mit.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Windows vs. color-dialogs and getting a cpixel value
Date: 25 Jan 93 16:18:00 GMT
             <9301251541.AA21219@cambridge.apple.com>


Thank you so much.  The fix worked.  By focusing the view on the
view-window the color-dropper returns the correct color value!

Thanks for offering excellent support.

Marc Davis
MIT Media Lab
From: markt@dgp.toronto.edu ("Mark A. Tapia")
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Stack Overflow Error
Date: 22 Jan 93 23:02:05 GMT

On Fri Jan 22 14:13:37 1993 Mark Carlotto <Mark_Carlotto@b1mac144.read.tasc.com>
writes:
 I am using the following code to display images stored as PICT resources.
  ...
  My problem is that if I make the rectangle too large... the system
  crashes
There are also good utilities in oodles of utils that will
do similar tasks, including a pict-di (pict dialog item) and
rsrc-svm. The utilities were developed by Michael Engber,
Northwestern University Institute for the Learning Sciences.

The utilities handle pictures and resources and are available through
anonymouse ftp from the pub/MCL2/contrib directory.

mark
Newsgroups: comp.lang.lisp.mcl
From: d92mbe@efd.lth.se (Martin Bergendahl)
Subject: What is MCL?
Organization: Lund Institute of Technology, Sweden
Date: Mon, 25 Jan 1993 12:10:00 GMT

What is MCL?
How big is it?
Can yuo write stand-alone applications?
Are there any good mac libraries?
Is it free?
Where can I then get a copy of it?

Answers, please

< Martin Bergendahl >
From: mark@cambridge.apple.com
Newsgroups: comp.lang.lisp.mcl
Subject: MCL 2.0 Patch 2
Date: 27 Jan 93 21:16:47 GMT

The second patch to Macintosh Common Lisp 2.0 is now available. There
are two ways to get it via the Internet: by sending mail to our archive 
server, or by anonymous FTP. It is also available on AppleLink, on the
"Macintosh Common Lisp Discussion" board. Instructions for decoding the 
patch (it's in BinHex format) and installing it are in the documentation file 
accompanying the patch. 

This is version 1.0 of patch 2 (you can check the version number in
the patch file's "Get Info" box). It is identical to the pre-release
(version 0.6) I announced on December 31, 1992. If you have been testing 
that pre-release, you do not need to download this one (and thanks 
for your help!).

This patch fixes a number of mostly minor bugs.  Here are descriptions of a 
few of them, from the documentation file:

        ; Fixed some problems printing on Imagewriter printers.

        ; LABELS wasn't consistent about "parallel" binding order in some cases.

        ; EQUALP hash tables no longer error when CLOS instances are 
        ; used as keys.

        ; Fixed a kernel bug that pushed the wrong stuff on the stack
        ; when a function had required, optional, rest, & keyword args
        ; and a value was not specified for all of the optionals.

        ; (fround 3) no longer signals an error.

You must install patch 1 before installing patch 2; you can download patch 1
from the same place as patch 2 (the files are "mcl2.0p1.fasl.hqx" and 
"mcl2.0p1-notes.txt").



To Download from the archive server:

The archive server is available to anyone who can send mail to an
Internet address, including those of you who use a service (like
Compuserve or AppleLink) that has a gateway to the Internet. If you
have not already done so, you should get the Help file on this
service by sending this message (this should be the body of the
message, not the Subject line):

    Help

to this address:

    Archive-server@cambridge.apple.com

Please see the MCL 2.0 Release Notes for more information on
this service. Here are the contents of a message that would
download the patch and documentation files to my Internet mailbox:

    path mark@cambridge.apple.com
    size 300000
    send mcl2/patches/mcl2.0p2.doc
    send mcl2/patches/mcl2.0p2.fasl.hqx

Please remember to replace my address (in the "path" command) with
yours!

If your mail system cannot receive long messages, be sure to
update the "size" line in the above message (see the archive server
help document for more on this command).


To download by anonymous ftp:


You can anonymously ftp the patch and its documentation from
cambridge.apple.com. Logon to this host as anonymous, then
type your user name for a password. Here are the files you want:

    /pub/mcl2/patches/mcl2.0p2.doc
    /pub/mcl2/patches/mcl2.0p2.fasl.hqx


Thanks for using our Lisp. Please let us know if you have any problems
downloading or installing the patch.


Mark Preece
Apple ATG East
mark@cambridge.apple.com
AppleLink: PREECE