Hello,
On Monday 30 October 2006 16:26, Hoehle, Joerg-Cyril wrote:
> I don't know whether Bruno answered separately. Here's my opinion from
> what I remember Bruno told me when I raised the topic years ago.
He did not reply yet.
> o ffcall is used by other packages (perhaps not in Debian), IIRC some
> Smalltalk implementation uses it (used it? -- or do I mix things up with
> libsigsegv?).
> Therefore it would IMHO be a bad idea to keep it completely inside the
> CLISP package.
=2E.
> o If that CVS tree is newer than any package, then it means that the
> maintainer exhibits symptoms of "too many things to do and maintain",
> e.g. Bruno Haible is likely too busy to make a new release. Obviously
> there has not been too much pressure from ffcall users to urge a new
> official release.
=46rom what I hear a new release is 'planned' so I will take the patches do=
ne=20
for clisp 2.41 and some powerpc patches I got and create a 'patched' versio=
n=20
of ffcall version 1.10.
If the library compiles on the autobuilders I will send the patches :-)
Thanks for the info.
Groetjes, Peter
=2D-=20
signature -at- pvaneynd.mailworks.org=20
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Arons=
on|=20

Peter Van Eynde asked:
>As future [Debian] maintainer of ffcall I noticed that the latest=20
>release of this library (1.10 from=20
>http://www.haible.de/bruno/packages->ffcall.html) does not=20
>seem to have been updated with the changes from clisp.
>Will there be a future ffcall release or should I just base=20
>the ffcall library on the ffcall part of clisp?
>
>Groetjes, Peter
I don't know whether Bruno answered separately. Here's my opinion from
what I remember Bruno told me when I raised the topic years ago.
o ffcall is used by other packages (perhaps not in Debian), IIRC some
Smalltalk implementation uses it (used it? -- or do I mix things up with
libsigsegv?).
Therefore it would IMHO be a bad idea to keep it completely inside the
CLISP package.
OTOH, CLISP's configure expects ffcall to be right there in the source
tree. I wonder if it's worth the effort to change that and have Debian
clisp builds depend on some ffcall-dev package.
o There's no other project page for ffcall than the one you mention.
o In particular, the only current online ffcall source is the one within
the CLISP CVS tree at sourceforge (or am I messing state again with
libsigsegv).
I don't know whether Bruno maintains a private copy of the source.
o If that CVS tree is newer than any package, then it means that the
maintainer exhibits symptoms of "too many things to do and maintain",
e.g. Bruno Haible is likely too busy to make a new release. Obviously
there has not been too much pressure from ffcall users to urge a new
official release.
Regards,
Jorg Hohle.

Bugs item #1538436, was opened at 2006-08-11 00:10
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1538436&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Smith (ansonyumo)
Assigned to: Bruno Haible (haible)
Summary: Internal Error: statement in file "debug.d", line 1149
Initial Comment:
Hi,
I was playing around with clisp 2.39 on cygwin tonight
and hit an internal error. It asked me to notify the
authors, so here goes. I eventually narrowed the
problem down to this set of repeatable steps:
[1]> (set 'a '(eval b))
(EVAL B)
[2]> set 'b '(eval a)
*** - EVAL: variable SET has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be
used instead of SET.
STORE-VALUE :R2 You may input a new value for SET.
ABORT :R3 ABORT
Break 1 [3]> exit
*** - EVAL: variable EXIT has no value
The following restarts are available:
USE-VALUE :R1 You may input a value to be
used instead of EXIT.
STORE-VALUE :R2 You may input a new value for EXIT.
ABORT :R3 ABORT
ABORT :R4 ABORT
Break 2 [4]> quit
[5]> (set 'b '(eval a))
(EVAL A)
[6]> (eval a)
*** - Program stack overflow. RESET
*** - Internal error: statement in file "debug.d", line
1149 has been
reached!!
Please send the authors of the program a
description how you produced
this error!
Break 1 [7]>
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-10-26 09:07
Message:
Logged In: YES
user_id=5735
may be related to
https://sourceforge.net/tracker/index.php?func=detail&aid=1584890&group_id=1355&atid=101355
----------------------------------------------------------------------
Comment By: Reini Urban (rurban)
Date: 2006-08-12 08:45
Message:
Logged In: YES
user_id=13755
After blowing up the stack inside the debugger I inspected
the bt->bt_stack and bt->bt_function with gdb:
stackptr=0x7c9232f8, funcptr=0x7c91e3ed
(gdb) x 0x7c9232f8
0x7c9232f8 <ntdll!CsrProbeForWrite+87>: 0x850ffb3b
(gdb) x 0x7c91e3ed
0x7c91e3ed <ntdll!ZwRequestWaitReplyPort+12>: 0x90000cc2
backtrace broken.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-08-11 16:10
Message:
Logged In: YES
user_id=5735
Brian, your bug report is appreciated.
please do not overreact.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-08-11 16:07
Message:
Logged In: YES
user_id=5735
the internal error, if reproducible, should be fixed even if
it is arrived at by a user blunder.
----------------------------------------------------------------------
Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 16:05
Message:
Logged In: YES
user_id=46488
OK, from the responses I have received from you guys it is
apparent that I should have fully qualified the error report
and my user profile.
1) I am not reporting any undesirable behavior, except for
the Internal Error.
2) I am not offering up these LISP statements up as an
example of anything useful. I whittled down the use case
into as small a set of steps as possible in order to help
you guys reproduce the error.
3) I am not a regular clisp user. This bug was found after
playing with clisp for about 10 minutes.
4) I am reporting this bug out of the goodness of my heart.
It does not matter to me whether you fix it.
5) Lastly, I am not an idiot. Please stop treating me as
such. If you would carefully read my original report, I was
only reporting the "Internal Error". I made no complaint
about the REPL not accepting my bad s-expressions or the
overflow. These were merely included to, as requested by the
clisp error message, describe how I got the machine into the
undesirable state.
Apologies for the flames, but my frustration level has
peaked. In the future, I will just ignore any requests from
clisp for help. Thank you. I have learned my lesson.
----------------------------------------------------------------------
Comment By: Reini Urban (rurban)
Date: 2006-08-11 15:41
Message:
Logged In: YES
user_id=13755
[1]> (set 'a '(eval b))
(EVAL B)
[2]> set 'b '(eval a)
I hope you ARE aware the the original error is from the
missing brackets in [2].
I don't know if you get to the point where you infinitly
recurse into (eval a) => eval b) => (eval a) ... statements,
which in every language would blow up either the stack or
the heap or even might freeze the system.
Thanks for your report though.
In my opinion it can be closed.
After the great message
"*** - Program stack overflow. RESET",
do we want to fix the symptom in debug.d?
-- reini urban - cygwin maintainer of clisp
----------------------------------------------------------------------
Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 13:22
Message:
Logged In: YES
user_id=46488
Look, I'm just trying to be a good citizen. clisp asked me
to report the error and I did.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-08-11 12:45
Message:
Logged In: YES
user_id=5735
I followed your example step-by-step on linux
and I did not see the internal error.
clisp developers do not have access to cygwin.
it is up to you to do the debugging.
----------------------------------------------------------------------
Comment By: Brian Smith (ansonyumo)
Date: 2006-08-11 12:28
Message:
Logged In: YES
user_id=46488
I realize that the overflow is expected, that was the goal
of the experiment. The "Internal error" was the issue I
reported.
If I do this on clisp 2.38/cygwin, I get a segmentation
fault. 2.39 is a little better, in that it just reports an
Internal Error.
You have to do the exact set of steps I did, including the
illegal statements.
I would debug it if I knew more about clisp, but
unfortunately for all those involved I'm just toying with it.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-08-11 11:34
Message:
Logged In: YES
user_id=5735
"Program stack overflow. RESET" is to be expected (you are
doing infinite recursion).
i cannot reproduce "Internal error" though - could you
please try to debug it?
set a break in top_of_back_trace_frame and use "xout" or
"zout" to print the valus of "fun".
see http://clisp.cons.org/impnotes/faq.html#faq-debug
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1538436&group_id=1355

