Subject: [clisp-list] Can anyone help me lispdebug?

From: [email-masked] (Thaddeus L. Olczyk)
Date: Sat Jan 19 23:38:03 2002

I'm trying to get this package working with 2.27, but have several
problems:
1) The first is that it doesn't like my version of tk/tcl ( it says
above 8.1 mine is 8.3 ). To fix this I modify the configure.in
which seems to work.
2) I seem to get all sorts of package errors. Everytime I modify the
build process I get more errors. The first one ( if I remeber
correctly is ) was special-form-p which I replaced with
ext:special-form-p. I get errors about the package SYMBOL
being missing ( I couldn't find it in the source ). fundamental-input
stream got changed to gray:fundamental-input-stream.
Then when loading debugger.fas, it complained that the package
DEBUGGER wasn't defined.

I figure ( and am desperately hoping ) that it's something that a few
changes can fix, but I can't figure out what those changes were.
Can anyone help?

---

From: [email-masked] (Dr. Edmund Weitz)
Date: Sat Jan 19 23:57:04 2002

> changes can fix, but I can't figure out what those changes were.

I can't help directly but I can confirm that (after patching
configure.in to recognize Tcl/Tk 8.3) it works fine with CMUCL. I
think what you're encountering must be due to changes in CLISP since
lispdebug was released.

Edi.

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Sun Jan 20 04:50:02 2002

Sorry Doc. I didn't realise the reply to was to the sender and not to
the list. Resent to the list.
On 20 Jan 2002 08:56:02 +0100, [email-masked] (Dr. Edmund Weitz)

>think what you're encountering must be due to changes in CLISP since
I've actually discovered what the problem is:

I've cut and paste this piece with the bug in it. ( I put in the
format. )

(format *standard-output* "~%Entering offending party ~%")
(defun parse-definition-package (source i l)
  (declare (string source) (fixnum i l))
  (let ((symbol ""))
    (declare (string symbol))
    (multiple-value-setq (symbol i) (parse-definition-string source i
l))
    (format *standard-output* "symbol-name-1:~S~%" symbol)
    (when (not (string= symbol ""))
      (format *standard-output* "symbol-name:~S~%" symbol)
      (when (not (find-package symbol)) (make-package symbol)) ;
******** This line generates error.
      (in-package symbol))
    i))
(format *standard-output* "Exiting offending party ~%")

Loading it I get the error between the first format and the last.
The others do not get executed. This happens while the compiler is
loading the file so in the line with the error ( find-package symbol )
trys to find the package "SYMBOL" at the time of loading, not when the
function is called.

Any idea how to fix this?

---

From: Sam Steingold <[email-masked]>
Date: Sun Jan 20 07:05:14 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Can anyone help me lispdebug?"
> * Sent on Sun, 20 Jan 2002 12:49:13 GMT
> * Honorable [email-masked] (Thaddeus L. Olczyk) writes:
>

set *package-tasks-treat-specially* to NIL.
(this is the default in the CVS)

when it is T, most package tasks, like MAKE-PACKAGE, USE-PACKAGE &c are
treated as if they were wrapped with (EVAL-WHEN (LOAD COMPILE EVAL)),
which is good for "novice users" (for some definition of a novice).

these days everyone knows to use DEFPACKAGE, so it's okay to turn this
off. 

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Lisp: its not just for geniuses anymore.

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Sun Jan 20 20:30:02 2002

>these days everyone knows to use DEFPACKAGE, so it's okay to turn this
Can you be a bit more specific?
Your approach doesn't seem to be working.

---

From: Sam Steingold <[email-masked]>
Date: Mon Jan 21 06:37:06 2002

> * In message <[email-masked]>
> * Sent on Mon, 21 Jan 2002 04:29:36 GMT

what did you do?  I am not clairvoyant (unfortunately).

