clisp-devel — closed list for developers and testers

Re: how to turn off localized compiler messages

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

10.04.2011, 21:56, "Sam Steingold" <sd...@gn...>:
> please try "LANG=C clisp".

It helps, thanks

(I am on Windows, therefore I did
set LANG=C
clisp
)

> (what does "clisp --version" print?)

If that still matters here is the result (*before* exporting LANG=C):

GNU CLISP 2.49 (2010-07-07) (built on STSst063.jenty.by [150.0.0.63])
Software: GNU C 3.4.5 (mingw-vista special r3) 
gcc -mno-cygwin -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -D_WIN32 -DENABLE_UNICODE -I/usr/local/include -DDYNAMIC_FFI -I. -L/usr/local/lib  -lintl /usr/local/lib/libreadline.dll.a -L/usr/local/lib -ltermcap /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -luser32 -lws2_32 -lole32 -loleaut32 -luuid -liconv -L/usr/local/lib -lsigsegv libgnu_cl.a 
SAFETY=0 HEAPCODES STANDARD_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
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 WIN32)
C Modules: (clisp i18n syscalls regexp readline)
Installation directory: C:\Program Files (x86)\clisp-2.49\
User language: ENGLISH
Machine: PC/386 (PC/686) HP-PC [192.168.0.101]

Best regards,
- Anton

Re: Windows installer replaces the PATH variable

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

10.04.2011, 23:33, "Elliott Slaughter" <ell...@gm...>:
>
> Anton: Did you install this "for everyone" or "just for me"? Have you ever had any previous versions of CLISP installed via the installer on this machine?
>
>> Elliott, could you please take a look at clisp/win32msvc/nsis/add_to_path.nsh?

"for everyone". Previously I had installed CLISP 2.48, which I uninstalled manually from control panel before installing the new installer.

I can not say what mode (everyone/just for me) was use in the old, 2.48, installation.

Best regards,
- Anton

Re: Windows installer replaces the PATH variable

[Elliott S. <ell...@gm...>]

On Sun, Apr 10, 2011 at 9:36 AM, Sam Steingold <sd...@gn...> wrote:

> > * Anton Vodonosov <nib...@ln...> [2011-04-10 05:16:40 +0400]:
> >
> > I just installed CLISP 2.49 on Windows. During installation I left the
> > checkbox "Path variable" as is - checked.
> >
> > After the installation the old value of the PATH variable had become
> > replaced by the CLISP installation directory: C:\Program Files
> (x86)\clisp-2.49.
> >
> > I would expect the CLISP path to be added to the PATH instead of
> replacing it.
> >
> > It's Windows 7, 64 bit.
>

Anton: Did you install this "for everyone" or "just for me"? Have you ever
had any previous versions of CLISP installed via the installer on this
machine?

Elliott, could you please take a look at
> clisp/win32msvc/nsis/add_to_path.nsh?
>

Sam: Thanks for letting me know, I'll take a look at it.

I should also mention that I've noticed a bug where the start menu item
doesn't get deleted properly when the install "just for me" option is
checked. Again, this bug only appears on Windows 7.

-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it." - Alan Kay

Re: how to turn off localized compiler messages

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

> * Anton Vodonosov <nib...@ln...> [2011-04-10 20:12:29 +0400]:
>
> 10.04.2011, 16:24, "Pascal J. Bourguignon" <pj...@in...>:
>> Anton Vodonosov <avo...@ya...>; writes:
>>
>>>  I glanced through the docs, and found the the variable CUSTOM:*CURREN-LANGUES*
>>
>> Perhaps setting  CUSTOM:*CURRENT-LANGUAGE*  would work better?
>
> No, it was just a typo in my email. Look what I have:
>
> C:\Users\anton\unpacked>clisp
> Добро пожаловать GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>
>
> Напечатайте :h и нажмите Ввод для получения справки.
> [1]> CUSTOM:*CURRENT-LANGUAGE*
> ENGLISH

your clisp was built without gnu gettext, right?
(what does "clisp --version" print?)

please try "LANG=C clisp".

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.10 (maverick) X
http://palestinefacts.org http://jihadwatch.org http://openvotingconsortium.org
http://truepeace.org http://pmw.org.il http://dhimmi.com
If your VCR is still blinking 12:00, you don't want Linux.

Re: clisp-cvs Digest, Vol 59, Issue 7 - econnreset

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

> * Don Cohen <qba...@vf...> [2011-04-10 09:54:25 -0700]:
>
> This is the case where a third output value similar to eof would be
> useful.

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

> The result should encode the fact that neither input nor
> output can be done on this stream ever again.

I thought that :ERROR was for that.
That's what I expected.

Actually, the fact that select() does not set the error bit for the
socket appears to indicate that the socket is not completely and
terminally dead after ECONNRESET.

> Which machines return which values?

:APPEND ubuntu 10.10
Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux

:EOF CentOS release 5.5 (Final)
Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

what do your machines do?

> Is this test supposed to fail in one case and succeed in the other?

all tests are always expected to succeed.

> [BTW, I now see that the diffs can be viewed by doing
>  hg log -v -p  |more
> ]

you can also click on

>  > details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid) X
http://mideasttruth.com http://jihadwatch.org http://memri.org http://ffii.org
http://palestinefacts.org http://thereligionofpeace.com
XML is like violence. If it doesn't solve the problem, use more.

clisp-cvs Digest, Vol 59, Issue 7 - econnreset

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

This is the case where a third output value similar to eof would be
useful.  The result should encode the fact that neither input nor
output can be done on this stream ever again.
The closest value we have now would be eof, I guess, since append
indicates that write would work immediately.
Which machines return which values?
Is this test supposed to fail in one case and succeed in the other?

[BTW, I now see that the diffs can be viewed by doing
 hg log -v -p  |more
]

 > Message: 5
 > Date: Sun, 10 Apr 2011 05:16:45 +0000
 > From: cli...@li...
 > Subject: clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some
 > 	machines S...
 > To: cli...@li...
 > Message-ID:
 > 	<hg....@vz...>
 > Content-Type: text/plain; charset="us-ascii"
 > 
 > details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7
 > changeset: 15335:83c307059ea7b1348a7c2d62e981e902e4af7bf7
 > user:      Sam Steingold <sd...@po...>
 > date:      2011-04-10 01:13:42 -0400
 > description:
 > * tests/socket.tst (ECONNRESET/EPIPE): on some machines SOCKET-STATUS
 > after ECONNRESET returns :EOF and on others it returns :APPEND
 > 
 > diffstat:
 > 
 >  tests/ChangeLog  |   5 +++++
 >  tests/socket.tst |  10 ++++------
 >  2 files changed, 9 insertions(+), 6 deletions(-)

Re: Windows installer replaces the PATH variable

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

Hi,

> * Anton Vodonosov <nib...@ln...> [2011-04-10 05:16:40 +0400]:
>
> I just installed CLISP 2.49 on Windows. During installation I left the
> checkbox "Path variable" as is - checked.
>
> After the installation the old value of the PATH variable had become 
> replaced by the CLISP installation directory: C:\Program Files (x86)\clisp-2.49.
>
> I would expect the CLISP path to be added to the PATH instead of replacing it.
>
> It's Windows 7, 64 bit.

Elliott, could you please take a look at clisp/win32msvc/nsis/add_to_path.nsh?


-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid) X
http://iris.org.il http://honestreporting.com http://pmw.org.il
http://palestinefacts.org http://truepeace.org http://jihadwatch.org
Those who can't write, write manuals.

Re: how to turn off localized compiler messages

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

> * Anton Vodonosov <nib...@ln...> [2011-04-10 12:06:53 +0400]:
>
> CLISP now prints error and information messages localized (in Russian
> in my case).
> How to turn it off?

http://www.clisp.org/impnotes/clisp.html#opt-lang
http://www.clisp.org/impnotes/i18n.html

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid) X
http://iris.org.il http://www.PetitionOnline.com/tap12009/ http://memri.org
http://honestreporting.com http://truepeace.org http://ffii.org
If you try to fail, and succeed, which have you done?

