HDTenEightyP/NetNews huggingface dataset:
From: haltraet@monsun.si.no (Hallvard Tr{tteberg)
Subject: remove
Organization: Center for Industrial Research, Dept. of Knowledge Based Systems
Distribution: co
Date: 20 Nov 92 08:11:21 GMT
X-Note1: mail msgid was <HALTRAET.92Nov20091121@monsun.si.no>
X-Note2: message-id generated by recnews

Hi, I'm profiling some code and found out that it's consing much more
than it should. I found that the following is true of MCL 2.0:

(let ((a '(1 2 3))) (eq    a (remove 0 a))) => nil, while of course
(let ((a '(1 2 3))) (equal a (remove 0 a))) => t

Remove conses up a new list even though it doesn't remove anything!
It shouldn't be difficult to write one that kept the biggest unchanged
tail of the original list, returning the whole unmodified list if it
didn't contain the first argument. It only requires an eq-test on the
result from a recursive call:

(defun faster-remove (elt list)
  (if (atom list)
    (values list)
    (let* ((cons (cdr list))
           (cons-result (faster-remove elt (cdr list))))
      (if (eq (car list) elt)
        (values cons-result)
        (if (eq cons cons-result)
          (values list)
          (cons (car list) cons-result))))))

Time-ing shows a big difference:

(DOTIMES (A 1000) (DOTIMES (B 8) (FASTER-REMOVE B '(1 2 3 4 5 1 2 3 4
5)))) took 2421 milliseconds (2.421 seconds) to run.
Of that, 117 milliseconds (0.117 seconds) were spent in The
Cooperative Multitasking Experience.
 240000 bytes of memory allocated.
NIL
? 
(DOTIMES (A 1000) (DOTIMES (B 8) (REMOVE B '(1 2 3 4 5 1 2 3 4 5))))
took 6966 milliseconds (6.966 seconds) to run.
Of that, 376 milliseconds (0.376 seconds) were spent in The
Cooperative Multitasking Experience.
 640000 bytes of memory allocated.
NIL

I know my function isn't as general as remove since it only works on
lists and doesn't take all those arguments. But I feel remove should
be optimized for the simplest cases and also should try to cons as
little as possible. As the results show, faster-remove (or should it
be called low-consing-remove) is far better when it comes to consing.

--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY

Tlf: +47 2 45 29 83 or  +47 2 45 20 10
Fax: +47 2 45 20 40
Email: Hallvard.Tretteberg@si.no
Xref: sparky comp.lang.lisp:2941 comp.lang.lisp.mcl:1668
From: Espen J. Vestre <espen@coli.uni-sb.de>
Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
Subject: Re: remove
Date: 23 Nov 1992 16:59:34 GMT
Organization: Computerlinguistik, Universitaet des Saarlandes
Distribution: world
NNTP-Posting-Host: mp-mac10.coli.uni-sb.de
X-UserAgent: Nuntius v1.1.1d12
X-XXMessage-ID: <A736CD59B9024453@mp-mac10.coli.uni-sb.de>
X-XXDate: Mon, 23 Nov 92 17:03:05 GMT

In article <SIMON.92Nov23130108@liasg2.epfl.ch> Simon Leinen,
simon@lia.di.epfl.ch writes:
>Espen is correct in that Hallvard's REMOVE variant isn't
>tail-recursive and may therefore cause problems with long lists.  One
>could code an iterative tail-preserving version (which might be slower).
>
>But I did some benchmarking on Sun-4s under Allegro and CMU CL, and even
>on longish lists (like 1000 elements or so), Hallvard's FASTER-REMOVE
>performed better on the whole than the system-provided REMOVE versions.
>I would bet that at least 90% of the uses of REMOVE would benefit from
>using FASTER-REMOVE.

Yes, especially if you take into account that if you're using very long
lists as your data structures, you are probably using the wrong kind of
data structure.
I guess a lot of programs might benefit even more from _memoizing_ the
remove function, i.e. if the program is using remove to filter the same
list again and again, it would benefit from knowing that, e.g., a given
value isn't present in that list at all.
--------------------------------------------------------------
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: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: 'manpage'-like CL-Definitions availiable ?
Organization: Private UUCP, Martin Cracauer, Norderstedt, Germany
Date: Tue, 17 Nov 92 11:26:47 GMT

Does anybody know a place, where I could find the definitions of
common lisp as an easy-to-index-file (plain ascii, one file per
definition or group of definitions) or perhaps as UNIX-like manpages ?


Thanks
	Martin


-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer,    cracauer@wavehh.hanse.de
Waldstrasse 200, W-2000 Norderstedt, Germany
Tel.: +49 / 522 18 29, Fax.: +49 / 522 85 36
Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
From: jfj@sc (James F. Jarrett)
Newsgroups: comp.lang.lisp
Subject: I need lisp examples
Date: 23 Nov 1992 14:18:13 GMT
Organization: Appalachian State University
NNTP-Posting-Host: sc.cs.appstate.edu
Summary: I need examples of recursive sorting in lisp.
Keywords: Help, Sorting, Recursion.

Hi, 

I am trying to learn lisp but I am having problems.  My biggest one
is I have no idea on how to do recursive sorting algorithms.  

I am working on (but failing miserably at) writing a recursive Merge Sort
algortihm and a Quicsort (also recursive)  If anyone has examples of this
sort of thing or has any pointers or explanations, PLEASE send them to me

Thanx

James

Newsgroups: comp.lang.lisp,comp.lang.lisp.mcl
From: haltraet@monsun.si.no (Hallvard Tr{tteberg)
Subject: remove
Date: Fri, 20 Nov 1992 08:11:21 GMT
Organization: Center for Industrial Research, Dept. of Knowledge Based Systems

Hi, I'm profiling some code and found out that it's consing much more
than it should. I found that the following is true of MCL 2.0:

(let ((a '(1 2 3))) (eq    a (remove 0 a))) => nil, while of course
(let ((a '(1 2 3))) (equal a (remove 0 a))) => t

Remove conses up a new list even though it doesn't remove anything!
It shouldn't be difficult to write one that kept the biggest unchanged
tail of the original list, returning the whole unmodified list if it
didn't contain the first argument. It only requires an eq-test on the
result from a recursive call:

(defun faster-remove (elt list)
  (if (atom list)
    (values list)
    (let* ((cons (cdr list))
           (cons-result (faster-remove elt (cdr list))))
      (if (eq (car list) elt)
        (values cons-result)
        (if (eq cons cons-result)
          (values list)
          (cons (car list) cons-result))))))

Time-ing shows a big difference:

(DOTIMES (A 1000) (DOTIMES (B 8) (FASTER-REMOVE B '(1 2 3 4 5 1 2 3 4
5)))) took 2421 milliseconds (2.421 seconds) to run.
Of that, 117 milliseconds (0.117 seconds) were spent in The
Cooperative Multitasking Experience.
 240000 bytes of memory allocated.
NIL
? 
(DOTIMES (A 1000) (DOTIMES (B 8) (REMOVE B '(1 2 3 4 5 1 2 3 4 5))))
took 6966 milliseconds (6.966 seconds) to run.
Of that, 376 milliseconds (0.376 seconds) were spent in The
Cooperative Multitasking Experience.
 640000 bytes of memory allocated.
NIL

I know my function isn't as general as remove since it only works on
lists and doesn't take all those arguments. But I feel remove should
be optimized for the simplest cases and also should try to cons as
little as possible. As the results show, faster-remove (or should it
be called low-consing-remove) is far better when it comes to consing.

--
Hallvard Traetteberg
Dept. of Knowledge Based Systems
Center for Industrial Research
Box 124 Blindern, 0314 Oslo 3
NORWAY

Tlf: +47 2 45 29 83 or  +47 2 45 20 10
Fax: +47 2 45 20 40
Email: Hallvard.Tretteberg@si.no
Newsgroups: comp.lang.lisp
From: Tim Larkin <tsl1@cornell.edu>
Subject: Re: Symbolics Machines
X-Xxdate: Fri, 20 Nov 92 20: 29:54 GMT
Nntp-Posting-User: tsl1@cornell.edu
Organization: Cornell University
X-Useragent: Nuntius v1.1.1d7
Date: Fri, 20 Nov 1992 20:25:25 GMT

In article <1992Nov18.112936.9459@cc.ic.ac.uk> Dr C. Bridgewater,
colinb@.ic.ac.uk writes:
>Anyone know of a mailing list for users and devotees
>of the Symbolics

Enjoy the news group, info.slug.

Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
tsl1@cornell.edu
607-255-7008
Newsgroups: comp.lang.lisp
From: SWM@stony-brook.scrc.symbolics.com (Scott McKay)
Subject: *READ-SUPPRESS* and #P syntax
X-Unparseable-Date: Wed
Organization: LCS news/mail gateway
Date: Wed, 18 Nov 1992 19:17:09 GMT

    Date: Tue, 10 Nov 1992 20:49 EST
    From: Andrew Philpot <philpot@kepler.arc.nasa.gov>

    Should *READ-SUPPRESS* be obeyed when reading literal pathnames using
    #P?

I am no dpANS language lawyer, but it certainly seems "right" that
*READ-SUPPRESS* should prevent #P from doing syntax-checking on the
literal pathname.

    Siutation: My code was trying to read in some files which contain
    references to pathnames using the #P syntax.  Lucid and Franz have
    different syntaxes for the object following the #P.  Lucid allows only
    a string, whereas Franz supports both strings and lists in this
    position.  Lucid signals an error when given an expression of the form
    #P followed by a list, since that violates its #P reader.

    So far, so good.  However, in (lucid) lcl4.1b, you can't avoid
    signaling this error when reading a Franz-derived #P pathname.
    Putting a #-LUCID or #+EXCL qualifier in front of the form doesn't
    seem to work; it reads enough to signal the error anyway.

    One would imagine that the intent of using READ-SUPPRESS to implement
    the *FEATURES* idea was to avoid signaling errors associated with just
    this kind of implementation-specific extension.

    However, strictly speaking, this behavior is allowed by pp. 522 ff. of
    CLtL2.  It appears that the appropriate section of the new dpAns spec
    agrees with CLtl2 in this matter.  I couldn't swear I got to the right
    section, but there was one in dict-reader.tex that mirrored 22.1.2
    pretty well, and I didn't find any reference to #P there.

    Is it the intent of dpAns that

      (defvar my-path
	  #+EXCL #P(:type "lisp")
	  #+LUCID #P".lisp"
	  )

    can cause an error?

    -- 
    ---------------------------------------------------------------
			 philpot@ptolemy.arc.nasa.gov
Newsgroups: comp.lang.lisp
From: colinb@.ic.ac.uk (Dr C. Bridgewater)
Subject: Symbolics Machines
Summary: Mailing list request
Organization: Imperial College
Distribution: comp.lang.lisp
Date: Wed, 18 Nov 92 11:29:36 GMT

Hiya Folks,

Anyone know of a mailing list for users and devotees of the Symbolics
machines ? I am grappling with a 3630 and don't really use it to its
fullest extent - I'm sure that the Hacksaws will eventually tell me 
what I need to know (as would a browse through the stack of manuals),
but it's often quicker to eavesdrop on someone elses' musings and try
them out in the safety of one's own office.....

Thanks,

Colin

****************************************************************************
#  Colin Bridgewater		     #       colinb@uk.ac.ic       # \   / #
#  Head Robot Wrangler		     # tel:+44-(0)71-589-5111x4842 #  \ /  #
#  Construction Robotics Research    # BE KIND TO SPIDERS & SNAILS # --*-- #
#  Department of Civil Engineering   #  -------------------------  #  / \  #
#  Imperial College, London, UK.     #  alias 'the happy hacker'   # /   \ #
****************************************************************************
From: wolf@prosun.first.gmd.de (Wolfgang Koehler)
Newsgroups: comp.lang.lisp
Subject: Help: apply for macros ???
Date: 19 Nov 92 11:08:24 GMT
Organization: GMD-FIRST, D-1000 Berlin 10

I use CMU-Lisp and  allegro since more than one year.
But since some days I am stuck with a problem that might have a very
simple solution, but I'm not clever enough to get it.

consider you have a function f and want to call it from some other
function g with its &rest arguments.
Then you may use the apply function :

(defun f (p1 p2 ...)
  ...)

(defun g (&rest args)
 (apply #'f args))

My question :
 
Does there exist a similiar solution if "f" is a macro ???

Any help is greatly appreciated.


wolf

-- 
-------------------------------------------------------------------------
    ... always look on the bright side of life ... (Monty Python)
-------------------------------------------------------------------------
Wolfgang Koehler                               wolf@first.gmd.de
GMD-FIRST an der TU Berlin              German National Research Centre 
Tel. (Berlin 030/049) 6704-2650              for Computer Science



Newsgroups: comp.lang.lisp
From: jahonen@cs.joensuu.fi (Jarmo Ahonen)
Subject: Commercial Lisp for OS/2 2.0
Organization: University of Joensuu
Date: Mon, 16 Nov 1992 10:53:40 GMT


Hello,

Does anyone out there know if there is/will be any commercial
Common Lisps (or any other dialects, CL preferred, however)
for OS/2 2.0?  If not yet, then will there be such a product some 
day? 

Hopefully this question reaches both Franz Inc and Luzid.

Thanks for help,

----------------------------------------------------------------------
Jarmo J. Ahonen
Computing Centre, Lappeenranta University of Technology, P.O.Box 20,
SF-53851 Lappeenranta, Finland. email: Jarmo.Ahonen@lut.fi

Newsgroups: comp.lang.lisp,comp.lang.scheme
From: werts@aardvark.cecs.csulb.edu (Michael Werts)
Subject: Quote syntax
Organization: Cal State Long Beach
Date: Tue, 17 Nov 1992 21:26:50 GMT

In the design of Lisp was there a profound reason for using

    (QUOTE (+ 1 1)) or '(+ 1 1)

to inhibit evaluation instead of something like

    [+ 1 1] ?

--

MICHAEL WERTS -- werts@csulb.edu
Computer Engineering Computer Science
California State University Long Beach
Xref: sparky comp.lang.lisp:2899 comp.lang.scheme:2603
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: Quote syntax
Date: 17 Nov 1992 22:48:21 GMT
Organization: University of California, Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu

werts@aardvark.cecs.csulb.edu (Michael Werts) writes:
>In the design of Lisp was there a profound reason for using
>    (QUOTE (+ 1 1)) or '(+ 1 1)
>to inhibit evaluation instead of something like
>    [+ 1 1] ?

Yes, the reason is that the Lisp notation allows a Lisp program to be
readable as Lisp data.  That is, (quote (+ 1 1)) is just an ordinary
Lisp list, so a Lisp program can read and manipulate it.  It's really
the same reason that you say (f x) and not f(x) -- the Lisp way makes
an expression readable as a list.

The notation '... is just an abbreviation for (quote ...) and is
converted to the latter form when read.

It would have been possible, I suppose, to make [...] abbreviate
quoting, but would [...] mean (quote (...)) or (quote ...)?  You
want a uniform notation that can quote symbols as well as lists.
If [+ 1 1] quotes (+ 1 1), how do you quote +?
Newsgroups: comp.lang.lisp
From: jpf@wstar.mixcom.com (John P. Flanagan)
Subject: Re: *READ-SUPPRESS* and #P syntax
Date: Sun, 15 Nov 1992 21:01:51 GMT
Organization: WaveStar Technology

barmar@think.com (Barry Margolin) writes:

>In article <1992Nov11.201954.825@wstar.mixcom.com> jpf@wstar.mixcom.com (John P. Flanagan) writes:
>>Strictly speaking, I don't think this behavior is allowed.  Section
>>2.4.8.14, p.2-33 in the dpANS makes the following statement:
>>
>>       "#P"..." is equivalent to #.(parse-namestring "...")."

>However, that doesn't say what "#P(...)" is equivalent to.

Yes, but why does this matter when *read-suppress* is non-nil?

Consider Steele's comments from section 22.1.4, p.537 in CLtL2 with
regard to `#P"..." is equivalent to #.(parse-namestring "...")':

["Presumably this was meant to be taken descriptively and not literally."]
 ...
["I interpret the intent of the vote to be that #p reads a following form,
 which should be a string, that is then converted to a pathname as if by
 application of the standard function parse-namestring."]

When the value of *read-suppress* is non-nil, it shouldn't matter what the
following form is unless the Sharpsign-P reader evaluates that form; as with
other standard # dispatching macro readers such as #\, #B, #O, #X, #R, #*,
#A, #S, #:, ##, and #., the Sharpsign-P reader returns nil instead.

Similar reasoning should also apply to the #C, #(, and #' macros although
an example involving the #( reader macro on p.23-22, section 23.2 of the
dpANS appears to suggest otherwise, i.e., #(a b c) becomes #(nil nil nil) 
rather than nil.  The last paragraph before the examples says, "#( notation
continues to delimit vectors"; it doesn't say, "#( notation continues to
delimit [and construct] vectors" as is true with parentheses.

-jpf
-- 
   __________________________________________________________________________
   WaveStar Technology           WaveStar Common Lisp        John P. Flanagan
   W344 N6855 Bayberry Court     ANSI-12.24, X3J13/92          (414) 367-5014
   Oconomowoc, WI  53066         HPUX-800/700/400/300    jpf@wstar.mixcom.com
Newsgroups: comp.lang.lisp
From: eskilb@dhhalden.no (Eskil Brun)
Subject: Re: 'manpage'-like CL-Definitions availiable ?
Organization: Ostfold College
Date: Wed, 18 Nov 1992 14:32:55 GMT

cracauer@wavehh.hanse.de (Martin Cracauer) writes:

>Does anybody know a place, where I could find the definitions of
>common lisp as an easy-to-index-file (plain ascii, one file per
>definition or group of definitions) or perhaps as UNIX-like manpages ?

Well. If you happen to have a TI Explorer Lisp machine on your
network, you can use my GNU Emacs interface, rpc-hm, to access
Explorer functions like DOCUMENTATION, in your case.

(lisp-dir-apropos "rpc") gives me:

             GNU Emacs Lisp Code Directory Apropos -- "rpc"
"~/" refers to
archive.cis.ohio-state.edu:/pub/gnu/emacs/elisp-archive/

rpc-hm (1.0)          92-07-20
     Eyvind Ness, <Eyvind.Ness@HRP.No>
     ugle.unit.no:/pub/gnu/emacs-lisp/rpc-hm-1.0.tar.Z
     Networking library for interfacing GNU Emacs with remote Lisp
Machines

Check out the Elisp function called rld-describe-function/variable: 

E.g. (rld-describe-function 'machine-instance) gives:

Function LISP:MACHINE-INSTANCE ()

        Return a string that identifies which particular machine this
implementation is.

;;; End of documentation for MACHINE-INSTANCE provided by REMULUS.


Typically I bind this function to C-h f when working with Lisp code to
easily access doc for the functions appearing in the source code.

rpc-hm works with Symbolics as well, but unfortunately Symbolics
doesn't make the documentation available outside their own Document
Examiner, so it won't be of any help to you.


Cheers,
Eyvind.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
  Eyvind Ness         Internet: Eyvind.Ness@HRP.No
  Research Scientist  Voicenet: +47 9 183100 ext. 275
  CRS Division        Faxnet:   +47 9 187109
  OECD HRP            Papernet: PO Box 173, N-1751 Halden, Norway

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Newsgroups: comp.lang.lisp
From: zzang@stat.ufl.edu (zzang)
Subject: How to pronounce CAR and CDR ?
Originator: zzang@manta
Organization: University of Florida
Distribution: usa
Date: Wed, 18 Nov 92 18:03:37 GMT

Hello,
I dont know how to pronounce the CAR and CDR?
CAR: /si://ei//a:/ or /ka:/ ?
CDR: /si://di://a:/  ??

Thanks in advance !


-- 
Zhuo Zang[~{j0WA~}]
Department of Statistics
University of Florida            Email: zzang@stat.ufl.edu
Newsgroups: comp.lang.lisp
From: jslewocz@uffa.wrc.Xerox.COM (john lewocz 0128-29e)
Subject: Using named pipes with "with-open-file"
Organization: Xerox
Date: Mon, 23 Nov 1992 21:17:28 GMT


Is there any way to do this?  I'm using Allegro 4.1 on a Sun
and I'm continually getting file errors when I try to do this.

Thanks.

--John S. Lewocz
From: JJH113@psuvm.psu.edu (Your Puerto Rican neighbor!)
Newsgroups: comp.lang.lisp.x
Subject: Chess using lisp
Date: 18 Nov 92 18:08:37 GMT
Organization: Penn State University

I need algorithms on how to build a computer chess program using LISP.
If someone knows anything about where can I find info please let me know.
Thanks.
Jose.
From: jmward@redcloud (Joel M. Ward)
Newsgroups: comp.lang.lisp.x
Subject: Xlisp plus v2.1d
Date: 22 Nov 1992 01:42:00 GMT
Organization: University of Colorado at Colorado Springs
Distribution: inet
NNTP-Posting-Host: redcloud.uccs.edu
X-Newsreader: TIN [version 1.1 PL6]

	I just got Xlisp plus 2.1d from, i think, wuarchive.  Is this Common
Lisp?  If not, what are the differences?
	Thanks in advance...
:)
Newsgroups: comp.lang.lisp.x
From: shendi@saruman.stgt.sub.org (Alexander Shendi)
Subject: Current XScheme version
Organization: private Coherent 4.0 site, Schwieberdingen, Germany
Date: Sun, 15 Nov 1992 13:54:43 GMT

Hi all!

I'd like to know the current version of XScheme. I have got
version 0.22, is that OK, or out of date?

BTW, is this the correct newsgroup for question about XScheme?
Part 4 of the LISP FAQ says so, but I havn't seen any postings concerning
XScheme so far.

Thanks a lot for answering.

Alex
-- 
Alexander Shendi                E-Mail: shendi@saruman.stgt.sub.org
Stuttgarter Str. 82                     (preferred)
W-7141 Schwieberdingen                  root@saruman.stgt.sub.org
Federal Republic of Germany     Phone:  ++49-7150-34997
From: voss@i43s6.ira.uka.de (Stefan Voss)
Newsgroups: comp.lang.lisp.x
Subject: Porting
Date: 23 Nov 92 13:37:21 GMT
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: i43s6.ira.uka.de

I'm working on porting XLisp 2.1d to an Apple IIGS. 
Do I have to pay attention to any law restrictions, copyright notices,
etc ?
May I post it to a newsgroup ?
Do I have to pay any shareware fee or something similar ?

        Stefan Voss        (voss@ira.uka.de)
From: dbetz@Apple.COM (David Betz)
Newsgroups: comp.lang.lisp.x
Subject: Re: Adventure System
Date: 17 Nov 92 17:38:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <oJ66TB2w164w@nzkites.UUCP> foster@nzkites.UUCP (Foster Schucker) writes:
>David Betz of Xlisp fame also wrote a lisp like adventure language
>with a compiler and interpreter.  The version I have is from 1986.
>
>Is there a newer version around, and if so, is there a listserv site
>I can get it from?

I'm afraid that there isn't a newer version of AdvSys.  Sorry.
Xref: sparky comp.lang.lisp:2936 comp.lang.lisp.mcl:1657
From: DG0244@uokmvsa.backbone.uoknor.edu
Newsgroups: comp.lang.lisp.mcl
Subject: need help on conversion
Date: 20 Nov 92 22:07:00 GMT

Can any one tell me how to convert XLISP-STAT programs into
MCL 2.0? Thanks.
Yu Chong Ho
U. of Oklahoma
From: cfry@MIT.EDU (Christopher Fry)
Newsgroups: comp.lang.lisp.mcl
Subject: Logical pathname bug?
Date: 18 Nov 92 23:03:38 GMT

I define some logical pathnames.
I use them to load some .lisp files.
The files load fine. I can meta-point functions defined in them.
They have pathnames like "hd:ccs:oval:foo.lisp".
When I eval a defun in such a file I get the warning message

;Warning:  FUNCTION LIST-OF-VALUES previously defined in: 
oval-source:eval.lisp
;                  is now being redefined in: root:hd;eval.lisp

Now when I meta point the fn, I get a choice of two pathnames, neither 
of which are
correct, and neither of which are either of the above two. They are:
"eval.lisp {hd;}" and
"eval.lisp {}"

Choosing the first errors with 
> Error: File #4P"root:hd;eval.lisp" does not exist.
> While executing: #<STANDARD-METHOD FRED-INITIALIZE (FRED-MIXIN)>
(it's true that that file doesn't exist, but why did meta-point think it 
did?)

Choosing the second works fine.

The directory in the title bar of a fred window editing the file is 
the correct physical directory.
Inspecting the window shows that its instance variable ccl::my-file-name
is the correct full physical pathname.

I play some tricks with defining logical pathnames. Its likely I'm doing 
something wrong. CLtL2 has done an excellent job of documenting a very 
complex mechanism obscurly. If there are better explanations of logical 
pathnames, please tell me where. But it still sounds like MCL2 is 
inconsistent here.
Newsgroups: comp.lang.lisp.mcl