HDTenEightyP/NetNews huggingface dataset:
From: hall@aplcen.apl.jhu.edu (Marty Hall)
Newsgroups: comp.lang.lisp
Subject: Re: power
Date: 19 Aug 92 14:03:58 GMT
Reply-To: hall@aplcen (Marty Hall)
Organization: AAI Corp AI Lab, JHU P/T CS Faculty

In article <IeYOkQy00iQQ8sCkN7@andrew.cmu.edu> gh1h+@andrew.cmu.edu 
(Gary Hooyman) writes:

>Does anyone have a general (power base-number power-number) that works
>better than Lucid's implementation of (expt bn pn)?  
>
>-> (expt 0.658 .5)
>1.8641498069802828E9
>
>I need something that at least gets close!  Maybe this is a bug in my
>version? (v 4.0)

4.0.1 and the older 4.0 (that came with KEE) on the Sun both work fine.

						- Marty
(proclaim '(inline skates))
From: york@oakland-hills.lucid.com (Bill York)
Newsgroups: comp.lang.lisp
Subject: Re: need some help with conditions and CLIM
Date: 20 Aug 92 18:53:51 GMT
Reply-To: York@Lucid.COM
Distribution: comp
Organization: Lucid, Inc.

In article <CHYDE.92Aug20142411@pecos.ads.com> chyde@pecos.ads.com (Clinton Hyde) writes:

   From: chyde@pecos.ads.com (Clinton Hyde)

   anyway, I would like to know how (if it's possible) to find out
   programmatically (or is that automagically) what condition is
   signalled when some piece of code does so.

You could try wrapping the following around the offending code
(represented here is "(/ 3 0)").

(handler-case (/ 3 0)
	      (error (e) (format t "~&The condition ~S was signalled" e)))
From: William.Lott@cs.cmu.edu
Newsgroups: comp.lang.lisp
Subject: Re: Calling C function from LCL
Date: 20 Aug 92 00:22:27 GMT
Article-I.D.: cs.4eYpN3W00jeiEkhC8z
	<16u3jhINN9m1@early-bird.think.com>
Organization: Carnegie Mellon, Pittsburgh, PA

barmar@think.com (Barry Margolin) writes:
> Fixnums have the type tags 00 (positive fixnum) and 11 (negative fixnum);
> this has the property that the tagged value is the result of an arithmetic
> shift of the untagged value, which allows them to be added without
> untagging, and multiplied by shifting the result rather than the arguments.

Are those tags on the low end or high end of the word?  If they are on
the low end, then how does adding two negative fixnums result in
anything useful (xxx11 + xxx11 = xxx10)?  If they are on the high end,
where does the shift come in?

We [CMU Common Lisp, that is] use the low three bits as a type-tag,
but have 000 for even fixnums and 100 for odd fixnums.  In other
words, if the low two bits are 00 then it is a fixnum with the value
in the upper 30 bits.  The implicit multiplication by 4 is handy when
accessing arrays of word (4 byte) sized objects: it's pre-scaled.

-William Lott
CMU Common Lisp Group
Newsgroups: comp.lang.lisp
From: berlage@gmd.de (Thomas Berlage)
Subject: Re: Lucid Lisp w/Knowledge Craft and CLX running under Motif?
Organization: GMD, Sankt Augustin, Germany
Date: Fri, 21 Aug 1992 06:20:26 GMT

In <1992Aug20.204016.23188@e3u001.ped.pto.ford.com> cannell@ed8217.ped.pto.ford.com (Larry Cannell) writes:
>Question: Will the KC/Lucid/CLX application have problems running under
>OSF/Motif?  If so, what kind of problems?

The only major problem I can think of is that your CLX code needs to follow
the ICCCM (Inter Client Communications Conventions Manual) that can be found
in the MIT X distribution. If not, you may have some problems with the Motif
window manager (mwm). That should not be too difficult to fix.

However, compared to other Motif programs your application may not look as
nice and may have a different feel (mouse buttons etc.). If you require that
your application is style-compatible with other Motif apps, then you could
use our Lisp binding for Motif called CLM (see the file CLM+GINA.README on
export.lcs.mit.edu in /contrib or on ftp.gmd.de in /gmd/gina). You could use
CLM to add Motif-style menus, scroll bars and dialog boxes to your
application. You will still need parts of your CLX code for custom drawings
etc.

Contact me for any further questions on CLM and GINA (GINA is a layer on top
of CLM and CLX, you can use it to write new graphical applications much more
easily).

Btw., do not confuse CLM with CLIM, the latter is a commercial interface
package.

Thomas Berlage (berlage@gmd.de)
GMD (German National Research Center for Computer Science)
P.O. Box 1316, 5205 Sankt Augustin 1, Germany
Newsgroups: comp.lang.lisp
From: iscleekk@nuscc.nus.sg (LEE KOK KIONG JAMES)
Subject: load pathnames in akcl
Organization: National University of Singapore
Date: Sat, 22 Aug 1992 05:22:00 GMT

How does one set paths in akcl so that every load or require
function call will go and search for the files directories
specified in paths? I've come across *load-pathname* but have
no success so far. What should I do?

Please reply via email.

Thanks

James KK Lee
-- 
James Kok-Kiong LEE                              leekk@iscs.nus.sg 
Dept of Information Systems & Computer Science   Tel: (65) 772 2906
National University of Singapore, S(0511)        Fax: (65) 779-4580
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: CLIM 2.0 release date?
Date: 21 Aug 92 19:59:52 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <BtBynH.L7F@news.larc.nasa.gov> smith@icat.larc.nasa.gov (Steven L. Smith) writes:
>Hi - When will CLIM 2.0 be officially released? Also, will the major lisp
>vendors (Symbolics, Franz, etc) release 2.0 at the same time? Thanks.

I don't think specific release dates were mentioned at the LUV-92
conference.

Symbolics said that CLIM 2.0 would go into beta release this fall at the
same time as they release the next Genera 8.1 ECO.

Lucid said that CLIM 2.0 is a 1992 development goal.

I didn't take notes during Franz's presentation, and I don't remember what
they said specifically about CLIM 2.0 timelines.

Franz and Symbolics are currently working together on their
implementations, so they'll probably release around the same time.  Lucid
is working with them on developing the documentation, but not on the
coding.

I think most of the vendors were demoing prototype implementations at the
conference.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: konstan@elmer-fudd.cs.berkeley.edu (Joe Konstan)
Newsgroups: comp.lang.lisp
Subject: Re: power
Date: 19 Aug 1992 03:35:42 GMT
Organization: Picasso Research Group, UCB Computer Science Division
Distribution: world
NNTP-Posting-Host: elmer-fudd.cs.berkeley.edu

In article <IeYOkQy00iQQ8sCkN7@andrew.cmu.edu>, Gary Hooyman <gh1h+@andrew.cmu.edu> writes:
|> Hello,
|> 
|> Does anyone have a general (power base-number power-number) that works
|> better than Lucid's implementation of (expt bn pn)?  
|> 
|> -> (expt 0.658 .5)
|> 1.8641498069802828E9
|> 
|> 
|> I need something that at least gets close!  Maybe this is a bug in my
|> version? (v 4.0)

Must be,  I tried it on Lucid 4.0.1+(4-Jun-91) and it returned the correct
answer.

Joe Konstan
Newsgroups: comp.lang.lisp
From: lstead@bellcore.com (Larry Stead)
Subject: Re: Allegro IPC / C interface question
Organization: /ul/lstead/.organization
Distribution: usa
Date: 13 Aug 92 11:33:21

--
Xref: sparky comp.lang.lisp:2215 news.answers:2476
From: doug@saturn.ads.com (Doug Morgan)
Subject: Re: Calling C function from LCL
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Wed, 19 Aug 1992 17:25:20 GMT

In article <Bt8G1E.229@iai.kfk.de> harry@issun1.kfk.de (Harald Kucharek) writes:
   I have the following little C program:
   ...
   ca(my_array)
	   int             my_array[2][2];
   ..
   which I want to call from LISP (I am using Lucid Common Lisp 4.0.1 on a SPARCstation330)
   I define:

   (def-foreign-function (run-ca (:return-type :signed-32bit)
	...(my_array (:array :signed-32bit (4))))
   ...
   (setq a (make-array '(2 2) :element-type 'integer))
   ...
   Questions:

   1) What is this missing symbol __DYNAMIC
   2) The contents of the array are all multiplied by 4. Has this something
      to do with the type of the lisp object? I always thought, it is coded in the high order
      bits of the data.
   3) What is wrong in my declaration of the foreign function, that make all these things happen?

   Harald

