HDTenEightyP/NetNews huggingface dataset:
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: ccl:scrolling window bug?
Date: 19 Nov 92 15:17:13 GMT

>I'm not sure if there is a reason for not doing this, but I've noticed
>that the class ccl::scrolling-windows does not seem to set the update
>region to exclude it's own scroll bars before it continues with the call
>chain.  This means that any views inside of it will automatically draw
>into the scroll bar area.  I'm assuming that the "view-draw-contents"
>methods are all called with the appropriate "with-focused-view" or 
>"with-focused-dialog-item" by the call chain (read that as I'm not
>using this macro within my "view-draw-contents" methods since I assumed
>all that is automatically handled).  Also note that resizing a scrolling
>window is what brings out this view.  If I simply cover up the subview with
>another window (such as the listener), then uncover it, the scroll bars
>seem to be drawn properly.
>
>Is there a fix available for this or am I doing this wrong?

A SCROLLING-WINDOW instance does not expect any subviews besides the
three it creates (a SCROLLER and two scroll bars). Hence, you need
to change your example by making your TEST-VIEW class inherit from
SCROLLER, and by passing a :SCROLLER-CLASS initarg to the MAKE-INSTANCE
for the SCROLLING-WINDOW:

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

(require "QUICKDRAW")
(require "SCROLLING-WINDOWS")

;; define a test class
(defclass test-view (scroller)
  nil)

;; make this a separate routine, so we can move it around the call chain easily
(defmethod draw-code ((me test-view))
   (with-fore-color *yellow-color*
    (paint-rect me 0 0 (point-h (view-size me)) (point-v (view-size me))))
  (with-fore-color *red-color*
    (move-to me 0 0)
    (line-to me (point-h (view-size me)) (point-v (view-size me)))
    (move-to me (point-h (view-size me)) 0)
    (line-to me 0 (point-v (view-size me)))))

(defmethod view-draw-contents ((me test-view))
  (draw-code me))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Create the window with a large subview in it
;;

(make-instance 'ccl::scrolling-window
  :window-title "test"
  :color-p t
  :view-size #@(285 85)
  :scroller-class 'test-view
  :track-thumb-p t)                     ; real-time scrolling
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: basic view-key-event-handler confusion
Date: 18 Nov 92 18:03:59 GMT

