gmane.lisp.clisp.devel

Re: [ clisp-Patches-3529615 ] ARM fixes

Sam Steingold — 2012-05-25T01:41:43

Bruno,


do we need to support v4?

[ clisp-Patches-3529607 ] Format specifier patch

SourceForge.net — 2012-05-25T01:37:08

Patches item #3529607, was opened at 2012-05-24 15:52
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3529607&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: Format specifier patch

Initial Comment:
While compiling on a 32-bit platform, I saw some GCC warnings about printf arguments not matching the corresponding format specifiers.  This patch fixes all of the warnings I saw on that platform.

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

Date: 2012-05-24 18:37

Message:
this patch results in these warnings on amd64:

In file included from ../src/spvw.d:161:0:
../src/spvw_debug.d: In function ‘nobject_out1’:
../src/spvw_debug.d:123:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintWL’
[-Wformat]
../src/spvw_debug.d:124:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 4 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:188:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 5 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:284:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
[-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 5 has type ‘int’ [-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 6 has type ‘int’ [-Wformat]
../src/spvw_debug.d:289:13: warning: format ‘%u’ expects argument of
type ‘unsigned int’, but argument 7 has type ‘long unsigned int’
[-Wformat]
../src/spvw_debug.d: In function ‘bt_out’:
../src/spvw_debug.d:362:11: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
../src/spvw_debug.d:371:13: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
[-Wformat]
In file included from ../src/spvw.d:3996:0:
../src/spvw_memfile.d: In function ‘loadmem_from_handle’:
../src/spvw_memfile.d:1820:5: warning: format ‘%lu’ expects argument of
type ‘long unsigned int’, but argument 3 has type ‘uintL’
[-Wformat]
In file included from ../src/error.d:502:0:
../src/errunix.d: In function ‘errno_out_low’:
../src/errunix.d:97:3: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 4 has type ‘uintL’ [-Wformat]


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

Re: Test failure on ARM

Jerry James — 2012-05-24T23:24:03

I just posted a patch for this problem on sourceforge.  Now the build
goes a lot farther, but ultimately crashes.  The crash is identical to
one that was earlier identified as being related to generational
garbage collection.  So I turned off generational GC and tried again,
only to have the build crash with a different segfault, which has also
been connected to garbage collection.

Maybe these problems have been fixed since the 2.49 release.  I tried
building with mercurial head, only to have a different build failure
because host_cpu_c_abi is set to "armel" instead of "arm" in makemake,
resulting in all of the ARM-specific code being skipped.  That's all
the time I have to mess with it today.  I'll try to patch that up
tomorrow.

[ clisp-Patches-3529615 ] ARM fixes

SourceForge.net — 2012-05-24T23:02:27

Patches item #3529615, was opened at 2012-05-24 16:02
Message generated for change (Tracker Item Submitted) made by jjames
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3529615&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: ARM fixes

Initial Comment:
As reported recently on the mailing list, I have had some problems with clisp failing to build on ARM platforms. WIth the help of Google and the ARM assembly language reference manual, I think I have all the problems sorted out now. The illegal instruction problem I reported is due to lines like this:

LDMFD sp!, {v1,v2,v3,v4,v5,v6,pc}^

The trailing carat indicates that this is a return-from-exception. But it isn't. All instances of this in the code are normal function returns. This patch eliminates all such trailing carats. After doing that, I again hit an illegal instruction, this time on a line of this form:

MOVEQS pc, lr

That form of the instruction has been deprecated, and is apparently now illegal on whatever Fedora's koji builders use. The new way to do that is this:

BXEQ lr

which the assembly language reference manual says is also friendlier to the branch prediction logic. However, that instruction is not available on ARM v4 and earlier. That doesn't cause me any issues, since Fedora only supports ARM v5 and later, but if you want to support those earlier versions, you may need a macro that expands to the existing form for v4 and earlier, and the new form for v5 and later.

GCC 4.7 also wants functions to have the appropriate ELF type, so I added the appropriate magic to the GLABEL macro.

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Patches-3529607 ] Format specifier patch

SourceForge.net — 2012-05-24T22:52:20

Patches item #3529607, was opened at 2012-05-24 15:52
Message generated for change (Tracker Item Submitted) made by jjames
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301355&aid=3529607&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jerry James (jjames)
Assigned to: Nobody/Anonymous (nobody)
Summary: Format specifier patch

Initial Comment:
While compiling on a 32-bit platform, I saw some GCC warnings about printf arguments not matching the corresponding format specifiers.  This patch fixes all of the warnings I saw on that platform.

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

Re: Test failure on ARM

Jerry James — 2012-05-18T21:28:24

Thanks, Sam.  I'm going to make one more attempt before I file a bug.
I'm going to try building the latest mercurial sources and see if the
same problem occurs.  We're stilling distributing vanilla 2.49 in
Fedora.  Should we be?

Anyway, compiling on the ARM VM takes a very long time, so I probably
won't have time to get to it until Monday or Tuesday.  If it suffers
the same failure, I'll file a bug.  If not, I'll see if I can figure
out what commit fixes the problem.

Regards,

Re: Test failure on ARM

Sam Steingold — 2012-05-18T20:05:47

I cannot help with the specific problem, but I will ask you to file a
CLISP bug report on SF.

You can disable all assembly by adding -DNO_ASM to CFLAGS (either at
configure time as "./configure CFLAGS=-DNO_ASM build-no-asm" or by editing
the Makefile and doing "make clean"). Please see clisp/unix/PLATFORMS
for more information.

Re: Test failure on ARM

Jerry James — 2012-05-18T17:39:39

I finally got around to figuring out how to create an ARM VM with
qemu.  I've got the upcoming Fedora 17 release running on that VM.
The problem is not in ffcall after all.  The illegal instruction error
is occurring on the very last instruction of copy_loop_up_l2() in
src/ariarm.d.  A disassembly with GDB shows:

0x00106b3c <+0>:     ldm     r0!, {r2, r4, r12, lr}
0x00106b40 <+4>:     stmia   r1!, {r2, r4, r12, lr}
0x00106b44 <+8>:     subs    r3, r3, #8
0x00106b48 <+12>:    ldmge   r0!, {r2, r4, r12, lr}
0x00106b4c <+16>:    stmiage r1!, {r2, r4, r12, lr}
0x00106b50 <+20>:    bgt     0x106b3c <copy_loop_up_l2>
0x00106b54 <+24>:    mov     r0, r1
0x00106b58 <+28>:    ldm     sp!, {r4, pc}^

It's that last ldm instruction, at +28, that is the problem.  Also, I
see this from compilation of src/ariarm.s:
ariarm.s: Assembler messages:
ariarm.s:1: Warning: ignoring attempt to redefine built-in register 'a1'
ariarm.s:2: Warning: ignoring attempt to redefine built-in register 'a2'
ariarm.s:3: Warning: ignoring attempt to redefine built-in register 'a3'
ariarm.s:4: Warning: ignoring attempt to redefine built-in register 'a4'
ariarm.s:5: Warning: ignoring attempt to redefine built-in register 'v1'
ariarm.s:6: Warning: ignoring attempt to redefine built-in register 'v2'
ariarm.s:7: Warning: ignoring attempt to redefine built-in register 'v3'
ariarm.s:8: Warning: ignoring attempt to redefine built-in register 'v4'
ariarm.s:9: Warning: ignoring attempt to redefine built-in register 'v5'
ariarm.s:10: Warning: ignoring attempt to redefine built-in register 'v6'
ariarm.s:12: Warning: ignoring attempt to redefine built-in register 'sl'
ariarm.s:13: Warning: ignoring attempt to redefine built-in register 'fp'
ariarm.s:14: Warning: ignoring attempt to redefine built-in register 'ip'
ariarm.s:15: Warning: ignoring attempt to redefine built-in register 'sp'
ariarm.s:16: Warning: ignoring attempt to redefine built-in register 'lr'
ariarm.s:17: Warning: ignoring attempt to redefine built-in register 'pc'
ariarm.s:152: Warning: s suffix on comparison instruction is deprecated
ariarm.s:1027: Warning: s suffix on comparison instruction is deprecated
ariarm.s:1032: Warning: s suffix on comparison instruction is deprecated

I don't speak ARM assembly.  Is there anybody here who does and can
give me a clue as to what to do?  This is with GCC 4.7 on an armv7hl
platform.  Thanks,

[ clisp-Bugs-3525509 ] CLISP treats CL:REQUIRE specially at compiletime

SourceForge.net — 2012-05-10T12:51:54

Bugs item #3525509, was opened at 2012-05-10 05:48
Message generated for change (Comment added) made by xach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3525509&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: Zach Beane (xach)
Assigned to: Bruno Haible (haible)
Summary: CLISP treats CL:REQUIRE specially at compile time

Initial Comment:
I have a file "test.lisp" that contains only this:

  (require 'bogus)

When I start "clisp -ansi -norc" and issue (compile-file "test.lisp"), I get this:

    [1]> (compile-file "test.lisp")
    ;; Compiling file /home/xach/test.lisp ...
    *** - LOAD: A file with name BOGUS does not exist
    The following restarts are available:
    ABORT          :R1      Abort main loop
    Break 1 [2]> :bt
    <1/574> #<SYSTEM-FUNCTION SHOW-STACK> 3
    <2/567> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE>
    <3/561> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE>
    <4/552> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2
    <5/549> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-3>
    <6/545> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2
    <7/531> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2>
    <8/529> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
    <9/489> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP>
    <10/486> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> 1
    <11/481> #<SYSTEM-FUNCTION SYSTEM::ERROR-OF-TYPE>
    <12/457> #<COMPILED-FUNCTION LOAD>
    <13/443> #<COMPILED-FUNCTION SYSTEM::SIMPLE-REQUIRE>
    <14/438> #<COMPILED-FUNCTION REQUIRE>
    <15/430> #<COMPILED-FUNCTION SYSTEM::LOAD-OR-COMPILE>
    <16/425> #<COMPILED-FUNCTION SYSTEM::C-REQUIRE>
    [422] EVAL frame for form (SYSTEM::C-REQUIRE 'BOGUS)
    <17/419> #<SPECIAL-OPERATOR PROGN>
    [418] EVAL frame for form (PROGN (SYSTEM::C-REQUIRE 'BOGUS))
    <18/410> #<SYSTEM-FUNCTION EVAL>
    <19/408> #<COMPILED-FUNCTION SYSTEM::C-EVAL-AND-WRITE-LIB>
    [406] EVAL frame for form (SYSTEM::C-EVAL-AND-WRITE-LIB '(PROGN (SYSTEM::C-REQUIRE 'BOGUS)))
    <20/403> #<SPECIAL-OPERATOR PROGN>
    [402] EVAL frame for form (PROGN (SYSTEM::C-EVAL-AND-WRITE-LIB '(PROGN (SYSTEM::C-REQUIRE 'BOGUS))))
    <21/394> #<SYSTEM-FUNCTION EVAL>
    <22/387> #<COMPILED-FUNCTION SYSTEM::C-EVAL-WHEN>
    <23/365> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <24/343> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <25/340> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
    <26/319> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <27/315> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
    <28/294> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <29/207> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
    <30/198> #<COMPILED-FUNCTION SYSTEM::COMPILE-LAMBDABODY>
    <31/186> #<COMPILED-FUNCTION SYSTEM::COMPILE-TOPLEVEL-FORM>
    <32/42> #<COMPILED-FUNCTION COMPILE-FILE>
    [34] EVAL frame for form (COMPILE-FILE "test.lisp")
    Printed 32 frames

I am using 64-bit Linux. I get this error with CLISP 2.49 and CLISP from Mercurial.

Since REQUIRE is a function, I expected the error at runtime (when loading the file or its fasl), not at compile-time.

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

Date: 2012-05-10 05:51

Message:
Well, duh, I now see this is documented in the manual. However, this causes
a problem for  a real program that does (ignore-errors (require 'asdf)) in
an attempt to load the "system" ASDF if it is available. Since REQUIRE is
eagerly evaluated at compile time, the error isn't ignored as it should
be.

Any suggestions?

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3525509 ] CLISP treats CL:REQUIRE specially at compiletime

SourceForge.net — 2012-05-10T12:48:32

Bugs item #3525509, was opened at 2012-05-10 05:48
Message generated for change (Tracker Item Submitted) made by xach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3525509&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: Zach Beane (xach)
Assigned to: Bruno Haible (haible)
Summary: CLISP treats CL:REQUIRE specially at compile time

Initial Comment:
I have a file "test.lisp" that contains only this:

  (require 'bogus)

When I start "clisp -ansi -norc" and issue (compile-file "test.lisp"), I get this:

    [1]> (compile-file "test.lisp")
    ;; Compiling file /home/xach/test.lisp ...
    *** - LOAD: A file with name BOGUS does not exist
    The following restarts are available:
    ABORT          :R1      Abort main loop
    Break 1 [2]> :bt
    <1/574> #<SYSTEM-FUNCTION SHOW-STACK> 3
    <2/567> #<COMPILED-FUNCTION SYSTEM::PRINT-BACKTRACE>
    <3/561> #<COMPILED-FUNCTION SYSTEM::DEBUG-BACKTRACE>
    <4/552> #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT> 2
    <5/549> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2-3>
    <6/545> #<SYSTEM-FUNCTION SYSTEM::SAME-ENV-AS> 2
    <7/531> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP-2>
    <8/529> #<SYSTEM-FUNCTION SYSTEM::DRIVER>
    <9/489> #<COMPILED-FUNCTION SYSTEM::BREAK-LOOP>
    <10/486> #<SYSTEM-FUNCTION INVOKE-DEBUGGER> 1
    <11/481> #<SYSTEM-FUNCTION SYSTEM::ERROR-OF-TYPE>
    <12/457> #<COMPILED-FUNCTION LOAD>
    <13/443> #<COMPILED-FUNCTION SYSTEM::SIMPLE-REQUIRE>
    <14/438> #<COMPILED-FUNCTION REQUIRE>
    <15/430> #<COMPILED-FUNCTION SYSTEM::LOAD-OR-COMPILE>
    <16/425> #<COMPILED-FUNCTION SYSTEM::C-REQUIRE>
    [422] EVAL frame for form (SYSTEM::C-REQUIRE 'BOGUS)
    <17/419> #<SPECIAL-OPERATOR PROGN>
    [418] EVAL frame for form (PROGN (SYSTEM::C-REQUIRE 'BOGUS))
    <18/410> #<SYSTEM-FUNCTION EVAL>
    <19/408> #<COMPILED-FUNCTION SYSTEM::C-EVAL-AND-WRITE-LIB>
    [406] EVAL frame for form (SYSTEM::C-EVAL-AND-WRITE-LIB '(PROGN (SYSTEM::C-REQUIRE 'BOGUS)))
    <20/403> #<SPECIAL-OPERATOR PROGN>
    [402] EVAL frame for form (PROGN (SYSTEM::C-EVAL-AND-WRITE-LIB '(PROGN (SYSTEM::C-REQUIRE 'BOGUS))))
    <21/394> #<SYSTEM-FUNCTION EVAL>
    <22/387> #<COMPILED-FUNCTION SYSTEM::C-EVAL-WHEN>
    <23/365> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <24/343> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <25/340> #<COMPILED-FUNCTION SYSTEM::C-GLOBAL-FUNCTION-CALL>
    <26/319> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <27/315> #<COMPILED-FUNCTION SYSTEM::C-PROGN>
    <28/294> #<COMPILED-FUNCTION SYSTEM::C-FORM>
    <29/207> #<COMPILED-FUNCTION SYSTEM::C-LAMBDABODY>
    <30/198> #<COMPILED-FUNCTION SYSTEM::COMPILE-LAMBDABODY>
    <31/186> #<COMPILED-FUNCTION SYSTEM::COMPILE-TOPLEVEL-FORM>
    <32/42> #<COMPILED-FUNCTION COMPILE-FILE>
    [34] EVAL frame for form (COMPILE-FILE "test.lisp")
    Printed 32 frames

I am using 64-bit Linux. I get this error with CLISP 2.49 and CLISP from Mercurial.

Since REQUIRE is a function, I expected the error at runtime (when loading the file or its fasl), not at compile-time.

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3524255 ] ANSI CL forbids mixed-type complex numbers

SourceForge.net — 2012-05-07T14:40:14

Bugs item #3524255, was opened at 2012-05-06 22:38
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&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: ANSI compliance issue
Resolution: Invalid
Priority: 5
Private: No
Submitted By: John Cowan (johnwcowan)
Assigned to: Bruno Haible (haible)
Summary: ANSI CL forbids mixed-type complex numbers

Initial Comment:
CLHS (under Function COMPLEX) says that the real and imaginary parts of a complex numbers must either be both rational or both of the same float type, and if they are not, floating-point coercion must be done.  One of the given examples is (complex 1 .99) =>  #C(1.0 0.99).

But in CLISP, (integerp (realpart (complex 1 .99)) => #t.  This means that the real part is being stored as a rational number, since there is no coercion from floats to rationals.  COMPLEX (and #C) should be changed to make sure both parts are either rational or of the same float type.

This bug is present both in 2.48 on Cygwin and 2.44.1 on Ubuntu Lucid (both from binary packages).  Here are the clisp --version outputs:

GNU CLISP 2.48 (2009-07-28) (built on ATGRZWN502840.avl01.avlcorp.lan [157.247.26.41])
Software: GNU C 4.3.4 20090804 (release) 1
gcc-4 -O2 -pipe  -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--stack,8388608 -Wl,--enable-auto-import  /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libreadline.dll.a -lncurses /usr/lib/libavcall.a /usr/lib/libcallback.a /usr/lib/libiconv.dll.a -L/usr/lib -lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.8
libiconv 1.13
libreadline 6.0
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 PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) LNGNYCL-FDB00M1.legal.regn.net [192.168.1.118]

GNU CLISP 2.44.1 (2008-02-23) (built 3476024583) (memory 3544628985)
Software: GNU C 4.4.3 
i486-linux-gnu-gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  -x none /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB CLX-ANSI-COMMON-LISP CLX 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 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.44.1/
User language: ENGLISH
Machine: I686 (I686) pubuntu [127.0.0.1]


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

Date: 2012-05-07 07:40

Message:
http://www.cygwin.com/acronyms/#PTC

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

Comment By: John Cowan (johnwcowan)
Date: 2012-05-07 07:11

Message:
I agree that it is documented, but deny that it is a valid ANSI CL
extension.  Section 1.6 of the CLHS says: "An implementation can have
extensions, provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard."  But
(integerp (realpart (complex 1 2.0))) is conforming code, and the standard
requires that it return NIL due to floating-point contagion.  Making it
return T instead is altering its behavior, and makes the implementation
non-conformant.

A legitimate way of providing mixed-type complex numbers is to introduce an
implementation-dependent function and/or lexical syntax for creating them.



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

Comment By: Sam Steingold (sds)
Date: 2012-05-07 06:51

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

Comment By: Bruno Haible (haible)
Date: 2012-05-07 04:42

Message:
This is a documented feature, not a bug:
http://www.clisp.org/impnotes.html#complex-comp


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3524255 ] ANSI CL forbids mixed-type complex numbers