Re: how to turn off localized compiler messages

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

10.04.2011, 16:24, "Pascal J. Bourguignon" <pj...@in...>:
> Anton Vodonosov <avo...@ya...>; writes:
>
>>  I glanced through the docs, and found the the variable CUSTOM:*CURREN-LANGUES*
>
> Perhaps setting  CUSTOM:*CURRENT-LANGUAGE*  would work better?
>

No, it was just a typo in my email. Look what I have:
етным файлом.

C:\Users\anton\unpacked>clisp
  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

Добро пожаловать GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Напечатайте :h и нажмите Ввод для получения справки.

;; Загружается файл C:\Users\anton\.clisprc.lisp...
;;  Загружается файл C:\Users\anton\quicklisp\setup.lisp...
;;   Загружается файл C:\Users\anton\quicklisp\ASDF.lisp...
;;   Загружен файл C:\Users\anton\quicklisp\ASDF.lisp
;;  Загружен файл C:\Users\anton\quicklisp\setup.lisp
;; Загружен файл C:\Users\anton\.clisprc.lisp
[1]> CUSTOM:*CURRENT-LANGUAGE*
ENGLISH
[2]>

Re: how to turn off localized compiler messages

[Pascal J. B. <pj...@in...>]

Anton Vodonosov <avo...@ya...> writes:

> CLISP now prints error and information messages localized (in Russian in my case).
>
> How to turn it off? I found localized compiler messages inconvenient. For example
> I can't post it to mailing lists. BTW, the only environment I know which also does 
> so is Adobe Flex. 
>
> I glanced through the docs, and found the the variable CUSTOM:*CURREN-LANGUES*

Perhaps setting  CUSTOM:*CURRENT-LANGUAGE*  would work better?

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

clisp-cvs Digest, Vol 59, Issue 7

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

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
	cli...@li...

You can reach the person managing the list at
	cli...@li...

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: article (cli...@li...)
   2. clisp: * modules/syscalls/calls.c (POSIX:SERVICE): fix
      non-missing (cli...@li...)
   3. clisp: * modules/bindings/glibc/linux.lisp (wait, waitpid):
      rest... (cli...@li...)
   4. clisp: (c)year (cli...@li...)
   5. clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some
      machines S... (cli...@li...)


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

Message: 1
Date: Sun, 10 Apr 2011 03:13:07 +0000
From: cli...@li...
Subject: clisp: article
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/47959c01195d
changeset: 15331:47959c01195d9287854cab858b83656a7617bd9f
user:      Sam Steingold <sd...@po...>
date:      2011-04-09 23:01:26 -0400
description:
article

diffstat:

 modules/syscalls/syscalls.xml |  8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)



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

Message: 2
Date: Sun, 10 Apr 2011 03:13:09 +0000
From: cli...@li...
Subject: clisp: * modules/syscalls/calls.c (POSIX:SERVICE): fix
	non-missing
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d1a83213df63
changeset: 15332:d1a83213df63d83039147478bca8949bee8c9d7f
user:      Sam Steingold <sd...@po...>
date:      2011-04-09 23:10:52 -0400
description:
* modules/syscalls/calls.c (POSIX:SERVICE): fix non-missing
protocol handling (bug#3280915)

diffstat:

 modules/syscalls/calls.c  |  23 ++++++++++++-----------
 modules/syscalls/test.tst |   3 ++-
 src/ChangeLog             |   5 +++++
 src/NEWS                  |   1 +
 4 files changed, 20 insertions(+), 12 deletions(-)



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

Message: 3
Date: Sun, 10 Apr 2011 05:16:42 +0000
From: cli...@li...
Subject: clisp: * modules/bindings/glibc/linux.lisp (wait, waitpid):
	rest...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9b07b4621357
changeset: 15333:9b07b4621357723310bb3a43bc67f2d4248448a0
user:      Sam Steingold <sd...@po...>
date:      2011-04-10 00:45:44 -0400
description:
* modules/bindings/glibc/linux.lisp (wait, waitpid): restore (revert
the 2011-03-23 patch); recommend POSIX:WITH-SUBPROCESSES in comments

diffstat:

 modules/bindings/glibc/linux.lisp |  16 ++++++++++++++--
 src/ChangeLog                     |   5 +++++
 src/NEWS                          |   8 +++++---
 3 files changed, 24 insertions(+), 5 deletions(-)



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

Message: 4
Date: Sun, 10 Apr 2011 05:16:44 +0000
From: cli...@li...
Subject: clisp: (c)year
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/13d99049da1c
changeset: 15334:13d99049da1cf66dc67228672396ed5e5e92a3fd
user:      Sam Steingold <sd...@po...>
date:      2011-04-10 01:04:49 -0400
description:
(c)year

diffstat:

 src/clhs.lisp      |  2 +-
 src/condition.lisp |  2 +-
 src/io.d           |  2 +-
 src/lispbibl.d     |  2 +-
 src/sequence.d     |  2 +-
 src/spvw.d         |  2 +-
 src/stream.d       |  2 +-
 src/unixaux.d      |  2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)



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

Message: 5
Date: Sun, 10 Apr 2011 05:16:45 +0000
From: cli...@li...
Subject: clisp: * tests/socket.tst (ECONNRESET/EPIPE): on some
	machines S...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7
changeset: 15335:83c307059ea7b1348a7c2d62e981e902e4af7bf7
user:      Sam Steingold <sd...@po...>
date:      2011-04-10 01:13:42 -0400
description:
* tests/socket.tst (ECONNRESET/EPIPE): on some machines SOCKET-STATUS
after ECONNRESET returns :EOF and on others it returns :APPEND

diffstat:

 tests/ChangeLog  |   5 +++++
 tests/socket.tst |  10 ++++------
 2 files changed, 9 insertions(+), 6 deletions(-)



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

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 59, Issue 7
****************************************

Re: how to turn off localized compiler messages

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

10.04.2011, 12:06, "Anton Vodonosov" <avo...@ya...>:
> CLISP now prints error and information messages localized (in Russian in my case).
>
> How to turn it off? I found localized compiler messages inconvenient. For example
> I can't post it to mailing lists. BTW, the only environment I know which also does
> so is Adobe Flex.
>
> I glanced through the docs, and found the the variable CUSTOM:*CURREN-LANGUES*

this variable as if should control the language. But I inspected it's value, and its ENGLISH.
While the messages are in Russian.

Best regards,
- Anton

how to turn off localized compiler messages

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

CLISP now prints error and information messages localized (in Russian in my case).

How to turn it off? I found localized compiler messages inconvenient. For example
I can't post it to mailing lists. BTW, the only environment I know which also does 
so is Adobe Flex. 

I glanced through the docs, and found the the variable CUSTOM:*CURREN-LANGUES*

[ clisp-Bugs-3280915 ] segfault when calling POSIX:SERVICE with two arguments

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

Bugs item #3280915, was opened at 2011-04-08 09:27
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3280915&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: segfault
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: rootzlevel (rootzlevel)
>Assigned to: Sam Steingold (sds)
Summary: segfault when calling POSIX:SERVICE with two arguments

Initial Comment:
clisp segfaults when calling e.g. (service "www" "tcp").

I'm using clisp from mercurial, changeset 15330:ee288568e64a, build with --with-debug

My uname:
 Linux 2.6.38-gentoo-r1 #1 SMP Tue Mar 29 17:30:38 CEST 2011 x86_64 AMD Athlon(tm) II X4 620 Processor AuthenticAMD GNU/Linux

My gcc:
 gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5

glibc version: 2.11.3 (Gentoo)

Locale: de_DE.UTF-8

Backtrace:
(gdb) r
Starting program: /home/hpd/Entwicklung/src/clisp/build-g/full/lisp.run -B . -N locale -E 1:1 -q -norc -M full/lispinit.mem
STACK size: 98222 [0x7ffff7fc1e00 0x7ffff7f02090]
                        size_t: 8 0
                       ssize_t: 8 1
                     ffi_uintp: 8 0