The problem should be in your make-array.  The type 'integer is very
general and results in all elements being tagged.  Instead, use
'(signed-byte 32).  Also, Lucid seems to use the low order two bits
for type tags.  I don't know what __DYNAMIC is.

Also, I don't think 'fixnum even gives you what you want.  Each fixnum
in the array will have tag bits.  (This is reaching back a ways for me
and could easily be wrong.)

doug
--------------------------------------------------------------------
Doug Morgan, doug@ads.com, (415) 960-7300
Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
1500 Plymouth St., Mountain View, CA 94043-1230
--------------------------------------------------------------------
Newsgroups: comp.lang.lisp,comp.lang.clos,comp.lang.misc,comp.object,comp.std.misc,comp.lang.scheme,comp.ai
From: chucko@kronos.arc.nasa.gov (Chuck Fry)
Subject: Re: Common Lisp is a dpANS in Public Review
Organization: Recom Technologies, NASA Ames Research Center, Moffett Field, CA
Date: Thu, 20 Aug 1992 19:34:36 GMT

In article <CHYDE.92Aug20142758@pecos.ads.com> chyde@pecos.ads.com (Clinton Hyde) writes:
>this is cool. how about if an electronic copy (which I understand to
>be both Tex and DVI versions) gets into an anon-ftp site?