Bugs item #1584890, was opened at 2006-10-26 02:37
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1584890&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: szergling (szergling)
Assigned to: Bruno Haible (haible)
Summary: Program stack overflow. RESET -> Internal error
Initial Comment:
Hi folks,
I met a problem the other day with some buggy code of
mine involving loop and tail-recursion. Here's the
reproducible problem:
[3]> (load "~/code/lisp/delme.lisp")
;; Loading file /cygdrive/c/home/code/lisp/delme.lisp ...
;; Loaded file /cygdrive/c/home/code/lisp/delme.lisp
T
...compile the function trace-outline...
[15]> (compiled-function-p #'trace-outline)
T
[16]> (trace-outline '(115 41))
*** - Program stack overflow. RESET
*** - Internal error: statement in file "debug.d", line
1149 has been
reached!!
Please send the authors of the program a
description how you produced
this error!
I can usually, but not always continue working after this.
My setups:
uname -a
CYGWIN_NT-5.1 mb6596 1.5.21(0.156/4/2) 2006-07-30 14:21
i686 Cygwin
CL-USER> (lisp-implementation-type)
"CLISP"
CL-USER> (lisp-implementation-version)
"2.39 (2006-07-16) (built 3367203258) (memory 3367203785)"
I have been able to reproduce this on a similar
pre-built cygwin clisp setup and without the full
linking set (all the same version). Here's the file I
used. Note that the code is *BUGGY*, and I have since
rewrote it to get the code to run. For context, I
provide that here. It was a quick hack to create an
ordered linked list of points around the boundary of an
image object, like chain codes.
(defparameter *coords* (list))
;; This works.
(defun trace-outline (start-coord)
(flet ((valid-step (c)
(and (= (apply #'aref *image* c) 1)
(not (equal (cadr *coords*) c)))))
(push start-coord *coords*)
(loop
for (row col) = (car *coords*)
do (loop
for c in `((,(1- row) ,col) (,(1+ row) ,col)
(,row ,(1- col)) (,row ,(1+ col)))
when (valid-step c)
do
(push c *coords*)
(return))
until (equal start-coord (car *coords*)))))
PS: It is not convenient to change the data *rows* or
*cols*, and since they're so small, it didn't matter -
I'm sending them verbatim. Additionally, using a global
counter, I counted more than 8000 iterations in the
loop tail-function-call bit before the stack error.
Please tell if I've screwed up anywhere, or missed out
anything. Thanks in advance.
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-10-26 09:07
Message:
Logged In: YES
user_id=5735
may be related to
https://sourceforge.net/tracker/index.php?func=detail&aid=1538436&group_id=1355&atid=101355
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1584890&group_id=1355

Bugs item #1584890, was opened at 2006-10-26 06:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1584890&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: szergling (szergling)
Assigned to: Bruno Haible (haible)
Summary: Program stack overflow. RESET -> Internal error
Initial Comment:
Hi folks,
I met a problem the other day with some buggy code of
mine involving loop and tail-recursion. Here's the
reproducible problem:
[3]> (load "~/code/lisp/delme.lisp")
;; Loading file /cygdrive/c/home/code/lisp/delme.lisp ...
;; Loaded file /cygdrive/c/home/code/lisp/delme.lisp
T
...compile the function trace-outline...
[15]> (compiled-function-p #'trace-outline)
T
[16]> (trace-outline '(115 41))
*** - Program stack overflow. RESET
*** - Internal error: statement in file "debug.d", line
1149 has been
reached!!
Please send the authors of the program a
description how you produced
this error!
I can usually, but not always continue working after this.
My setups:
uname -a
CYGWIN_NT-5.1 mb6596 1.5.21(0.156/4/2) 2006-07-30 14:21
i686 Cygwin
CL-USER> (lisp-implementation-type)
"CLISP"
CL-USER> (lisp-implementation-version)
"2.39 (2006-07-16) (built 3367203258) (memory 3367203785)"
I have been able to reproduce this on a similar
pre-built cygwin clisp setup and without the full
linking set (all the same version). Here's the file I
used. Note that the code is *BUGGY*, and I have since
rewrote it to get the code to run. For context, I
provide that here. It was a quick hack to create an
ordered linked list of points around the boundary of an
image object, like chain codes.
(defparameter *coords* (list))
;; This works.
(defun trace-outline (start-coord)
(flet ((valid-step (c)
(and (= (apply #'aref *image* c) 1)
(not (equal (cadr *coords*) c)))))
(push start-coord *coords*)
(loop
for (row col) = (car *coords*)
do (loop
for c in `((,(1- row) ,col) (,(1+ row) ,col)
(,row ,(1- col)) (,row ,(1+ col)))
when (valid-step c)
do
(push c *coords*)
(return))
until (equal start-coord (car *coords*)))))
PS: It is not convenient to change the data *rows* or
*cols*, and since they're so small, it didn't matter -
I'm sending them verbatim. Additionally, using a global
counter, I counted more than 8000 iterations in the
loop tail-function-call bit before the stack error.
Please tell if I've screwed up anywhere, or missed out
anything. Thanks in advance.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1584890&group_id=1355

Hello,
As future maintainer of ffcall I noticed that the latest release of this
library (1.10 from http://www.haible.de/bruno/packages-ffcall.html) does not
seem to have been updated with the changes from clisp.
Will there be a future ffcall release or should I just base the ffcall library
on the ffcall part of clisp?
Groetjes, Peter
--
signature -at- pvaneynd.mailworks.org
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave Aronson|

Bruno Haible wrote:
> Sam wrote:
>> What does this warning mean:
>> xthread.d: In function 'testandset':
>> xthread.d:393: warning: matching constraint does not allow a register
>> xthread.d:390: warning: matching constraint does not allow a register
>
> You have the gcc doc and gcc sources. What do they say about the warning?
>
> To me it looks like gcc either wants to emit a hint for optimization, or
> wants to use a register variable but is encumbered by the "=m" constraint.
> But there's nothing to optimize: A spinlock _must_ be in memory because
> the xchgl instruction only works on memory words.
spinlock appears to be a fairly generic concept.
why did you implement it yourself? (with assembly, no less!)
isn't there a library for that?
what do other MT systems use?
> Therefore I'd say you need
> to verify the .s file produced by gcc to see that gcc doesn't do unwanted
> things with the spin lock.
I don't grok assembly.
Sam.

Sam wrote:
> What does this warning mean:
> xthread.d: In function 'testandset':
> xthread.d:393: warning: matching constraint does not allow a register
> xthread.d:390: warning: matching constraint does not allow a register
You have the gcc doc and gcc sources. What do they say about the warning?
To me it looks like gcc either wants to emit a hint for optimization, or
wants to use a register variable but is encumbered by the "=m" constraint.
But there's nothing to optimize: A spinlock _must_ be in memory because
the xchgl instruction only works on memory words. Therefore I'd say you need
to verify the .s file produced by gcc to see that gcc doesn't do unwanted
things with the spin lock.
Bruno

On Oct 20, 2006, at 7:30 AM, Magnus Henoch wrote:
> Jos=E9 H. Espinosa <jose.h.espinosa@...> writes:
>
>> configure: error: `CPPFLAGS' has changed since the previous run:
>> configure: former value: -I/sw/include
>> configure: current value: -I/sw/include
>> configure: error: changes in the environment can compromise the build
>
> I stumbled upon this once, but didn't pay much attention. If I
> remember correctly, the problem is that the CPPFLAGS variable contains
> a space, but somewhere the space is removed, and then this comparison
> fails. I "fixed" it by setting CPPFLAGS to a value without spaces.
>
> Magnus
>
I find the problem. Attached is the patch

José H. Espinosa <jose.h.espinosa@...> writes:
> configure: error: `CPPFLAGS' has changed since the previous run:
> configure: former value: -I/sw/include
> configure: current value: -I/sw/include
> configure: error: changes in the environment can compromise the build
I stumbled upon this once, but didn't pay much attention. If I
remember correctly, the problem is that the CPPFLAGS variable contains
a space, but somewhere the space is removed, and then this comparison
fails. I "fixed" it by setting CPPFLAGS to a value without spaces.
Magnus

> * Klaus Ebbe Grue <tehr@...> [2006-10-17 17:09:16 +0200]:
>
> Hi clisp-devel,
>
> In the distribution, step 12 of the file unix/INSTALL says:
>
> 12. If you are lazy and have too few spare neurons to remember this long
> process, just use the shortcut, like I do:
>
> ./configure --with-module=rawsock --build build-dir
>
> this covers the build process through step 8 (except mod-check).
> You will need to become root to do the install.
>
> I suggest changing the last line to
>
> To install, proceed thus:
>
> cd build-dir
> su
> make install
>
> With the present formulation, one has to go back to step 9 (a problem
> for us who are lazy) and also have to figure out the 'cd build-dir' (a
> problem for us with few spare neurons).
I made a different change: when ${prefix} or ${exec_prefix} are not
writable, run "make install" using su and recommend "--install" in step
12.
please try CVS head.
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://truepeace.orghttp://dhimmi.comhttp://mideasttruth.comhttp://ffii.orghttp://pmw.org.ilhttp://memri.orghttp://israelnorthblog.livejournal.com
There is Truth, and its value is T. Or just non-NIL. So 0 is True!