(describe '*package-tasks-treat-specially*) ==> ?

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
If it has syntax, it isn't user friendly.

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Mon Jan 21 11:42:03 2002

>(describe '*package-tasks-treat-specially*) ==> ?
I put:
(setf *package-tasks-treat-specially* nil) at the begining of every
file in the package ( well every clisp relevant file I left things
like inst-cmucl.lisp alone ). I went on the open projects IRC
yesterday night and the help there indicated that the in-package
call was to blame. But I still kept getting all kinds of errors which
I was unable to resolve so I've basically given up. At this point the
source is to corrupt with changes to make it work anywhere as it
was intended, but has too many changes to abandon willy nilly.

What I need to do now is flush both clisp and lispdebug and start 
with a new install. ( Recording what I consider important changes to
both. BTW for clisp it is just using the "full" images instead of the
base ones. ) Then archive that so I can recover from changes. That
takes a lor of time, and at the moment my productivity with clisp is
0. So I take a break and increase my productivity before tackling it.

Here is more or less what I've done till this point: 
1) Replaced in-package with some form of:
(setf p (find-package p-name))
(if (package-exists p) ;pseudo-code here
     (setf *package* p))
as was appropriate given the place in code
( eg I didn't add the if, if the code came after a make-package.)
2) I changed:
 (make-package "DEBUGGER") 
to:
 (make-package "DEBUGGER" 
       :use (find-package "COMMON-LISP-USER" 
       :use (find-package "COMMON-LISP") ) 
Since I was initialially getting errors like
DEBUGGER::SHELL undefined and later other symbols were undefined.
I found I had to get both packages.
3) At that point I kep getting weird compile messages: things like
LOAD and EVAL not defined. Removing the outright "in-package"
substitutes, ( The ones called from a "global" line in the file. I
left the ones embedded in a defun alone. ) That got it to compile,
but it can't find the debugger.

The last desperate thing I tried to do was remove all references to
the package debugger, and just have it compile in the "global
namespace" (????). I went and modified the associated c code and
all the lisp files, and it still wants the DEBUGGER package.

---

From: Sam Steingold <[email-masked]>
Date: Mon Jan 21 12:47:05 2002

> * In message <[email-masked]>
> * Sent on Mon, 21 Jan 2002 19:41:36 GMT
> >> >these days everyone knows to use DEFPACKAGE

please do evaluate this form to make sure that you do have the variable
(i.e., that your CLISP is recent enough).

> I put: (setf *package-tasks-treat-specially* nil) at the begining of
> every file in the package ( well every clisp relevant file I left
> things like inst-cmucl.lisp alone ).

this is an overkill.
you should just set the var once.

> ( eg I didn't add the if, if the code came after a make-package.)

this is wrong.
there are two forms you need: IN-PACKAGE and DEFPACKAGE
if you are not an expert, you should _never_ use anything else.
if you think you have to use other forms, you are probably wrong (unless
you _are_ an expert, _and_ you are writing something which works with
packages on a deeper level than just setting the working environment).

> I found I had to get both packages.

replace this with
(defpackage "DEBUGGER" (:use "CL" "EXT"))

> but it can't find the debugger.

don't do this.

> all the lisp files, and it still wants the DEBUGGER package.

don't do this either.

I suggest that you
- make sure that your CLISP is 2.27
- make sure that *package-tasks-treat-specially* is NIL in your images
  (dump new images if necessary)
- get a clean lispdebug.
- replace
        (when (not (find-package "DEBUGGER")) (make-package "DEBUGGER"))
  (which is a pre-ANSI abomination) with
        (defpackage "DEBUGGER" (:use "CL" "EXT"))
  in debugger.lisp

report errors (or, better yet, success stories :-) here!

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Sufficiently advanced stupidity is indistinguishable from malice.

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Wed Jan 23 06:28:08 2002

>(i.e., that your CLISP is recent enough).
CLisp-2.27.
In fact I think this is the problem. The person who wrote it, got it
to work on one version and changes to Clisp have broken it.

It says the variable is nil.
>you should just set the var once.
But it is OK isn't it. Yeah it's overkill, but that way I'm sure the
variable is nil.

>packages on a deeper level than just setting the working environment).
I'm not an expert, but I'm trying to get something to work that was
written by an expert. ( Or at least I believe he *thought* he was an
expert ;) )