SourceForge.net — 2012-05-07T14:11:02

Bugs item #3524255, was opened at 2012-05-06 22:38
Message generated for change (Comment added) made by johnwcowan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&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: ANSI compliance issue
Resolution: Invalid
Priority: 5
Private: No
Submitted By: John Cowan (johnwcowan)
Assigned to: Bruno Haible (haible)
Summary: ANSI CL forbids mixed-type complex numbers

Initial Comment:
CLHS (under Function COMPLEX) says that the real and imaginary parts of a complex numbers must either be both rational or both of the same float type, and if they are not, floating-point coercion must be done.  One of the given examples is (complex 1 .99) =>  #C(1.0 0.99).

But in CLISP, (integerp (realpart (complex 1 .99)) => #t.  This means that the real part is being stored as a rational number, since there is no coercion from floats to rationals.  COMPLEX (and #C) should be changed to make sure both parts are either rational or of the same float type.

This bug is present both in 2.48 on Cygwin and 2.44.1 on Ubuntu Lucid (both from binary packages).  Here are the clisp --version outputs:

GNU CLISP 2.48 (2009-07-28) (built on ATGRZWN502840.avl01.avlcorp.lan [157.247.26.41])
Software: GNU C 4.3.4 20090804 (release) 1
gcc-4 -O2 -pipe  -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--stack,8388608 -Wl,--enable-auto-import  /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libreadline.dll.a -lncurses /usr/lib/libavcall.a /usr/lib/libcallback.a /usr/lib/libiconv.dll.a -L/usr/lib -lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.8
libiconv 1.13
libreadline 6.0
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 PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) LNGNYCL-FDB00M1.legal.regn.net [192.168.1.118]

