clisp-devel — closed list for developers and testers

Re: CLISP 2.49 build error on MinGW

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

> * Elliott Slaughter <ryy...@tz...> [2011-04-14 17:43:10 -0700]:
>
> Here is the unabridged build log: http://pastebin.com/MMkrsEjV

please try the appended patch (make sure makemake is _not_ called with --win32gcc)

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X 11.0.60900031
http://pmw.org.il http://dhimmi.com http://honestreporting.com
http://www.PetitionOnline.com/tap12009/ http://palestinefacts.org
To understand recursion, one has to understand recursion first.


diff -r b573979456c9 src/makemake.in
--- a/src/makemake.in	Fri Apr 15 13:03:03 2011 -0400
+++ b/src/makemake.in	Fri Apr 15 15:10:40 2011 -0400
@@ -591,11 +591,17 @@ fi
 # feature or bug than to look at various `uname ...` results and list
 # the buggy systems explicitly. ONLY in this case!
 
+set_win32gcc(){
+  HSYSOS=$HSYS
+  HOS=win32
+  COMPILER=gcc
+}
+
 case $# in
   0 | 1)
      # Assume we are on Unix (or win32gcc); target=host (not cross-compiling).
      CROSS=false
-     if [ -z "$HSYS" ]; then # not win32gcc
+     if [ -z "$HSYS" ]; then # no --win32gcc
        # some shells (A/UX and OSF/1) need the parentheses around "arch" below.
        HSYS=`((arch) 2>/dev/null || uname -m 2>/dev/null) | $tolower` # system name in lowercase
        HSYSOS=`((uname) 2>/dev/null || arch 2>/dev/null) | $tolower` # OS name in lowercase
@@ -605,16 +611,16 @@ case $# in
        if [ "$HSYS" = sun4m ] ; then
          HSYS='sun4'
        fi
+       HOS='unix'
        case "$HSYSOS" in
          # Canonicalize cygwin32/nt and cygwin32/95 to plain cygwin.
          cygwin*) HSYSOS=cygwin ;;
+         # Canonicalize mingw32_nt-6.1 - as if --win32gcc
+         mingw32*) HSYS=win32gcc; set_win32gcc ;;
        esac
-       HOS='unix'
        COMPILER=??
      else                       # win32gcc
-       HSYSOS=$HSYS
-       HOS=win32
-       COMPILER=gcc
+       set_win32gcc
      fi
      TSYS="$HSYS"
      TSYSOS="$HSYSOS"

Re: CLISP 2.49 build error on MinGW

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

> * Elliott Slaughter <ryy...@tz...> [2011-04-15 11:32:46 -0700]:
>
> # host system:
>  hostname = "Blackthorn"
>      HSYS = "i686"
>    HSYSOS = "mingw32_nt-6.1"
>       HOS = "unix"
>  host_cpu = "i686"
>       cpu = "i386"
>   host_os = "mingw32"
>      host = "i686-pc-mingw32"
> # target system:
>      TSYS = "i686"
>    TSYSOS = "mingw32_nt-6.1"
>       TOS = "unix"

I wonder if HOS and TOS should be set from HSYSOS and TSYSOS in this case...

> Ok, with the mingw configure flag it builds, but looks like I'm getting a
> failure in check-fresh-line:
>
> ./lisp.exe -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -q -M
> lispinit.mem -x '(progn (dolist (s (quote (*terminal-io* *standard-output*
> *error-output* *query-io* *debug-io* *trace-output*))) (format t "~S = ~S~%"
> s (symbol-value s) (values))' 2>&1 > fresh-line.out
>
> [../src/eval.d:573] reset() found no driver frame (sp=0x28fe60-0x28b3d4)
> make: *** [check-fresh-line] Error 255

this is not good and it would be nice if you could debug this, but it
should not prevent you from fixing the installer problem.

thanks.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X 11.0.60900031
http://honestreporting.com http://jihadwatch.org http://www.memritv.org
http://truepeace.org http://www.PetitionOnline.com/tap12009/ http://camera.org
The only time you have too much fuel is when you're on fire.

Re: CLISP 2.49 build error on MinGW

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

On Fri, Apr 15, 2011 at 7:23 AM, Sam Steingold <sd...@gn...> wrote:

> Hi,
>
> > * Elliott Slaughter <ryy...@tz...> [2011-04-14 17:43:10
> -0700]:
> >
> > ../src/lispbibl.d:1986:21: fatal error: win32.c: No such file or
> directory
>
> this means that the compiler is trying to compile a native win32 version
> of clisp (which is obviously what you want) but makemake did not agree.
>
> > Here is the unabridged build log: http://pastebin.com/MMkrsEjV
>
> thanks for the log. it is very helpful. it shows that TOS (target OS) is
> set to unix instead of win32.  if you add "-verbose" to the makemake
> invocation in the Makefile and do "make Makefile", you _should_ see
> something like this:
>
> what do you see?
>

# host system:
 hostname = "Blackthorn"
     HSYS = "i686"
   HSYSOS = "mingw32_nt-6.1"
      HOS = "unix"
 host_cpu = "i686"
      cpu = "i386"
  host_os = "mingw32"
     host = "i686-pc-mingw32"
# target system:
     TSYS = "i686"
   TSYSOS = "mingw32_nt-6.1"
      TOS = "unix"

the solution is to add "--with-mingw" to the top-level configure invocation
> or
> "--win32gcc" to the makemake invocation in Makefile.
>
> Good luck!
>

Ok, with the mingw configure flag it builds, but looks like I'm getting a
failure in check-fresh-line:

./lisp.exe -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -q -M
lispinit.mem -x '(progn (dolist (s (quote (*terminal-io* *standard-output*
*error-output* *query-io* *debug-io* *trace-output*))) (format t "~S = ~S~%"
s (symbol-value s) (values))' 2>&1 > fresh-line.out

[../src/eval.d:573] reset() found no driver frame (sp=0x28fe60-0x28b3d4)
make: *** [check-fresh-line] Error 255

-- 
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: CLISP 2.49 build error on MinGW

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

Hi,

> * Elliott Slaughter <ryy...@tz...> [2011-04-14 17:43:10 -0700]:
>
> ../src/lispbibl.d:1986:21: fatal error: win32.c: No such file or directory

