HDTenEightyP/NetNews huggingface dataset:
From: theodore-michael@yale.edu (Michael Theodore)
Newsgroups: comp.lang.lisp
Subject: Lucid Lisp complains about this code fragment
Date: 4 Jan 1993 21:50:16 -0500
Organization: Yale University Science & Engineering UNIX(tm), New Haven, CT 06520-2158
NNTP-Posting-Host: minerva.cis.yale.edu

Any thoughts on how to correct this?
For some reason, what follows is no problem on Vax Lisp, nor on Macintosh
Common Lisp, but when run on Lucid Lisp gets a warning :
;;Warning function tweak defined more than once 

I wouldn't care if it weren't for the fact that warning is printed to the 
screen repeatedly (about 50 times).

(defun addNoiseToListOfNumbers (l)
  (defun tweak (x)
    (+
     x
     (- (* (random 1000) 0.0001) 0.05)))
  (mapcar #'tweak l))

Please excuse my ignorance if this is a very obvious problem. 

	Thanks,
	Michael


(BTW, this function is from some code in a book by Mark Watson entitled
"Common Lisp Modules - Artificial Intelligence in the Era of Neural Networks
and Chaos Theory").

-- 
Practice random acts of randomness.........
		theodore-michael@cs.yale.edu
Newsgroups: comp.lang.lisp.x
From: emcoop@bnr.ca (hume smith)
Subject: Re: *unbound* in *obarray*
Organization: Bell-Northern Research, Ottawa, Canada
Date: Sun, 10 Jan 1993 21:34:34 GMT

In article <21495.1993Jan5.174456@bcars148> emcoop@bnr.ca (hume smith) writes:

>  (let* ((ind (hash "*UNBOUND*" (length *obarray*)))
>	 (ls (aref *obarray* ind))
>	 (z (car (member "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
>    (unless (boundp 'z)
>      (setf (aref *obarray* ind) (remove "*UNBOUND*" ls :test #'string= :key #'symbol-name))))

of course boundp doesn't work right (i.e. the way i wish it did :-)
with "letted" variables...  this all has to be done in the global environment.

(setq ind (hash "*UNBOUND*" (length *obarray*))
      ls (aref *obarray* ind)
      z (car (member "*UNBOUND*" ls :test #'string= :key #'symbol-name)))
(unless (boundp 'z)
  (setf (aref *obarray* ind) (remove "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
  
i just LOVE saying stupid things in front of the whole world :-)

to make up for it:  here's a definition with-open-stream.  not much use
in `standard' XLisp, but nice with my client and accept accept functions.
and it can be used on an already-open stream, of course...  the uninterned
symbol protects against things like
     (with-open-stream (x z) (setq x 'b))

(defmacro with-open-stream (sym-stream &rest body)
  (let ((sym (first sym-stream))
        (stream (second sym-stream))
	(gsym (gensym)))
    `(let* ((,gsym ,stream)
	    (,sym ,gsym))
       (unwind-protect 
           (progn ,@body)
         (close ,gsym)))))
--
Hume Smith
hume.smith@acadiau.ca
emcoop@bnr.ca
Newsgroups: comp.lang.lisp.x
From: emcoop@bnr.ca (hume smith)
Subject: Re: Re: *unbound* in *obarray*
Organization: Bell-Northern Research, Ottawa, Canada
X-Poster: Emacs-NNTP-0.1
Date: Wed, 6 Jan 1993 22:35:32 GMT

In <13142@sail.LABS.TEK.COM>, toma@sail.LABS.TEK.COM (Tom Almy) said:
> Hume,
>  The first part of your message appears to be missing.

but apearances can be deceiving!  it was all there.  i guess i really
should be ambitious enough to capitalise.

btw Tom, have you gotten any mail from me lately, like, the last
few days?  i've got a sneaking suspicion my mail connections are
downn...

> You know, I don't know why it wasn't done that way in the first place. If 
> *unbound* was not interned in the first place then everything should work 
> fine (however, special treatment would be needed in the gc, as you seem 
> to be alluding to, and also in save/restore.

what i was actually alluding to was that once my slip of excessively-commented
code was run, if ever EVERY symbol was boundp and fboundp (and whatever other
pointers *unbound* got used in), AND a gc was done, the special symbol would
be collected, probably making ripe chunder later.

i've been theorizing a little on how to fix it... i'm wondering, if s_unbound pointed
to a static (C compile-time) piece of memory, what would hapen.  surely the "figure
out what's used" part of gc would just mark it used, and the "build freelist" part
would just not see it, it not being in a segment.  so it should work.

i've obviously got to wade through the gc code and find out.

it does, still, need treatment in save/restore.

another possibility - now that nil is an actual symbol, how hard would it be to
use the NUL pointer?
--
Hume Smith                      Wenn ich des Tages nicht dreimal
hume.smith@acadiau.ca           mein Schaelchen Coffee trinken darf,
emcoop@bnr.ca              //   so werd' ich ju zu meiner Qual
                         \X/    wie ein verdorrtes Ziegenbraetchen.
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: Re: Re: *unbound* in *obarray*
Date: 7 Jan 93 16:12:53 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

In article <21495.1993Jan6.173532@bcars148> emcoop@bnr.ca (hume smith) writes:
>In <13142@sail.LABS.TEK.COM>, toma@sail.LABS.TEK.COM (Tom Almy) said:

>btw Tom, have you gotten any mail from me lately, like, the last
>few days?  i've got a sneaking suspicion my mail connections are
>downn...

No mail, it's down, I guess.

>> You know, I don't know why it wasn't done that way in the first place. If 
>> *unbound* was not interned in the first place then everything should work 
>> fine (however, special treatment would be needed in the gc, as you seem 
>> to be alluding to, and also in save/restore.

>what i was actually alluding to was that once my slip of excessively-commented
>code was run, if ever EVERY symbol was boundp and fboundp (and whatever other
>pointers *unbound* got used in), AND a gc was done, the special symbol would
>be collected, probably making ripe chunder later.

Yes, that's why I stated "special treatment" in the GC. It would need to be
explicitly marked, just like objects in the stacks.

>i've been theorizing a little on how to fix it... i'm wondering, if s_unbound pointed
>to a static (C compile-time) piece of memory, what would hapen.  

After the post, I thought of that too. There is no real reason that a normal 
symbol would have to be used (same case as NIL).

As to making the value NULL (since NIL != NULL), no thanks! I'm just glad I 
finally cleaned out that can of worms!

Tom
-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
From: toma@sail.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.lisp.x
Subject: Re: *unbound* in *obarray*
Date: 6 Jan 93 15:38:18 GMT
Reply-To: toma@sail.labs.tek.com
Organization: Tektronix, Inc., Beaverton,  OR.

In article <21495.1993Jan5.174456@bcars148> emcoop@bnr.ca (hume smith) writes:
>prompted by boredom...  the only thing i wonder (it just occurred to me) -
>if there were no unbound symbols when a garbage collection occurred, would
>the special symbol disappear?  it's unlikely to happen, but still...

Hume,
 The first part of your message appears to be missing.

>;;; XLisp knows whether a symbol is bound or not by whether a particular
>;;; symbol is bound to its value or function field.
>;;; that symbol is internal; i.e. in the obarray.  this can make for
>;;; nasties when you want to manipulate the obarray.  it also creates
>;;; certain strange situations:
>;;;  (setq z '*unbound*)  ->  *unbound*
>;;;  (boundp z)  ->  nil
>;;; it would probably be better if that symbol were not in the
>;;; obarray. 

You know, I don't know why it wasn't done that way in the first place. If 
*unbound* was not interned in the first place then everything should work 
fine (however, special treatment would be needed in the gc, as you seem 
to be alluding to, and also in save/restore.

Tom


-- 
Tom Almy
toma@sail.labs.tek.com
Standard Disclaimers Apply
Newsgroups: comp.lang.lisp.x
From: emcoop@bnr.ca (hume smith)
Subject: *unbound* in *obarray*
Organization: Bell-Northern Research, Ottawa, Canada
X-Poster: Emacs-NNTP-0.1
Date: Tue, 5 Jan 1993 22:44:56 GMT

prompted by boredom...  the only thing i wonder (it just occurred to me) -
if there were no unbound symbols when a garbage collection occurred, would
the special symbol disappear?  it's unlikely to happen, but still...

once this is run it's easy to write things that explore the obarray
without tripping over an Unbound Symbol error.

;;; XLisp knows whether a symbol is bound or not by whether a particular
;;; symbol is bound to its value or function field.
;;; that symbol is internal; i.e. in the obarray.  this can make for
;;; nasties when you want to manipulate the obarray.  it also creates
;;; certain strange situations:
;;;  (setq z '*unbound*)  ->  *unbound*
;;;  (boundp z)  ->  nil
;;; it would probably be better if that symbol were not in the
;;; obarray.  the following code safely removes it.

(let* ((ind (hash "*UNBOUND*" (length *obarray*)))
       (ls (aref *obarray* ind))
       (z (car (member "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
  (unless (boundp 'z)
    ;; it's possible that the special *unbound* had already been removed,
    ;; in which case z is nil; or that another symbol named *unbound* without
    ;; the special semantics has been created.  the check we just did
    ;; ensures that the special *unbound* is still in the obarray.
    (setf (aref *obarray* ind) (remove "*UNBOUND*" ls :test #'string= :key #'symbol-name))))
--
Hume Smith                      Wenn ich des Tages nicht dreimal
hume.smith@acadiau.ca           mein Schaelchen Coffee trinken darf,
emcoop@bnr.ca              //   so werd' ich ju zu meiner Qual
                         \X/    wie ein verdorrtes Ziegenbraetchen.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Introduction to CLOS
Date: 12 Jan 93 15:58:27 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1993Jan12.113923.22333@cs.tu-berlin.de> net@cs.tu-berlin.de (Oliver Laumann) writes:
>I'm looking for a short overview or introduction to CLOS that is available
>as a file on an FTP server or elsewhere in the net.

I don't know of an online paper, but if you can get back issues of
Communications of the ACM I believe there was an overview of CLOS in the
special issue on LISP about a year and a half ago.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: draft standard question
Date: 4 Jan 1993 19:57:57 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <21495.1993Jan4.123513@bcars148> emcoop@bnr.ca (hume smith) writes:
>now that the public review period is over, and considering that they wouldn't
>take email notices anyway, what would now the best way to mention that there
>are conflicts in the descriptions of atan and atanh?

There's almost certainly going to be a second public review period, to
review the version of the draft that results from fixing the problems
during the first review.  You can raise this issue then.  Unfortunately, if
fixing it requires making a technical change to the draft, that would force
a third revision and public review.

X3J13 isn't technically restricted to making changes only as a result of
review comments, although I believe we're trying to limit ourselves to
this.  Please send me a description of the problem and I'll see what needs
to be done about it.

What does not taking email comments have to do with it?
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.lisp
Subject: Acorns & Nexts & LISP
From: agapow@latcs1.lat.oz.au (p-m agapow)
Date: Mon, 11 Jan 1993 00:49:48 GMT
Organization: Calvin Coolidge Home for Dead Biologists

Hi folks,

We've had a few queries down here from people wanting some software of
ours on Acorns and on Nexts. Fortunately the software is written in Common
LISP so we have little trouble in the past getting it to various flavours
of Unix, Mac, Dos etc. etc. So the $64,000 question is :

Whats available on the Next and Acorns in the way of LISP? Is AKCL
available? Any versions to watch out for? Any tricks to the port?

Thanks. If there's sufficient demand, i'll summarise.

p-m

--------------------------------------------------------------------------------
paul-michael agapow (agapow@latcs1.oz.au) Machine Intelligence Lab, LaTrobe Uni

        "Teenage sex, nuclear winter, Junior Miss fashion 
               & the mechanics of emotional capitalism ..."
From: haible@ma2s3.uucp (Bruno Haible)
Newsgroups: comp.lang.lisp
Subject: Re: (SETF VALUES)
Date: 12 Jan 1993 15:50:58 GMT
Organization: University of Karlsruhe, Germany
NNTP-Posting-Host: ma2s3.mathematik.uni-karlsruhe.de
Summary: multiple-value-setq obsolete
Keywords: places, multiple-value-setq, let

sjameson@atl.ge.com writes:
> Thank you, I understand now. I don't have a Cltl2 or draft standard handy, but
> isn't there such a thing as multiple-value-setf which would serve exactly this
> purpose? 

There is MULTIPLE-VALUE-SETQ, but this one only handles symbols as places.
The good thing about the (VALUES ...) place is that it makes
MULTIPLE-VALUE-SETQ obsolete. You can also write macros LETF and LETF* that
make MULTIPLE-VALUE-BIND obsolete. You can then write

(letf* (((values x y) (values (car l) (cdr l)))
        ((values q r) (floor x y)))
  (foo q r)
)

which expands into

(let ((x (car l)) (y (cdr l)))
  (multiple-value-bind (q r) (floor x y)
    (foo q r)
) )


Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de
From: pierce@at-mail-server.vitro.com ("pierce")
Newsgroups: comp.lang.lisp.mcl
Subject: RE: Reducing Size of MCL applications
Date: 11 Jan 93 04:05:15 GMT

>>We'll probably be looking into a few ways to reduce the size of MCL (though
>>probably not for 2.1). Some ideas are:
>>
>>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 discussion seems to be implying that size of MCL applications is the only
issue preventing the rapid delivery of commercial applications in MCL.  

Let me emphasize that I believe the ability to integrate existing foreign C++
libraries and application frameworks such as Bedrock with MCL code is equally
important.  The Lisp community should not have to reinvent everything and MCL
should not prevent MCL developers from benefiting from existing foreign code. 
Supporting hybrid application development would make MCL applications smaller
and allow MCL developers to work with other programming team members or other
programming teams who have chosen C++ without having to convince them to switch
to Lisp.

-Jonathan Pierce

pierce@Vitro.com
From: kaye@linc.cis.upenn.edu (Jonathan Kaye)
Newsgroups: comp.lang.lisp.mcl
Subject: scrollbars & growbox in sequence-dialog-items
Date: 7 Jan 93 00:23:46 GMT


I have two embarrassingly simple questions:

1. How does one control the behavior of a scrollbar in a
sequence-dialog-item?  Specifically, when my text runs out of the
visible part of a sequence-dialog-item, when I click on the horiz
scrollbar, it shows blank simply.  I assume the text is there but the
step size or something is out of whack.

2. How does one install a grow box in a sequence-dialog-item?  The
documentation for :GROW-ICON-P in table-dialog-item is kind of
vague.  I tried setting this to T, but nothing happened.  It seems
a little tricky because I want it to coincide with the listbox's
container view's growth (would I really have to shadow the method
for growing the container view?)

Any help would be appreciated!

-jonathan
From: bhyde@gensym.com (Ben A. Hyde)
Newsgroups: comp.lang.lisp.mcl
Subject: Tree shaking.
Date: 12 Jan 93 14:57:43 GMT

There are two things that make tree shaking hard in Common Lisp.

The first is symbol-function.  Any quoted symbol in your sources may
have symbol-function applied, sooner or later.

The second is the integrated design of Common Lisp.  Errors use the
class system.  Errors use format.  Format uses streams and all of
arithmetic.  Etc. etc.

Of course HARD work, coupled pragmatic advice from the application builder
can over come both of these.

  - ben
From: howell@cats.UCSC.EDU
Newsgroups: comp.lang.lisp.mcl
Subject: applications
Date: 8 Jan 93 21:48:38 GMT


Dear Bill:

First, this is a fabulous net...I am delighted to be on it.

Second, a "tree shaker to automagically" would be a fabulous thing to have
as I suspect I don't use more than half of the functions compiled into my
applications.

Best,

Dave Cope
Newsgroups: comp.lang.lisp.mcl
From: brent@ssd.csd.harris.com (Brent Benson)
Subject: Re: Re2: MCL support for MOP
Organization: Harris Computer Systems
Date: Mon, 11 Jan 1993 15:32:00 GMT

UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,GB,IDV) writes:

> 1) A tree shaker - could be neat, but sounds like a lot of effort
> given the sneaky ways that fruit can be accessed.

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
about other difficulties.



--
Brent Benson                     
Harris Computer Systems
From: jbk@world.std.com (Jeffrey B Kane)
Newsgroups: comp.lang.lisp.mcl
Subject: getting selected text
Date: 11 Jan 93 15:38:08 GMT


What is the best approach to reading selected text from a
Fred window?  Since it's not a stream subject to random
i/o, I'm not sure how to get the actual characters after
I determine the selection range.

             Jeffrey


======================================
Jeffrey Kane, MD
Kane Biomedical Systems
Boston, MA

Internet    jbk@world.std.com
Compuserve  74206,640
AppleLink   D0738
200518
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Balloon help descenders missing
Date: 7 Jan 93 20:14:48 GMT

>In this sequence:
>1. Launch MCL 2.0p1
>2. Bring up one of the various dialogs (first seen with the dialog posed by
>the Environment... item in the Tools menu)
>3. Turn on balloon help.

Thank you for telling me how to reliably duplicate this problem.
I have seen it from time to time, but never knew how to make it
happen reliably. Your message motivated me to look at the problem
again, and I found a fix this time:

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

; help-descenders-patch.lisp
;
; Fix the missing descenders in MCL's balloon help.
; This is a source patch for "ccl:library;help-manager.lisp".

(defun help-tehandle (string &aux (length (length string)))
   "returns a texthandle with string as it's string contents. There is one terec *help-tehandle*"
   (let ((terec *help-tehandle*)
         font size)
     (if terec
       ; Necessary because bug in system neglects to initialize these.
       (setf (href terec :terec.destrect.topleft) #@(5 5)
             (href terec :terec.destrect.botRight) #@(100 100)
             (href terec :terec.viewrect.topleft) #@(5 5)
             (href terec :terec.viewrect.botRight) #@(100 100))
       (rlet ((r :rect
                 :topleft #@(5 5)
                 :bottomright #@(100 100)))
         (setq *help-tehandle* (setq terec (#_tenew r r)))))
     (rlet ((font-info :integer))
       (#_HMGetFont font-info)
       (setf (href terec :terec.txfont)
             (setq font (%get-word font-info)))
       (#_HMGetFontSize font-info)
       (setf (href terec :terec.txsize)
             (setq size (%get-word font-info)))
       (setf (href terec :terec.txmode) 0)
       (setf (href terec :terec.txface) 0))
     (multiple-value-bind (ascent descent maxwid leading)
                          (font-codes-info (make-point 0 font)
                                           (make-point size 0))
       (declare (ignore maxwid))
       (setf (href terec :terec.fontascent) ascent
             ; maybe this should be just (+ ascent descent)
             (href terec :terec.lineheight) (+ ascent descent leading)))
     (with-cstr (cs string 0 length)
       (#_tesettext cs length terec))
     terec))
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: please send bug reports to bug-mcl, not me
Date: 8 Jan 93 22:34:57 GMT

I have recently received quite a few MCL bug reports that were
addressed directly to me instead of to bug-mcl. As many of you
have obviously noticed, I do a large portion of the responding to
MCL bugs. However, I am not as familiar with some parts of MCL as
are some of the other people who read bug-mcl. Also, if you send
to bug-mcl, Mark Preece will enter your bug report in his list of
bug reports, and will prompt the rest of us from time to time to
go over the list. It will also be archived on our mail server.
I'm a bit looser about tracking bug reports. If you send one directly
to me, I will usually manage to either answer or forward to bug-mcl, but
sometimes I'll be busy, your message will scroll off the top of my inbox,
and end up in my mail archive never to be seen again.

Conclusion: please send MCL bug reports to bug-mcl@cambridge.apple.com,
not directly to me. I'm just as likely to answer bug-mcl mail as my
own personal mail, and your message is less likely to be dropped on
the floor.

Also, if your message is a general question about how to do something
with MCL, and not a bug report, you'll probably do better to send it
to info-mcl@cambridge.apple.com, rather than bug-mcl. Hundreds of smart
people from all over the world read info-mcl, and one of them may be
able to help you. You'll also reduce my mail load and allow me to spend
more of my time working on new features for MCL.

-----
Bill St. Clair
bill@cambridge.apple.com
From: jbk@world.std.com (Jeffrey B Kane)
Newsgroups: comp.lang.lisp.mcl
Subject: getting selected text
Date: 11 Jan 93 14:08:04 GMT


What is the best approach to reading selected text from a
Fred window?  Since it's not a stream subject to random
i/o, I'm not sure how to get the actual characters after
I determine the selection range.

             Jeffrey


======================================
Jeffrey Kane, MD
Kane Biomedical Systems
Boston, MA

Internet    jbk@world.std.com
Compuserve  74206,640
AppleLink   D0738