When I try to load a compiled LISP file (LUCID 4.X on a DECStation 5000) I
get messages that say:
;;; Warning: function FUN%1303%332 defined more than once in "/usr/home/pkg/hol/Library.ds5000/prettyp/PP_hol/link_to_hol_ml.l"
;;; Warning: function FUN%1303%333 defined more than once in "/usr/home/pkg/hol/Library.ds5000/prettyp/PP_hol/link_to_hol_ml.l"
over and over again (hundreds of them for a large file). The first number
changes everytime lisp is started, the second number changes every load so
this isn't a number that was generated by the compiler, but is being
generated by the load.
What can I do to stop these annoying warning messages? The files load and
run correctly, so I don't care if the orginal problem is fixed or if the
warning messages are just turned off. I've tried *load-verbose*, but the
warnings keep coming.
Any help?
--
Phillip J. Windley, Asst. Professor | ·······@cs.uidaho.edu
Laboratory for Applied Logic | ·······@panther.cs.uidaho.edu
Department of Computer Science |
University of Idaho | Phone: 208.885.6501
Moscow, ID 83843 | Fax: 208.885.6645
From: Kent Sandvik
Subject: Re: Warning: function FUN%1303%333 defined more than once
Date:
Message-ID: <20004@goofy.Apple.COM>
In article <····················@panther.cs.uidaho.edu>, ·······@cs.uidaho.edu (Phillip J. Windley) writes:
> What can I do to stop these annoying warning messages? The files load and
> run correctly, so I don't care if the orginal problem is fixed or if the
> warning messages are just turned off. I've tried *load-verbose*, but the
> warnings keep coming.
Check out ignore, page 230 in the Common Lisp, second edition book.
Should things like this be collected to a FAQ?
Kent Sandvik
From: Barry Margolin
Subject: Re: Warning: function FUN%1303%333 defined more than once
Date:
Message-ID: <kp3emjINN7lk@early-bird.think.com>
In article <·····@goofy.Apple.COM> ·····@apple.com (Kent Sandvik) writes:
>In article <····················@panther.cs.uidaho.edu>, ·······@cs.uidaho.edu (Phillip J. Windley) writes:
>> What can I do to stop these annoying warning messages? The files load and
>> run correctly, so I don't care if the orginal problem is fixed or if the
>> warning messages are just turned off. I've tried *load-verbose*, but the
>> warnings keep coming.
>
>Check out ignore, page 230 in the Common Lisp, second edition book.
How would an IGNORE declaration suppress warnings about multiple
definitions of internally-created functions?
>Should things like this be collected to a FAQ?
This is the first time I've seen this question, so I don't think it counts
as a frequently-asked question. There is someone working on a FAQ list,
though.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Kent Sandvik
Subject: Re: Warning: function FUN%1303%333 defined more than once
Date:
Message-ID: <20128@goofy.Apple.COM>
In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
>
> In article <·····@goofy.Apple.COM> ·····@apple.com (Kent Sandvik) writes:
> >In article <····················@panther.cs.uidaho.edu>, ·······@cs.uidaho.edu (Phillip J. Windley) writes:
> >> What can I do to stop these annoying warning messages? The files load and
> >> run correctly, so I don't care if the orginal problem is fixed or if the
> >> warning messages are just turned off. I've tried *load-verbose*, but the
> >> warnings keep coming.
> >
> >Check out ignore, page 230 in the Common Lisp, second edition book.
>
> How would an IGNORE declaration suppress warnings about multiple
> definitions of internally-created functions?
Apologies, I misinterpreted the text on 230, assumed one could ignore
multiple definitions by wrapping them inside ignore statements.
Anyway, maybe the system has some way to terminate the warning
messages, something like *warn-if-redefine*, or a way to block
the warnings using the internal condition system.
I have some hints how to turn off warnings from the MCL environment
provided by the MCL engineers, so let me know if this might help. Maybe
someone else has a better idea how to stop the warnings...
Kent Sandvik
In article <·····@goofy.Apple.COM> ·····@apple.com (Kent Sandvik) writes:
In article <····················@panther.cs.uidaho.edu>, ·······@cs.uidaho.edu (Phillip J. Windley) writes:
> What can I do to stop these annoying warning messages? The files load and
> run correctly, so I don't care if the orginal problem is fixed or if the
> warning messages are just turned off. I've tried *load-verbose*, but the
> warnings keep coming.
Check out ignore, page 230 in the Common Lisp, second edition book.
I'm not sure I see how this will help. Ignore can be used with variables
that *I* use and create. The names that Lucid is complaining about are
variable (actually function) names that *it* created.
--
Phillip J. Windley, Asst. Professor | ·······@cs.uidaho.edu
Laboratory for Applied Logic | ·······@panther.cs.uidaho.edu
Department of Computer Science |
University of Idaho | Phone: 208.885.6501
Moscow, ID 83843 | Fax: 208.885.6645
From: Raymond K. Fink
Subject: Re: Warning: function FUN%1303%333 defined more than once
Date:
Message-ID: <1992Feb11.155041.19043@inel.gov>
In article <····················@panther.cs.uidaho.edu>, ·······@cs.uidaho.edu (Phillip J. Windley) writes:
> What can I do to stop these annoying warning messages? The files load and
> run correctly, so I don't care if the orginal problem is fixed or if the
> warning messages are just turned off. I've tried *load-verbose*, but the
> warnings keep coming.
I don't have a Lucid CL manual handy, but if memory serves I recall
a flag *ignore-redefinition-errors*, or something like that.
It's a Lucid extension, not part of standard CL. Try (apropos 'redef)
if you don't have the manuals. Hope this helps...
(BTW, I tried replying by mail but our name servers have never heard
of uidaho.edu...hmm.)
Ray Fink -- Idaho National Engineering Laboratory -- Idaho Falls ID
···@inel.gov 208-525-5431
========== long legal disclaimer follows, press n to skip ===========
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights. No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory. The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.