I was just thinking that once it becomes a standard, it should be
available on CD-ROM, preferably with a KWIC index and a (reasonably)
portable accessor program written in CL, and tied to the DOCUMENTATION
mechanism already in the language!  Any takers?

 -- Chuck Fry  Chucko@charon.arc.nasa.gov
    Chair, Lisp Users and Vendors '93 conference

Newsgroups: comp.lang.lisp
From: ram+@cs.cmu.edu (Rob MacLachlan)
Subject: Re: Mutually Referential DEFSTRUCT Slot Types: How?
Organization: School of Computer Science, Carnegie Mellon
Distribution: comp
Date: Tue, 18 Aug 1992 18:10:35 GMT

In article <16d8rrINNm7q@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <EEIDE.92Aug12120727@asylum.cs.utah.edu> eeide%asylum.cs.utah.edu@cs.utah.edu (Eric Eide) writes:
>>I would like to write something like the following in Common Lisp:
>>
>>  (defstruct a
>>    (slot nil :type b))
>>
>>  (defstruct b
>>    (slot nil :type a))
>

The ANSI draft says that:
    "it is permissable for an unknown type to appear in a declaration
    at compile time, though a warning might be signalled in this
    case."

The rationale (which didn't make it into the standard) for this
decision was to support constructs such as the above.

Barmar suggests:
>(defstruct a
>  slot)
>
[...]
>
>(declaim (ftype a-slot (a) b))
>

Nit: the syntax for the FTYPE declaration should be:
    (declaim (ftype (function (a) b) a-slot))

>Except that this doesn't permit you to declare that the type of the new
>value when SETFing A-SLOT must be B.

You could:
    (declaim (ftype (function (b a) b) (setf a-slot)))

but the standard doesn't seem to require structure slot setters to be
SETF functions (though the integration of structures and CLOS would
suggest this approach.)
 
>>but I think that this type specifier would not give my compiler
>>enough information to allow it to opencode my structure accessors.
>>Speed is important in my application, but probably not critically
>>so.
>
>I'm not sure that this particular set of declarations is likely to be used
>by most implementations.  What kind of open coding do you expect it to
>enable?

Any Common Lisp implementation should open-code uses of slot
accessors as long as the structure definition has been seen by the
compiler.  It won't matter what the slot types are or what is known
about the types of the actual operands to the accessors (which are
required to be of the correct type.)

CMU Common Lisp does respect to these declarations, but the main
advantage of specifying the types of structure-valued slots is better
run-time error detection and reduced cost for run-time type checking.
In other words, it is more of a robustness advantage than an
efficency advantage.  

There can be a significant efficency advantage for slot type
declarations such as FIXNUM, SIMPLE-BASE-STRING, SIMPLE-VECTOR, etc.,
since a good compiler will be able to automatically use the appropriate
type-specific operations on values of those slots.

>>Second, how can I create an instance of either of these objects,
>>while keeping the declared types accurate?

You can't.  Our coding practice for CMU Common Lisp is to
explicitly specify how we are going to "ground out" the recursion:
  (defstruct a
    (slot nil :type (or b null)))

  (defstruct b
    (slot (error "Slot must be supplied.") :type a))

You make the A first with a null SLOT, then make the B, then
back-patch the A.

  Robert A. MacLachlan
Newsgroups: comp.lang.lisp.x
From: sverkerw@Minsk.docs.uu.se (Sverker Wiberg)
Subject: 8-bit chars
Organization: UDAC, Uppsala, Sweden
Date: Wed, 19 Aug 1992 14:16:25 GMT

Is there any XLisp-hack which allows 8-bit characters in strings.

I tried this with XLisp 2.1 on my PC at home:
                 
>(format t "Lisp \"ar roligt")
and then I pressed my Swedish a-diaraesis key and XLisp barfed.
(Illegal character I think it said).

In the example above I used TeXconventions for the funny letter.
And it means "Lisp is fun" in English.

--
--------------------------------------------------------------------------------
#include<stddisclaim.h>	         Every interesting data structure is recursive.
sverkerw@mizar.docs.uu.se (Sverker Wiberg)		                  /Cons
--------------------------------------------------------------------------------
From: schweik@cpp.ob.open.de (Martin Schweikert)
Newsgroups: comp.lang.lisp.x
Subject: Re: 8-bit chars
Date: 21 Aug 92 15:35:18 GMT
Organization: Private/FRG

sverkerw@Minsk.docs.uu.se (Sverker Wiberg) writes:

>Is there any XLisp-hack which allows 8-bit characters in strings.

I would love that, too. Somebody else? Write to Dave Betz. I did, and
he told me that 8-bit characters might be allowed in a future
release. The more people are demanding it, the sooner he'll implement
it, I think ;-)