FUNTAB_length=512
FUNTABR_length=66
[1]> (service "www" "tcp")

Program received signal SIGSEGV, Segmentation fault.
0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
1679	    with_string_0(check_string(protocol),Symbol_value(GLO(misc_encoding)),
(gdb) bt
#0  0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
#1  0x0000000000474818 in eval_subr (fun=...) at ../src/eval.d:3592
#2  0x0000000000471b4a in eval1 (form=...) at ../src/eval.d:3084
#3  0x0000000000471565 in eval (form=...) at ../src/eval.d:2966
#4  0x0000000000590ae4 in C_read_eval_print () at ../src/debug.d:409
#5  0x000000000047cc97 in funcall_subr (fun=..., args_on_stack=2) at ../src/eval.d:5227
#6  0x000000000047bbbe in funcall (fun=..., args_on_stack=2) at ../src/eval.d:4867
#7  0x000000000048237a in interpret_bytecode_ (closure=..., codeptr=0x333d0da90, byteptr=0x333d0dad7 "\037(\a") at ../src/eval.d:6799
#8  0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#9  0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#10 0x0000000000496a2c in C_driver () at ../src/control.d:1999
#11 0x00000000004825ab in interpret_bytecode_ (closure=..., codeptr=0x333d0da10, byteptr=0x333d0da3d "\031\003") at ../src/eval.d:6805
#12 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#13 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#14 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#15 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#16 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#17 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#18 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#19 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#20 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#21 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#22 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#23 0x00000000005911c8 in driver () at ../src/debug.d:478
#24 0x0000000000460005 in main_actions (p=0x93a540) at ../src/spvw.d:3638
#25 0x00000000004602c0 in main (argc=11, argv=0x7fffffffe288) at ../src/spvw.d:3899
(gdb) info local
protocolz_bytelen = 262144
protocolz_data = 0x100000031 <Address 0x100000031 out of bounds>
protocolz_len = 3
protocolz_offset = 0
protocolz_string = {one_o = 6192463242502352}
ptr1 = 0x7fffffff2bc0
protocol = {one_o = 6192463242502352}
proto = 0x0
proto_buf = "D\000\000\000\000\000\000\000\016j\025糖", <incomplete sequence \363\233>
serv = {one_o = 6192463242502352}
se = 0x7fffffff32f0
(gdb)

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

Comment By: Sam Steingold (sds)
Date: 2011-04-09 23:16

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).

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

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

Windows installer replaces the PATH variable

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

Hello.

I just installed CLISP 2.49 on Windows. During installation I left 
the checkbox "Path variable" as is - checked.

After the installation the old value of the PATH variable had become 
replaced by the CLISP installation directory: C:\Program Files (x86)\clisp-2.49.

I would expect the CLISP path to be added to the PATH instead of replacing it.

It's Windows 7, 64 bit.

Best regards,
- Anton

[ clisp-Bugs-3280915 ] segfault when calling POSIX:SERVICE with two arguments

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

Bugs item #3280915, was opened at 2011-04-08 15:27
Message generated for change (Tracker Item Submitted) made by rootzlevel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3280915&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: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: rootzlevel (rootzlevel)
Assigned to: Bruno Haible (haible)
Summary: segfault when calling POSIX:SERVICE with two arguments

Initial Comment:
clisp segfaults when calling e.g. (service "www" "tcp").

I'm using clisp from mercurial, changeset 15330:ee288568e64a, build with --with-debug

My uname:
 Linux 2.6.38-gentoo-r1 #1 SMP Tue Mar 29 17:30:38 CEST 2011 x86_64 AMD Athlon(tm) II X4 620 Processor AuthenticAMD GNU/Linux

My gcc:
 gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5

glibc version: 2.11.3 (Gentoo)

Locale: de_DE.UTF-8

Backtrace:
(gdb) r
Starting program: /home/hpd/Entwicklung/src/clisp/build-g/full/lisp.run -B . -N locale -E 1:1 -q -norc -M full/lispinit.mem
STACK size: 98222 [0x7ffff7fc1e00 0x7ffff7f02090]
                        size_t: 8 0
                       ssize_t: 8 1
                     ffi_uintp: 8 0
FUNTAB_length=512
FUNTABR_length=66
[1]> (service "www" "tcp")

Program received signal SIGSEGV, Segmentation fault.
0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
1679	    with_string_0(check_string(protocol),Symbol_value(GLO(misc_encoding)),
(gdb) bt
#0  0x000000000042f3a1 in C_subr_posix_service () at /home/hpd/Entwicklung/src/clisp/modules/syscalls/calls.c:1679
#1  0x0000000000474818 in eval_subr (fun=...) at ../src/eval.d:3592
#2  0x0000000000471b4a in eval1 (form=...) at ../src/eval.d:3084
#3  0x0000000000471565 in eval (form=...) at ../src/eval.d:2966
#4  0x0000000000590ae4 in C_read_eval_print () at ../src/debug.d:409
#5  0x000000000047cc97 in funcall_subr (fun=..., args_on_stack=2) at ../src/eval.d:5227
#6  0x000000000047bbbe in funcall (fun=..., args_on_stack=2) at ../src/eval.d:4867
#7  0x000000000048237a in interpret_bytecode_ (closure=..., codeptr=0x333d0da90, byteptr=0x333d0dad7 "\037(\a") at ../src/eval.d:6799
#8  0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#9  0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#10 0x0000000000496a2c in C_driver () at ../src/control.d:1999
#11 0x00000000004825ab in interpret_bytecode_ (closure=..., codeptr=0x333d0da10, byteptr=0x333d0da3d "\031\003") at ../src/eval.d:6805
#12 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#13 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#14 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#15 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#16 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#17 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#18 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#19 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#20 0x000000000048353d in interpret_bytecode_ (closure=..., codeptr=0x333d10198, byteptr=0x333d101e4 "\031\001\230\016\033l") at ../src/eval.d:6854
#21 0x000000000047e0aa in funcall_closure (closure=..., args_on_stack=0) at ../src/eval.d:5630
#22 0x000000000047bb5d in funcall (fun=..., args_on_stack=0) at ../src/eval.d:4862
#23 0x00000000005911c8 in driver () at ../src/debug.d:478
#24 0x0000000000460005 in main_actions (p=0x93a540) at ../src/spvw.d:3638
#25 0x00000000004602c0 in main (argc=11, argv=0x7fffffffe288) at ../src/spvw.d:3899
(gdb) info local
protocolz_bytelen = 262144
protocolz_data = 0x100000031 <Address 0x100000031 out of bounds>
protocolz_len = 3
protocolz_offset = 0
protocolz_string = {one_o = 6192463242502352}
ptr1 = 0x7fffffff2bc0
protocol = {one_o = 6192463242502352}
proto = 0x0
proto_buf = "D\000\000\000\000\000\000\000\016j\025糖", <incomplete sequence \363\233>
serv = {one_o = 6192463242502352}
se = 0x7fffffff32f0
(gdb)

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

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

clisp-cvs Digest, Vol 59, Issue 6

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

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
	cli...@li...

You can reach the person managing the list at
	cli...@li...

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 fault address heap range check
      (cli...@li...)
   2. clisp: [MULTITHREAD, UNIX_MACOSX, GENERATIONAL_GC]: patch for
      st... (cli...@li...)


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

Message: 1
Date: Fri, 08 Apr 2011 09:30:21 +0000
From: cli...@li...
Subject: clisp: fix fault address heap range check
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/2e0dd145f7e2
changeset: 15329:2e0dd145f7e2e943adcdd232aaacffed1783507c
user:      Vladimir Tzankov <vtz...@gm...>
date:      2011-04-08 12:29:16 +0300
description:
fix fault address heap range check

diffstat:

 src/spvw_fault.d |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)



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