>Please help.
>
>There is something *very basic* that I don't understand about 
>view-key-event-handlers, despite having read and re-read
>the docs and sample code a hundred times.  Here is a simple 
>example that fails to handle key events -- all keystrokes go 
>to the listener:
>
>(defclass simple-key-handling-view (dialog-item)
>  ()
>  )
>
>;;; When you get a keystroke, draw that character.
>;;;  ***BUT NOTHING HAPPENS
>
>(defmethod view-key-event-handler ((item simple-key-handling-view)
>char)
>  "Just print the character in the view."
>  (when (integerp char) (setq char (code-char char)))  ; (why?)
>  (move-to item 20 20)
>  (format item "~c" char))
>
>(setq *w* (make-instance 'window))
>(setq *v* (make-instance 'simple-key-handling-view
>            :view-position #@(4 4)
>            :view-size #@(200 200)))
>
>(add-subviews *w* *v*)
>
>;;; (key-handler-p *v*)  --> NIL
>
>
>Please don't tell me to use an instance of some text dialog
>item; I want to do something very special with the keystrokes,
>and anyway there must be a simpler way...
>
>Many, many thanks for your kind attention.

The problem is that the window is not passing the VIEW-KEY-EVENT-HANDLER
call on to your dialog item. If you mix in the KEY-HANDLER-MIXIN class, this
will be done for you. It also makes KEY-HANDLER-P return true.

(defclass simple-key-handling-view (key-handler-mixin dialog-item)
  ()
  )

It looks a little better if you erase before drawing. Also, the CHAR arg
to view-key-event-handler is a character. No need to coerce it from an
integer:

(defmethod view-key-event-handler ((item simple-key-handling-view) char)
  "Just print the character in the view."
;  (when (integerp char) (setq char (code-char char)))  ; (why?)
  (with-focused-view (view-container item)
    (rlet ((rect :rect :topleft #@(0 0) :botright #@(100 100)))
      (#_EraseRect rect)))
  (move-to item 20 20)
  (format item "~c" char))
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: directoryp
Date: 24 Nov 92 01:18:25 GMT

As far as I can tell, there's no Common Lisp portable way
to tell if a directory exists. [Remember a dir can exist
without having any files in it.]

I also can't find a way of creating a directory in CL
without also creating a file in that dir.
I suppose I can create a file in a new dir, then
delete the file, but that's pretty crude.

Am I wrong?
From: kab (Kim Barrett)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Making a lambda-expr more like a fn
Date: 18 Nov 92 16:48:34 GMT

> While reading the messages about turning lambda expressions
> into functions, it seemed to me that the following might be reasonable...
> 
> (defmacro with-environment ((var) &body body &environment env)
>     `(let ((,var ',env))
>        ,@body))
> 
> In an artificial example..
> 
> (let ((x 0))
>         (with-environment (env)
>                 (setf counter-fn
>                                                                                 
(enclose '(lambda () (incf x)) env))))
> 
> However...
> 
> ? (let ((x 'non-nil-environment))
>     (declare (ignore x))
>     (with-environment (var) var))
> #<BOGUS object @ #x5DF871>
> ?
> 
> Does this work in any Lisp?
> Should it?

Macro environments are specified to have dynamic extent.  See CLtL2, p.203, in 
the paragraph beginning "X3J13 voted in March 1989 <117> ...".
From: rik@cs.UCSD.EDU (Rik Belew)
Newsgroups: comp.lang.lisp.mcl
Subject: Making a lambda-expr more like a fn
Date: 16 Nov 92 07:03:06 GMT


One of the changes to CL2 that bit me has been that
raw lambda's can no longer be funcall'd (or apply'd)
directly.

With CMULisp, I have remedied this by coercing the lambda
into a function first:

        (setf (org-lexpr p) (coerce lexpr 'function))

But CCL::COERCE-TO-FUNCTION won't have it:


> Error: value (LAMBDA (WLIST &AUX X1) (SETQ X1 (NTH 0 HISTORY)) (VALUES (+ (CAR WLIST) (* (NTH 1 WLIST) X1)) (LIST 1.0 X1))) is not of the expected type FUNCTION.
> While executing: CCL::COERCE-TO-FUNCTION

I have also tried prepending the #' (function) abbrev., but
that result couldn't be funcalled either.

I was able to get what I wanted compiling the form instead.  However, in
this application, I would like very much to avoid the compilation overhead
if at all possible.  Can I?

Richard K. Belew
Computer Science & Engr. Dept. (C-014)
Univ. California -- San Diego
La Jolla, CA 92093
rik@cs.ucsd.edu
619 / 534-2601
      534-5288 (msgs)
      534-7029 (fax)
From: straz@cambridge.apple.com (Steve Strassmann)
Newsgroups: comp.lang.lisp.mcl
Subject: Basic color use in MCL
Date: 23 Nov 92 16:51:37 GMT

>From: waander@cs.umd.edu (Bill Andersen)
>Newsgroups: comp.lang.lisp.mcl
>Subject: Basic color use in MCL
>Date: 22 Nov 92 08:59:04 GMT
>Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
>
>  But the string just gets drawn in the default foreground
>color of the outermost window.  What's the deal?  Could someone
>supply some examples of how to do stuff with colors??  Maybe
>post it to the archive????

One possibility is that you forgot to specify :COLOR-P T when you created
the window. (I know, I know, I get burned by this myself a lot too. We'll
change the default for :COLOR-P from nil to t in a future release). 

You can make sure this doesn't happen by adding this to your window's defclass:

(defclass my-window (window)
  (... other slots ...)
  (:default-initargs :color-p t))

I've written a pretty simple example file, available in our user library
as cambridge.apple.com:/pub/MCL2/contrib/window-example.lisp.
Newsgroups: comp.lang.lisp.mcl
From: mmm@casimir.lanu.ca.us (Michael Maciag)
Subject: Re: Paradigms of AI by Peter Norvig
Date: Tue, 24 Nov 1992 05:03:56 GMT
Organization: TA Systems

72110.1107@CompuServe.COM (Bruce Lester) writes:

>Does anyone know where I can get "Paradigms of AI by Peter Norvig"?  Publisher
>name and address.

>Bruce Lester
>Pillsbury

Morgan Kaufmann Publishers
San Mateo, California

I bought my copy at:
OPAMP Technical Books (Los Angeles California)
Will take phone orders at:
213.464.4322
-- 
=========================================================================
Michael Maciag		mmm@casimir.lanu.ca.us		uunet!casimir!mmm
=========================================================================
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: bug using array dialog items
Date: 23 Nov 92 20:15:26 GMT

At 13:45 11/20/92 -0600, lynch@ils.nwu.edu wrote:
>Actually, it's not just *white-color*.
>
>If you use, say, *blue-color*, you will note that the selected-cell ends up
>being drawn in blue on [de]activate event.
>Thus, you're disappearing cells are really just being drawn in
>*white-color*.
>
>Also, since view-[de]activate-event-handler do a simple inversion [ack],
>and *white-color* isn't really white, you are probably seeing a color
>indistinguishable (to us humans) from white, that isn't quite white, being
>inverted to a color that is very close to black, but probably isn't quite
>black.
>Now I'm not sure exactly how the inversion gets off-sync, but it sure looks
>like [de]activate-event is not up to snuff for drawing frames.
>
>[ack]:  *NO* method should do any direct drawing except view-draw-contents!

I sent this to dfoster last Thursday, but forgot to cc info-mcl. I'll
send the patch to anyone who wants it. Ask for "table-frame-color-patch".

-Bill

Date: Thu, 19 Nov 1992 10:18:21 -0600
To: dfoster@ils.nwu.edu
From: bill@cambridge.apple.com (Bill St. Clair)
Subject: Re: array-dialog-item bug
Cc: bug-mcl

>;;;  Notice of bug in MCL 2.0
>;;;  David Foster
>;;;  The Institute for the Learning Sciences
>;;;  dfoster@ils.nwu.edu
>;;;
>
>;;;-----------------------------------------------------------------------
>;;;  Bug: when setting the frame of an array dialog item to *white-color*,
>;;;  the window refreshes don't work properly on the cells of the array
>;;;  dialog item.  Cell contents go away, parts of cells covered by other
>;;;  windows never are fixed, etc.
>;;;-----------------------------------------------------------------------
>
>;;; required: code for "array-dialog-item", included in Examples Folder
>
>
>;;;  To observe the problem, type (doit).  Play around with clicking on
>;;;  cells, switching back and forth between windows, partially covering
>;;;  highlighted cells with another window and then reactivating the
>;;;  window, and so forth.
>

The view-activate-event-handler & view-deactivate-event-handler methods
were setting the foreground color so that System 6 scroll bars would be
drawn in the :frame color. This was causing the text to be drawn in the
:frame color as well. The enclosed patch, which will be part of patch 2
for MCL 2.0, should fix this problem.
From: cartier@math.uqam.ca (Guillaume Cartier)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Binary manipulation
Date: 23 Nov 92 21:41:10 GMT

<---
| What is the best way to do binary manipulation of data within MCL?
| I need to do the equivalent of shifts, ands, nors, ors, etc., but the problem
| I'm having is doing these with integers and fixnums  How would you convert the following
| to mcl:
| 
| {
|         short var1 47;
|         unsigned long var2 0x322459;
| 
|         *((var1 & 0x7 << 3) + var2)
| }
| 
| going back and forth between MCL fixnum and bit-arrays (without losing data)?
| 
|         Jeffrey
--->

If I understand your problem correctly you don't need bit-arrays
and can use the whole bunch of CLtL2's boolean functions that will
manipulate integers. See sections 12.7 and 12.8 of CLtL2.

Examples:

? (logior 3 4 5)
7
? (lognot 45)
-46
? (logand 23 1 456)
0

Guillaume.

*********************************************************************
* 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: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: window-size-parts question
Date: 23 Nov 92 20:14:31 GMT

At 19:55 11/18/92 +0000, Kemi Jona wrote:
>When creating a new window, it appears that window-size-parts gets called
>_before_ any subviews are added to it.  Is this intentional?  It seems like
>a mistake to me.  If you want to have a window's subviews adjust
>dynamically to the size of the window, you most certainly would want to
>have them also adjust to whatever :view-size initarg is supplied when that
>window is initially created.
>
>Here's a simple test case:
>
>[...]
>
>Right now I have to call window-size-parts "manually" after all the
>subviews have been added, but before I show the window.
>
>Any ideas?

Sounds like a bug to me. I'll send a patch to anyone who requests it.
This patch will be part of Patch 2 for MCL 2.0.

-Bill
From: mmeehan@eesof.com (Mike Meehan)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: ffi to MCL
Date: 23 Nov 92 20:45:03 GMT


Bill and others...


In my opinion, Think-C and Cartiers excellent package are currently
the only way to go--unless you dont mind the *cost* and speed of mpw-c...
Especially if you already own Think-C! Get a copy of Guillaume's pkg
and try it out...(You dont need to study the lisp in his package to use
it, although it makes for a quality experience in the use of lisp.)

On the horizon, be on the lookout for a stand-alone c/cpp package from
Zortech...

-MM
Newsgroups: comp.lang.lisp.mcl
From: jwbaxter@halcyon.halcyon.com
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Picture-files example
Date: 21 Nov 92 16:56:07 GMT
Original-To: lieber@MEDIA-LAB.MEDIA.MIT.EDU
Original-Cc: info-mcl@cambridge.apple.com

>This may not be Lisp's problem, it may be
>endemic to the underlying pict manipulation functions, as not every Mac
>program seems to agree on picts.
>
Henry,
   A file of type PICT is supposed to contain a 512-byte header area
(written as zeros unless a particular application wants to use it),
followed by the same data structure as a picture handle or PICT resource. 
Either the old or new format picture should work (the new format will
appear blank in some old applications running very old System software).
   The 512-byte header is "left over" from original (ie, 1984) MacPaint,
which stored user-customized patterns there.
   --John

--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
Newsgroups: comp.lang.lisp.mcl
From: nrb!keunen@relay.EU.net (Vincent Keunen)
Newsgroups: comp.lang.lisp.mcl
Subject: [jh%sger.uucp@BBN.COM: Prototype CLIM Builder]
Date: 17 Nov 92 08:52:00 GMT
Reply-To: nrb!keunen@relay.EU.net

Since CLIM 1.1 works on MCL 2.0 final, I'm forwarding this to the
info-mcl list for your information.

vk

    Message-Id: <9211061325.AA05649@sger.SGER.COM>
    Date: 6 Nov 92 14:23:12 U
    From: Jens Herder <jh%sger.uucp@BBN.COM>
    Subject: Prototype CLIM Builder
    To: mcsun!unido!sger!Rainer_Anscheit.BRIEFKASTEN, mcsun!unido!sger!hpb

    Announcement of the article:

			   A Prototype Interface Builder 
		     for the Common Lisp Interface Manager 
				    C L I B

		    Jan Hesse, Rainer Koenig and Filippo Logi
		  Forschungszentrum Informatik (FZI), Technical
			   Expertsystems and Robotics

				  Jens Herder
			   Symbolics Systemhaus GmbH

				   Abstract

    The Common Lisp Interface Manager (CLIM) is used to develop graphical
    user interfaces for Lisp-based applications. With the prototype of the
    CLIM Interface Builder (CLIB) the programmer can generate code for CLIM
    interactively. The developing process will be fast and less prone to errors.
    With this new tool, the interactive rapid prototyping reduces costs of a
    specification phase. Here we present the concept and first results of the
    prototype of CLIB.

    Keywords:

    CLIM, Graphical User Interface, Interface Builder, Lisp, Rapid Prototyping


    A prototype of a CLIM-Interface-Builder is being developed within a joint
    effort of Forschungszentrum Informatik (FZI) and Symbolics Systemhaus GmbH.

    You can get the article in Postcript format via anonymous FTP from gate.fzi.de
    (141.21.4.3, pathname pub/CLIB/CLIB-paper.ps.Z) or in printed form
    (FZI Bericht Nr.6) from the authors. We are pleased to receive comments
    and any response.


    Rainer Koenig

    Forschungszentrum Informatik (FZI),        Tel:    +49 (721) 9654-313
    Technical Expertsystems                    Fax:    +49 (721) 9654-309
    and Robotics                            e-mail:    rkeonig@fzi.de
    Haid-& Neustr. 10-14
    D-7500 Karlsruhe 1
    Germany

    Jens Herder

    Software Development
    Symbolics Systemhaus GmbH                 Tel:    +49 (61 96) 47 22-100
    Mergenthaler Allee 77-81                  Fax:    +49 (61 96) 48 11 16
    D-6236 Eschborn/Ts.                    e-mail:    JH@SGER.UUCP
    Germany                                       (or JH%SGER.UUCP@GERMANY.EU.NET)




--
Never trust a pretty header: use keunen@nrb.be to reply
--
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
Newsgroups: comp.lang.lisp.mcl
From: espen@coli.uni-sb.de (Espen J. Vestre)
Subject: can I copy to a drop folder?
Organization: Computerlinguistik, Universitaet des Saarlandes
Distribution: co
Date: 19 Nov 92 11:03:45 GMT
X-Note1: mail msgid was <1992Nov19.110345.15384@coli.uni-sb.de>
X-Note2: message-id generated by recnews

I would like to be able to copy a file to a "drop" folder, a folder into
which I can drop things (with the Finder), but which I am not allowed to
open.
Using COPY-FILE directly doesn't work, because COPY-FILE tries to look
into the folder, and thus violates the protection of the folder.  
Is it possible at all to do such a copy-operation from MCL?  If not, is
it possible to do it by sending appleevents to the Finder?
--------------------------------------------------------------
Espen J. Vestre,                          espen@coli.uni-sb.de
Universitaet des Saarlandes,        
Computerlinguistik, Gebaeude 17.2 
Im Stadtwald,                          tel. +49 (681) 302 4501
D-6600 SAARBRUECKEN, Germany           fax. +49 (681) 302 4351
--------------------------------------------------------------
Newsgroups: comp.lang.lisp
From: charest@Aig.Jpl.Nasa.Gov (Len Charest)
Subject: Re: Help: apply for macros ???
Reply-To: charest@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Thu, 19 Nov 1992 22:24:19 GMT

In article <2610@bigfoot.first.gmd.de>, wolf@prosun.first.gmd.de (Wolfgang Koehler) writes:
[ asks if it is possible to APPLY #'F where F is the name of a macro. ]

[[ This question and an appropriate answer should appear in the FAQ list. ]]

The short answer is no. Recall that #'F is shorthand for (FUNCTION F). However, F
names a macro--not a function or a LAMBDA-expression--so it is an error to
evaluate (FUNCTION F) (see CLtL2, p 116).* Furthermore, it is not permitted to
write (APPLY F ...) either since "the global function value of that symbol [F] is
used (but it is illegal for the symbol to be the name of a macro or special form."
(CLtL2, p 145)

It is quite possible to work around this problem:

Layered workaround: if you have the source code for the original macro then you
might want to rewrite it such that the macroexpansion is simply a call to a
function. The function may passed to APPLY. Here, the only job of the 
macroexpansion is to interpret, quote, rewrite or otherwise massage the arguments
of the macro. The philosophy behind this approach can be summed up as "If I can 
do it with a macro then I should also be able to do it with an equivalent function
call." Example:

(defun define-widget (name color viscosity)
  ...code to make a widget...)

;;; this macro simply quotes its args
(defmacro defwidget (name &key color viscosity)
  ;;there is an underlying function to do the work
  `(define-widget ',name ',color ',viscosity))

;;; macroexpansion reveals the equivalent function call:
(macroexpand-1 '(defwidget jello :color green)
=> (define-widget 'jello 'green nil)

Encapsulation workaround: you could simply define a function that calls your
macro. One pitfall here is that the macro call will not evaluate its arguments,
so if the macroexpansion quotes any arguments, an explicit call to EVAL
around those arguments will be necessary to get the encapsulation to perform 
correctly.

DEFSUBST workaround: you could redefine your macro as a DEFSUBST--that is, a
function that is proclaimed inline. An inline function *is* a function, so it may
be used with APPLY, but lexical calls to it will also be expanded inline by the
compiler.

#' workaround: you could redefine the #' reader to do whatever you want. I don't
recommend this approach. ;-)
..................................................
                                  Len Charest, Jr.
                 JPL Artificial Intelligence Group
                          charest@aig.jpl.nasa.gov
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.lang.lisp
Date: Fri, 20 Nov 1992 13:42:47 -0500 
From: Andrew Joseph Kompanek <ak10+@andrew.cmu.edu>
Subject: Release Info. on CMU Common Lisp

Can anyone supply me with the following info. on CMU Common Lisp:

1.  Version and date of most recent version.  Is the version 16e?
2.  Should non-Sun users update from 16d to 16e?
3.  When is the newest version due?  Major Revisions?

Will the info. to this board?  Is there are a mailing list that anyone
is aware of?

Thanks,
Drew
Andrew Kompanek
Dept. of Human Genetics
University of Pittsburgh
Newsgroups: comp.lang.lisp
From: jota@iguana.inesc.pt (Joao Pedro Martins)
Subject: Minimax w/ alfa beta cuttofs...
Reply-To: jota@iguana.inesc.pt
Organization: Never Heard Of It, Ltd
Date: Mon, 23 Nov 1992 20:02:03 GMT

	I have implemented a version of the Minimax alfa beta w/ cuttofs 
algorithm, according to the book 'Artificial Inteligence', by Elaine Rich
& Kevin Knight, but unfortunatelly the cuttof part is not working.
	Can someone send me a version of this algorithm (in Common Lisp) ?
It can be other version besides the one in the mentioned book, but 
I would prefer if it was aplication-independent.

Note:
This is NOT for a homework assignment, and not even for a project, it
is for a program I was challenged to do, but after 3 month working on it,
and after having implemented the A* on one part of it, only 2 routines are
missing... and one of these is Minimax-a-b w/ cuttofs...

I would really appreciate any help, 'cause I have reached a dead end... :-(

----
 Joao Pedro Martins, Lisboa, Portugal - jota@iguana.inesc.pt
 
 "cover my face while the animals cry [...],	
  cover my face while the animals die !" (The Cure) 
Organization: Carnegie Mellon, Pittsburgh, PA