GNU CLISP 2.44.1 (2008-02-23) (built 3476024583) (memory 3544628985)
Software: GNU C 4.4.3 
i486-linux-gnu-gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  -x none /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB CLX-ANSI-COMMON-LISP CLX 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 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.44.1/
User language: ENGLISH
Machine: I686 (I686) pubuntu [127.0.0.1]


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

Date: 2012-05-07 07:11

Message:
I agree that it is documented, but deny that it is a valid ANSI CL
extension.  Section 1.6 of the CLHS says: "An implementation can have
extensions, provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard."  But
(integerp (realpart (complex 1 2.0))) is conforming code, and the standard
requires that it return NIL due to floating-point contagion.  Making it
return T instead is altering its behavior, and makes the implementation
non-conformant.

A legitimate way of providing mixed-type complex numbers is to introduce an
implementation-dependent function and/or lexical syntax for creating them.



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

Comment By: Sam Steingold (sds)
Date: 2012-05-07 06:51

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

Comment By: Bruno Haible (haible)
Date: 2012-05-07 04:42

Message:
This is a documented feature, not a bug:
http://www.clisp.org/impnotes.html#complex-comp


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3524255 ] ANSI CL forbids mixed-type complex numbers

SourceForge.net — 2012-05-07T13:51:50