Message: 2
Date: Fri, 08 Apr 2011 09:34:17 +0000
From: cli...@li...
Subject: clisp: [MULTITHREAD, UNIX_MACOSX, GENERATIONAL_GC]: patch for
	st...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ee288568e64a
changeset: 15330:ee288568e64a340c7a11f62b56193f07a7cb7030
user:      Vladimir Tzankov <vtz...@gm...>
date:      2011-04-08 12:33:53 +0300
description:
[MULTITHREAD, UNIX_MACOSX, GENERATIONAL_GC]: patch for strange SIGPIPE delivered to libsigsegv thread

diffstat:

 src/ChangeLog      |   5 +++++
 src/spvw_sigpipe.d |  13 ++++++++++++-
 2 files changed, 17 insertions(+), 1 deletions(-)



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

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


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

[ clisp-Feature Requests-3276560 ] econnreset error => subclass of eof

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

Feature Requests item #3276560, was opened at 2011-04-05 20:13
Message generated for change (Comment added) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Sam Steingold (sds)
Summary: econnreset error => subclass of eof

Initial Comment:
Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input.
At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without
marking the stream as closed (which I think it should not do).  The result is that further attempts to use the stream give EBADF OS errors.
Requests:
- new condition class CONNECTION-RESET: 
  (define-condition connection-reset (end-of-file) ()) 
- change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET 
  and not in OS-ERROR (or whatever) 
- don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof.
Test code (at least for linux)
This requires two lisp processes, one for the client, one for the server.  I make use of the fact that closing a socket when there is
still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN.  The result of a FIN terminated 
connection is what I view as correct, so I will demonstrate that also.
[server] (setf ss (socket:socket-server 1234))
[server] (setf s (socket-accept ss))
[client]  (setf s (socket:socket-connect 1234))
[server-RST] (princ "asd" s)
[client] (close s)
at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included
[server] (read-char s)
the result in FIN scenario is an EOF error, in the RST scenario it's  *** - UNIX error 9 (EBADF): Bad file number
[server] (read-char s)
in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number
In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed.

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

>Comment By: Don Cohen (donc)
Date: 2011-04-08 05:19

Message:
> the client program closes the socket when there is still some input
there,
> thus the client kernel sends an RST telling the server that the "asd"
was not read.
> seems strait from the rfc.
I don't understand this at all.
Where does the rfc say anything like that?

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

Comment By: Sam Steingold (sds)
Date: 2011-04-08 05:06

Message:
>>The purpose of TCP RST which CLISP observes as ECONNRESET
>>is to tell us that the client never read the string "asd" which the
>>server sent with princ,
>I do not agree. I think this reset is unjustified by the TCP spec, in
>fact contradicts it.
the client program closes the socket when there is still some input there,

thus the client kernel sends an RST telling the server that the "asd" was
not read.
seems strait from the rfc.

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

Comment By: Don Cohen (donc)
Date: 2011-04-07 21:15

Message:
drat, my formatting was lost in the last comment
Next time I'll know to use something in addition to spaces to mark the
quoted text I'm replying to.
Sorry.

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

Comment By: Don Cohen (donc)
Date: 2011-04-07 21:13

Message:
  1. EOF is, intrinsically, an input event.
I agree, though there is a corresponding problem with trying to write to a
stream that is closed for output.
  ECONNRESET can happen on both input and output.
Here you are referring to a particular error number.
I would not view the appearance of that error number on a write to be the
same sort of event as the appearance of that number on a read.
  I don't think it is right to treat it separately for input and output.
So you adopt the position that an error number defines a condition.  Is
there any justification for this?
  2. EOF is a normal (non-error) condition in POSIX;
  ECONNRESET is an exception.
It seems possible (in fact, eof is proof) that the lisp models and posix
models are not completely compatible.
As a lisp implementer you have to make lisp present the lisp model.

  3. The purpose of TCP RST which CLISP observes as ECONNRESET
  is to tell us that the client never read the string "asd" which the
server sent with princ,
I do not agree.  I think this reset is unjustified by the TCP spec, in
fact contradicts it.

  not that there will be no more data coming through this connection
However the RST does imply that there will be no more data coming.

  (that's the purpose of the FIN which the server gets in the second
  read-char).