this means that the compiler is trying to compile a native win32 version
of clisp (which is obviously what you want) but makemake did not agree.

> Here is the unabridged build log: http://pastebin.com/MMkrsEjV

thanks for the log. it is very helpful. it shows that TOS (target OS) is
set to unix instead of win32.  if you add "-verbose" to the makemake
invocation in the Makefile and do "make Makefile", you _should_ see
something like this:

# # host system:
#   hostname = "stnt067"
#       HSYS = "win32gcc"
#     HSYSOS = "win32gcc"
#        HOS = "win32"
#   host_cpu = "i686"
#        cpu = "i386"
#    host_os = "mingw32"
#       host = "i686-pc-mingw32"
# # target system:
#       TSYS = "win32gcc"
#     TSYSOS = "win32gcc"
#        TOS = "win32"

what do you see?

the solution is to add "--with-mingw" to the top-level configure invocation or
"--win32gcc" to the makemake invocation in Makefile.

Good luck!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X 11.0.60900031
http://jihadwatch.org http://ffii.org http://mideasttruth.com
http://honestreporting.com http://iris.org.il http://pmw.org.il
History doesn't repeat itself, but historians do repeat each other.

CLISP 2.49 build error on MinGW

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

Hi,

I'm trying to do a minimal CLISP 2.49 build (with libsigsegv and nothing
else) on MinGW so I can test installer fixes.

The build terminates with:

gcc -I/c/Users/Elliott/Desktop/clisp-2.49/../clisp-libs/include
-I/c/Users/Elliott/Desktop/clisp-2.49/build/gllib -g -O2 -W -Wswitch
-Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations
-falign-functions=4 -DENABLE_UNICODE -DNO_TERMCAP_NCURSES -DDYNAMIC_MODULES
-I. -c spvw.c
In file included from ../src/spvw.d:23:0:
../src/lispbibl.d:1986:21: fatal error: win32.c: No such file or directory

Here is the unabridged build log: http://pastebin.com/MMkrsEjV

I am running Windows 7 64-bit with a fairly recent fresh install of MinGW.

$ gcc --version
gcc.exe (GCC) 4.5.2

Let me know if you want me to try anything.

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

[ clisp-Bugs-3046401 ] Windows XP PATH overwritten

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

Bugs item #3046401, was opened at 2010-08-16 15:46
Message generated for change (Comment added) made by slaguth
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3046401&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: Jackson McCann (rjmccann)
Assigned to: Elliott Slaughter (slaguth)
Summary: Windows XP PATH overwritten

Initial Comment:
Hi,

When I installed the pre-build windows binary clisp-2.49-win32-mingw-big.exe (it reports being Welcome to GNU CLISP 2.49 (2010-07-07) when run) the intstaller replaced my PATH environment variable rather than appending to it.  This happened with a default install under Windows XP SP3.

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

>Comment By: Elliott Slaughter (slaguth)
Date: 2011-04-15 00:12

Message:
Brandon, could you please check to see if this happens with version 2.48 of
CLISP?

http://sourceforge.net/projects/clisp/files/clisp/2.48/clisp-2.48-win32-mingw-big.exe/download

I haven't been able to duplicate this on my end, so it would be really
helpful to know what OS version and service pack, 32/64-bit-ness, whether
you installed "for everyone" or "just me", etc.

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

Comment By: Brandon J. Van Every (bvanevery)
Date: 2011-04-15 00:00

Message:
Confirmed, by myself and also another person on comp.lang.lisp. 
https://groups.google.com/d/msg/comp.lang.lisp/0pB2IKiNasU/1pEODEH5M-8J

If you notice the path has been overwritten before you reboot, you may be
able to recover an older copy of the path.  Start regedit and look under
HKLM\System\ControlSetXXX\Control\Session Manager\Environment\Path, where
"XXX" is a number such as "004". Otherwise once you reboot it is completely
gone. 

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

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

[ clisp-Bugs-3046401 ] Windows XP PATH overwritten

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

Bugs item #3046401, was opened at 2010-08-16 11:46
Message generated for change (Comment added) made by bvanevery
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3046401&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: Jackson McCann (rjmccann)
Assigned to: Elliott Slaughter (slaguth)
Summary: Windows XP PATH overwritten

Initial Comment:
Hi,

When I installed the pre-build windows binary clisp-2.49-win32-mingw-big.exe (it reports being Welcome to GNU CLISP 2.49 (2010-07-07) when run) the intstaller replaced my PATH environment variable rather than appending to it.  This happened with a default install under Windows XP SP3.

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

Comment By: Brandon J. Van Every (bvanevery)
Date: 2011-04-14 20:00

Message:
Confirmed, by myself and also another person on comp.lang.lisp. 
https://groups.google.com/d/msg/comp.lang.lisp/0pB2IKiNasU/1pEODEH5M-8J

If you notice the path has been overwritten before you reboot, you may be
able to recover an older copy of the path.  Start regedit and look under
HKLM\System\ControlSetXXX\Control\Session Manager\Environment\Path, where
"XXX" is a number such as "004". Otherwise once you reboot it is completely
gone. 

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

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

[ clisp-Bugs-1672132 ] mprotect configure test incorrect

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

Bugs item #1672132, was opened at 2007-03-02 01:26
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1672132&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Adam Fedor (fgstep)
Assigned to: Bruno Haible (haible)
Summary: mprotect configure test incorrect

Initial Comment:
The configure test for mprotect appears to be incorrect, producing exactly the opposite result it is supposed to. Attached is the patch

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-04-14 20:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Sam Steingold (sds)
Date: 2011-03-31 19:26

Message:
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case
or answering our other recent requests),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


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

Comment By: Sam Steingold (sds)
Date: 2007-03-05 00:44

Message:
Logged In: YES 
user_id=5735
Originator: NO

OK, so you are saying that the tests are too permissive.
fine, please add more tests (but first make sure that they will not cause
undue loss of mprotect functionality on linux etc)

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

Comment By: Adam Fedor (fgstep)
Date: 2007-03-04 22:58

Message:
Logged In: YES 
user_id=1326233
Originator: YES

