HDTenEightyP/NetNews huggingface dataset:
From: tcasasent@diamond.kbsi.com ("Tod Casasent" )
Newsgroups: comp.lang.lisp.mcl
Subject: Error messages from snapshots
Date: 28 Jan 93 16:13:17 GMT
Reply-To: tcasasent@diamond.kbsi.com
Organization: Knowledge Based Systems, Inc.

Frequently my snapshots, when double-clicked, returns a "Bad f-line 
instruction" and give a type 10 error with the choice of restarting or 
continuing.  This happens with a fair regularity.  I'm running MCL2.0p1.  
(We're getting patch 2 Monday.)  Anybody know what's causing this or why 
it's happening?

Thanks,
	-Tod

========================================================================
tcasasent@kbsi.com
========================================================================
"Truth then, that's it, truth.  For when a man lies he murders some part
of the world.  You should know that." - Merlin to Arthur in "Excalibur"
========================================================================
Jean -  Henna neko da ne... == Hobbes - Do you believe in God?
Nadia - Raiyon yo!          == Calvin - Well, Somebody's out to get me.
========================================================================
The opinions and statements herein expressed are not those of KBSI and,
if attributable to anyone, are mine.
========================================================================
From: kurihara@tansei.cc.u-tokyo.ac.jp (Akira Kurihara)
Newsgroups: comp.lang.lisp.mcl
Subject: how to change stack size?
Date: 21 Jan 93 20:47:03 GMT


Could you tell me how to change stack size of mcl2?
 
Looks like I have to do it, since I am now calculating integers
as big as (expt 10 300000).
 
Thank you.
 
========================================================================
Akira Kurihara                            |  School of Mathematics
E-mail: kurihara@tansei.cc.u-tokyo.ac.jp  |  Japan Women's University
Phone: 03-3943-3131 ext-7243              |  Mejirodai 2-8-1, Bunkyo-ku
                                          |  Tokyo 112, Japan
========================================================================
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Do Again
Date: 26 Jan 93 20:38:49 GMT

At 18:25 1/25/93 -0600, lynch@ils.nwu.edu wrote:
>I'm interested in providing a "Do Again" menu-item which will re-issue the
>most recent menu command...
>
>Any suggestions how?

(defvar *last-selected-menu* nil)

(advise menu-item-action
        (setq *last-selected-menu* (car arglist))
        :when :after
        :name *last-selected-menu*)

(defun redo-last-menu-item-action ()
  (when *last-selected-menu*
    (menu-item-action *last-selected-menu*)))
From: mdavis@media.mit.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Windows vs. color-dialogs and getting a cpixel value
Date: 23 Jan 93 18:15:58 GMT


Hi,

I am really stumped on something.  I have written a simple
color-dropper function which allows the user to get a color by
positioning an eye-dropper cursor on a point and clicking to get its
color value.  The problem I have is that this function returns the
correct color when defined as the dialog-item-action of a button when
that button is the subview of a window, but not when the button is the
subview of a color-dialog (it just seems to return black or white).
What is going on here?

Marc Davis
MIT Media Lab

******Code below (urgent help appreciated)*****

;function to get a color value at an x y
(defun getcpixelcolorvalue (x y)
    (with-rgb (rgb *black-color*)
              (#_getcpixel x y rgb)
              (rgb-to-color rgb)))

;Code to get a color value by clicking on a point 
;put your favorite cursor in here 
;(we took one from Studio 8, the *watch-cursor* from MCL works too.

(defvar *color-dropper-cursor* *watch-cursor*)

(defun get-color-with-color-dropper (&optional (color-dropper-cursor
	*color-dropper-cursor*))
    (with-cursor color-dropper-cursor
         (let ((color nil))
            (do () ((mouse-down-p))
                (let ((mouse-position (view-mouse-position nil)))
                   (setf color (getcpixelcolorvalue (point-h mouse-position)
						(point-v mouse-position)))))
            color)))

;this works

(make-instance 'window
     :view-subviews (list (make-instance 'button-dialog-item
                :dialog-item-action 
		#'(lambda (item)
			(declare (ignore item))
			(pprint (get-color-with-color-dropper))))))

;this does not

(make-instance 'color-dialog
     :view-subviews (list (make-instance 'button-dialog-item
                :dialog-item-action
                #'(lambda (item)
                        (declare (ignore item))
                        (pprint (get-color-with-color-dropper))))))
From: U0919@AppleLink.Apple.COM (Boise State U, Stan Smith,HEP)
Newsgroups: comp.lang.lisp.mcl
Subject: Using-save application
Date: 22 Jan 93 22:14:00 GMT

Date:         Fri, 22 Jan 93 11:09:16 MST
From: Dewey Dykstra <RPHDYKST@IDBSU.IDBSU.EDU>
Subject:      Using save-application
To: MCL Help Line <info-mcl@CAMBRIDGE.APPLE.COM>
 
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: language@skdad.usask.ca
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  What is MCL?
Date: 25 Jan 93 19:40:31 GMT

> What is MCL?
a most excellent Lisp programming environment.

> How big is it?
rather large,  however there appears to be interest
in making it smaller...

> Can yuo write stand-alone applications?
yes,  but,  they're rather large too (1.5 megs on average),
but there appears to be interest in decreasing this size too..

> Are there any good mac libraries?
you can ftp to cambridge.apple.com and pick up some excellent
sources and examples.

> Is it free?
definitly not.

> Where can I then get a copy of it?
apda.

 
Answers, please

     -john
From: nrb!slack@starbase.MITRE.ORG (M. G. Slack)
Newsgroups: comp.lang.lisp.mcl
Subject: Packaging MCL
Date: 21 Jan 93 14:11:48 GMT


   Date: Wed, 20 Jan 1993 09:44+0200
   From: Vincent Keunen <nrb!keunen@nrbmi2.ia.nrb.be>
   Reply-To: nrb!keunen@nrb.be

       Date: Fri, 15 Jan 1993 22:01+0200
       From: ph@netcom.com (Peter Hendrickson)

       I think this is a good idea and here's how to package it: Call it the
       "MCL Operating System".  Distribute it in an "MCL Operating System
       Folder".  Nobody cares how big an operating system is!  When you are
       delivering an MCL program to a customer, you specify that it requires
       the "MCL Operating System" and they won't bat an eye.  The tone of the
       interaction changes from "... but the application will be 1.5MB" to
       "... you are up to date with the MCL Operating System, aren't you?"


Best of all, make the MCL OS Free and packaged with the MAC OS.  I'll bet that
this will greatly increase the # of people doing development in the language
and thus up the Number of sales of the MCL language.

Marc
From: nrb!cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Packaging MCL
Date: 22 Jan 93 23:27:13 GMT

> Return-Path: <slack@starbase.mitre.org>
> Date: Thu, 21 Jan 93 09:11:48 EST
> From: nrb!slack@starbase.MITRE.ORG (M. G. Slack)
> To: info-mcl@nrbmi2.ia.nrb.be
> In-Reply-To: Vincent Keunen's message of Wed, 20 Jan 1993 09:44+0200 <19930120074430.1.KEUNEN@nrbmi1.ia.nrb.be>
> Subject: Packaging MCL
> 
>    Date: Wed, 20 Jan 1993 09:44+0200
>    From: Vincent Keunen <nrb!keunen@nrbmi2.ia.nrb.be>
>    Reply-To: nrb!keunen@nrb.be
> 
>        Date: Fri, 15 Jan 1993 22:01+0200
>        From: ph@netcom.com (Peter Hendrickson)
> 
>        I think this is a good idea and here's how to package it: Call it the
>        "MCL Operating System".  Distribute it in an "MCL Operating System
>        Folder".  Nobody cares how big an operating system is!  When you are
>        delivering an MCL program to a customer, you specify that it requires
>        the "MCL Operating System" and they won't bat an eye.  The tone of the
>        interaction changes from "... but the application will be 1.5MB" to
>        "... you are up to date with the MCL Operating System, aren't you?"
> 
> 
> Best of all, make the MCL OS Free and packaged with the MAC OS.  I'll bet that
> this will greatly increase the # of people doing development in the language
> and thus up the Number of sales of the MCL language.

- OK, we've got the dollars end covered. 
- We've got the "psycological" end covered
with the"MCL operationg system" or its "Lieberman init" equivalent.
[Just make it so that when the machine boots up, the init doesn't take up
much room until the user actually launches an MCL applet.]
- We've got the design mapped out [use essentailly fasl files]
- We've got the user interface [see previous fry note on making it easy
to switch the menu bar, change applets with the right hand pull down menu],
- we've got some complications to work out with Apple-events but this need not
be smooth on first pass.
- Implementation is always harder than you initially hope but doesn't SOUND
  like a lot of work.