The server does not get a FIN at all in this case.  Only a RST.  
A FIN means "I'm done sending".  After that I can send more packets but no
more stream data.
You can continue to send stream data.  I am supposed to ACK that data. 
When you FIN then I
ACK your FIN.  (You probably already ACK'd my FIN.)  Then the connection
is closed.
On the other hand, if you send RST then I'm supposed to not send you
anything more.  I interpret
that as meaning that as far as you're concerned, this connection is
closed.

  In fact, I am not even sure that this is the case - is it really true
that
  no data will ever arrive from a socket which signaled ECONNRESET?
If it is following the protocol then it will not send any data or anything
else after sending RST.
It thinks there is no such connection.  At most it will reply to any
further communication to that
(non)connection with another RST.

  It would be nice if a TCP or POSIX expert could clarify this matter for
us.
There are degrees of expertise, but for purposes of this discussion, at
least, I seem to be the expert.
This is mostly a matter of how much time you spend reading the rfc (and
other related rfcs).


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

Comment By: Sam Steingold (sds)
Date: 2011-04-07 20:29

Message:
Let me clarify my objections to the proposal:
1. EOF is, intrinsically, an input event. 
ECONNRESET can happen on both input and output.
I don't think it is right to treat it separately for input and output.

2. EOF is a normal (non-error) condition in POSIX; 
ECONNRESET is an exception.

3. The purpose of TCP RST which CLISP observes as ECONNRESET
is to tell us that the client never read the string "asd" which the server
sent with princ,
not that there will be no more data coming through this connection
(that's the purpose of the FIN which the server gets in the second
read-char).

In fact, I am not even sure that this is the case - is it really true that

no data will ever arrive from a socket which signaled ECONNRESET?
It would be nice if a TCP or POSIX expert could clarify this matter for
us.

see http://thread.gmane.org/gmane.lisp.clisp.general/13700

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 16:38

Message:
I am extremely reluctant to treat ECONNRESET differently on input and
output.

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

Comment By: Don Cohen (donc)
Date: 2011-04-06 16:18

Message:
I now notice that the ECONNRESET OS-ERROR occurs on both read and write.
I'd like to clarify that only reads should result in EOF errors, so the
condition should perhaps be named to indicate some relation to eof or read,
e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not
result in that particular condition.

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

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

[ clisp-Feature Requests-3276560 ] econnreset error => subclass of eof

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

Feature Requests item #3276560, was opened at 2011-04-05 16:13
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Sam Steingold (sds)
Summary: econnreset error => subclass of eof

Initial Comment:
Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input.
At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without
marking the stream as closed (which I think it should not do).  The result is that further attempts to use the stream give EBADF OS errors.
Requests:
- new condition class CONNECTION-RESET: 
  (define-condition connection-reset (end-of-file) ()) 
- change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET 
  and not in OS-ERROR (or whatever) 
- don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof.
Test code (at least for linux)
This requires two lisp processes, one for the client, one for the server.  I make use of the fact that closing a socket when there is
still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN.  The result of a FIN terminated 
connection is what I view as correct, so I will demonstrate that also.
[server] (setf ss (socket:socket-server 1234))
[server] (setf s (socket-accept ss))
[client]  (setf s (socket:socket-connect 1234))
[server-RST] (princ "asd" s)
[client] (close s)
at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included
[server] (read-char s)
the result in FIN scenario is an EOF error, in the RST scenario it's  *** - UNIX error 9 (EBADF): Bad file number
[server] (read-char s)
in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number
In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed.

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-08 01:06

Message:
>>The purpose of TCP RST which CLISP observes as ECONNRESET
>>is to tell us that the client never read the string "asd" which the
>>server sent with princ,
>I do not agree. I think this reset is unjustified by the TCP spec, in
>fact contradicts it.
the client program closes the socket when there is still some input there,

thus the client kernel sends an RST telling the server that the "asd" was
not read.
seems strait from the rfc.

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

Comment By: Don Cohen (donc)
Date: 2011-04-07 17:15

Message:
drat, my formatting was lost in the last comment
Next time I'll know to use something in addition to spaces to mark the
quoted text I'm replying to.
Sorry.

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

Comment By: Don Cohen (donc)
Date: 2011-04-07 17:13

Message:
  1. EOF is, intrinsically, an input event.
I agree, though there is a corresponding problem with trying to write to a
stream that is closed for output.
  ECONNRESET can happen on both input and output.
Here you are referring to a particular error number.
I would not view the appearance of that error number on a write to be the
same sort of event as the appearance of that number on a read.
  I don't think it is right to treat it separately for input and output.
So you adopt the position that an error number defines a condition.  Is
there any justification for this?
  2. EOF is a normal (non-error) condition in POSIX;
  ECONNRESET is an exception.
It seems possible (in fact, eof is proof) that the lisp models and posix
models are not completely compatible.
As a lisp implementer you have to make lisp present the lisp model.

  3. The purpose of TCP RST which CLISP observes as ECONNRESET
  is to tell us that the client never read the string "asd" which the
server sent with princ,
I do not agree.  I think this reset is unjustified by the TCP spec, in
fact contradicts it.

  not that there will be no more data coming through this connection
However the RST does imply that there will be no more data coming.

  (that's the purpose of the FIN which the server gets in the second
  read-char).
The server does not get a FIN at all in this case.  Only a RST.  
A FIN means "I'm done sending".  After that I can send more packets but no
more stream data.
You can continue to send stream data.  I am supposed to ACK that data. 
When you FIN then I
ACK your FIN.  (You probably already ACK'd my FIN.)  Then the connection
is closed.
On the other hand, if you send RST then I'm supposed to not send you
anything more.  I interpret
that as meaning that as far as you're concerned, this connection is
closed.

  In fact, I am not even sure that this is the case - is it really true
that
  no data will ever arrive from a socket which signaled ECONNRESET?
If it is following the protocol then it will not send any data or anything
else after sending RST.
It thinks there is no such connection.  At most it will reply to any
further communication to that
(non)connection with another RST.

  It would be nice if a TCP or POSIX expert could clarify this matter for
us.
There are degrees of expertise, but for purposes of this discussion, at
least, I seem to be the expert.
This is mostly a matter of how much time you spend reading the rfc (and
other related rfcs).


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

Comment By: Sam Steingold (sds)
Date: 2011-04-07 16:29

Message:
Let me clarify my objections to the proposal:
1. EOF is, intrinsically, an input event. 
ECONNRESET can happen on both input and output.
I don't think it is right to treat it separately for input and output.

2. EOF is a normal (non-error) condition in POSIX; 
ECONNRESET is an exception.

3. The purpose of TCP RST which CLISP observes as ECONNRESET
is to tell us that the client never read the string "asd" which the server
sent with princ,
not that there will be no more data coming through this connection
(that's the purpose of the FIN which the server gets in the second
read-char).

In fact, I am not even sure that this is the case - is it really true that

no data will ever arrive from a socket which signaled ECONNRESET?
It would be nice if a TCP or POSIX expert could clarify this matter for
us.

see http://thread.gmane.org/gmane.lisp.clisp.general/13700

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 12:38

Message:
I am extremely reluctant to treat ECONNRESET differently on input and
output.

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

Comment By: Don Cohen (donc)
Date: 2011-04-06 12:18

Message:
I now notice that the ECONNRESET OS-ERROR occurs on both read and write.
I'd like to clarify that only reads should result in EOF errors, so the
condition should perhaps be named to indicate some relation to eof or read,
e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not
result in that particular condition.

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

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

[ clisp-Feature Requests-3276560 ] econnreset error => subclass of eof

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

Feature Requests item #3276560, was opened at 2011-04-05 20:13
Message generated for change (Comment added) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Sam Steingold (sds)
Summary: econnreset error => subclass of eof

Initial Comment:
Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input.
At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without
marking the stream as closed (which I think it should not do).  The result is that further attempts to use the stream give EBADF OS errors.
Requests:
- new condition class CONNECTION-RESET: 
  (define-condition connection-reset (end-of-file) ()) 
- change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET 
  and not in OS-ERROR (or whatever) 
- don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof.
Test code (at least for linux)
This requires two lisp processes, one for the client, one for the server.  I make use of the fact that closing a socket when there is
still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN.  The result of a FIN terminated 
connection is what I view as correct, so I will demonstrate that also.
[server] (setf ss (socket:socket-server 1234))
[server] (setf s (socket-accept ss))
[client]  (setf s (socket:socket-connect 1234))
[server-RST] (princ "asd" s)
[client] (close s)
at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included
[server] (read-char s)
the result in FIN scenario is an EOF error, in the RST scenario it's  *** - UNIX error 9 (EBADF): Bad file number
[server] (read-char s)
in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number
In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed.

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

>Comment By: Don Cohen (donc)
Date: 2011-04-07 21:15

Message:
drat, my formatting was lost in the last comment
Next time I'll know to use something in addition to spaces to mark the
quoted text I'm replying to.
Sorry.

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

Comment By: Don Cohen (donc)
Date: 2011-04-07 21:13

Message:
  1. EOF is, intrinsically, an input event.
I agree, though there is a corresponding problem with trying to write to a
stream that is closed for output.
  ECONNRESET can happen on both input and output.
Here you are referring to a particular error number.
I would not view the appearance of that error number on a write to be the
same sort of event as the appearance of that number on a read.
  I don't think it is right to treat it separately for input and output.
So you adopt the position that an error number defines a condition.  Is
there any justification for this?
  2. EOF is a normal (non-error) condition in POSIX;
  ECONNRESET is an exception.
It seems possible (in fact, eof is proof) that the lisp models and posix
models are not completely compatible.
As a lisp implementer you have to make lisp present the lisp model.

  3. The purpose of TCP RST which CLISP observes as ECONNRESET
  is to tell us that the client never read the string "asd" which the
server sent with princ,
I do not agree.  I think this reset is unjustified by the TCP spec, in
fact contradicts it.

  not that there will be no more data coming through this connection
However the RST does imply that there will be no more data coming.

  (that's the purpose of the FIN which the server gets in the second
  read-char).
The server does not get a FIN at all in this case.  Only a RST.  
A FIN means "I'm done sending".  After that I can send more packets but no
more stream data.
You can continue to send stream data.  I am supposed to ACK that data. 
When you FIN then I
ACK your FIN.  (You probably already ACK'd my FIN.)  Then the connection
is closed.
On the other hand, if you send RST then I'm supposed to not send you
anything more.  I interpret
that as meaning that as far as you're concerned, this connection is
closed.

  In fact, I am not even sure that this is the case - is it really true
that
  no data will ever arrive from a socket which signaled ECONNRESET?
If it is following the protocol then it will not send any data or anything
else after sending RST.
It thinks there is no such connection.  At most it will reply to any
further communication to that
(non)connection with another RST.

  It would be nice if a TCP or POSIX expert could clarify this matter for
us.
There are degrees of expertise, but for purposes of this discussion, at
least, I seem to be the expert.
This is mostly a matter of how much time you spend reading the rfc (and
other related rfcs).


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

Comment By: Sam Steingold (sds)
Date: 2011-04-07 20:29

Message:
Let me clarify my objections to the proposal:
1. EOF is, intrinsically, an input event. 
ECONNRESET can happen on both input and output.
I don't think it is right to treat it separately for input and output.

2. EOF is a normal (non-error) condition in POSIX; 
ECONNRESET is an exception.

3. The purpose of TCP RST which CLISP observes as ECONNRESET
is to tell us that the client never read the string "asd" which the server
sent with princ,
not that there will be no more data coming through this connection
(that's the purpose of the FIN which the server gets in the second
read-char).

In fact, I am not even sure that this is the case - is it really true that

no data will ever arrive from a socket which signaled ECONNRESET?
It would be nice if a TCP or POSIX expert could clarify this matter for
us.

see http://thread.gmane.org/gmane.lisp.clisp.general/13700

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 16:38

Message:
I am extremely reluctant to treat ECONNRESET differently on input and
output.

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

Comment By: Don Cohen (donc)
Date: 2011-04-06 16:18

Message:
I now notice that the ECONNRESET OS-ERROR occurs on both read and write.
I'd like to clarify that only reads should result in EOF errors, so the
condition should perhaps be named to indicate some relation to eof or read,
e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not
result in that particular condition.

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

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

[ clisp-Feature Requests-3276560 ] econnreset error => subclass of eof

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

Feature Requests item #3276560, was opened at 2011-04-05 20:13
Message generated for change (Comment added) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Sam Steingold (sds)
Summary: econnreset error => subclass of eof

Initial Comment:
Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input.
At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without
marking the stream as closed (which I think it should not do).  The result is that further attempts to use the stream give EBADF OS errors.
Requests:
- new condition class CONNECTION-RESET: 
  (define-condition connection-reset (end-of-file) ()) 
- change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET 
  and not in OS-ERROR (or whatever) 
- don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof.
Test code (at least for linux)
This requires two lisp processes, one for the client, one for the server.  I make use of the fact that closing a socket when there is
still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN.  The result of a FIN terminated 
connection is what I view as correct, so I will demonstrate that also.
[server] (setf ss (socket:socket-server 1234))
[server] (setf s (socket-accept ss))
[client]  (setf s (socket:socket-connect 1234))
[server-RST] (princ "asd" s)
[client] (close s)
at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included
[server] (read-char s)
the result in FIN scenario is an EOF error, in the RST scenario it's  *** - UNIX error 9 (EBADF): Bad file number
[server] (read-char s)
in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number
In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed.

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

>Comment By: Don Cohen (donc)
Date: 2011-04-07 21:13

Message:
  1. EOF is, intrinsically, an input event.
I agree, though there is a corresponding problem with trying to write to a
stream that is closed for output.
  ECONNRESET can happen on both input and output.
Here you are referring to a particular error number.
I would not view the appearance of that error number on a write to be the
same sort of event as the appearance of that number on a read.
  I don't think it is right to treat it separately for input and output.
So you adopt the position that an error number defines a condition.  Is
there any justification for this?
  2. EOF is a normal (non-error) condition in POSIX;
  ECONNRESET is an exception.
It seems possible (in fact, eof is proof) that the lisp models and posix
models are not completely compatible.
As a lisp implementer you have to make lisp present the lisp model.

  3. The purpose of TCP RST which CLISP observes as ECONNRESET
  is to tell us that the client never read the string "asd" which the
server sent with princ,
I do not agree.  I think this reset is unjustified by the TCP spec, in
fact contradicts it.

  not that there will be no more data coming through this connection
However the RST does imply that there will be no more data coming.

  (that's the purpose of the FIN which the server gets in the second
  read-char).
The server does not get a FIN at all in this case.  Only a RST.  
A FIN means "I'm done sending".  After that I can send more packets but no
more stream data.
You can continue to send stream data.  I am supposed to ACK that data. 
When you FIN then I
ACK your FIN.  (You probably already ACK'd my FIN.)  Then the connection
is closed.
On the other hand, if you send RST then I'm supposed to not send you
anything more.  I interpret
that as meaning that as far as you're concerned, this connection is
closed.

  In fact, I am not even sure that this is the case - is it really true
that
  no data will ever arrive from a socket which signaled ECONNRESET?
If it is following the protocol then it will not send any data or anything
else after sending RST.
It thinks there is no such connection.  At most it will reply to any
further communication to that
(non)connection with another RST.

  It would be nice if a TCP or POSIX expert could clarify this matter for
us.
There are degrees of expertise, but for purposes of this discussion, at
least, I seem to be the expert.
This is mostly a matter of how much time you spend reading the rfc (and
other related rfcs).


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

Comment By: Sam Steingold (sds)
Date: 2011-04-07 20:29

Message:
Let me clarify my objections to the proposal:
1. EOF is, intrinsically, an input event. 
ECONNRESET can happen on both input and output.
I don't think it is right to treat it separately for input and output.

2. EOF is a normal (non-error) condition in POSIX; 
ECONNRESET is an exception.

3. The purpose of TCP RST which CLISP observes as ECONNRESET
is to tell us that the client never read the string "asd" which the server
sent with princ,
not that there will be no more data coming through this connection
(that's the purpose of the FIN which the server gets in the second
read-char).

In fact, I am not even sure that this is the case - is it really true that

no data will ever arrive from a socket which signaled ECONNRESET?
It would be nice if a TCP or POSIX expert could clarify this matter for
us.

see http://thread.gmane.org/gmane.lisp.clisp.general/13700

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 16:38

Message:
I am extremely reluctant to treat ECONNRESET differently on input and
output.

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

Comment By: Don Cohen (donc)
Date: 2011-04-06 16:18

Message:
I now notice that the ECONNRESET OS-ERROR occurs on both read and write.
I'd like to clarify that only reads should result in EOF errors, so the
condition should perhaps be named to indicate some relation to eof or read,
e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not
result in that particular condition.

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

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

[ clisp-Feature Requests-3276560 ] econnreset error => subclass of eof

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

Feature Requests item #3276560, was opened at 2011-04-05 16:13
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3276560&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: Extend ANSI CL
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Sam Steingold (sds)
Summary: econnreset error => subclass of eof

Initial Comment:
Right now, when a socket is reset by the peer, nothing exciting happens until you try to read past the last available input.
At that point you get a OS error (ECONNRESET) which is not an EOF condition (I think it should be), and this further closes the fd, without
marking the stream as closed (which I think it should not do).  The result is that further attempts to use the stream give EBADF OS errors.
Requests:
- new condition class CONNECTION-RESET: 
  (define-condition connection-reset (end-of-file) ()) 
- change in CLISP behavior s.t. ECONNRESET results in CONNECTION-RESET 
  and not in OS-ERROR (or whatever) 
- don't close fd on ECONNRESET - it should act like other eof's - another attempt to read from the stream should cause another eof.
Test code (at least for linux)
This requires two lisp processes, one for the client, one for the server.  I make use of the fact that closing a socket when there is
still input available seems to result (again, only tested in linux) in a TCP reset rather than a FIN.  The result of a FIN terminated 
connection is what I view as correct, so I will demonstrate that also.
[server] (setf ss (socket:socket-server 1234))
[server] (setf s (socket-accept ss))
[client]  (setf s (socket:socket-connect 1234))
[server-RST] (princ "asd" s)
[client] (close s)
at this point the stream is closed, either with FIN if the [server-RST] line is left out, or with RST if it is included
[server] (read-char s)
the result in FIN scenario is an EOF error, in the RST scenario it's  *** - UNIX error 9 (EBADF): Bad file number
[server] (read-char s)
in the FIN scenario the result is another EOF error, in the RST scenario it's *** - UNIX error 9 (EBADF): Bad file number
In both cases s appears to be an open stream, though in the RST scenario, the underlying fd has been closed.

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-07 16:29

Message:
Let me clarify my objections to the proposal:
1. EOF is, intrinsically, an input event. 
ECONNRESET can happen on both input and output.
I don't think it is right to treat it separately for input and output.

2. EOF is a normal (non-error) condition in POSIX; 
ECONNRESET is an exception.

3. The purpose of TCP RST which CLISP observes as ECONNRESET
is to tell us that the client never read the string "asd" which the server
sent with princ,
not that there will be no more data coming through this connection
(that's the purpose of the FIN which the server gets in the second
read-char).

In fact, I am not even sure that this is the case - is it really true that

no data will ever arrive from a socket which signaled ECONNRESET?
It would be nice if a TCP or POSIX expert could clarify this matter for
us.

see http://thread.gmane.org/gmane.lisp.clisp.general/13700

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 12:38

Message:
I am extremely reluctant to treat ECONNRESET differently on input and
output.

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

Comment By: Don Cohen (donc)
Date: 2011-04-06 12:18

Message:
I now notice that the ECONNRESET OS-ERROR occurs on both read and write.
I'd like to clarify that only reads should result in EOF errors, so the
condition should perhaps be named to indicate some relation to eof or read,
e.g., TCP-RESET-EOF, and ECONNRESET resulting from a write should not
result in that particular condition.

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

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

clisp-cvs Digest, Vol 59, Issue 5

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

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
	cli...@li...

You can reach the person managing the list at
	cli...@li...

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: make code more readable
      (cli...@li...)
   2. clisp: merge (cli...@li...)
   3. clisp: * src/unixaux.d (fd_read): revert the 2008-12-30 patch
      wh... (cli...@li...)
   4. clisp: * src/sequence.d (interactive_no_hang): new function
      (cli...@li...)
   5. clisp: fix bug#3182597: WRITE-BYTE-SEQUENCE :no-hang t is
      only f... (cli...@li...)
   6. clisp: make sure socket-server is closed
      (cli...@li...)


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

Message: 1
Date: Wed, 06 Apr 2011 14:21:22 +0000
From: cli...@li...
Subject: clisp: make code more readable
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/da7b2a70a777
changeset: 15323:da7b2a70a777c4a0b1e3cefad4d52e0d24bf64c8
user:      Sam Steingold <sd...@po...>
date:      2011-04-05 12:48:01 -0400
description:
make code more readable

diffstat:

 tests/socket.tst |  10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)



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

Message: 2
Date: Wed, 06 Apr 2011 14:21:24 +0000
From: cli...@li...
Subject: clisp: merge
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/e77dff65e094
changeset: 15324:e77dff65e09410bb378a86645c377b628338827a
user:      Sam Steingold <sd...@po...>
date:      2011-04-06 10:21:06 -0400
description:
merge

diffstat:

 src/ChangeLog    |   8 ++++++++
 src/lispbibl.d   |  36 ++++++++++++++++++++++++------------
 src/spvw.d       |   8 +++++++-
 src/spvw_fault.d |  11 +++++------
 4 files changed, 44 insertions(+), 19 deletions(-)



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

Message: 3
Date: Wed, 06 Apr 2011 16:00:05 +0000
From: cli...@li...
Subject: clisp: * src/unixaux.d (fd_read): revert the 2008-12-30 patch
	wh...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/620ace6fa7e2
changeset: 15325:620ace6fa7e2932bde03447f92d204d62453501c
user:      Sam Steingold <sd...@po...>
date:      2011-04-06 11:59:39 -0400
description:
* src/unixaux.d (fd_read): revert the 2008-12-30 patch which closed
the fd on ECONNRESET without marking the lisp stream as closed,
thus leading to EBADF when the stream was closed

diffstat:

 src/ChangeLog         |   6 +++
 src/unixaux.d         |   5 --
 tests/ChangeLog       |   5 ++
 tests/econnreset.lisp |  68 ----------------------------------
 tests/socket.tst      |  16 ++++++++
 5 files changed, 27 insertions(+), 73 deletions(-)



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

Message: 4
Date: Wed, 06 Apr 2011 17:02:38 +0000
From: cli...@li...
Subject: clisp: * src/sequence.d (interactive_no_hang): new function
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/9dd8d5b15418
changeset: 15326:9dd8d5b154189784288772f64c8a2a4d56d6c13b
user:      Sam Steingold <sd...@po...>
date:      2011-04-06 12:56:46 -0400
description:
* src/sequence.d (interactive_no_hang): new function
(READ-BYTE-SEQUENCE, WRITE-BYTE-SEQUENCE): use it

diffstat:

 src/ChangeLog  |   5 +++++
 src/sequence.d |  32 +++++++++++++++++++-------------
 2 files changed, 24 insertions(+), 13 deletions(-)



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

Message: 5
Date: Wed, 06 Apr 2011 17:02:40 +0000
From: cli...@li...
Subject: clisp: fix bug#3182597: WRITE-BYTE-SEQUENCE :no-hang t is
	only f...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/a00aa0125366
changeset: 15327:a00aa0125366eb5a6956dbc04d3021df88903849
user:      Sam Steingold <sd...@po...>
date:      2011-04-06 13:02:19 -0400
description:
fix bug#3182597: WRITE-BYTE-SEQUENCE :no-hang t is only for byte vectors
* src/sequence.d (WRITE-BYTE-SEQUENCE): implement "persev !=
persev_full" for sequences other than (VECTOR (UNSIGNED-BYTE 8))

diffstat:

 src/ChangeLog       |   6 ++++++
 src/NEWS            |   2 ++
 src/sequence.d      |  37 +++++++++++++++++++++++++++----------
 tests/ext-clisp.tst |   5 ++---
 4 files changed, 37 insertions(+), 13 deletions(-)



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

Message: 6
Date: Wed, 06 Apr 2011 22:08:16 +0000
From: cli...@li...
Subject: clisp: make sure socket-server is closed
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/ee06402804dd
changeset: 15328:ee06402804dd0a9377199da0b73d77f4244cc853
user:      Sam Steingold <sd...@po...>
date:      2011-04-06 16:17:23 -0400
description:
make sure socket-server is closed

diffstat:

 tests/socket.tst |  32 +++++++++++++++++++++-----------
 1 files changed, 21 insertions(+), 11 deletions(-)



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

------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev

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

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


End of clisp-cvs Digest, Vol 59, Issue 5
****************************************

[ clisp-Bugs-3114096 ] Conformity and convenience problems with pathnames

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

Bugs item #3114096, was opened at 2010-11-20 22:28
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3114096&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: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: Conformity and convenience problems with pathnames

Initial Comment:
Hello,

It is well known that implementations of CL pathnames have been greatly
implementation dependant.  However, the standard still specifies clear
behavior for logical pathnames, for one thing, and for the other, since
there are several implementations working on the same POSIX systems
(unix including linux and MacOSX; and MS-Windows), it is desirable that
all implementations converge in their handling of pathnames on these
plateforms.

Personnaly, I resolved to use logical pathnames and logical-pathname
translations as much as possible, and to use make-pathname to build
portably physical pathnames. 

However, most implementations have problems dealing with these two
aspects.   To improve the situation, I wrote a little script to check
the behavior of implementations in these two aspects.

The script can be found at:

ftp://ftp.informatimago.com/users/pjb/lisp/check-pathnames.lisp

Since I'm sending a similar message to most implementation  lists, it
might be better, if there is any need for 'language lawyer' discussions,
to direct them to news:comp.lang.lisp.


Here are the results for clisp:
------------------------------------------------------------------------
[pjb@kuiper :0.0 ~]$ clisp -ansi -norc 
  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-07) <http://clisp.cons.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]> (load "/home/pjb/src/lisp/check-pathnames.lisp")
;; Loading file /home/pjb/src/lisp/check-pathnames.lisp ...
================================================================================

Test and probe conforming logical pathnames, and their translation to
unix physical pathnames.

We want to check the good working of logical pathnames, and the
translation of logical pathnames to physical pathnames, in a
semi-standard way on unix systems.

Namely, given the logical host and its translations:

  (setf (logical-pathname-translations "LOGICAL") nil)
  (setf (logical-pathname-translations "LOGICAL") 
        '((#P"LOGICAL:**;*.*" #P"/tmp/**/*.*")
          (#P"LOGICAL:**;*"   #P"/tmp/**/*")))

#P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
must be the same as (make-pathname :host "LOGICAL"
                                   :directory '(:absolute "DIR" "SUBDIR")
                                   :name "NAME" :type "TYPE" :version :newest
                                   :case :common)
and must translate to: #P"/tmp/dir/subdir/name.type" on unix.



Merging physical pathnames specified with :case :common is also tested:

  (merge-pathnames (make-pathname :directory '(:relative "DIR" "SUBDIR")
                                  :name "NAME" :type "TYPE" :version :newest
                                  :case :common :default #1=#P"/tmp/")
                    #1# nil)

must give #P"/tmp/dir/subdir/name.type".

================================================================================
The customary case for the file system of CLISP (2.49 (2010-07-07) (built 
3498306068) (memory 3498306421)) is lower case.

================================================================================
(MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
 (:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
 :COMMON)


LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
--------------------------------------------------------------------------------
Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-DIRECTORY PATH :CASE :COMMON) = (:ABSOLUTE "dir" "subdir")
    and: (POP EXPECTED-VALUES) = (:ABSOLUTE "DIR" "SUBDIR")
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-NAME PATH :CASE :COMMON) = "name"
    and: (POP EXPECTED-VALUES) = "NAME"
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-TYPE PATH :CASE :COMMON) = "type"
    and: (POP EXPECTED-VALUES) = "TYPE"
--------------------------------------------------------------------------------
Failed assertion: (STRING= EXPECTED-PRINTED (PRIN1-TO-STRING PATH))
   with: EXPECTED-PRINTED = "#P\"LOGICAL:DIR;SUBDIR;NAME.TYPE\""
    and: (PRIN1-TO-STRING PATH) = "#P\"LOGICAL:dir;subdir;name.type.NEWEST\""

It would be better if logical pathnames were printed using upper case
letters, mostly because of 19.3.1.1.7, and because:

    22.1.1 Overview of The Lisp Printer

    Reading a printed representation typically produces an object that is
    equal to the originally printed object. 

and

    2.4.8.14 Sharpsign P

    #P reads a following object, which must be a string.

    #P<<expression>> is equivalent to #.(parse-namestring '<<expression>>),
    except that #P is not affected by *read-eval*.

and

    Function PARSE-NAMESTRING

    * If host is nil and thing is a syntactically valid logical pathname
      namestring containing an explicit host, then it is parsed as a
      logical pathname namestring.

and

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
    When parsing words and wildcard-words, lowercase letters are translated to uppercase.

Notice that means that a logical pathname built with mixed cases (or
lower case), cannot be printed readably with a conforming syntax (but
it doesn't matter, since it's not a conforming logical pathname
anyways).
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES))
   with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL"
    and: (POP EXPECTED-VALUES) = "logical"
19.2.2.1.2  makes no exception for pathname-host of logical pathnames.



================================================================================
(MAKE-PATHNAME :HOST "logical" :DEVICE :UNSPECIFIC :DIRECTORY
 (:ABSOLUTE "dir" "subdir") :NAME "name" :TYPE "type" :VERSION :NEWEST :CASE
 :LOCAL)


LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
--------------------------------------------------------------------------------
Failed assertion: (DIRLIST= (PATHNAME-DIRECTORY PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-DIRECTORY PATH :CASE :COMMON) = (:ABSOLUTE "dir" "subdir")
    and: (POP EXPECTED-VALUES) = (:ABSOLUTE "DIR" "SUBDIR")
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-NAME PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-NAME PATH :CASE :COMMON) = "name"
    and: (POP EXPECTED-VALUES) = "NAME"
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-TYPE PATH :CASE :COMMON) (POP EXPECTED-VALUES))
   with: (PATHNAME-TYPE PATH :CASE :COMMON) = "type"
    and: (POP EXPECTED-VALUES) = "TYPE"
