HDTenEightyP/NetNews huggingface dataset:
From: oddmund@idt.unit.no
Newsgroups: comp.lang.lisp.mcl
Subject: RE: MCL size/distribution (was: MCL support for MOP)
Date: 10 Jan 93 16:18:38 GMT


>We'll probably be
>looking into a few ways to reduce the size of MCL (though probably
>not for 2.1). 

>1) A tree shaker to automagically remove parts of MCL that are
>   not used by your application.
 
A tree shaker would be nice, if one could conveniently declare a list of 
functions etc. which might be used and therefore should not be removed.

>2) Make the development environment be optional, or distribute 2
>   MCL applications: with & without development environment. Maybe
>   even a third application that has just Common Lisp with no
>   application framework.

The issue of alternative distribution forms is important. It involves not only 
the size of what may be redistributed to end users of apps created in MCL, but 
also the functionality of those apps. Obviously, Apple needs to prevent people 
from "reselling" MCL, and that is the reason why the compiler must be excised 
before redistribution. I believe other ways of reducing the value of what may 
be redistributed should be considered. Removal of the development environment 
is an obvious choice. 

This would make MCL extremely attractive for writing compilers of special 
purpose languages, and for writing systems which contain such special purpose 
languages. If necessary, a small fee (<<$500) could be charged for 
redistribution with compiler but without development environment.

I believe that AppleScript will make programming languages a much more 
important part of the Macintosh user interface. This will make it attractive to 
provide many applications with end user programming languages (usually quite 
similar to/extensions of AppleScript). Additionally, increased depth and 
complexity of graphical user interfaces will make it more attractive to compile 
plans created at runtime by user manipulation (as for example in ThingLab). 
With a way to redistribute the compiler, MCL would be great for writing all 
those future applications.

>3) One or more shared libraries for the different pieces of MCL.
>   This will allow small MCL applications at the expense of some
>   large inits.