- And its a potentially big win.
From: moon (David A. Moon)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Calling MPW C code: is malloc safe?
Date: 25 Jan 93 23:52:19 GMT

> From: westling@starbase.mitre.org (Mark Westling)
> Date: 25 Jan 93 22:10:13 GMT
> 
> I'm calling MPW C code using MCL 2.0's foreign function
> interface.  My program bombs occasionally (but not
> consistently), and I suspect it's due to malloc calls. Is
> it safe to use the MPW memory allocation/deallocation
> calls in a Lisp environment, or should I create a static
> array and manage it all myself?

Calling malloc (or C++ new) works reliably for me.  Perhaps your C program
would bomb even if you weren't running it under MCL?
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Do Again
Date: 26 Jan 93 00:25:45 GMT

I'm interested in providing a "Do Again" menu-item which will re-issue the
most recent menu command...

Any suggestions how?

E-mail, and I'll summarize if there's enough interest...
-- 
--
-- "TANSTAAFL" Rich lynch@ils.nwu.edu
From: cgay@skinner.cs.uoregon.edu ("Carl L. Gay")
Newsgroups: comp.lang.lisp.mcl
Subject: contribution
Date: 25 Jan 93 10:19:05 GMT
Reply-To: cgay@cs.uoregon.edu

...mcl2/contrib/fred/fill-paragraph.lisp does filling and
justification of comments and plain text (a la m-Q in emacs).
Documentation is at the top of the file.  It can be very useful if you
tend to write long comments, or if you tend to use fred to edit plain
text because it's the best emacs for the Mac.  :-) Let me know if you
find bugs other than the ones listed in the file.  I've been using it
for a while, but other users are bound to turn up bugs I didn't find.