--------------------------------------------------------------------------------
Failed assertion: (STRING= EXPECTED-PRINTED (PRIN1-TO-STRING PATH))
   with: EXPECTED-PRINTED = "#P\"LOGICAL:DIR;SUBDIR;NAME.TYPE\""
    and: (PRIN1-TO-STRING PATH) = "#P\"LOGICAL:dir;subdir;name.type.NEWEST\""

It would be better if logical pathnames were printed using upper case
letters, mostly because of 19.3.1.1.7, and because:

    22.1.1 Overview of The Lisp Printer

    Reading a printed representation typically produces an object that is
    equal to the originally printed object. 

and

    2.4.8.14 Sharpsign P

    #P reads a following object, which must be a string.

    #P<<expression>> is equivalent to #.(parse-namestring '<<expression>>),
    except that #P is not affected by *read-eval*.

and

    Function PARSE-NAMESTRING

    * If host is nil and thing is a syntactically valid logical pathname
      namestring containing an explicit host, then it is parsed as a
      logical pathname namestring.

and

    19.3.1.1.7 Lowercase Letters in a Logical Pathname Namestring
    When parsing words and wildcard-words, lowercase letters are translated to uppercase.

Notice that means that a logical pathname built with mixed cases (or
lower case), cannot be printed readably with a conforming syntax (but
it doesn't matter, since it's not a conforming logical pathname
anyways).
--------------------------------------------------------------------------------
Failed assertion: (STRING= (PATHNAME-HOST PATH :CASE :LOCAL) (POP EXPECTED-VALUES))
   with: (PATHNAME-HOST PATH :CASE :LOCAL) = "LOGICAL"
    and: (POP EXPECTED-VALUES) = "logical"