This would be nice for developers with lots of homemade MCL applications on 
their hard disk(s) (I'm working on becoming one of "them".). How about making 
the development environment a big init? That might make tree shaking the rest 
of each application easier as well. In such a scenario, developers could keep 
exact end-user versions of apps on their hard disk. All end-user versions could 
have the property that they call the development environment IF-AND-ONLY-IF(an 
error occurs AND the development environment init is present). This would allow 
convenient debugging without version confusion 


Oddmund Mogedal
Norwegian Institute of Technology
oddmund@idt.unit.no
From: 76377.1176@CompuServe.COM (Michael Templeman)
Newsgroups: comp.lang.lisp.mcl
Subject: info-mcl list
Date: 7 Jan 93 14:37:38 GMT

Please remove me from the info-mcl list.

Thanks,
Mike Templeman


Distribution:
  >INTERNET: info-mcl@cambridge.apple.com
From: feng@.cs.umass.edu
Newsgroups: comp.lang.lisp.mcl
Subject: color selected text
Date: 6 Jan 93 21:09:49 GMT
Reply-To: feng@.cs.umass.edu ()
Distribution: usa
Organization: University of Massachusetts, Amherst


I am implementing an interface. The interface is designed as a dialog
window, in which there are several items, one of them is an editable-
text-dialog-item. I want to color or change the font of the selected 
text in the editable-text-dialog-item. The build-in method set-part-
color does not work for the selection range, but for the whole item.
Has anyone known some method that can make this change ? 

For example, the following code makes a dialog window in which an
editable-text-dialog item and a button-dialog-item are enclosed.
The dialog-item-action of the button-dialog-item should color or 
change the font of the selected text in the editable-text-dialog-item 
text-item, once clicking on the button.

(setq interface
	(make-instance 'dialog
	               :view-position 'centered
		       :view-size #@(250 250)
		       :view-subviews
			(list
	(setq text-item
	(make-dialog-item 'editable-text-dialog-item
	                  #@(5 20)
			  #@(100 180)
			  ""
			  'nil
			  :allow-return t))
	(setq coloring
	(make-dialog-item 'button--dialog-item
	                  #@(5 200)
			  #@(100 180)
			  "coloring selection"
			  #'(lambda (item) item))) ;;;I need the
                                                 ;;;coloring method here
	)))


Any suggestion is very welcomed, even without using the editable item.
However, both the table-dialog-item and sequence-dialog-item can not
be used for this purpose since them can not partially select a cell.
Thank you very much.

Fangfang Feng (fff in short)
From: lph@paradigm.com
Newsgroups: comp.lang.lisp.mcl
Subject: Exes and Re: MCL size/distribution
Date: 12 Jan 93 01:59:42 GMT
Organization: Paradigm Associates Inc, Cambridge MA

From the standpoint of a developer of a large software system for
use under a variety of common lisps on various hardware platforms:

The tree-shaker approach falls a little short for programs that
compute a function to be APPLY'ed or FUNCALL'ed unless you supply
a mechanism for a training run or can specify a list of functions
to include.

As far as reducing the amount of CL that must be present
in an executable image, I personally favor the approach taken in
DEC's VAX-Lisp 2.2 (modified to be less favorable in later releases.)
There you select a set of relatively orthogonal extensions beyond
basic functionality and can eliminate those desired, such as the
compiler, debugger, editor interface, read-eval-print loop, window
system graphics, and etc. [a certain subset is mandatorily excluded
for execute-only systems that you can distribute without a license,
and the amount that must be excluded was increased in subsequent
releases, which is less favorable to developers.] If this could be
extended further to enable me to exclude certain CL functions that
I never call (as long as they aren't called in functions that I
retain) I would be able to reduce the size of an executable further.

Can the building of an executable image be made more intelligent?
So that functions that call each other get on the same set of
pages to reduce paging/swapping? Can the garbage collector place
lists more contiguously in memory for the same purpose?

I am very impressed with MACL in general, since it executes very
favorably and in a very modest amount of space compared with
other CL implementations on other machines, though it does not
carry out much of the open-coding that is characteristic of
other lisps on other hardware.

Leo Harten
Paradigm Associates, Inc.
29 Putnam Avenue, Suite 6
Cambridge, MA 02139/USA
+1(617)492-6079
LPH@PARADIGM.COM
From: ph@netcom.com (Peter Hendrickson)
Newsgroups: comp.lang.lisp.mcl
Subject: Re2: MCL support for MOP
Date: 11 Jan 93 22:57:30 GMT


> Brent Benson   writes...
> I'm not convinced that it is hard to tree shake code that does not
> contain calls to eval.  I would appreciate it if someone could tell me

Then Ben Hyde writes ...
> More generally any interning can create symbols that can then have
> symbol-function applied to them.  I.e. parsing user input can lead to
> difficulties knowning what the domain over which intern can operate.
> This is can be handled by disallowing intern, and find-symbol.  The
> application writer must then implement his own find-symbol/intern if
> he desires this functionality.

Bob Kerns says ...
> In fact, in my coding style, I avoid symbol-function.  I tend
> to write macros that define functions, and then store the function
> itself in a data-structure, or write #'foo instead of 'foo.

> If you use symbol-function, who knows what you might end up
> running?  ;=)

Then miller@cs.rochester.edu states...
> On the flip side, I couldn't live without symbol-function. When I
> incrementally redefine a function symbol in a file (e.g. defun of foo),
> I don't want to go have to recompile every #' mention of the function, I
> want the newest version always. Sure, it loses in the face of a macro,
> but that's just another reason to try to avoid macros (or at least get
> them right the first time :-).

How about a tree shaker that warns you that symbol-function or
eval calls prevent it from shaking everything out? Then the
developer can decide whether he or she wants a small application
or symbol-function.

I'd be happy to gimp the functionality of Lisp from time to time
if it meant I could have an application which fit onto a single
diskette. I have not yet heard a convincing explanation of what
makes this hard.

For simple or even moderately complex applications, I suspect the
lavish amounts of disk space and memory consumed by MCL are mostly
unused. (Please enlighten me if you know better.)

I like MCL and I think the people who have worked on it over the
years have done a great job. But, I'd like it even more if I could
confidently compete with C programmers using it.

Peter Hendrickson
ph@netcom.com
From: pierce@at-mail-server.vitro.com ("pierce")
Newsgroups: comp.lang.lisp.mcl
Subject: RE: MCL support for MOP
Date: 9 Jan 93 01:05:27 GMT


>> One or more shared libraries for the different pieces of MCL.
>>  This will allow small MCL applications at the expense of some
>>  large inits.

>>Feedback please. Do you need these facilities? 

This would be especially great if parts of MCL could be linked into C based
applications and accessed via a new FFI.

-----
Jonathan Pierce
pierce@Vitro.com
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: update events from tight loops?
Date: 8 Jan 93 22:36:33 GMT

>Hiya,
>
>I am creating a view item that increments or decrements a number when a
>button is clicked. I would like the button (inc and dec) to behave such
>that a click inc/decs by one, and holding the button continuously inc/decs
>(at some rate).
>
>I can get the behaviour, but the view does not update. The key part is the
>looping structure below:
>
>(defmethod view-click-event-handler ((self increment-button) where)
>  (declare (ignore where))
>  (let ((to-view (if (message-view self)
>                   (message-view self)
>                   (view-container self))))
>    (when to-view
>      (increment to-view)
>      (let ((start (rref *current-event* :EventRecord.when)))
>        ;; key bit
>        (loop
>          (unless (mouse-down-p)
>            (return))
>          (when (= (mod (- (#_TickCount) start) 20))
>            (increment to-view)
>            (WHAT GOES HERE????)))))))))
>
>The WHAT GOES HERE? is where I need something that will cause LISP to allow
>invalidated views to update themselves.

The easiest thing is:

(window-update-event-handler (view-window to-view))

You should NOT call WINDOW-UPDATE-EVENT-HANDLER from anywhere but
something that is called by EVENT-DISPATCH, however. Inside of
VIEW-CLICK-EVENT-HANDLER is fine.

Another, slightly more Kosher way of doing this is to define a macro:

(defmacro with-event-processing-enabled (&body body)
  `(let ((ccl::*interrupt-level* 0)
         (ccl::*processing-events* nil))
     ,@body))

Then in place of (WHAT GOES HERE????) you can say:

(with-event-processing-enabled
  (event-dispatch))

Make sure to do it with the macro or your code will cease to compile
correctly when MCL 2.1 is released. MCL 2.1 will have a different
implementation of WITH-EVENT-PROCESSING-ENABLED that will be
functionally equivalent.

Since you know which view needs to be redrawn, a third way to do
your updating is to do the drawing yourself:

(view-focus-and-draw-contents to-view)
From: jwbaxter@halcyon.halcyon.com
Newsgroups: comp.lang.lisp.mcl
Subject: Balloon line wrap
Date: 5 Jan 93 07:57:40 GMT

While exploring the missing descenders in window-content balloons (see
other message), I noticed a line-wrap problem, exemplified by this balloon
text.  This message has been handed to the Internet with the wrapping as
seen in the balloon.  (The problem is that the "Editible-Text-Dialog-Item"
'word' is wrapped between the e and m in 'Item', in case the Internet has
rewrapped.)
   This is a view of type
   Editible-Text-Dialog-Ite
   m inside the dialog "Edit
   Definition" (type
   String-Dialog).


--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: Malcolm Pradhan <pradhan@camis.stanford.edu>
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Balloon help descenders missing
Date: 9 Jan 1993 06:40:47 GMT
Organization: Section of Medical Informatics, Stanford University
Distribution: world
NNTP-Posting-Host: hoskins-kfps-dynamic.stanford.edu
X-UserAgent: Nuntius v1.1.1d16
X-XXMessage-ID: <A773B3D66E02005C@hoskins-kfps-dynamic.stanford.edu>
X-XXDate: Fri, 8 Jan 93 06:42:30 GMT

In article <199301050753.AA23632@halcyon.com> ,
jwbaxter@halcyon.halcyon.com writes:
>In help balloons related to the content area of the active MCL window,
>descenders are cut off the characters.  Other balloons seem OK.  Line
>spacing seems normal, just no descenders.

 I have had this problem when calling the Help Manager from Prograph
(data-flow language). Prograph's built in balloon help does not have
this problem but when I call the Help Manager directly the descenders
are cut off. I still haven't worked a way around it yet...

 Regards,
 Malcolm
--------------------------------------------
Malcolm Pradhan
Section on Medical Informatics
MSOB X-215, Stanford University, CA, 94305
pradhan@camis.stanford.edu  (415) 725-3398
From: cassels@cambridge.apple.com (Robert A. Cassels)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: screen dump
Date: 4 Jan 93 18:36:09 GMT

At 10:13 AM 1/4/93 -0500, Gerhard Werner wrote:
>In the old Allegro Lisp running in operating system 6 versions, one
>could freeze a picture of the screen for printing, using a program called
>screendump. How can one copy a picture of the screen running MCL in
>system 7 ?

In System 7, Command-shift-3 takes a snapshot of the whole screen.  (See
the "Finder Shortcuts" window, page 5.)  As straz mentioned, there are
various shareware programs that give more fine-grained control over what's
in the picture.
Newsgroups: comp.lang.lisp.mcl
From: gersh@aplpy.jhuapl.edu (John R. Gersh)
Subject: Re: remove-view-from-window
Summary: Works all right for me.
Organization: Johns Hopkins University Applied Physics Lab
Date: Tue, 5 Jan 93 21:28:02 GMT

In article <9301051918.AA19536@newton.apple.com> Maurice Sharp writes:
>
>According to both the manual and MCL.help the arguments to
>remove-view-from-window are a view and a window.
>
>This is not correct, there are actually no arguments.
>

Well, actually there seem to be three versions:
	
	The manual says that the argument to remove-view-from-window
	is a view.

	The built-in documentation (c-x c-d) says that the arguments
	are a view and a window.

	If you inspect the function the inspector window says that its
	arglist is nil.

The manual appears to be correct - the function works as one would
expect from its description if you give it a view as an argument.

>My question... is there some alternate method that I can use instead of
>remove-view-from-window to perform actions prior to a views removal from a
>window or subview?

Well, remove-view-from-window seems to work OK at doing that. Here's
some test code to demonstrate that:

(defclass special-view (view) ())

(defmethod view-draw-contents ((s-v special-view))
  (frame-oval s-v #@(0 0) #@(100 100)))  ;so we can see when the view
				         ;is installed

(defmethod install-view-in-window ((s-v special-view) window)
  (set-back-color window *blue-color*)
  (call-next-method s-v window))

(defmethod remove-view-from-window ((s-v special-view))
  (set-back-color (view-container s-v) *red-color*)
  (call-next-method s-v))

(setf the-view (make-instance 'special-view))

(setf the-window (make-instance 'window :color-p t))

;;Then try the following in succession:

(add-subviews the-window the-view)

(remove-subviews the-window the-view)


---------------------------------------------------------------------
John Gersh                                      John_Gersh@jhuapl.edu
The Johns Hopkins University Applied Physics Laboratory
Johns Hopkins Rd., Laurel, MD 20723		       (301) 953-5503
From: oddmund@idt.unit.no
Newsgroups: comp.lang.lisp.mcl
Subject: Correct to  ignore params to :around methods?
Date: 9 Jan 93 19:50:55 GMT


I use :around methods to bind special variables and then
call call-next-method with no parameters.

This works, but causes compiler warnings for each non-
specialized parameter.

I can get rid of the warnings by declaring to ignore 
the parameters, but I feel uncomfortable doing that since 
the parameters are in fact "used" by the method called 
by call-next-method. Ignoring them works, but would it 
work if my declaration were trusted?

What is the correct way to handle this? 
Thanks for any assistance.

Oddmund Mogedal
oddmund@idt.unit.no

******
Here is an example:

(defvar *test* 0)

(defclass test-class ()
  ((first-slot :accessor first-slot)))

; a perfectly useless method, but that isn't the point
(defmethod set-first-slot ((obj test-class) 
                           new-value)
  (setf (first-slot obj) 
        (+ *test* new-value)))

(defclass test-class-sub (test-class)
  ())

;Evaluating the :around method below causes the
;following compiler warning:
;Compiler warnings :
;   Unused lexical variable NEW-VALUE, in SET-FIRST-SLOT.
(defmethod set-first-slot :around ((obj test-class-sub) 
                                   new-value)
  (let ((*test* 24))
    (call-next-method)))

#|
;The following version gets rid of the warning, but is it
;correct (i.e. would it be correct if my declaration were
;trusted):
(defmethod set-first-slot :around ((obj test-class-sub) 
                                   new-value)
  (declare (ignore new-value))
  (let ((*test* 24))
    (call-next-method)))
|#
From: gwer1@cislabs.pitt.edu (Gerhard Werner)
Newsgroups: comp.lang.lisp.mcl
Subject: <stdin>
Date: 10 Jan 93 16:33:03 GMT

I am hopelessly stuck: the purpose of the following abbreviated code is to use 

the list (items) and build from it a dialog consisting of buttons, 

check-boxes etc.  I am building the list *show-list* for use by 

:view-subviews. I encounter a hopeless tangle of interactions 

among and between buttons and  boxes. The static text items are 

work well.

What are the errors of my way ? Please adevise.

  

(defun init-all-items (items)


  (declare (list items))


     (setf *show-list* '())


     (dolist (item items)


     (let ((display-item (first item))


          (left-x (second item))

     	    (skipping rest)))


            (declare (atom sym left-x left-y right-x right-y) (string dialog-text))


    (cond ((equal display-item :radio)


           (setf *show-list* (append *show-list* (list


                         (make-dialog-item 'radio-button-dialog-item


                         (make-point left-x left-y)


                         (make-point right-x right-y)


                         dialog-text


                          #'(lambda (item)


                              item


                              (set-display-hash sym))


                         :view-font '("Monaco" 12 :plain)


                         :radio-button-cluster 1


                     )))))


          ((equal display-item :check)


           (setf *show-list* (append *show-list* (list


                           (make-dialog-item 'check-box-dialog-item


                           (make-point left-x left-y)


                           (make-point right-x right-y)


                            dialog-text


                            #'(lambda (item)


                                item


                                (set-display-hash sym))


                            :view-font '("Monaco" 9 :bold)


                         )))))                                           


        (t nil))))


     

     (make-instance 'dialog


                  :window-type :document 


                  :window-title "Test Dialog"


                  :view-position #@(20 40)


                  :view-size #@(200 300) 


                  :view-subviews  *show-list*)


     )

                                         


(setf items

   

    T( (:radio 10 110 150 120 "Dysarthria" :dysarthric)


     (:radio 10 130 150 150 "Acute Onset" :course-acute)


     (:check 10 100 120 80 "Married" :status-married)


     (:check 10  80 120 80 "Unemployed" :status-unemployed)


    ))
From: ralex@tigger.cs.colorado.edu (Repenning Alexander)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: MCL support for MOP
Date: 8 Jan 93 04:48:41 GMT

bill@cambridge.apple.com (Bill St. Clair) writes:

> Adding more MOP support to MCL is on my list of
> things to do, but it's not very near the top of the list so I'm not
> likely to do it soon.

I wonder how high the need for MOP support is on the list of typical
MCL users. Some users are worried about the lack of MCL/MOP features.
Others, however, (including me) don't really use MOP and, therefore,
are worried about making trade offs regarding performance and/or
memory.

Questions:

- what impacts would a full MOP implementation have to MCL in terms of
  performance or memory?
  
- could a full MOP implementation be packaged into a separate module 
  (sort of like PCL minus MCL)

One of the many nice things about MCL is its size compared to other
Common Lisp implementations. It allows developers to create
applications able to run on low-end machines. However, If more and
more functionality is creeping into MCL (maybe partly due to the
ANSIfication of the Common Lisp clean up process) I wonder how much
longer this is going to be true.
 

   Alex Repenning
From: lynch@ils.nwu.edu
Newsgroups: comp.lang.lisp.mcl
Subject: Re: flooding region w/ paint -- how?
Date: 5 Jan 93 23:22:59 GMT

>You know how in MacPaint and similar paint programs you can click on a
>pixel and fill the surrounding region with paint?  
>
>I need to do this -- i.e., given a graphics window whose contents I
>know nothing about, and a pixel, flood the region around that pixel
>with paint.  B/W is ok, tho' color would be useful.
>
>I don't suppose there is a primitive quickdraw command for this? :-) 
>Suggestions?
>
>Thanks for your kind attention.

I believe the ToolBox routine you want is call SeedFill, or SeedCFill.

When I last attempted to make it work, I failed miserably.

Good luck.
-- 
--
-- "TANSTAAFL" Rich lynch@ils.nwu.edu