Martin
-- 
M. Schweikert-Oberhausen/Germany-schweik@cpp.ob.open.de /    My life is based on
 <>< Life-Net: martin_schweikert@credo.zer (Joh3:16)   /   two things: Belief in
   Fax: +49 208 85 97 108, Phone: +49 208 85 97 142   /  Christ and Murphy's Law
From: steve.rainwater@ocitor.fidonet.org (Steve Rainwater)
Sender: FredGate@ocitor.fidonet
From: ptw@riverside.scrc.symbolics.com (P. T. Withington)
Newsgroups: comp.lang.lisp
Subject: Re: "Next-iteration" clause in Loop macro?
Date: 14 Aug 92 14:23:15 GMT
Organization: LCS news/mail gateway
X-Unparseable-Date: Fri


    Date: Fri, 14 Aug 1992 03:53 EDT
    From: Barry Margolin <barmar@think.com>

    In article <16eujtINNhma@agate.berkeley.edu> konstan@cs.berkeley.edu (Joe Konstan) writes:
    >Is there a clause or macro within loop to cause execution to continue 
    >at the next iteration?  

    I don't think so.  There's a macro to terminate the entire loop,
    LOOP-FINISH.

Gee, I could've sworn there was a LOOP-CONTINUE macro in some LOOP
dialect; but I can't find it in any I have references on.  Perhaps I
dreamt it.  I can't think of a case where I couldn't get by without it,
but there are certainly times I wished I had it!

    >			 If not, is adding a label at the start of the 
    >loop-body and "go"ing there guaranteed to work--or might that not properly
    >execute the loop stepping code (which would mean that I need to instead
    >go to the bottom of the loop).  

    It's not going to work at all, since you can't put GO tags in loop bodies.
    Symbols are treated as LOOP keywords, not tags.
    -- 
    Barry Margolin
    System Manager, Thinking Machines Corp.

    barmar@think.com          {uunet,harvard}!think!barmar