19.2.2.1.2  makes no exception for pathname-host of logical pathnames.

--------------------------------------------------------------------------------
Failed assertion: 
(PATHNAME-EQUAL #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
 (MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
  '(:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
  :COMMON))
   with: #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST" = #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
    and: 
(MAKE-PATHNAME :HOST "LOGICAL" :DEVICE :UNSPECIFIC :DIRECTORY
 '(:ABSOLUTE "DIR" "SUBDIR") :NAME "NAME" :TYPE "TYPE" :VERSION :NEWEST :CASE
 :COMMON) = #P"LOGICAL:dir;subdir;name.type.NEWEST"

LOGICAL-PATHNAME #P"LOGICAL:DIR;SUBDIR;NAME.TYPE.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "TYPE"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "DIR" "SUBDIR")
Name      : "NAME"
Type      : "TYPE"
Version   : :NEWEST
--------------------  

LOGICAL-PATHNAME #P"LOGICAL:dir;subdir;name.type.NEWEST"
--------------------  :case :local (default)
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  :case :common
Host      : "LOGICAL"
Device    : :UNSPECIFIC
Directory : (:ABSOLUTE "dir" "subdir")
Name      : "name"
Type      : "type"
Version   : :NEWEST
--------------------  
;; Loaded file /home/pjb/src/lisp/check-pathnames.lisp
T
[2]> (quit)
Bye.
[pjb@kuiper :0.0 ~]$ 


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