Bugs item #3524255, was opened at 2012-05-06 22:38
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&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: ANSI compliance issue
Priority: 5
Private: No
Submitted By: John Cowan (johnwcowan)
Assigned to: Bruno Haible (haible)
Summary: ANSI CL forbids mixed-type complex numbers

Initial Comment:
CLHS (under Function COMPLEX) says that the real and imaginary parts of a complex numbers must either be both rational or both of the same float type, and if they are not, floating-point coercion must be done.  One of the given examples is (complex 1 .99) =>  #C(1.0 0.99).

But in CLISP, (integerp (realpart (complex 1 .99)) => #t.  This means that the real part is being stored as a rational number, since there is no coercion from floats to rationals.  COMPLEX (and #C) should be changed to make sure both parts are either rational or of the same float type.

This bug is present both in 2.48 on Cygwin and 2.44.1 on Ubuntu Lucid (both from binary packages).  Here are the clisp --version outputs:

GNU CLISP 2.48 (2009-07-28) (built on ATGRZWN502840.avl01.avlcorp.lan [157.247.26.41])
Software: GNU C 4.3.4 20090804 (release) 1
gcc-4 -O2 -pipe  -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--stack,8388608 -Wl,--enable-auto-import  /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libreadline.dll.a -lncurses /usr/lib/libavcall.a /usr/lib/libcallback.a /usr/lib/libiconv.dll.a -L/usr/lib -lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.8
libiconv 1.13
libreadline 6.0
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 PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) LNGNYCL-FDB00M1.legal.regn.net [192.168.1.118]