Xref: sparky comp.lang.lisp:2282 comp.lang.clos:694 comp.lang.misc:2765 comp.object:3300 comp.std.misc:111 comp.lang.scheme:2081 comp.ai:3181
From: mi@ponder.csci.unt.edu (Mark Interrante)
Subject: Comparison BTW Franz/Lucid
Organization: University of North Texas, Denton
Date: Sun, 16 Aug 1992 10:05:25 GMT

I am developing some code on Sun Commonlisp (which I just found out is 
discontinued)  and need t otherefore port to the code to another product.
The code makes use of the lightwieght threads facility in SunCL and I 
would like the new environment to support a similar flavor of threads.

This has already been discussed, what is the net wisdom about the relative
merits between Franz and Lucid? I will summarize if there are enough 
responses.  Thanks,

Mark Interrante
Newsgroups: comp.lang.lisp
From: layer@Franz.COM (Kevin Layer)
Subject: Re: floating point precision
Organization: Franz Inc., Berkeley, CA
	<1992Aug14.175857.7314@cs.yale.edu> <16igqkINNo4h@early-bird.think.com>
Date: Mon, 17 Aug 1992 17:48:40 GMT

For what it's worth, Allegro CL supports two types of floats
(corresponding to the IEEE single and double floats).
--
-----
Kevin Layer, Franz Inc.         1995 University Avenue, Suite 275
layer@Franz.COM (internet)      Berkeley, CA  94704  USA
Phone: (510) 548-3600           FAX: (510) 548-8253
Newsgroups: comp.lang.lisp
From: scm@aiware.in-berlin.de (Harald Schmidt)
Subject: Scheme or CommonLisp
Keywords: lang
Organization: AIware
Date: Wed, 12 Aug 1992 22:44:46 GMT

Hallihallo,

I am sure this discussion is very old (sorry) but I am an
novice in lisp, so here is my problem:

I would like to start learning Lisp and do not know which
dialect I should use (Scheme or CommonLisp).
My aim is to work in any company, so this is my next question,
which dialect is mostly used in companies? 

Much thanks in advance,

	Harald
-- 
User:		Harald Schmidt
E-Mail:		scm@aiware.in-berlin.de
Voice:		Berlin - 815 59 75
Data:		Berlin - 815 75 90 (nuucp/nuucp)
From: bhuiyan@skorpio.usask.ca (Shawkat Bhuiyan)
Newsgroups: comp.lang.lisp.mcl
Subject: Remove me of the mailing list
Date: 17 Aug 92 21:34:41 GMT
Original-To: info-mcl@cambridge.apple.com
X-Envelope-To: info-mcl@cambridge.apple.com


Please remove me of the mailing list