The funny thing is that it seems that in-package causes a lot of
problems, by insisting on being evaluated during compiles and loads.
>(defpackage "DEBUGGER" (:use "CL" "EXT"))
I'll try this.

>report errors (or, better yet, success stories :-) here!
I'll do this, it will take some time though since I'll write a script
which does all this. ( That way I guarantee that I have a fresh system
each time. )

---

From: William Harold Newman <[email-masked]>
Date: Wed Jan 23 08:17:07 2002

> But it is OK isn't it. Yeah it's overkill, but that way I'm sure the

It really is better to set it once, really early (e.g. in your
configuration file). That way, you can be sure it's NIL when you need
it, whether the time you need it is at read time or EVAL-WHEN
:COMPILE-TOPLEVEL time or execution time or what. If you try to assign
it in each file, you get into subtleties about exactly when the
assignment is executed, and because of EVAL-WHEN, reader macros, and
the other times (e.g. macroexpansion time) that things can be executed
in Common Lisp, this can get trickier than you think.
 
> written by an expert. ( Or at least I believe he *thought* he was an

I'll second Sam's advice here. Don't replace IN-PACKAGE with
hand-rolled code like that unless you're ready to spend some time
getting your mind around EVAL-WHEN, the reader, and the package
system. (When you are ready, that's fine. Learning those things is by
no means wasted time, since they can be useful. But there are lots of
other useful things you may be interested in learning first.)
 
(Or, if you are maintaining code where someone else uses hand-rolled
package code like that, then prepare to learn something about that
stuff, and hope that the original author and earlier maintainers were
relatively sane. Some don't use packages, some use IN-PACKAGE, and
some have #+FOO:BAR #.(SHADOWING-IMPORT BAZ:BLETCH) thrust upon
them.:-)

> problems, by insisting on being evaluated during compiles and loads.

IN-PACKAGE really needs to do that in order to do what it's supposed
to do. DEFPACKAGE does too. Consider a file like
  (cl:defpackage "FOO" (:use "CL") (:export "THIS" "THAT"))
  (cl:defpackage "BAR" (:use "CL") (:export "XXX" "YYY"))
  (cl:in-package "FOO")
  (defun this (x)
    (bar:xxx x (+ x 1) (+ x 2)))
If the DEFPACKAGEs aren't executed at compile time, then the form with
BAR:XXX will cause a reader error when COMPILE-FILE tries to READ the
form. If the IN-PACKAGE isn't executed at compile time, then the
definition of THIS will end up in whatever *PACKAGE* was bound to when
COMPILE-FILE is called, rather than in the FOO package as was
intended.

-- 
William Harold Newman <[email-masked]>
"Look on my works, ye Mighty, and despair!" -- Ozymandias, King of Kings 
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

---

From: Sam Steingold <[email-masked]>
Date: Wed Jan 23 17:08:03 2002

> * In message <[email-masked]>
> * Sent on Wed, 23 Jan 2002 14:27:32 GMT

okay. next time, when I take my time to type in a form, please do take
your time to copy and paste it into your (freshly started with a '-norc'
option) CLISP and then copy and paste the output into your reply.

> But it is OK isn't it. Yeah it's overkill, but that way I'm sure the

you are making a mistake.
instead, make sure this variable is not set in any file you use.

if you want to get something done (and learn something in the process),
I suggest that you pay attention to the advice you are getting here.

> problems, by insisting on being evaluated during compiles and loads.

this is what IN-PACKAGE is required to do - by the CLHS.

> which does all this. ( That way I guarantee that I have a fresh system

do _not_ waste your time writing scripts.
save old files and use diff(1) and patch(1) - included if you are on
a Unix, available with cygwin on woe32.

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
It's not just a language, it's an adventure.  Common Lisp.

---

From: [email-masked] (Thaddeus L. Olczyk)
Date: Wed Jan 23 22:33:02 2002

>option) CLISP and then copy and paste the output into your reply.
Sorry I misunderstood. 
Here is the output. { I also did 
(symbol-plist '*package-tasks-treat-specially*)  since describe
suggested it. }
-------------------------------------------------------------------------------------------------------------------------------------------
calling clisp

[1]> 

*PACKAGE-TASKS-TREAT-SPECIALLY* is the symbol
*PACKAGE-TASKS-TREAT-SPECIALLY*, lies in #<PACKAGE CUSTOM>, is
accessible in the packages COMMON-LISP-USER, CUSTOM, EXT, FFI, SCREEN,
SYSTEM, a variable declared SPECIAL, value: NIL, has the property
SYSTEM::DOCUMENTATION-STRINGS.
Documentation as a VARIABLE:
Treat package-related operations the same way at compile and load
time.
For more information, evaluate (SYMBOL-PLIST
'*PACKAGE-TASKS-TREAT-SPECIALLY*).

 #<PACKAGE CUSTOM> is the package named CUSTOM.
 It exports 38 symbols to the package EXT.

 NIL is the empty list, the symbol NIL, lies in #<PACKAGE
COMMON-LISP>, is accessible in the packages CLOS, COMMON-LISP,
COMMON-LISP-USER, EXT, FFI, POSIX, REGEXP, SCREEN, SYSTEM, a constant,
value: NIL, names a type, has the properties SYSTEM::INSTRUCTION,
SYSTEM::TYPE-SYMBOL.
 For more information, evaluate (SYMBOL-PLIST 'NIL).

  #<PACKAGE COMMON-LISP> is the package named COMMON-LISP. It has the
nicknames LISP, CL.
  It imports the external symbols of the package CLOS and exports 950
symbols to the packages REGEXP, FFI, SCREEN, CLOS, POSIX,
COMMON-LISP-USER, EXT, SYSTEM.

  NIL [see above]

[2]> 

(SYSTEM::DOCUMENTATION-STRINGS
 (VARIABLE
  "Treat package-related operations the same way at compile and load
time."))
[3]> 
--------------------------------------------------------------------------------------------------------------------------------------------------------------
>I suggest that you pay attention to the advice you are getting here.
Uhm. The very first time you mentioned this variable you said:

:>set *package-tasks-treat-specially* to NIL.
:>(this is the default in the CVS)
so I set it. And then made sure it was set everywhere.
If you want I can make sure that it is not set.

>this is what IN-PACKAGE is required to do - by the CLHS.
Hmm. I get the fealing that lispdebug doesn't expect this behaviour.
The function in my first post is not used when lispdebug is run. It is
used when lispdebug is being compiled and installed. 
Perhaps this is old behaviour that was changed and the writer of
lispdebug no longer maintains the CLisp version?

>a Unix, available with cygwin on woe32.
You forgot that before I go on I want to install fresh clisp and
lispdebug. So I have to delete the old ones, extract the new ones,
tweak the things I need to tweak, then finally install. I prefer to do
this from a script since I can always reinstall if I even have the
slightest suggestion that the installation has been corrupted.

---

From: Marco Antoniotti <[email-masked]>
Date: Thu Jan 24 10:41:03 2002

> From: [email-masked] (Thaddeus L. Olczyk)
> Organization: [email-masked]
> Reply-To: [email-masked]
> Content-Type: text/plain; charset=us-ascii
> Sender: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.5
> Precedence: bulk

> Hmm. I get the fealing that lispdebug doesn't expect this behaviour.

Then lispdebug is a non-conformant program.  You need to fix
lispdebug, not CLisp.

> lispdebug no longer maintains the CLisp version?

Perhaps.  How does CLisp work with other CL implementations (if it
does at all)?

Ciao

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.

---

From: [email-masked] (Dr. Edmund Weitz)
Date: Thu Jan 24 10:56:02 2002

Marco Antoniotti <[email-masked]> writes:

> > The function in my first post is not used when lispdebug is
> > run. It is used when lispdebug is being compiled and installed.

You mean lispdebug, I suppose. Works fine with CMUCL.

Edi.