clisp-devel — closed list for developers and testers

[ clisp-Bugs-3206412 ] Installation on HP-UX 11.11

[SourceForge.net <no...@so...>]

Bugs item #3206412, was opened at 2011-03-11 13:23
Message generated for change (Tracker Item Submitted) made by fridolin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christoph Bauer (fridolin)
Assigned to: Bruno Haible (haible)
Summary: Installation on HP-UX 11.11

Initial Comment:
in principle it is possible to install clisp on HP-UX. But I had some problems.

You have to configure with --without-dynamic-module. Otherwise you get an error later.
You could put this as a note in unix/PLATFORMS.

unix/PLATFORM says, you should be able to compile clisp with "cc -Aa -z -D_HPUX_SOURCE"
But at least you would need -Ae instead of -Aa. And even then you get either a undefined symbol  divu_6432_3232_.
(There was a mail in the mailing list about that). But much more success you have with gcc,
which is fine for me.

In the makemake (clisp-4.49was a match of hpux9* and hpux10*, but not hpux11, but this seems to be fixed in the CVS version.

In the Makefile there is a line

	m=`cd ../modules/$@; pwd`; \

unfortunatly it doesn't work on HP-UX. (maybe the string contains a newline or so. it seems to be good, but I can't
do an `ls $m')

I replaced it by 
    m=$(realpath  ../modules/$@) ; \
because I have GNU make here and I changed the next line to

if test -f $$m/configure -a \( ! -f $@/config.status -o $$m/configure -nt $@/config.status \); then ( cd $@ ; $(RMRF) gllib;\
 
(This was also needed with make SHELL=bash. Is my bash 2.04 too old?).

With ffcall installed, i get this error (CVS Version):
subrkw.d: In function 'init_subr_tab_2':
subrkw.d:219: error: 'struct symbol_tab_' has no member named 'S_Krequire'
subrkw.d:220: error: 'struct subr_tab_' has no member named 'D_open_foreign_library'

So I configured with --without-ffcall

I ignored this warning
time.d:565: warning: integer overflow in expression

The last problem (solved with #if 0)

.../clisp/src/gllib/sys/socket.h:398: error: redefinition of 'struct sockaddr_storage'

and then finally:
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/>






----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3206412&group_id=1355

[ clisp-Bugs-3203319 ] ext-clisp test fails on repository

[SourceForge.net <no...@so...>]

Bugs item #3203319, was opened at 2011-03-08 16:01
Message generated for change (Tracker Item Submitted) made by bfishman
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3203319&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: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Barry Fishman (bfishman)
Assigned to: Bruno Haible (haible)
Summary: ext-clisp test fails on repository

Initial Comment:
After December 2, 2010 my builds fail the ext-clisp test.  My last build attempt was March 3, 2011

I am using a generic Ubuntu 10.10 system with the CVS version of FFCALL (built with GCC-4.5)
% uname -a
Linux ecube 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC 2011 x86_64 GNU/Linux
 
My last successful build responds:

GNU CLISP 2.49+ (2010-07-17) (built 3500223877) (memory 3500224198)
Software: GNU C 4.4.5 
gcc -I/usr/include/postgresql -I/usr/local/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a  -lsigsegv libgnu_cl.a  
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 6.1
libffcall 1.11
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /home/util64/clisp/lib/clisp-2.49+/
User language: ENGLISH
Machine: X86_64 (X86_64) ecube [127.0.0.1]

Trying a new build with just "configure --cbd build" I get:

% build/clisp --version
GNU CLISP 2.49+ (2010-07-17) (built 3508604791) (memory 3508604946)
Software: GNU C 4.4.5 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I.  -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a  -lsigsegv libgnu_cl.a  
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 6.1
libffcall 1.11
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI
 GETTEXT UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /home/barry/src/gen/clisp/build/
User language: ENGLISH
Machine: X86_64 (X86_64) ecube [127.0.0.1]

And the contents of the build/test/ext-clisp.erg file is attached.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3203319&group_id=1355

Re: Test ext-clisp fails on ubuntu maverick 64 bit

[Sam S. <sd...@gn...>]

> * Barry Fishman <one...@np...> [2011-03-08 13:17:41 -0500]:
>
> I tried submitting a bug report through sourceforge, but
> only get a blank page when select to add a report.

you need to login
<http://sourceforge.net/apps/trac/sourceforge/ticket/18108>

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://memri.org http://palestinefacts.org http://dhimmi.com
http://truepeace.org http://jihadwatch.org http://mideasttruth.com
Only a fool has no doubts.

Test ext-clisp fails on ubuntu maverick 64 bit

[Barry F. <bar...@ac...>]

This has been a problem with the cvs (now hg) repository since at least
December 2.  I tried submitting a bug report through sourceforge, but
only get a blank page when select to add a report.  I tried posting the
information here but it got rejected because the message was too long
when I included the ext-clisp.erg output and the relevant information.

I am using a standard maverick setup with the exception of using the
latest CVS version of ffcall which passes all of its own test (using
GCC-4.5).  FFCALL fails with the GCC-4.4 but works with GCC-4.3 and
GCC-4.5, but that is another issue.  I tried building CLISP with
the default GCC-4.4 and GCC-4.5 and get the same error.

There are three failurs involving RUN-COMMAND and
MAKE-PIPE-INPUT-STREAM, and LAUNCH.

The errors are:

Form: (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (LIST (RUN-PROGRAM CMD :ARGUMENTS (APPEND ARGS '("-x" "(exit 42)"))) (RUN-PROGRAM CMD :ARGUMENTS (APPEND ARGS '("-x" "(exit)")))))
CORRECT: (42 NIL)
CLISP  : (1 1)
Differ at position 0: 42 vs 1
CORRECT: (42 NIL)
CLISP  : (1 1)

Form: (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (WITH-OPEN-STREAM (S (MAKE-PIPE-INPUT-STREAM (WITH-OUTPUT-TO-STRING (S) (PRINC CMD S) (DOLIST (A ARGS) (PRINC #\Space S) (PRINC A S)) (PRINC " -x \"(quote hello)\"" S)))) (READ-LINE S)))
CORRECT: "HELLO"
CLISP  : ERROR
READ: input stream #1=#<INPUT BUFFERED PIPE-INPUT-STREAM CHARACTER 20022> has reached its end

OUT:
"[SIMPLE-END-OF-FILE]: READ: input stream #1=#<INPUT BUFFERED PIPE-INPUT-STREAM CHARACTER 20022> has reached its end

"

Form: (MULTIPLE-VALUE-BIND (CMD ARGS) (CMD-ARGS) (MULTIPLE-VALUE-BIND (PID IN OUT ERR) (EXT::LAUNCH CMD :ARGUMENTS ARGS :INPUT :PIPE :OUTPUT :PIPE :ERROR :PIPE) (UNWIND-PROTECT (LIST (INTEGERP (SHOW PID)) (OUTPUT-STREAM-P IN) (INPUT-STREAM-P OUT) (INPUT-STREAM-P ERR) (WRITE-LINE "(quit)" IN) (FORCE-OUTPUT IN) (READ-LINE OUT)) (CLOSE IN) (CLOSE OUT) (CLOSE ERR))))
CORRECT: (T T T T "(quit)" NIL "[1]> ")
CLISP  : ERROR
READ: input stream #1=#<INPUT BUFFERED PIPE-INPUT-STREAM CHARACTER 20025> has reached its end

OUT:
"20025
[SIMPLE-END-OF-FILE]: READ: input stream #1=#<INPUT BUFFERED PIPE-INPUT-STREAM CHARACTER 20025> has reached its end

"
-- 
Barry Fishman

clisp "crossbuild" 32bit userland, 64bit kernel broken

[Christoph E. <chr...@de...>]

Hi!

    I'm having trouble getting clisp to build on my mipsel box, a
fuloong mini-PC. Problem is the 64bit kernel causes arimips64.c to be
created but the 32bit compiler (it's a whole 32bit userland) is trying
to build arimips.c which isn't there.

    If I pass --build=mipsel-linux-gnu it fails after the comment5 stage
because the generated files are all empty. Also lots of variables like
CC are empty in the Makefile. seting --host to the same value dies as
well -- this time no arimips* is created but arimips.c still needed.

    While this can probably all be worked around by using the linux32
wrapper script (which modifies uname() and by this tricks the
buildsystem to believe it's in a pure 32bit environment) It'd be just a
workaround and a pitfall for building (and may indicate broken
cross-compile support).

    Testing this kind of issue should be easily possible with a 32bit
linux chroot on a x86_64 system.

Regards

    Christoph

Re: more problems from MT debugger/stack overflow => segfault

[<don...@is...>]

Vladimir Tzankov writes:
 > You are closing the socket too early!
(ah, one of the few places where moving something later in the code
causes it to happen earlier in the execution!)

 > However having segfaults even in this case (read from closed socket)
 > is not good. Will check.
I suspect the next message explains what's happening here.
If each complaint about the closed stream leads to an attempt to enter
the debugger, and the debugger tries to print to the same stream which
causes another error, then we get a stack overflow, and since it's
occuring in a non-main thread, that causes the segfault.

Vladimir Tzankov writes:
 > On 3/6/11, Don Cohen <don...@is...> wrote:
 > > I send this on the theory that any segfault qualifies as a clisp bug.
 > > This is with current source.  On non-MT I get
 > >   *** - Program stack overflow. RESET
 > > whereas in MT I get segfault.
 > 
 > With MT - only the "main thread" (first one) has stack overflow detection.
 > Stack overflow detection/recovery is implemented via libsigsegv and it
 > supports single stack range.
 > May be libsigesgv should be enhanced with multiple stack range support? ?

A few thoughts on this.
- Perhaps there's some shorter term solution involving checking when 
doing at least some operations that use more stack?
- I thought there was something similar used for generational GC, which
I imagined was going to need to detect writes to arbitrary sets of pages.
- It would be useful for debugging if we could get a lisp error BEFORE
the overflow, say, when you exceed half of the available stack and
then again when you exceed 3/4, etc.

Re: stack overflow => segfault in MT

[Vladimir T. <vtz...@gm...>]

On 3/6/11, Don Cohen <don...@is...> wrote:
> I send this on the theory that any segfault qualifies as a clisp bug.
> This is with current source.  On non-MT I get
>   *** - Program stack overflow. RESET
> whereas in MT I get segfault.

With MT - only the "main thread" (first one) has stack overflow detection.
Stack overflow detection/recovery is implemented via libsigsegv and it
supports single stack range.
May be libsigesgv should be enhanced with multiple stack range support? gSam?

Re: more problems from MT debugger

[Vladimir T. <vtz...@gm...>]

On 3/6/11, Don Cohen <don...@is...> wrote:
>
> Code is below.  (It's similar to what I've sent before.)
> ...
>     (unwind-protect
> 	(mt:thread-interrupt
> 	 ans
> 	 :function
> 	 (lambda nil
> 	   (let ((*standard-input* socket)
> 		 (*standard-output* socket)
> 		 (*debug-io* socket)
> 		 (*error-output* socket)
> 		 (*trace-output* socket)
> 		 (*query-io* socket))
> 	     (break "debug"))))
>       (close socket))))

You are closing the socket too early! In your previous mails the code
of your debug-server closes the socket within the interrupted thread:
 (mt:thread-interrupt
 ans
 :function
 (lambda nil
   (let ((*standard-input* socket)
         (*standard-output* socket)
         (*debug-io* socket)
         (*error-output* socket)
         (*trace-output* socket)
                        (*query-io* socket))
     (unwind-protect
          (break "debug")
       (close socket)))))


However having segfaults even in this case (read from closed socket)
is not good. Will check.

Vladimir

stack overflow => segfault in MT

[<don...@is...>]

I send this on the theory that any segfault qualifies as a clisp bug.
This is with current source.  On non-MT I get 
  *** - Program stack overflow. RESET 
whereas in MT I get segfault.
This is, of course, caused by a bug in my program.
In this case I was lucky and got a warning at each recursion,
so was able to break by setting CUSTOM:*BREAK-ON-WARNINGS* to T.
Here's the backtrace a few recursions into the process that 
eventually ends in segfault.

 > Break 1 AP5[8]> :bt
 > <1/3091> #<SYSTEM-FUNCTION EXT:SHOW-STACK> 3
 > <2/3084> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE>
 > <3/3078> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE>
 > <4/3069> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2
 > <5/3066> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-3>
 > <6/3062> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2
 > <7/3048> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2>
 > <8/3046> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
 > <9/3006> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP>
 > <10/2989> #<COMPILED-FUNCTION SYSTEM::WARN-OF-TYPE>
 > <11/2981> #<COMPILED-FUNCTION SYSTEM::C-WARNING>
 > <12/2976> #<COMPILED-FUNCTION SYSTEM::C-WARN>
 > <13/2973> #<COMPILED-FUNCTION SYSTEM::NOTE-FUNCTION-USED>
 > <14/2969> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <15/2948> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <16/2940> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <17/2919> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <18/2838> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL-INLINE>
 > <19/2832> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION-CALL>
 > <20/2829> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL>
 > <21/2808> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <22/2795> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <23/2790> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <24/2772> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <25/2751> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <26/2746> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <27/2728> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <28/2707> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <29/2703> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <30/2682> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <31/2640> #<COMPILED-FUNCTION SYSTEM::C-LET/LET*>
 > <32/2638> 
 > #<COMPILED-FUNCTION
 >   #:|2105 2263 (DEFCONSTANT C-FORM-TABLE (LET # # ...))-172-1|>
 > <33/2617> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <34/2613> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <35/2592> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <36/2505> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <37/2493> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION>
 > <38/2472> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <39/2467> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <40/2459> #<COMPILED-FUNCTION SYSTEM::C-NORMAL-FUNCTION-CALL>
 > <41/2445> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <42/2424> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <43/2402> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <44/2398> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <45/2377> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <46/2290> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <47/2281> #<COMPILED-FUNCTION SYSTEM::COMPILE-LAMBDABODY>
 > <48/2201> #<COMPILED-FUNCTION COMMON-LISP:COMPILE>
 > <49/2194> #<COMPILED-FUNCTION COMPILE>
 > <50/2188> #<COMPILED-FUNCTION MYCOMPILE>
 > <51/2185> #<COMPILED-FUNCTION COMPILE-AP>
 > <52/2181> #<COMPILED-FUNCTION NEED-TESTER>
 > <53/2170> #<COMPILED-FUNCTION TRANSLATE??>
 > <54/2165> #<COMPILED-FUNCTION ??>
 > <55/2165> #<SYSTEM-FUNCTION FUNCALL> 3
 > <56/2163> #<SYSTEM-FUNCTION MACROEXPAND>
 > <57/2150> #<COMPILED-FUNCTION MAKE-TEST-GENERATOR>
 > <58/2141> #<COMPILED-FUNCTION FINDGENERATORS>
 > <59/2132> #<COMPILED-FUNCTION FINDGENERATOR>
 > <60/2111> #<COMPILED-FUNCTION GET-GENERATOR>
 > <61/2103> #<COMPILED-FUNCTION ANALYZE-DESC>
 > <62/2097> #<COMPILED-FUNCTION GENERATOR>
 > <63/2097> #<SYSTEM-FUNCTION FUNCALL> 3
 > <64/2095> #<SYSTEM-FUNCTION MACROEXPAND>
 > <65/2080> #<COMPILED-FUNCTION FORANY>
 > <66/2080> #<SYSTEM-FUNCTION FUNCALL> 3
 > <67/2053> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <68/2045> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <69/2024> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <70/1943> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL-INLINE>
 > <71/1937> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION-CALL>
 > <72/1934> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL>
 > <73/1913> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <74/1900> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <75/1895> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <76/1877> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <77/1856> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <78/1851> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <79/1833> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <80/1812> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <81/1808> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <82/1787> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <83/1745> #<COMPILED-FUNCTION SYSTEM::C-LET/LET*>
 > <84/1743> 
 > #<COMPILED-FUNCTION
 >   #:|2105 2263 (DEFCONSTANT C-FORM-TABLE (LET # # ...))-172-1|>
 > <85/1722> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <86/1718> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <87/1697> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <88/1610> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <89/1598> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION>
 > <90/1577> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <91/1572> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <92/1564> #<COMPILED-FUNCTION SYSTEM::C-NORMAL-FUNCTION-CALL>
 > <93/1550> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <94/1529> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <95/1507> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <96/1503> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <97/1482> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <98/1395> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <99/1386> #<COMPILED-FUNCTION SYSTEM::COMPILE-LAMBDABODY>
 > <100/1306> #<COMPILED-FUNCTION COMMON-LISP:COMPILE>
 > <101/1299> #<COMPILED-FUNCTION COMPILE>
 > <102/1293> #<COMPILED-FUNCTION MYCOMPILE>
 > <103/1290> #<COMPILED-FUNCTION COMPILE-AP>
 > <104/1286> #<COMPILED-FUNCTION NEED-TESTER>
 > <105/1275> #<COMPILED-FUNCTION TRANSLATE??>
 > <106/1270> #<COMPILED-FUNCTION ??>
 > <107/1270> #<SYSTEM-FUNCTION FUNCALL> 3
 > <108/1268> #<SYSTEM-FUNCTION MACROEXPAND>
 > <109/1255> #<COMPILED-FUNCTION MAKE-TEST-GENERATOR>
 > <110/1246> #<COMPILED-FUNCTION FINDGENERATORS>
 > <111/1237> #<COMPILED-FUNCTION FINDGENERATOR>
 > <112/1216> #<COMPILED-FUNCTION GET-GENERATOR>
 > <113/1208> #<COMPILED-FUNCTION ANALYZE-DESC>
 > <114/1202> #<COMPILED-FUNCTION GENERATOR>
 > <115/1202> #<SYSTEM-FUNCTION FUNCALL> 3
 > <116/1200> #<SYSTEM-FUNCTION MACROEXPAND>
 > <117/1185> #<COMPILED-FUNCTION FORANY>
 > <118/1185> #<SYSTEM-FUNCTION FUNCALL> 3
 > <119/1158> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <120/1150> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <121/1129> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <122/1048> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL-INLINE>
 > <123/1042> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION-CALL>
 > <124/1039> #<COMPILED-FUNCTION SYSTEM::C-FUNCALL>
 > <125/1018> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <126/1005> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <127/1000> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <128/982> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <129/961> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <130/956> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <131/938> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <132/917> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <133/913> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <134/892> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <135/850> #<COMPILED-FUNCTION SYSTEM::C-LET/LET*>
 > <136/848> 
 > #<COMPILED-FUNCTION
 >   #:|2105 2263 (DEFCONSTANT C-FORM-TABLE (LET # # ...))-172-1|>
 > <137/827> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <138/823> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <139/802> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <140/715> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <141/703> #<COMPILED-FUNCTION SYSTEM::C-FUNCTION>
 > <142/682> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <143/677> #<COMPILED-FUNCTION SYSTEM::COLLECT-ARGS>
 > <144/669> #<COMPILED-FUNCTION SYSTEM::C-NORMAL-FUNCTION-CALL>
 > <145/655> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
 > <146/634> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <147/612> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <148/608> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
 > <149/587> #<COMPILED-FUNCTION SYSTEM::C-FORM>
 > <150/500> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
 > <151/491> #<COMPILED-FUNCTION SYSTEM::COMPILE-LAMBDABODY>
 > <152/411> #<COMPILED-FUNCTION COMMON-LISP:COMPILE>
 > <153/404> #<COMPILED-FUNCTION COMPILE>
 > <154/398> #<COMPILED-FUNCTION MYCOMPILE>
 > <155/395> #<COMPILED-FUNCTION COMPILE-AP>
 > <156/391> #<COMPILED-FUNCTION NEED-TESTER>
 > <157/380> #<COMPILED-FUNCTION TRANSLATE??>
 > <158/375> #<COMPILED-FUNCTION ??>

 ... 

more problems from MT debugger

[<don...@is...>]

Code is below.  (It's similar to what I've sent before.)
I build from current source, run, load the file below.
Next, go to another shell and telnet to localhost port 1234.
The response is something like this:
 telnet localhost 1234
 Trying 127.0.0.1...
 Connected to localhost.
 Escape character is '^]'.

 ((1 . #<THREAD "debugger-2011-3-5 16:56:59">) (2 . #<THREAD "debug-server">)
 (3 . #<THREAD "main thread">)) 
 enter the number of a thread to interrupt/debug: 

If I enter 1 then things seem to work.
I've recently noticed that if I enter anything else then bad things
happen.  For instance,

 2
 ** - Continuable Error
 debug
 If you continue (by typing 'continue'): Return from BREAK loop
 Break 1 [1]> 

up to this point everything is as expected.  However, I then type
() followed by enter and get

 Connection closed by foreign host.
The original clisp image is not doing so well either.
In one case, while trying to get a response I saw this:
 *** - Internal error: statement in file "../src/stream.d", line 9789
 has been reached!!


If I enter 3 (debug the main thread):

 debug
 If you continue (by typing 'continue'): Connection closed by foreign host.

and in this case the original lisp shows:

 *** - PRINC: The value of *ERROR-OUTPUT* was not an appropriate stream:
      #<CLOSED IO INPUT-BUFFERED SOCKET-STREAM CHARACTER 127.0.0.1:1234>. It
      has been changed to #<IO SYNONYM-STREAM *TERMINAL-IO*>.
followed by a lot of these
 *** - WRITE-CHAR on
      #<CLOSED IO INPUT-BUFFERED SOCKET-STREAM CHARACTER 127.0.0.1:1234> is
      illegal
followed by
 *** - Segmentation fault (core dumped)

It occurs to me that the write-char's may be attempted outputs from new
debugger levels and that I may be running out of stack.

Something similar happens if I try to debug another debug thread.

In any case, I hope others with better understanding of the code can
reproduce this and debug it.
I'm pretty confident on the reproducing side, since this happens on both
of my test machines.

====
(defun serve-one-debugger(socket)
  (let ((tlist (loop for x in (mt:list-threads) with i = 0
		 when (mt:thread-active-p x) collect (cons (incf i) x)))
	ans)
    (print tlist socket)
    (format socket
	    "~&enter the number of a thread to interrupt/debug: ")
    (setf ans (or (cdr (assoc (read socket) tlist))
		  ;; try to put in package ap5?
		  (mt:current-thread)))
    (unwind-protect
	(mt:thread-interrupt
	 ans
	 :function
	 (lambda nil
	   (let ((*standard-input* socket)
		 (*standard-output* socket)
		 (*debug-io* socket)
		 (*error-output* socket)
		 (*trace-output* socket)
		 (*query-io* socket))
	     (break "debug"))))
      (close socket))))
(defun show-ut (&optional (ut (get-universal-time))) 
  (multiple-value-bind 
   (s m h d mo y) (decode-universal-time ut) 
   (format nil "~d-~d-~d ~2,'0d:~2,'0d:~2,'0d" y mo d h m s)))
(defun new-debugger-name()
  (format nil "debugger-~a" (show-ut)))
(defun debug-server()
  (let ((server (socket:socket-server *debug-server-port*
				      :interface "localhost")))
       (unwind-protect
	   (loop
	    (let ((socket (socket:socket-accept server ;; :buffered nil
                                                )))
	      (mt:make-thread #'(lambda ()(serve-one-debugger socket))
			      :name (new-debugger-name))))
	 (socket:socket-server-close server))))

(setf *debug-server-port* 1234)
(mt:make-thread #'debug-server :name "debug-server")

[ clisp-Bugs-3198722 ] CLISP issues arg warning despite :allow-other-keys t

[SourceForge.net <no...@so...>]

Bugs item #3198722, was opened at 2011-03-03 17:56
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3198722&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Bruno Haible (haible)
Summary: CLISP issues arg warning despite :allow-other-keys t

Initial Comment:
(compile nil (lambda () (directory "/" 'xach t :allow-other-keys t))) signals a full warning:

WARNING: keyword XACH is not allowed for function DIRECTORY.
         The only allowed keywords are :IF-DOES-NOT-EXIST, :CIRCLE and :FULL.

I expected no warning, because :allow-other-keys has a compile-time constant value of t.

Also, when putting :allow-other-keys before the unknown keyword, I get this warning:

WARNING: DIRECTORY: ignored keyword XACH T

I would most prefer no warning at all, because I'm trying to signal my intention to use an unknown-to-CLISP keyword argument by passing :allow-other-keys t. However, if there is a warning of some sort, it would be nice if it was a style warning, and it would also be nice if the warning it produced was consistent regardless of the order of the keyword arguments.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3198722&group_id=1355

Re: clisp: cvs --> hg

[Sam S. <sd...@gn...>]

> * Vladimir Tzankov <igm...@tz...> [2011-03-01 23:11:23 +0200]:
>
> On 3/1/11, Sam Steingold <sd...@gn...> wrote:
>> you pushed to the wrong (closed!) branch.
>> this is no good.
>> what is your hg version?
>
> I pushed from OSX and have used Mercurial 1.7.5 (downloaded from
> http://mercurial.berkwood.com/). Have not done anything fancy - just
> clone, replace ChangeLog and spvw_garcol.d, commit, push.

you pushed into a closed branch.
I fixed that.
please do "hg update default" and see if everything is OK.


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://dhimmi.com http://truepeace.org http://honestreporting.com
http://thereligionofpeace.com http://mideasttruth.com http://ffii.org
Rhinoceros has poor vision, but, due to his size, it's not his problem.

Re: clisp: cvs --> hg

[Vladimir T. <vtz...@gm...>]

On 3/1/11, Sam Steingold <sd...@gn...> wrote:
> you pushed to the wrong (closed!) branch.
> this is no good.
> what is your hg version?

I pushed from OSX and have used Mercurial 1.7.5 (downloaded from
http://mercurial.berkwood.com/). Have not done anything fancy - just
clone, replace ChangeLog and spvw_garcol.d, commit, push.

Re: clisp: cvs --> hg

[Sam S. <sd...@gn...>]

> * Vladimir Tzankov <igm...@tz...> [2011-02-25 08:46:02 +0200]:
>
> Sam, I cloned the repository and it contains the same files as my last
> cvs update.
> I committed locally in the new hg repository the only change I have
> pending (fix in GC when gen 0 is split fue to large holes at its end).
> So far everything looks fine.

you pushed to the wrong (closed!) branch.
this is no good.
what is your hg version?


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://palestinefacts.org http://memri.org http://camera.org
http://truepeace.org http://www.memritv.org http://pmw.org.il
Democrats, get out of my wallet! Republicans, get out of my bedroom!

Re: clisp: cvs --> hg

[Vladimir T. <vtz...@gm...>]

On 3/1/11, Sam Steingold <sd...@gn...> wrote:
> OK, please try to push...

looks like it works.

Re: clisp: cvs --> hg

[Sam S. <sd...@gn...>]

> * Vladimir Tzankov <igm...@tz...> [2011-02-25 08:46:02 +0200]:
>
> Sam, I cloned the repository and it contains the same files as my last
> cvs update.
> I committed locally in the new hg repository the only change I have
> pending (fix in GC when gen 0 is split fue to large holes at its end).
> So far everything looks fine.

OK, please try to push...

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://memri.org http://honestreporting.com http://mideasttruth.com
http://openvotingconsortium.org http://dhimmi.com http://jihadwatch.org
char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);}

Re: Threaded CLISP

[Vladimir T. <vtz...@gm...>]

Note that threads in clisp are still experimental - they are not
officially released.
There are still few known issues. When they are resolved - probably
Fink/MacPorts will add --with-threads compilation option.

Vladimir

On 2/28/11, Andrew Pennebaker <and...@gm...> wrote:
> Bordeaux Threads reports that threading is not enabled in Fink CLISP nor
> MacPorts CLISP.
>
> Can Fink and MacPorts CLISP add --with-threads to the compilation options as
> per gnu.org <http://www.gnu.org/software/clisp/impnotes/mt.html>?
>
> Specs:
>
>    - Fink CLISP 2.48-1
>    - MacPorts CLISP 2.49
>    - Mac OS X 10.6.6
>    - MacBook Pro 5,1
>
> Test code:
>
> (ql:quickload 'bordeaux-threads)
> (bt:make-thread (lambda () (format t "Hello Threads~%")) :name "thready")
>
> Trace:
>
> *** - There is no thread support in this instance.
>
> Cheers,
> Andrew Pennebaker
>

Threaded CLISP

[Andrew P. <and...@gm...>]

Bordeaux Threads reports that threading is not enabled in Fink CLISP nor
MacPorts CLISP.

Can Fink and MacPorts CLISP add --with-threads to the compilation options as
per gnu.org <http://www.gnu.org/software/clisp/impnotes/mt.html>?

Specs:

   - Fink CLISP 2.48-1
   - MacPorts CLISP 2.49
   - Mac OS X 10.6.6
   - MacBook Pro 5,1

Test code:

(ql:quickload 'bordeaux-threads)
(bt:make-thread (lambda () (format t "Hello Threads~%")) :name "thready")

Trace:

*** - There is no thread support in this instance.

Cheers,
Andrew Pennebaker

Re: clisp: cvs --> hg

[<don...@is...>]

Sam Steingold writes:

 > basically, "hg pull" gets all the changes from the remote repo to your
 > local machine and "-u" or a separate command "hg up" updates the
 > checkout with the current changes.
Ok, so for people like me who only want to track the repository on sf,
the answer is 
 hg pull -u
(not hg -u pull, btw)

It seems that pull gets the changes and update applies them.
Just doing update applies the changes you already had.

This info appears near the end of 
http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html

I estimate this message will save a half hour for all those who only
want to track the current sf version.

Re: clisp: cvs --> hg

[Anton V. <avo...@ya...>]

25.02.2011, 22:43, "Don Cohen" <don...@is...>:
> Can you explain the difference between pull and update?

I can explain, but I doubt I will be as clear as the hg authors. If you 
know CVS this reading is very easy:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html

Re: clisp: cvs --> hg

[Sam S. <sd...@gn...>]

> * Don Cohen <qba...@vf...> [2011-02-25 09:50:04 -0800]:
>
> Sam Steingold writes:
>  > > please read up https://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial
>  > 
>  > there are now two hg repos: clisp & www.
>  > https://sourceforge.net/projects/clisp/develop
>  > no one has write access yes, but everyone should be able to read.
>  > please test the repos.
>
> I'm trying to figure out what corresponds to 
>   cd ...
>   cvs up -d

hg clone -- once! -- like "cvs co"

hg pull -u -- regularly -- like "cvs up"

basically, "hg pull" gets all the changes from the remote repo to your
local machine and "-u" or a separate command "hg up" updates the
checkout with the current changes.

similarly, "hg ci" commits the changes to the local repo and "hg push"
delivers them for everyone to see.

_PLEASE_ _do_ read at least a few pages here: http://hgbook.red-bean.com/read/
it DOES take some time to get used to the ideas of distributed VCS.

the main idea you have to start living with is that the 3 clisp repos I
have here on my HD are no different from the official clisp repo on SF
or from the (several?) repos Vladimir has or from what you will get when
you clone.  technically they all correspond to the cvs root directory
with all those "*,v" rcs files, i.e., they contain full development
history.
"pull" and "push" allow synchronizing them and the official repo at SF
is the dead drop through which all our repos are communicating, although
they do not have to - you can clone and push between your own repos.


-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X
http://ffii.org http://dhimmi.com http://truepeace.org http://www.memritv.org
http://iris.org.il http://memri.org http://honestreporting.com
My inferiority complex is not as good as yours.

Re: clisp: cvs --> hg

[<don...@is...>]

  > hg update
  You are almost right.
  Actually, "cvs up -d" corresponds just to "hg pull".
Can you explain the difference between pull and update?

Re: clisp: cvs --> hg

[Anton V. <avo...@ya...>]

"Don Cohen" <don...@is...>:
>>I'm trying to figure out what corresponds to
>>  cd ...
>>  cvs up -d

> This seems to have worked for me (after installing mercurial):
>  cd ...
>  hg clone http://clisp.hg.sourceforge.net:8000/hgroot/clisp/clisp
> [..]
>  hg update

You are almost right.

Actually, "cvs up -d" corresponds just to "hg pull".

As for the "hg clone", it just corresponds to "cvs co".

Best regards,
- Anton

Re: clisp: cvs --> hg

[Raymond T. <toy...@gm...>]

On 2/25/11 1:37 PM, Don Cohen wrote:
>  > > http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial#Access
>  > > contains this:
>  > >   rsync -av PROJECTNAME.hg.sourceforge.net::hgroot/PROJECTNAME/* .
>  > rsync was disabled for git and hg on sourceforge a while ago.  I think
>  > it still is.
> (So why does the sourceforge page contain that instruction?)
I assume the disabling is temporary, due to the attack on
sourceforge.net about a month ago.  They might still be recovering.

Ray

Re: clisp: cvs --> hg

[<don...@is...>]

Raymond Toy writes:

 > > I'm trying to figure out what corresponds to 
 > >   cd ...
 > >   cvs up -d
 > I think you want to do hg clone first.  Then you can do hg pull to get
 > new stuff and hg update to update your local files.  (I am a new hg
 > user, but this is what I do.  There might be better ways.)
In hope of saving some trouble for others,
This seems to have worked for me (after installing mercurial):
 cd ...
 hg clone http://clisp.hg.sourceforge.net:8000/hgroot/clisp/clisp
I notice some differences between the resulting directory and the 
one I had from cvs.  All of these seem to be missing from hg:
 acorn, amiga, cygwin32, dos, dosdjgpp, doswatcom, ffcall, libcharset,
 libiconv, nextapp, os2, queued, sigsegv, win32bc, win32gcc 

It looks like
 cd ...
 hg update
at least does something plausible (reports no changes).
My configure and make commands do seem to work there.
So I'll assume, unless I hear otherwise, that the two lines
above are the answer to my question.

 > > http://sourceforge.net/apps/trac/sourceforge/wiki/Mercurial#Access
 > > contains this:
 > >   rsync -av PROJECTNAME.hg.sourceforge.net::hgroot/PROJECTNAME/* .
 > rsync was disabled for git and hg on sourceforge a while ago.  I think
 > it still is.
(So why does the sourceforge page contain that instruction?)