Shawkat
:x
From: cassels@cambridge.apple.com (Robert A. Cassels)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Apply
Date: 12 Aug 92 16:11:09 GMT
Full-Name: Bob Cassels
Original-To: Denis R Howlett <drh@world.std.com>,
        MacLisp Info Line <info-macl@cambridge.apple.com>

>I too discovered that apply and funcall don't work for lambda lists any
>more and was rather disheartened since a great deal of our user interface
>code relies on constructing functions which are then attached to buttons.
>
>Much of this code is created with backquotes so that variables can be
>insterted, a simple example might be:
>
>(defun make-menu-items (items)
>  (let (menu-items)
>    (dolist (item items)
>      (push (make-instance ...
>                           :attached-function
>                           `(lambda (window)
>			      (declare (ignore window))
>                              (print ',item)))))))
>
>I know the code isn't quite right but you get the idea, each lambda
>expression is created at run time.
>
>The solution I have adopted (but don't like) is to make the function
>dispatcher more intelligent and do the following:
>
>;; attached-function & window are bound in preceding lines
>  (funcall (if (listp attached-function)
>              (eval `(function ,attached-function))
>              attached-function)
>           window)
>
>This allows my dispatcher to deal with all the things that funcall (and
>apply used to deal with), but I always thought it was bad form to use eval
>in the middle of code? ...

Your particular example doesn't need to use EVAL.  Just use closures.

(defun make-menu-items (items)
  (let (menu-items)
    (dolist (item items)
      (push (make-instance ...
                           :attached-function
                           (let ((item item))
                             #'(lambda (window)
			                              (declare (ignore window))
                                 (print item))))))))

The reason for the seemingly spurious binding of ITEM has to do with the
fact that DOLIST does it's iteration by SETQ'ing the iteration variable. 
An alternative, cleaner way to do this is:

(defun make-menu-items (items)
  (let (menu-items)
    (mapc #'(lambda (item)
              (push (make-instance ...
                       :attached-function
                       #'(lambda (window)
			                        (declare (ignore window))
                           (print item)))))
           items)))

See the discussion on pp. 115-118 of CLtL II for more information about
closures.

You are right that you need EVAL or COMPILE to turn arbitrary list
structure into an object which is FUNCTIONP (as required by APPLY). 
Fortunately, you don't need that most of the time.  You'll find that
closures cover most of what you need.  Thay are also much more time- and
space-efficient than using list expressions.
From: bill@cambridge.apple.com (Bill St. Clair)
Newsgroups: comp.lang.lisp.mcl
Subject: Re: Stack Overflow Error
Date: 17 Aug 92 19:58:57 GMT
Full-Name: Bill St. Clair
Original-To: frege@eecs.umich.edu
Original-Cc: info-mcl

>   Here is what I get:
>
>> Error: Stack overflow.
>> While executing: #<STANDARD-METHOD FOCUS-VIEW (SIMPLE-VIEW)>
>> Type Command-. to abort.
>
>   Is there a way to set the size of the system stack space?
>
>- Young-pa So

There is a way, but I doubt very much that it will help. The stack
almost always overflows because your code is doing infinite recursion,
not because it needs more stack. Look at the output of:

(print-call-history)

or use the Stack Backtrace dialog and look for a function that is called
multiple times with the same arguments. If you are indeed using up the stack
because of code that needs a huge amount of it, page 5 of the MCL 2.0 Release
Notes documents the :STACK-MAXIMUM and :STACK-MINIMUM keywords for the
:MEMORY-OPTIONS argument to SAVE-APPLICATION. You can also change these
values by editing the 'LSIZ' resource with ResEdit.

If you are still stumped, send me the output (or part of the output, it
will be long) from (print-call-history).

P.S. There is one other place that can sometimes cause stack overflow
even without infinite recursion. Code that recurses on both the
CAR and CDR of a list will often stack overflow when given a long
list as an argument. This code should be rewritten to recurse on
the CAR and iterate (often via a tail-call) on the CDR.