GNU CLISP 2.44.1 (2008-02-23) (built 3476024583) (memory 3544628985)
Software: GNU C 4.4.3 
i486-linux-gnu-gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  -x none /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB CLX-ANSI-COMMON-LISP CLX 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 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.44.1/
User language: ENGLISH
Machine: I686 (I686) pubuntu [127.0.0.1]


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

Comment By: Sam Steingold (sds)
Date: 2012-05-07 06:51

Message:
This bug report is now marked as "pending"/"invalid".
This means that we think that the problem you report is not a problem with
CLISP.
Unless you - the reporter - act within 2 weeks, the bug will be permanently
closed.
Sorry about the inconvenience - we hope your silence means that you agree
that this is not a bug in CLISP.

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

Comment By: Bruno Haible (haible)
Date: 2012-05-07 04:42

Message:
This is a documented feature, not a bug:
http://www.clisp.org/impnotes.html#complex-comp


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3524255 ] ANSI CL forbids mixed-type complex numbers

SourceForge.net — 2012-05-07T05:38:38

Bugs item #3524255, was opened at 2012-05-06 22:38
Message generated for change (Tracker Item Submitted) made by johnwcowan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3524255&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: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Cowan (johnwcowan)
Assigned to: Bruno Haible (haible)
Summary: ANSI CL forbids mixed-type complex numbers

Initial Comment:
CLHS (under Function COMPLEX) says that the real and imaginary parts of a complex numbers must either be both rational or both of the same float type, and if they are not, floating-point coercion must be done.  One of the given examples is (complex 1 .99) =>  #C(1.0 0.99).