Note that I created the directory called fred.  I think it would be a
good idea to move some of the fred hacks into there to create a little
structure in the contrib directory.  I volunteer to do it (and update
the README file) if people think it's a good idea.

-Carl
From: kab (Kim Barrett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: shiftf
Date: 27 Jan 93 16:31:30 GMT

> 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.
Newsgroups: comp.lang.lisp.mcl
From: Douglas C. Merrill <dmerrill@ils.nwu.edu>
Subject: Nasty interaction of toplevel and menu-items
X-Xxmessage-Id: <A7846CF0970164D8@dmerrill.ils.nwu.edu>
X-Xxdate: Thu, 21 Jan 93 21:08:32 GMT
Organization: The Institute for the Learning Sciences
X-Useragent: Nuntius v1.1.1d13
Date: Thu, 21 Jan 1993 20:42:21 GMT

Hi to all...

I've been working on a small program that replaces the toplevel loop with one
of my 
own.  However, I'm doing something wrong (aargh)!  When I take over the loop, 
anything typed into the Listener gets listened to correctly, but any function
called from a 
menu-item that contains a (format t ) breaks in an odd way.  Basically, it
looks like the 
output of the format calls are being evaluated.  So, if my menu calls a
function (test), and 
test contains a call (format t "This will break"), my toplevel responds 
> Error: Unbound variable: THIS
> While executing: SYMBOL-VALUE
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry getting the value of THIS.
See the RestartsU menu item for further choices.
as if I had typed "This".  

Code to produce this error is below:
;;;; Toplevel code to show break

;; set-top is an accessor function to set the toplevel routine
;; new-top is the new toplevel routine

(defun set-top (top-level-fn)
   (%set-toplevel top-level-fn)
   (throw :toplevel t))

(defun new-top (&aux form)
   (format t "~&LISP> ")
   (setq form (read))
   (format t "~& ~a" (eval form)))

;; now just create the test case

(defun test ()
   (format t "This will break"))

(defparameter *stupid-menu* (make-instance 'menu
                                                    :menu-title "Test"
                                                    :menu-items
                                                    (list
                                                      (make-instance 'menu-item
                                                          :menu-item-title
"Breaks"
                                                          :menu-item-action 
                                                          #'(lambda ()
(test))))))

(menu-install *stupid-menu*)


I don't have any good ideas about what's going on -- maybe I'm confused about
the 
various streams?  Advice would be gratefully appreciated.


Thanks,

Douglas Merrill
Visiting Scholar
The Institute for the Learning Sciences
Northwestern University
1890 Maple Ave
Evanston IL 60201
dmerrill@ils.nwu.edu
From: language@skdad.usask.ca
Newsgroups: comp.lang.lisp.mcl
Subject: Re:  Re2: Mother ship App.(flame)
Date: 25 Jan 93 19:35:15 GMT

> The "problem" of buggy MCL applications can be viewed from another
> angle: Most of those buggy MCL applications wouldn't have been 
> completed at all if they had been implemented in another language, 
> and they most certainly would not have been less buggy at the 
> same level of fuctionality.

well,  I'm not really talking about 'buggy' in the sense that there
are a lot of lisp exceptions.  lisp has a wonderful debugging environment
that works well inside of mcl.  What I am taling about are the apparant
mystery crashes that happen for no apparant reason,  why a program
crashes on one machine and not another,  the mouse freezing, why
version 2.0 crashes every time with the even-better-buss-error init
distributed at ftp.apple.com.  unexplained mouse freezing,  that sort of
thing.  These things simply should not happen!

    -john