>Comment By: Sam Steingold (sds)
Date: 2011-04-06 13:04

Message:
does the latest version reflect the c.l.l consensus (such as there is)?

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

Comment By: Sam Steingold (sds)
Date: 2011-01-02 11:33

Message:
there have been some discussion on c.l.l which seems to have invalidated
some of these tests

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

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

[ clisp-Bugs-3182597 ] WRITE-BYTE-SEQUENCE :no-hang t is only for byte vectors

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

Bugs item #3182597, was opened at 2011-02-15 13:19
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182597&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
>Assigned to: Sam Steingold (sds)
>Summary: WRITE-BYTE-SEQUENCE :no-hang t is only for byte vectors

Initial Comment:
[3]> (EXT:WRITE-BYTE-SEQUENCE #(1) f :no-hang t) 
   *** - WRITE-BYTE-SEQUENCE on  
         #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 8) #P"/tmp/out1"> is  illegal  
works when array is element-type (unsigned-byte 8)
(the bug is that it does not work for other types)
same problem for unbuffered streams

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

Comment By: Sam Steingold (sds)
Date: 2011-04-06 13:02

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: Sam Steingold (sds)
Date: 2011-03-23 17:17

Message:
this comes from 
    if (no_hang || interactive) /* FIXME: need write_byte_will_hang_p()
*/
      error_illegal_streamop(S(write_byte_sequence),STACK_3);
in sequence.d (and similar comment in stream.d).
PTC.
workaround: use binary arrays (as you have noticed yourself)

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

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