But in CLISP, (integerp (realpart (complex 1 .99)) => #t.  This means that the real part is being stored as a rational number, since there is no coercion from floats to rationals.  COMPLEX (and #C) should be changed to make sure both parts are either rational or of the same float type.

This bug is present both in 2.48 on Cygwin and 2.44.1 on Ubuntu Lucid (both from binary packages).  Here are the clisp --version outputs:

GNU CLISP 2.48 (2009-07-28) (built on ATGRZWN502840.avl01.avlcorp.lan [157.247.26.41])
Software: GNU C 4.3.4 20090804 (release) 1
gcc-4 -O2 -pipe  -g -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--stack,8388608 -Wl,--enable-auto-import  /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libreadline.dll.a -lncurses /usr/lib/libavcall.a /usr/lib/libcallback.a /usr/lib/libiconv.dll.a -L/usr/lib -lsigsegv
SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED
libsigsegv 2.8
libiconv 1.13
libreadline 6.0
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 PC386 UNIX CYGWIN)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: /usr/lib/clisp-2.48/
User language: ENGLISH
Machine: I686 (I686) LNGNYCL-FDB00M1.legal.regn.net [192.168.1.118]

GNU CLISP 2.44.1 (2008-02-23) (built 3476024583) (memory 3544628985)
Software: GNU C 4.4.3 
i486-linux-gnu-gcc -g -O2 -Igllib -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -I. -Wl,-Bsymbolic-functions  -x none /usr/lib/libreadline.so -lncurses -ldl /usr/lib/libavcall.so /usr/lib/libcallback.so  -L/usr/lib -lsigsegv 
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.5
libreadline 5.2
Features: 
(ASDF CLC-OS-DEBIAN COMMON-LISP-CONTROLLER BERKELEY-DB CLX-ANSI-COMMON-LISP CLX 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 PC386 UNIX)
C Modules: (clisp i18n syscalls regexp readline linux clx bdb)
Installation directory: /usr/lib/clisp-2.44.1/
User language: ENGLISH
Machine: I686 (I686) pubuntu [127.0.0.1]


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

clisp-cvs Digest, Vol 70, Issue 1

2012-05-04T12:05:07

Send clisp-cvs mailing list submissions to
clisp-cvs< at >lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
clisp-cvs-request< at >lists.sourceforge.net

You can reach the person managing the list at
clisp-cvs-owner< at >lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: update berkeley-db to 5.1
      (clisp-cvs-request< at >lists.sourceforge.net)


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

Message: 1
Date: Fri, 04 May 2012 05:04:37 +0000
From: clisp-cvs-request< at >lists.sourceforge.net
Subject: clisp: update berkeley-db to 5.1
To: clisp-cvs< at >lists.sourceforge.net
Message-ID:
<hg.3d1765c46a62.1336107877.-3352671374714820773< at >vz-hg-2.sog>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3d1765c46a62
changeset: 15587:3d1765c46a6203535397462492e58f66f8c02da6
user:      Sam Steingold <sds< at >podval.org>
date:      2012-05-04 01:04:01 -0400
description:
update berkeley-db to 5.1
* modules/berkeley-db/bdb.c (add_message): fix
(DB-VERSION): use db_full_version when available
(DBE-CREATE): remote is no longer supported by upstream
(dbt_to_object): also return nil when p_dbt->size==0
(DB-COMPACT): add
(DB-VERIFY): mark the db handle invalid because it "may not be accessed
again after DB->verify() is called, regardless of its return"

diffstat:

 doc/common.xsl                      |   22 +++--
 modules/berkeley-db/bdb.c           |  123 ++++++++++++++++++++++-------------
 modules/berkeley-db/berkeley-db.xml |   33 ++++++---
 modules/berkeley-db/configure.in    |    6 +-
 modules/berkeley-db/dbi.lisp        |   16 +++-
 modules/berkeley-db/test.tst        |   26 ++++--
 src/ChangeLog                       |   11 +++
 src/NEWS                            |    5 +-
 8 files changed, 158 insertions(+), 84 deletions(-)



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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

_______________________________________________
clisp-cvs mailing list
clisp-cvs< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 70, Issue 1
****************************************

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

clisp-cvs Digest, Vol 69, Issue 6

2012-04-28T12:05:01

Send clisp-cvs mailing list submissions to
clisp-cvs< at >lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
clisp-cvs-request< at >lists.sourceforge.net

You can reach the person managing the list at
clisp-cvs-owner< at >lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Fix bug#3467762: symlink to directory handling
      (clisp-cvs-request< at >lists.sourceforge.net)


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

Message: 1
Date: Fri, 27 Apr 2012 19:29:03 +0000
From: clisp-cvs-request< at >lists.sourceforge.net
Subject: clisp: Fix bug#3467762: symlink to directory handling
To: clisp-cvs< at >lists.sourceforge.net
Message-ID:
<hg.c88260c2da71.1335554943.-3352671374714820773< at >vz-hg-3.sog>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/c88260c2da71
changeset: 15586:c88260c2da71db954e403b0d206a5d9034f29edf
user:      Sam Steingold <sds< at >podval.org>
date:      2012-04-27 15:28:06 -0400
description:
Fix bug#3467762: symlink to directory handling
* modules/syscalls/calls.c (symlink_file): strip trailing "/" from
new_pathstring
(copy_one_file): use PROBE-PATHNAME instead of PROBE-FILE to
accommodate directories
* src/pathname.d (delete_directory): when rmdir() fails with ENOTDIR,
call unlink() because we are dealing with a symbolic link

diffstat:

 modules/syscalls/calls.c  |   9 ++++++---
 modules/syscalls/test.tst |   7 +++++++
 src/ChangeLog             |  10 ++++++++++
 src/NEWS                  |   1 +
 src/pathname.d            |   3 ++-
 5 files changed, 26 insertions(+), 4 deletions(-)



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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