From: mcdougal@cs.uchicago.edu (Tom McDougal)
Newsgroups: comp.lang.lisp.mcl
Subject: offscreen drawing
Date: 28 Jan 93 18:02:41 GMT

What is the standard technique for drawing to an off-screen bitmap?

Thx.

-Tom
(mcdougal@cs.uchicago.edu)
From: oddmund@idt.unit.no
Newsgroups: comp.lang.lisp.mcl
Subject: Re2: Mother ship App.(flame)
Date: 23 Jan 93 08:39:05 GMT


>The fact is,  MCL makes B I G CLUMSY and BUGGY applications

I believe John has a point in that there are a lot of buggy MCL 
applications out there, but that isn't necessarily MCL's fault. 

As Howard at UK0392@applelink.apple.com points out, MCL bugs 
which crash the Mac are fairly rare. That may be part of the
"problem": Bugs in MCL programs don't cost programmers enough, 
so they are too easly ignored. At least in my case, I am a lot more 
careful about tracking down bugs and writing correct code in 
the first place when using an environment where the price of 
an error is heigh. I am quite new to Lisp, but I can write 10 pages of
Lisp before I start testing - and still make the program work within 
a reasonable amount of time. That is an important part of the reason 
for increased programmer productivity. It is also the cause of a lot 
of little bugs in little used parts of my code.

Add to this the fact that many MCL "applications" are prototypes
and probably quite few go through anywhere near the kind of testing
applied to traditional large market commercial applications. 

The Lisp tradition is to make many of the "prototypes" available to
fellow programmers. I really like that tradition, but for obvious reasons
what is given away can not be supported in the same way as what people
pay for (although some people do a good job trying).

The "problem" of buggy MCL applications can be viewed from another 
angle: Most of those buggy MCL applications wouldn't have been completed
at all if they had been implemented in another language, and they most 
certainly would not have been less buggy at the same level of fuctionality.

Oddmund Mogedal
Norwegian Institute of Technology
oddmund@idt.unit.no
From: language@skdad.usask.ca
Newsgroups: comp.lang.lisp.mcl
Subject: re: John's Flame
Date: 25 Jan 93 19:26:56 GMT

> Some ideas of yours are interesting.  But why don't you express them in
> a more gentle way?  They will be more acceptable.  And your messages are
well vincent,  I feel that infact I was being quite gentle.  I provided
references to my sources and I was quite factual.  Perhaps the stuff about
'BIG' and 'CLUMSY' was a bit too much,  however,  you may have noticed that
it did get some attention,  and there have been many thoughtful replies
that address the issues I brought up in a constructive way.  The posting
did in fact have a 'flame' flavour to it,  and this was intentional.
My prime interest here is to be the 'squeeky wheel' and get some people's
attention in the hope that something infact will be done about MCL's size.
In a few years,  the way media is growing,  size will be irrelevant-
-there's no doubt about it.  But,  nowadays,  a tree-shaker would be a major
boon to people doing development work.  Not all of us have the privledge
of working in an ivory tower:  we have real concerns, real demands,
and size is an issue.  Selling vertical market software isn't often a problem:
clients are usually willing to go and buy a machine just to run the software
we make.  However, this is not always the case.....

> read by lots of people.  Don't abuse that power.  Personnaly, I don't
> like reading aggressive messages like that all day long...  I'm saying
> this with no negative thoughts, I hope you don't feel hurt.
This isn't an abuse of power, this is a legitimate and well motivated
attempt to get things done.
 
> Thanks for your consideration of netetiquette,
thankyou for being politically correct....

    -john
From: lieber@media.mit.edu (Henry Lieberman)
Newsgroups: comp.lang.lisp.mcl
Subject: MCL Operating System
Date: 25 Jan 93 16:37:03 GMT


   Date: 23 Jan 93 04:53 GMT
   From: AMBLE@AppleLink.Apple.COM (Amble, Bob)

   I believe the size of MCL applications being discussed is the disk footprint

But [excluding the CD] MCL comes on fewer floppy disks than Photoshop,
Macromind Director, Pagemaker ... all of which you've got to run in >2
MB partitions for reasonable work anyway.

A real villain is that the Mac OS makes you allocate a fixed-size "partition"
for the application. Application "size" should be dynamically allocated.
This is an obsolete holdover. 

Application-switching is not an issue; the real measure is "working set", 
the relative size of recently and frequently accessed memory. Generational
GC may "move things around" in your address space, but that it irrelevant.
The purpose of GC is not to "reclaim memory" as many think, but to increase
the density of objects that you access in memory.

I was one of the original inventors of generation-based GC. 

Henry Lieberman