Err, OK I see that. But now the test makes absolutely no sense at all. All
it seems to be testing is that you are properly prohibited from looking at
or writing to memory that has been protected correctly.  It certainly
doesn't check to see if you can make memory writeable or even executable,
which is what trampoline.c expects to use it for. I'll defer to other bugs
(#1531290 for instance), which encapsulate what I really want fixed...

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

Comment By: Sam Steingold (sds)
Date: 2007-03-04 18:01

Message:
Logged In: YES 
user_id=5735
Originator: NO

This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


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

Comment By: Sam Steingold (sds)
Date: 2007-03-04 18:01

Message:
Logged In: YES 
user_id=5735
Originator: NO

I deleted my patch because I now think that the original code is correct.
please examine the comments:
/* this should cause an exception or signal */ ==>
action-if-succeed="no_mprotect=1"
/* this should not cause an exception or signal */ ==>
action-if-fail="no_mprotect=1"

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

Comment By: Adam Fedor (fgstep)
Date: 2007-03-04 17:48

Message:
Logged In: YES 
user_id=1326233
Originator: YES

OK. I missed that one. Thanks.

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

Comment By: Sam Steingold (sds)
Date: 2007-03-04 04:46

Message:
Logged In: YES 
user_id=5735
Originator: NO

then why are you changing the 2 places only?
see my patch (attached): now no_mprotect is handled identically in all 5
places.
File Added: mprotect.m4.diff

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

Comment By: Adam Fedor (fgstep)
Date: 2007-03-02 05:37

Message:
Logged In: YES 
user_id=1326233
Originator: YES

The autoconf code for AC_TRY_RUN is roughly: 
AC_TRY_RUN(program, action-if-succeed, action-if-fail,
action-if-cross-compile), 
and in mprotect.m4, it's implemented roughly as:
AC_TRY_RUN('mprotect program', no_mprotect=1, , )
so no_mprotect gets set if the program suceeds (it's correct in the first
test but not the others). Later on, it's tested:  if test -z
"$no_mprotect"; cl_cv_func_mprotect_works=yes - so the test shows mprotect
as working if no_mprotect is NOT set, but the previous AC_TRY_RUN tests set
no_mprotect if it does works.  I can show you a config.log file where the
mprotect test clearly fails, but HAVE_WORKING_MPROTECT is defined. Perhaps
it's worked all these years for other reasons?

Actually, I found this on powerpc-apple-darwin8.8 and fixed it, but this
just causes other problems, which may be similar to bug #1535284. Perhaps I
just need to look at the wider issue of what's not working...


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

Comment By: Sam Steingold (sds)
Date: 2007-03-02 05:00

Message:
Logged In: YES 
user_id=5735
Originator: NO

the current code have been detecting mprotect just fine for many years.
could you please be more specific - what are you unhappy about?

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

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

clisp-cvs Digest, Vol 59, Issue 10

[<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: clisp.cons.org -> clisp.org
      (cli...@li...)
   2. clisp: On Max OS X the value of *PATHNAME-ENCODING* is set to
      UT... (cli...@li...)
   3. clisp: add periods to "thanks" lines
      (cli...@li...)


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

Message: 1
Date: Wed, 13 Apr 2011 21:29:13 +0000
From: cli...@li...
Subject: clisp: clisp.cons.org -> clisp.org
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/6c15020bc7c9
changeset: 15340:6c15020bc7c9519cd21a48d03352a31bc51dc81b
user:      Sam Steingold <sd...@po...>
date:      2011-04-13 17:23:58 -0400
description:
clisp.cons.org -> clisp.org

diffstat:

 src/NEWS |  22 ++++++++++------------
 1 files changed, 10 insertions(+), 12 deletions(-)



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

Message: 2
Date: Wed, 13 Apr 2011 21:29:15 +0000
From: cli...@li...
Subject: clisp: On Max OS X the value of *PATHNAME-ENCODING* is set to
	UT...
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/a111df54b78c
changeset: 15341:a111df54b78ce3acf403199448c9cd77d3362cbc
user:      Sam Steingold <sd...@po...>
date:      2011-04-13 17:24:57 -0400
description:
On Max OS X the value of *PATHNAME-ENCODING* is set to UTF-8 and cannot
be changed because MacOSX pathnames are UTF-8 strings, not byte
sequences (http://thread.gmane.org/gmane.lisp.clisp.general/13725
and http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html)
* src/lispbibl.d (CONSTANT_PATHNAME_ENCODING) [UNIX_MACOSX]: define to UTF-8
* src/encoding.d (init_dependent_encodings) [CONSTANT_PATHNAME_ENCODING]:
set O(pathname_encoding) to CONSTANT_PATHNAME_ENCODING
(SYSTEM::SET-PATHNAME-ENCODING): signal an error when the encoding
argument is not CONSTANT_PATHNAME_ENCODING
* src/spvw.d (argv_encoding_pathname): do not define when
CONSTANT_PATHNAME_ENCODING is defined
(parse_options): do not accept -Epathname
* src/makemake.in (encflags) [TSYSOS=darwin]: do not add -Epathname
Thanks to Carlos Ungil <car...@gm...> for testing.

diffstat:

 doc/impext.xml  |   3 +++
 src/ChangeLog   |  17 +++++++++++++++++
 src/NEWS        |   4 ++++
 src/encoding.d  |  14 ++++++++++++++
 src/lispbibl.d  |   4 ++++
 src/makemake.in |   9 ++++++---
 src/spvw.d      |  12 +++++++++---
 tests/ChangeLog |   5 +++++
 tests/path.tst  |   8 ++++----
 9 files changed, 66 insertions(+), 10 deletions(-)



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

Message: 3
Date: Wed, 13 Apr 2011 21:29:17 +0000
From: cli...@li...
Subject: clisp: add periods to "thanks" lines
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/49ddafbe8d1b
changeset: 15342:49ddafbe8d1bcc3b9d65c7b6e751b91f96f9279d
user:      Sam Steingold <sd...@po...>
date:      2011-04-13 17:25:51 -0400
description:
add periods to "thanks" lines

diffstat:

 src/ChangeLog |  8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)



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

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

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

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


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

Re: A Modest Proposal

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

Noah Lavine <noa...@gm...> writes:

> Hello Guile and Clisp developers,
>
> I'm writing to talk about vague big-picture ideas, but please bear
> with me for a minute, because I think this could be useful.
>
> I noticed in the recent GNU Summer of Code applications (I'm a mentor
> for Guile) that CLisp wants to become embeddable, and embed into Emacs
> as a first test case. That would make Clisp an embeddable Lisp
> implementation with a bytecode-interpreting virtual machine, compiler,
> interpreter, debugger, etc. A very cool thing. Clisp developers might
> not be aware that that is exactly what GNU Guile is - a
> bytecode-interpreting virtual machine with a compiler, interpreter,
> debugger, and collection of useful tools. Guile is already embeddable,
> because that was one of Guile's original goals, but the difference is
> not so big. Guile also has a summer of code projects to embed itself
> into Emacs, in fact.
>
> It seems to me that it is time for Guile and CLisp to consider working
> together, because if we don't work together then I think we're both
> going to do the same work twice, separately.
>
> This depends greatly on what CLisp's goals are as a project, and I do
> not know those. Maybe you have very different goals than Guile, in
> which case we might not gain anything by working together. But I do
> have a feeling that we are both evolving towards the same place, and
> if so, I think it would be nice to cooperate some along the way.


I think we should first compare the virtual machines.


If no obvious impossibility is observed, then perhaps modifying the
compiler of clisp to generate guile VM code would be an easy path to
obtain a CL implementation running on guile VM.  (This would disable the
interpreter in clisp, since it is implemented in C).

Or, vice-versa, if the VM of clisp has advantages (but if guile has
continuations, this would be lacking in the clisp VM).



In general, there may be a need for a very good lisp virtual machine to
run and integrate lisp code in general (CL, various schemes, and other
sorts of lisp-like languages, we could include perhaps implementations
of python,  ruby,  smalltalk,  javascript, etc).  From well afar, it
looks like the JVM is not good enough for lisp (ABCL, Clojure, seem to
have some difficulties to implement some basic lisp features on the
JVM).


This VGLVM would:

- be embeddable in applications,

- include a FFI to native code,

- be more performant than the JVM,

- be natively multithreaded,

- have a good real-time multithreaded garbage collector,

- possibly have a JIT and/or a retargetting compiler,

- allow easy (FFI-less) communication between the different languages
  targetting it (for example, when we run pseudo, we can call CL
  function from scheme and scheme functions from CL)..



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

clisp-cvs Digest, Vol 59, Issue 9

[<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: add select unix entity
      (cli...@li...)
   2. clisp: http://translationproject.org/latest/clisp/da.po
      (cli...@li...)
   3. clisp: On Max OS X the value of *PATHNAME-ENCODING* is set to
      UT... (cli...@li...)


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

Message: 1
Date: Tue, 12 Apr 2011 13:38:55 +0000
From: cli...@li...
Subject: clisp: add select unix entity
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/54157081b5d8
changeset: 15338:54157081b5d84c29b6244ff649a9d4159c327fee
user:      Sam Steingold <sd...@po...>
date:      2011-04-12 09:38:11 -0400
description:
add select unix entity

diffstat:

 doc/unix-ent.xml            |  1 +
 modules/rawsock/rawsock.xml |  5 ++---
 2 files changed, 3 insertions(+), 3 deletions(-)



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

Message: 2
Date: Tue, 12 Apr 2011 14:51:56 +0000
From: cli...@li...
Subject: clisp: http://translationproject.org/latest/clisp/da.po
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/bd62bbe6afc7
changeset: 15339:bd62bbe6afc7f967f4aaf2ee59133e996f3ec7d0
user:      Sam Steingold <sd...@po...>
date:      2011-04-12 10:49:33 -0400
description:
http://translationproject.org/latest/clisp/da.po

diffstat:

 src/po/da.po |  86 +++++++++++++++++++++----------------------
 1 files changed, 42 insertions(+), 44 deletions(-)



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

Message: 3
Date: Tue, 12 Apr 2011 18:23:21 +0000
From: cli...@li...
Subject: clisp: On Max OS X the value of *PATHNAME-ENCODING* is set to
	UT...
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/c8f10bb068a0
changeset: 15340:c8f10bb068a0d9ad416a8578f19af0720e0a8c48
user:      Sam Steingold <sd...@po...>
date:      2011-04-12 14:23:01 -0400
description:
On Max OS X the value of *PATHNAME-ENCODING* is set to UTF-8 and cannot
be changed because MacOSX pathnames are UTF-8 strings, not byte
sequences (http://thread.gmane.org/gmane.lisp.clisp.general/13725
and http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html)
* src/lispbibl.d (CONSTANT_PATHNAME_ENCODING) [UNIX_MACOSX]: define to UTF-8
* src/encoding.d (init_dependent_encodings) [CONSTANT_PATHNAME_ENCODING]:
set O(pathname_encoding) to CONSTANT_PATHNAME_ENCODING
(SYSTEM::SET-PATHNAME-ENCODING): signal an error when the encoding
argument is not CONSTANT_PATHNAME_ENCODING
* src/spvw.d (argv_encoding_pathname): do not define when
CONSTANT_PATHNAME_ENCODING is defined
(parse_options): do not accept -Epathname

diffstat:

 doc/impext.xml  |   3 +++
 src/ChangeLog   |  15 +++++++++++++++
 src/NEWS        |  26 ++++++++++++++------------
 src/encoding.d  |  14 ++++++++++++++
 src/lispbibl.d  |   4 ++++
 src/spvw.d      |  12 +++++++++---
 tests/ChangeLog |   5 +++++
 tests/path.tst  |   4 ++--
 8 files changed, 66 insertions(+), 17 deletions(-)



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

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo

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

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


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

[ 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-12 17:39

Message:
Now let me respond to your poll. 
Your question was slightly misleading. 
I'd have preferred something that specifically says 
 when you try to read on a stream that has been reset and you get to 
 the end, should you get a signal that is a (subclass of) EOF 
In this context, the definition of EOF makes my case: 
 The type end-of-file consists of error conditions related to read 
 operations that are done on streams that have no more data.  
 
On the other hand I thought your example was good. 
The point is that when the peer closes the connection then your 
example code *MAY* get an error (previous post shows both cases). 
 
The problem I see is that you can't really tell whether the RST 
is a signal that your output was not all read or something more 
serious (the peer went down and then came back up with no record  
of this connection).  (This is what I don't like about rfc1122.) 
I don't see that failure to read all of the input indicates an  
error, and as I pointed out, this RST is not a good indication  
of that anyway.   
 
Therefore, as a programmer you have to make a choice. 
The problem is that it's so inconvenient to make the choice now. 
I think this justifies some support for controlling the choice, as 
I suggested in the post of 2011-04-11 18:34:10 GMT. 

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

Comment By: Don Cohen (donc)
Date: 2011-04-12 16:59

Message:
A little new info on this: 
The first reply in comp.lang.lisp mentions something I also saw 
searching comp.protocols.tcp-ip.  It's in rfc1122: 
 
    A host MAY implement a "half-duplex" TCP close sequence, so 
    that an application that has called CLOSE cannot continue to 
    read data from the connection.  If such a host issues a 
    CLOSE call while received data is still pending in TCP, or 
    if new data is received after CLOSE is called, its TCP 
    SHOULD send a RST to show that data was lost. 
 
This at least explains the behavior that I thought was not justified  
by rfc 793. 
Just to clarify, if the client sends a FIN, that means that he is 
done sending but is still reading. 
This form of reset is a signal that the peer is not listening any 
more.  It seems more relevant to writing than reading.  It's really a 
signal that your write is not working. 
 
Note that the tcp is actually connected to some other program and even 
if tcp has delivered all the data to that program, it cannot tell 
whether that program ever looked at that data.  Watch this: 
 
[server] (setf s (socket-accept ss)) 
[client] (setf s (socket:socket-connect 1234)) 
[server] (princ "asd" s) 
up to here the same script we saw before 
[client](read-char s) 
[client] (close s) 
The previous script skipped the read-char. 
In that case we get RST. 
By doing the read-char, clisp retrieves the data in the tcp queue, 
namely "asd".  Tcp considers that data to be delivered, even though 
the lisp application has only looked at the "a".  In this case the 
close ends with FIN.  And therefore, 
[server] (read-char s) 
  *** - READ: input stream #<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER 
  0.0.0.0:1234> has reached its end 
 


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

Comment By: Sam Steingold (sds)
Date: 2011-04-12 15:11

Message:
cll seems to agree with me: ECONNRESET is a stream-error
 (as it is now in clisp) but _not_ an end-of-file (as you want).
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/6f3e239e147663ea

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

Comment By: Don Cohen (donc)
Date: 2011-04-11 18:34

Message:
I would like to see all of the errors that are intuitively stream errors to
be be classified that way.
I don't think I am trying to require any where near as many conditions as
you suggest.
At this point I only really want to argue for one,
(define-condition connection-reset-on-input (end-of-file os-error) ())
to allow this particular case to be treated like eof.
The other applications you mention seem unfair comparisons, since the
protocols involved
generally require one side to read all the input from the other before
answering.
(I guess we could program a web server to read GET / and then ignore all
after the / and send a web page
and then close, and see what the browser does.  But then I don't see what
conclusion we'd draw from any answer.)
Since there seems to be some disagreement about whether the read
encountering RST is an eof, I suggest a run time switch (or if you like,
even a special variable that can be bound different ways in different
cases) to determine whether the condition in this case is a subtype of EOF.
 

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

Comment By: Sam Steingold (sds)
Date: 2011-04-11 14:09

Message:
>So you adopt the position that an error number defines a condition. 
>Is there any justification for this?

CLISP is built on top of the API provided by the kernel (linux &
windows).
Both l.&w. define their errors in terms of errnos.
What you require is the following:
(define-condition os-error (error) (($errno :initarg :errno :reader
of-error-number)))
(define-condition connection-reset-on-input (end-of-file os-error) ())
(define-condition connection-reset-on-output (os-error) ())
(define-condition connection-reset-other (os-error) ())
and 3 such conditions for each socket errno.
I think this is an overkill.

As for use cases: do socket applications out there treat ECONNRESET
the same way they treat a routine EOF? E.g,, mozilla? ftp?

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

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-12 11:11

Message:
cll seems to agree with me: ECONNRESET is a stream-error
 (as it is now in clisp) but _not_ an end-of-file (as you want).
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/6f3e239e147663ea

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

Comment By: Don Cohen (donc)
Date: 2011-04-11 14:34

Message:
I would like to see all of the errors that are intuitively stream errors to
be be classified that way.
I don't think I am trying to require any where near as many conditions as
you suggest.
At this point I only really want to argue for one,
(define-condition connection-reset-on-input (end-of-file os-error) ())
to allow this particular case to be treated like eof.
The other applications you mention seem unfair comparisons, since the
protocols involved
generally require one side to read all the input from the other before
answering.
(I guess we could program a web server to read GET / and then ignore all
after the / and send a web page
and then close, and see what the browser does.  But then I don't see what
conclusion we'd draw from any answer.)
Since there seems to be some disagreement about whether the read
encountering RST is an eof, I suggest a run time switch (or if you like,
even a special variable that can be bound different ways in different
cases) to determine whether the condition in this case is a subtype of EOF.
 

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

Comment By: Sam Steingold (sds)
Date: 2011-04-11 10:09

Message:
>So you adopt the position that an error number defines a condition. 
>Is there any justification for this?

CLISP is built on top of the API provided by the kernel (linux &
windows).
Both l.&w. define their errors in terms of errnos.
What you require is the following:
(define-condition os-error (error) (($errno :initarg :errno :reader
of-error-number)))
(define-condition connection-reset-on-input (end-of-file os-error) ())
(define-condition connection-reset-on-output (os-error) ())
(define-condition connection-reset-other (os-error) ())
and 3 such conditions for each socket errno.
I think this is an overkill.

As for use cases: do socket applications out there treat ECONNRESET
the same way they treat a routine EOF? E.g,, mozilla? ftp?

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

Comment By: Don Cohen (donc)
Date: 2011-04-08 01: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 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-cvs Digest, Vol 59, Issue 8

[<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: win32msvc/nsis/install.nsi: Fix start menu item not
      being... (cli...@li...)
   2. clisp: do not mention tests/econnreset.lisp
      (cli...@li...)


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

Message: 1
Date: Mon, 11 Apr 2011 17:13:36 +0000
From: cli...@li...
Subject: clisp: win32msvc/nsis/install.nsi: Fix start menu item not
	being...
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/c4b8ef9b24a7
changeset: 15336:c4b8ef9b24a784cb2de598a19998a846556dfad5
user:      Elliott Slaughter <ell...@gm...>
date:      2011-04-10 22:20:47 -0700
description:
win32msvc/nsis/install.nsi: Fix start menu item not being deteled on Win 7.

diffstat:

 win32msvc/nsis/install.nsi |  3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)



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

Message: 2
Date: Mon, 11 Apr 2011 18:07:07 +0000
From: cli...@li...
Subject: clisp: do not mention tests/econnreset.lisp
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/4f86fb7679b8
changeset: 15337:4f86fb7679b808834162c76eb28f9f7f007d1db4
user:      Sam Steingold <sd...@po...>
date:      2011-04-11 14:06:22 -0400
description:
do not mention tests/econnreset.lisp

diffstat:

 doc/impext.xml |  8 +++-----
 1 files changed, 3 insertions(+), 5 deletions(-)



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

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo

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

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


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

New Danish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the Danish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/da.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

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

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

> * Don Cohen <qba...@vf...> [2011-04-11 13:08:45 -0700]:
>
> Sam Steingold writes:
>  > > * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]:
>  > >
>  > > My first suggested patch would be to move this statement close to the
>  > > top of the doc.
>  > >   This is the interface to select (on some platforms, poll) ...
>  > 
>  > we specify the underlying posix call at the _end_ of the docs for
>  > each function.
>
> The meaning of :error is hard to describe without referring to select.
> Are forward references allowed?

yes, this is lisp, not ML.

>  > > What counts as a pending error?  RST?  EOF?
>  > RST is an error; EOF is not.
> In that case, rst should cause socket-status to return :error, right?

I agree.

>  > This is best discussed on comp.protocols.tcp-ip
>  > Please _do_ take this discussion there, and report back with your findings.
>
> I don't think this is a tcp question.  I think it's more like posix.
> Or perhaps even more specific, linux, windows, etc.

Whatever.  This is certainly not a clisp question.
I am sure comp.protocols.tcp-ip people will either answer the
question straight away, or tell you where to ask.

>  > again, comp.protocols.tcp-ip is your friend.
>  > the translation for them:
>  > - why does select() return -1 and set errno=ECONNRESET instead of
>  > returning the socket in the errorfds set?
> Again, this is not related to tcp (or ip), but to the OS interface.

make your choice.

> BTW, is windows supposed to be posix compliant?

yes, if you buy a posix compatibility layer :-)

> > RFC793 describes situations when the recipient of RST goes into LISTEN
> > and not ABORT states.
>
> Perhaps we should not use the term "socket" here but "connection".
> When you go into listen state you're looking for requests to start
> new connections.  Another request to start a connection on the same
> socket may succeed, even from the same port on the same peer ip
> address, but it will be a new connection.  You're supposed to send a
> reset for a connection when that connection, as far as you are
> concerned, is already dead, or never existed to begin with.

Ah, this is highly illuminating.  Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X
http://www.PetitionOnline.com/tap12009/ http://palestinefacts.org
http://memri.org http://jihadwatch.org http://mideasttruth.com
Live Lisp and prosper.

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

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

Sam Steingold writes:
 > > * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]:
 > >
 > > My first suggested patch would be to move this statement close to the
 > > top of the doc.
 > >   This is the interface to select (on some platforms, poll) ...
 > 
 > we specify the underlying posix call at the _end_ of the docs for
 > each function.

The meaning of :error is hard to describe without referring to select.
Are forward references allowed?

 > > http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful
 > > here.  It says
 > >
 > >   If a socket has a pending error, it shall be considered to have an
 > >   exceptional condition pending. Otherwise, what constitutes an
 > > What counts as a pending error?  RST?  EOF?
 > 
 > RST is an error; EOF is not.
In that case, rst should cause socket-status to return :error, right?

 > >   exceptional condition is file type-specific. For a file descriptor for
 > >   use with a socket, it is protocol-specific except as noted below. For
 > >   other file types it is implementation-defined.
 > > And then below:
 > >   A socket shall be considered to have an exceptional condition
 > >   pending if [...  out-of-band data is pending]
 > > (I don't think I've ever even heard of the OOB feature being used.)
 > >   Other circumstances under which a socket may be considered to have
 > >   an exceptional condition pending are protocol-specific and
 > >   implementation-defined.
 > >
 > > So I still have no ideas how to cause socket-status to return :error
 > > other than possibly trying to send OOB data.
 > > If any are known or discovered, I'd appreciate some mention of them
 > > in impnotes, and if none are known, it might be worth mentioning that
 > > as well.
 > 
 > This is best discussed on comp.protocols.tcp-ip
 > Please _do_ take this discussion there, and report back with your findings.

I don't think this is a tcp question.  I think it's more like posix.
Or perhaps even more specific, linux, windows, etc.

 > > Also, it occurs to me to ask about this statement:
 > >   Additionally, for a SOCKET:SOCKET-STREAM, we define status in the
 > >   given direction (one of :INPUT, :OUTPUT, and :IO) to be
 > > Does all this apply as well to other (non-socket) streams?
 > > If you're just calling select, I'd expect so.  In which case the
 > > statement should be generalized.
 > 
 > we already say at the end of the doc that this is applicable to any
 > FD-based stream.
That's not a good excuse for the text above to be misleadingly over
specific. 

 > >  Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens
 > >  if the SOCKET:SOCKET-STREAM receives an RST packet, see
 > >  tests/econnreset.lisp. 
 > > This seems weird.
 > > After the reset I get:
 > >  [45]> (socket-status s)
 > >
 > >  [../src/stream.d:6196] 
 > >  *** - UNIX error 104 (ECONNRESET): Connection reset by peer
 > >  The following restarts are available:
 > >  ABORT          :R1      Abort main loop
 > >
 > > but then 
 > >  Break 1 [46]> (socket-status s)
 > >  :APPEND ;
 > >  1
 > >  Break 1 [46]> 
 > >
 > > I'd have expected that the two successive calls (with no activity on
 > > the socket in between) would have acted the same.
 > 
 > again, comp.protocols.tcp-ip is your friend.
 > the translation for them:
 > - why does select() return -1 and set errno=ECONNRESET instead of
 > returning the socket in the errorfds set?
Again, this is not related to tcp (or ip), but to the OS interface.
BTW, is windows supposed to be posix compliant?  (I assume linux is?)

 > >  > 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.
 > >
 > > Is "completely and terminally dead" supposed to be a technical term?
 > 
 > what I mean is that no communication will ever be possible over the
 > socket.
 > 
 > > It is clear that after a reset you can't get more input or send more
 > > output on the stream.
 > 
 > It is not obvious to me.
 > RFC793 describes situations when the recipient of RST goes into LISTEN
 > and not ABORT states.

Perhaps we should not use the term "socket" here but "connection".
When you go into listen state you're looking for requests to start
new connections.  Another request to start a connection on the same
socket may succeed, even from the same port on the same peer ip
address, but it will be a new connection.  You're supposed to send a
reset for a connection when that connection, as far as you are
concerned, is already dead, or never existed to begin with.

[ 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-11 18:34

Message:
I would like to see all of the errors that are intuitively stream errors to
be be classified that way.
I don't think I am trying to require any where near as many conditions as
you suggest.
At this point I only really want to argue for one,
(define-condition connection-reset-on-input (end-of-file os-error) ())
to allow this particular case to be treated like eof.
The other applications you mention seem unfair comparisons, since the
protocols involved
generally require one side to read all the input from the other before
answering.
(I guess we could program a web server to read GET / and then ignore all
after the / and send a web page
and then close, and see what the browser does.  But then I don't see what
conclusion we'd draw from any answer.)
Since there seems to be some disagreement about whether the read
encountering RST is an eof, I suggest a run time switch (or if you like,
even a special variable that can be bound different ways in different
cases) to determine whether the condition in this case is a subtype of EOF.
 

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

Comment By: Sam Steingold (sds)
Date: 2011-04-11 14:09

Message:
>So you adopt the position that an error number defines a condition. 
>Is there any justification for this?

CLISP is built on top of the API provided by the kernel (linux &
windows).
Both l.&w. define their errors in terms of errnos.
What you require is the following:
(define-condition os-error (error) (($errno :initarg :errno :reader
of-error-number)))
(define-condition connection-reset-on-input (end-of-file os-error) ())
(define-condition connection-reset-on-output (os-error) ())
(define-condition connection-reset-other (os-error) ())
and 3 such conditions for each socket errno.
I think this is an overkill.

As for use cases: do socket applications out there treat ECONNRESET
the same way they treat a routine EOF? E.g,, mozilla? ftp?

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

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

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

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

> * Don Cohen <qba...@vf...> [2011-04-11 10:31:12 -0700]:
>
> My first suggested patch would be to move this statement close to the
> top of the doc.
>   This is the interface to select (on some platforms, poll) ...

we specify the underlying posix call at the _end_ of the docs for each function.

> http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful
> here.  It says
>
>   If a socket has a pending error, it shall be considered to have an
>   exceptional condition pending. Otherwise, what constitutes an
> What counts as a pending error?  RST?  EOF?

RST is an error; EOF is not.

>   exceptional condition is file type-specific. For a file descriptor for
>   use with a socket, it is protocol-specific except as noted below. For
>   other file types it is implementation-defined.
> And then below:
>   A socket shall be considered to have an exceptional condition
>   pending if [...  out-of-band data is pending]
> (I don't think I've ever even heard of the OOB feature being used.)
>   Other circumstances under which a socket may be considered to have
>   an exceptional condition pending are protocol-specific and
>   implementation-defined.
>
> So I still have no ideas how to cause socket-status to return :error
> other than possibly trying to send OOB data.
> If any are known or discovered, I'd appreciate some mention of them
> in impnotes, and if none are known, it might be worth mentioning that
> as well.

This is best discussed on comp.protocols.tcp-ip
Please _do_ take this discussion there, and report back with your findings.

> Also, it occurs to me to ask about this statement:
>   Additionally, for a SOCKET:SOCKET-STREAM, we define status in the
>   given direction (one of :INPUT, :OUTPUT, and :IO) to be
> Does all this apply as well to other (non-socket) streams?
> If you're just calling select, I'd expect so.  In which case the
> statement should be generalized.

we already say at the end of the doc that this is applicable to any
FD-based stream.

>  Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens
>  if the SOCKET:SOCKET-STREAM receives an RST packet, see
>  tests/econnreset.lisp. 
> This seems weird.
> After the reset I get:
>  [45]> (socket-status s)
>
>  [../src/stream.d:6196] 
>  *** - UNIX error 104 (ECONNRESET): Connection reset by peer
>  The following restarts are available:
>  ABORT          :R1      Abort main loop
>
> but then 
>  Break 1 [46]> (socket-status s)
>  :APPEND ;
>  1
>  Break 1 [46]> 
>
> I'd have expected that the two successive calls (with no activity on
> the socket in between) would have acted the same.

again, comp.protocols.tcp-ip is your friend.
the translation for them:
- why does select() return -1 and set errno=ECONNRESET instead of
returning the socket in the errorfds set?

>  > 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.
>
> Is "completely and terminally dead" supposed to be a technical term?

what I mean is that no communication will ever be possible over the
socket.

> It is clear that after a reset you can't get more input or send more
> output on the stream.

It is not obvious to me.
RFC793 describes situations when the recipient of RST goes into LISTEN
and not ABORT states.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X
http://dhimmi.com http://ffii.org http://palestinefacts.org
http://pmw.org.il http://iris.org.il http://www.memritv.org
You can have it good, soon or cheap.  Pick two...

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

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

Sam Steingold writes:
 > > * 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
This seems to be closely related to the next msg about error return
from socket-status and doc.

My first suggested patch would be to move this statement close to the
top of the doc.
  This is the interface to select (on some platforms, poll) ...
Then to change
  We define status for a SOCKET:SOCKET-SERVER or a SOCKET:SOCKET-STREAM
  to be :ERROR if any i/o operation will cause an ERROR.
to 
  Socket-status returns :error if select finds an exceptional condition
  pending on any of the argument streams.
(or some other version of that statement that is actually true - this 
is how I interpreted your reply to the doc complaint).

http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful
here.  It says

  If a socket has a pending error, it shall be considered to have an
  exceptional condition pending. Otherwise, what constitutes an
What counts as a pending error?  RST?  EOF?

  exceptional condition is file type-specific. For a file descriptor for
  use with a socket, it is protocol-specific except as noted below. For
  other file types it is implementation-defined.
And then below:
  A socket shall be considered to have an exceptional condition
  pending if [...  out-of-band data is pending]
(I don't think I've ever even heard of the OOB feature being used.)
  Other circumstances under which a socket may be considered to have
  an exceptional condition pending are protocol-specific and
  implementation-defined.

So I still have no ideas how to cause socket-status to return :error
other than possibly trying to send OOB data.
If any are known or discovered, I'd appreciate some mention of them
in impnotes, and if none are known, it might be worth mentioning that
as well.

Also, it occurs to me to ask about this statement:
  Additionally, for a SOCKET:SOCKET-STREAM, we define status in the
  given direction (one of :INPUT, :OUTPUT, and :IO) to be
Does all this apply as well to other (non-socket) streams?
If you're just calling select, I'd expect so.  In which case the
statement should be generalized.

 Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens
 if the SOCKET:SOCKET-STREAM receives an RST packet, see
 tests/econnreset.lisp. 
This seems weird.
After the reset I get:
 [45]> (socket-status s)

 [../src/stream.d:6196] 
 *** - UNIX error 104 (ECONNRESET): Connection reset by peer
 The following restarts are available:
 ABORT          :R1      Abort main loop

but then 
 Break 1 [46]> (socket-status s)
 :APPEND ;
 1
 Break 1 [46]> 

I'd have expected that the two successive calls (with no activity on
the socket in between) would have acted the same.

I guess this is related to the fact that if I try to read this stream
then I get ECONNRESET the first time and EOF the second time, which
I also find weird.  

Does the term "pending error" have something to do with whether the
error has been reported by setting errno before?

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

I guess that depends on what select does in this case, and that seems
depend on what it means for a socket to have a pending error, or else
to be implementation defined.

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

Is "completely and terminally dead" supposed to be a technical term?
It is clear that after a reset you can't get more input or send more
output on the stream.  But the lisp stream is still open, so in that
sense it's not completely dead.

 > > 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?
The append result above comes from fedora 14.  I've not yet tried the
older linux version. 

 > > Is this test supposed to fail in one case and succeed in the other?
 > all tests are always expected to succeed.

    2.26 -(:OUTPUT "foo" :OUTPUT STREAM-ERROR :EOF ERROR :EOF END-OF-FILE)
    2.27 +(:OUTPUT "foo" :OUTPUT STREAM-ERROR NIL ERROR NIL END-OF-FILE)
What does this mean in terms of whether append is considered successful?

 > > [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

Thanks.

Re: Windows installer patch

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

On Mon, Apr 11, 2011 at 7:15 AM, Sam Steingold <sd...@gn...> wrote:

> Hi Elliott,
>
> > * Elliott Slaughter <ryy...@tz...> [2011-04-10 22:25:43
> -0700]:
> >
> > The patch in question fixes the issue with the start menu item not being
> > deleted under Windows Vista and 7 when installed for "Just Me".
>
> please go ahead and push it to sf (you have write access now).
>

Ok, pushed.

please follow these simple guidelines:
>
> - do not create new heads
>
> - pull right before _committing_ & push right after committing to avoid
>  creating "merge" heads.
>
> thanks!
> --
> Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X
> http://jihadwatch.org http://www.PetitionOnline.com/tap12009/
> http://ffii.org
> http://memri.org http://truepeace.org http://dhimmi.com http://iris.org.il
> Let us remember that ours is a nation of lawyers and order.
>



-- 
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: Windows installer patch

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

Hi Elliott,

> * Elliott Slaughter <ryy...@tz...> [2011-04-10 22:25:43 -0700]:
>
> The patch in question fixes the issue with the start menu item not being
> deleted under Windows Vista and 7 when installed for "Just Me".

please go ahead and push it to sf (you have write access now).

please follow these simple guidelines:

- do not create new heads

- pull right before _committing_ & push right after committing to avoid
  creating "merge" heads.

thanks!
-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X
http://jihadwatch.org http://www.PetitionOnline.com/tap12009/ http://ffii.org
http://memri.org http://truepeace.org http://dhimmi.com http://iris.org.il
Let us remember that ours is a nation of lawyers and order.

[ 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-11 10:09

Message:
>So you adopt the position that an error number defines a condition. 
>Is there any justification for this?

CLISP is built on top of the API provided by the kernel (linux &
windows).
Both l.&w. define their errors in terms of errnos.
What you require is the following:
(define-condition os-error (error) (($errno :initarg :errno :reader
of-error-number)))
(define-condition connection-reset-on-input (end-of-file os-error) ())
(define-condition connection-reset-on-output (os-error) ())
(define-condition connection-reset-other (os-error) ())
and 3 such conditions for each socket errno.
I think this is an overkill.

As for use cases: do socket applications out there treat ECONNRESET
the same way they treat a routine EOF? E.g,, mozilla? ftp?

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

Comment By: Don Cohen (donc)
Date: 2011-04-08 01: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 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

Windows installer patch

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

Hi Sam,

I have a patch for the Windows installer and I'm wondering how you'd like me
to provide it to you? Should I "hg export" and email you the patch, or setup
a clone on bitbucket or a similar service so you can pull from my clone? I
suppose you could also give me write access to the main hg repo, although I
obviously don't write patches very often. (Sorry if this information is in
the manual somewhere--I couldn't find it if it was.)

The patch in question fixes the issue with the start menu item not being
deleted under Windows Vista and 7 when installed for "Just Me". The method
used in the fix is explained here:

http://nsis.sourceforge.net/Shortcuts_removal_fails_on_Windows_Vista

-- 
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: Windows installer replaces the PATH variable

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

2011/4/10 Anton Vodonosov <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.
>

I can't seem to reproduce the bug you observed. I also had CLISP 2.48
installed ("just for me") before starting, uninstalled it, and then
installed CLISP 2.49 ("for everyone"). At every step my user and system
PATHs were still intact, and CLISP path got added and removed as expected. I
am also using Windows 7 64-bit, so no difference there.

I'm not exactly sure what to do from here if I can't reproduce the bug...

In the meantime I do have a patch for the other issue I found (regarding the
start menu), but I'll start another thread for that.

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