_______________________________________________
clisp-cvs mailing list
clisp-cvs< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 69, Issue 6
****************************************

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3521402 ] ffcall-1.10 (or CVS head) fails to buildx86_64 on OS X

SourceForge.net — 2012-04-27T22:10:55

Bugs item #3521402, was opened at 2012-04-25 11:26
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521402&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: ffcall
Group: build problems
Priority: 5
Private: No
Submitted By: Hanspeter Niederstrasser (nieder)
Assigned to: Bruno Haible (haible)
Summary: ffcall-1.10 (or CVS head) fails to build x86_64 on OS X

Initial Comment:
On OS X 10.6 (and 10.7) which builds as 64bit by default, ffcall fails to build with the following error:

./configure --host=x86_64-apple-darwin10 (explicit --host is needed or it misidentifies as a 32 bit and that also fails in a 64bit environment [1] )
...
cd avcall; make all
/bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
avcall-x86_64.c:5:Unknown pseudo-op: .type
avcall-x86_64.c:5:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:331:Unknown pseudo-op: .size
avcall-x86_64.c:331:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:332:unknown section type: < at >progbits
avcall-x86_64.c:332:Rest of line ignored. 1st junk character valued 46 (.).
avcall-x86_64.c:337:Unknown pseudo-op: .string
avcall-x86_64.c:337:Rest of line ignored. 1st junk character valued 34 (").
make[1]: *** [avcall-x86_64.lo] Error 1
make: *** [all] Error 2
### execution of make failed, exit code 2

Building as 32bit in a 32bit environment builds correctly.

[1] http://www.mail-archive.com/fink-users< at >lists.sourceforge.net/msg31434.html

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

Comment By: Hanspeter Niederstrasser (nieder)
Date: 2012-04-27 14:03

Message:
For the record, the ffcall home page <http://ftp.gnu.org/gnu/libffcall/>
says to file bugs here against the category 'ffcall'.

I'v now filed the bug at savannah:
https://savannah.gnu.org/bugs/index.php?36323

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

Comment By: Sam Steingold (sds)
Date: 2012-04-27 10:50

Message:
please file this bug in the libffcall bug tracker, not against clisp.
https://savannah.gnu.org/bugs/?group=libffcall

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3521402 ] ffcall-1.10 (or CVS head) fails to buildx86_64 on OS X

SourceForge.net — 2012-04-27T21:03:21

Bugs item #3521402, was opened at 2012-04-25 11:26
Message generated for change (Comment added) made by nieder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521402&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: ffcall
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hanspeter Niederstrasser (nieder)
Assigned to: Bruno Haible (haible)
Summary: ffcall-1.10 (or CVS head) fails to build x86_64 on OS X

Initial Comment:
On OS X 10.6 (and 10.7) which builds as 64bit by default, ffcall fails to build with the following error:

./configure --host=x86_64-apple-darwin10 (explicit --host is needed or it misidentifies as a 32 bit and that also fails in a 64bit environment [1] )
...
cd avcall; make all
/bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
avcall-x86_64.c:5:Unknown pseudo-op: .type
avcall-x86_64.c:5:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:331:Unknown pseudo-op: .size
avcall-x86_64.c:331:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:332:unknown section type: < at >progbits
avcall-x86_64.c:332:Rest of line ignored. 1st junk character valued 46 (.).
avcall-x86_64.c:337:Unknown pseudo-op: .string
avcall-x86_64.c:337:Rest of line ignored. 1st junk character valued 34 (").
make[1]: *** [avcall-x86_64.lo] Error 1
make: *** [all] Error 2
### execution of make failed, exit code 2

Building as 32bit in a 32bit environment builds correctly.

[1] http://www.mail-archive.com/fink-users< at >lists.sourceforge.net/msg31434.html

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

Date: 2012-04-27 14:03

Message:
For the record, the ffcall home page <http://ftp.gnu.org/gnu/libffcall/>
says to file bugs here against the category 'ffcall'.

I'v now filed the bug at savannah:
https://savannah.gnu.org/bugs/index.php?36323

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

Comment By: Sam Steingold (sds)
Date: 2012-04-27 10:50

Message:
please file this bug in the libffcall bug tracker, not against clisp.
https://savannah.gnu.org/bugs/?group=libffcall

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

[ clisp-Bugs-3467762 ] delete-file cannot delete directory symlink

SourceForge.net — 2012-04-27T19:30:59

Bugs item #3467762, was opened at 2011-12-30 18:52
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3467762&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
Priority: 5
Private: No
Submitted By: Gabor Balazs (gabalz)
Summary: delete-file cannot delete directory symlink

Initial Comment:

The delete-file function can remove file and dead symlinks but not (alive) directory symlinks, because it always resolves the provided pathname in the directory symlink case even if it should not (according to the CLISP documentation) :

    "(DELETE-FILE pathname) deletes the pathname PATHNAME, not its TRUENAME, ..."

Problem reconstruction:
~~~~~~~~~~~~~~~~~~

ls -lR
drwxr-xr-x 2 bege users 4096 Dec 30 19:40 dir
-rw-r--r-- 1 bege users    0 Dec 30 19:26 file
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-dead -> dead/
lrwxrwxrwx 1 bege users    3 Dec 30 19:26 link-dir -> dir
lrwxrwxrwx 1 bege users    4 Dec 30 19:26 link-file -> file

./dir:
-rw-r--r-- 1 bege users 0 Dec 30 19:40 dir-file

Then
(delete-file "dir")
*** - DELETE-FILE: "/home/bege/TEST/dir" names a directory, not a file
so the provided pathname is resolved.

However,
(delete-file "link-file")
deletes the link-file link (properly), so in this case the provided pathname is not resolved.

(delete-file "link-dead") works properly too without resolving the dead symlink.

Desired behaviour:
~~~~~~~~~~~~~~
delete-file should not resolve the pathname for a directory symlink and should delete the symlink without error.

Version
~~~~~~
clisp --version
GNU CLISP 2.49 (2010-07-07) (built 3529014440) (memory 3529014964)
Software: GNU C 4.5.3 
gcc -O2 -march=core2 -fomit-frame-pointer -pipe -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_FFI -I. -Wl,-O1 -Wl,--as-needed  /usr/lib64/libreadline.so -lncurses -ldl /usr/lib64/libavcall.a /usr/lib64/libcallback.a  -L/usr/lib64 -lsigsegv -L/usr/lib64 -lc libgnu_cl.a 
SAFETY=0 TYPECODES WIDE_HARD GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.8
libreadline 6.2
Features: 
(READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP
 LISP=CL INTERPRETER MT 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: /usr/lib64/clisp-2.49/
User language: ENGLISH
Machine: X86_64 (X86_64) localhost [127.0.0.1]


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

Date: 2012-04-27 12:30

Message:
as explained in http://clisp.org/impnotes/dir-is-not-file.html,
you  should use delete-directory for symlinks to directories.
however, that also fails.
I fixed that in the sources, thanks.

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

Comment By: Sam Steingold (sds)
Date: 2012-04-27 12:30

Message:
thank you for your bug report.
the bug has been fixed in the source tree (mercurial/hg).
you can either wait for the next release (recommended)
or check out the current mercurial tree (see http://clisp.org)
and build CLISP from the sources (be advised that between
releases the source tree is very unstable and may not even build
on your platform).

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

Comment By: Gabor Balazs (gabalz)
Date: 2011-12-30 18:55

Message:
Sorry, there is a mistake in the description, but the error exist. So
correctly,

(delete-file "link-dir")
*** - DELETE-FILE: "/home/bege/TEST/dir" names a directory, not a file

/ instead of (delete-file "dir") /


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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

Re: A few newbie questions

Pascal J. Bourguignon — 2012-04-27T18:11:53


There's no variable named values.
There's a function named values, which returns a variable number of
values: one of each argument.

Therefore (values) returns no value, since it has no argument.


A function doesn't return nil by default, it returns whatever its
returning form returns.  In this case if you remove the call to VALUES,
it's FORMAT which returns only one value, nil, which are taken by the
implicit PROGN which returns them, which are taken by the BLOCK
<function-name> which returns them, which are taken by the LAMBDA
implicit PROGN which returns them.

[ clisp-Bugs-3521402 ] ffcall-1.10 (or CVS head) fails to buildx86_64 on OS X

SourceForge.net — 2012-04-27T17:51:06

Bugs item #3521402, was opened at 2012-04-25 11:26
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3521402&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: ffcall
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hanspeter Niederstrasser (nieder)
Assigned to: Bruno Haible (haible)
Summary: ffcall-1.10 (or CVS head) fails to build x86_64 on OS X

Initial Comment:
On OS X 10.6 (and 10.7) which builds as 64bit by default, ffcall fails to build with the following error:

./configure --host=x86_64-apple-darwin10 (explicit --host is needed or it misidentifies as a 32 bit and that also fails in a 64bit environment [1] )
...
cd avcall; make all
/bin/sh ./libtool --mode=compile gcc -x none -c ./avcall-x86_64.s
gcc -x none -c ./avcall-x86_64.s -o avcall-x86_64.o
avcall-x86_64.c:5:Unknown pseudo-op: .type
avcall-x86_64.c:5:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:331:Unknown pseudo-op: .size
avcall-x86_64.c:331:Rest of line ignored. 1st junk character valued 95 (_).
avcall-x86_64.c:332:unknown section type: < at >progbits
avcall-x86_64.c:332:Rest of line ignored. 1st junk character valued 46 (.).
avcall-x86_64.c:337:Unknown pseudo-op: .string
avcall-x86_64.c:337:Rest of line ignored. 1st junk character valued 34 (").
make[1]: *** [avcall-x86_64.lo] Error 1
make: *** [all] Error 2
### execution of make failed, exit code 2

Building as 32bit in a 32bit environment builds correctly.

[1] http://www.mail-archive.com/fink-users< at >lists.sourceforge.net/msg31434.html

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

Date: 2012-04-27 10:51

Message:
please file this bug in the libffcall bug tracker, not against clisp.
https://savannah.gnu.org/bugs/?group=libffcall

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

Comment By: Sam Steingold (sds)
Date: 2012-04-27 10:50

Message:
please file this bug in the libffcall bug tracker, not against clisp.
https://savannah.gnu.org/bugs/?group=libffcall

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
clisp-devel mailing list
clisp-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel