clisp-devel — closed list for developers and testers

[ clisp-Bugs-3292605 ] new-clx get-property unpacks properties incorrectly on 64bit

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

Bugs item #3292605, was opened at 2011-04-25 12:17
Message generated for change (Comment added) made by dangerousben
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&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: clx
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Spencer (dangerousben)
Assigned to: Bruno Haible (haible)
Summary: new-clx get-property unpacks properties incorrectly on 64bit

Initial Comment:
>From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).'  But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64.  Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine.

This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel

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

Comment By: Ben Spencer (dangerousben)
Date: 2011-04-28 07:34

Message:
I tried to write a simple test case but found that it fails (differently)
both with and without the patch, so I'm pretty confused now :(

> 1. actual_format_return is 32, not 64; value of 64 raises an exception

Yep, sorry, that was a typo.

> what could "padded in the upper 4 bytes" mean? how should it be handled?

I assumed it meant padded with zeroes.  However, having looked more more
closely at the source of xprop, it does:
	    value = * (const unsigned long *) *pointer & 0xffffffff;

Changing the patch to do this didn't help though.  Here's my test case and
results:

(let* ((display (xlib:open-display ""))
       (screen (first (xlib:display-roots display)))
       (window (xlib:create-window :parent (xlib:screen-root screen) :x 0
:y 0 :width 100 :height 100))
       (hints (xlib:make-wm-size-hints :x 1 :y 2 :width 3 :height 4)))
  (setf (xlib:wm-normal-hints window) hints)
  (print hints)
  (print (xlib:wm-normal-hints window)))

Without patch:

#S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL
:USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL
:MIN-HEIGHT NIL :MAX-WIDTH NIL
   :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL
:MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL
   :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) 
#S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL
:USER-SPECIFIED-SIZE-P NIL :X 0 :Y 2 :WIDTH 0 :HEIGHT 4 :MIN-WIDTH NIL
:MIN-HEIGHT NIL :MAX-WIDTH NIL
   :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL
:MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL
   :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) 

With patch:

#S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL
:USER-SPECIFIED-SIZE-P NIL :X 1 :Y 2 :WIDTH 3 :HEIGHT 4 :MIN-WIDTH NIL
:MIN-HEIGHT NIL :MAX-WIDTH NIL
   :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL
:MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL
   :PROGRAM-SPECIFIED-POSITION-P NIL :PROGRAM-SPECIFIED-SIZE-P NIL) 
#S(XLIB:WM-SIZE-HINTS :USER-SPECIFIED-POSITION-P NIL
:USER-SPECIFIED-SIZE-P NIL :X 2 :Y 4 :WIDTH 0 :HEIGHT 0 :MIN-WIDTH NIL
:MIN-HEIGHT NIL :MAX-WIDTH NIL
   :MAX-HEIGHT NIL :WIDTH-INC NIL :HEIGHT-INC NIL :MIN-ASPECT NIL
:MAX-ASPECT NIL :BASE-WIDTH NIL :BASE-HEIGHT NIL :WIN-GRAVITY NIL
   :PROGRAM-SPECIFIED-POSITION-P T :PROGRAM-SPECIFIED-SIZE-P T) 

Your test code works (or at least runs without error) both with and
without the patch on my system.


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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 21:05

Message:
1. actual_format_return is 32, not 64; value of 64 raises an exception
(NOTREACHED)
2. the text you are quoting comes from
http://www.x.org/releases/X11R7.5/doc/man/man3/XGetWindowProperty.3.html
and
http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml
which say:
"If the returned format is 32, the property data will be stored as an
array of longs (which in a 64-bit application will be 64-bit values that
are padded in the upper 4 bytes)."
what could "padded in the upper 4 bytes" mean? how should it be handled?

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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 20:39

Message:
at any rate, on my 64-bit linux box, the following works without the patch
and breaks with it:

(xlib:with-open-display (dpy)
  (dolist (screen (xlib:display-roots dpy))
    (dolist (window (xlib:query-tree (xlib:screen-root screen)))
      (multiple-value-bind (data type format bytes-after)
          (xlib:get-property window :WM_NORMAL_HINTS)
        (when data
          (assert (eq type :WM_SIZE_HINTS))
          (assert (= format 32))
          (assert (= bytes-after 0))
          (assert (= (length data) 18))
          (print (list (xlib:wm-name window) data))
          (print (xlib:wm-normal-hints window)))))))

("Firefox"
 (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144
  4294862672 4294862752 2872256880 6587458)) 
*** - AREF: index 6587458 for
       #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST
:SOUTH-WEST
         :SOUTH :SOUTH-EAST :STATIC)
      is out of range


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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 17:08

Message:
thanks for the patch. do you have a test case?
The reason I am asking is that I am not quite sure it is quite correct.
(specifically, make_uint32(unsigned long) should be UL_to_I)

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

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

Re: Windows installer replaces the PATH variable

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

On Wed, Apr 27, 2011 at 8:51 AM, Sam Steingold <sd...@gn...> wrote:

> > * Elliott Slaughter <ryy...@tz...> [2011-04-26 10:55:34
> -0700]:
> > On Mon, Apr 25, 2011 at 2:44 AM, Anton Vodonosov <avo...@ya...
> >wrote:
> >>
> >> 25.04.2011, 07:49, "Elliott Slaughter" <ell...@gm...>:
> >> >
> >> > Anton, could you try this fix?
> >> > http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix2.exe
> >>
> >> Works for me. Thanks.
> >
> > Ok, should be fixed in Mercurial now.
>
> Thanks. However, you forgot to add the ChangeLog entry.
> You need to massage it into your patch (rather than make a separate
> commit).
> Specifically, you need to
> - roll back your change in your repo
> - apply the patch
> - add the ChangeLog entry
> - commit
> - push
> this will work because I am about to roll back your change in the SF repo.
>

Ok, done. Let me know if there is anything else that needs fixing.

-- 
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: division by zero in new-clx

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

> * Shawn Betts <fn...@tz...> [2009-08-25 21:07:31 -0700]:
>
> A user reports that mplayer 1.3 crashes stumpwm. The backtrace
> revealed a problem in decode-wm-size-hints. Here's the call, taken
> from that backtrace, that breaks new-clx.
>
> (xlib::decode-wm-size-hints #(924 0 528 0 349 0 624 0 352 0 4 0 4 0 0 0 0 0))
>
> It seems mplayer uses 0,0 for the max aspect ratio to mean that there
> is no max aspect ratio.

cf bug https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&group_id=1355

I suspect that Ben Spencer is right and, indeed, we need to fix
XLIB:GET-PROPERTY.
Alas, the appended patch bombs with

bad gravity: 6587458

when I try to get window size hints for _all_ windows with

(xlib:with-open-display (dpy)
  (dolist (screen (xlib:display-roots dpy))
    (dolist (window (xlib:query-tree (xlib:screen-root screen)))
      (multiple-value-bind (data type format bytes-after)
          (xlib:get-property window :WM_NORMAL_HINTS)
        (when data
          (assert (eq type :WM_SIZE_HINTS))
          (assert (= format 32))
          (assert (= bytes-after 0))
          (assert (= (length data) 18))
          (print (list (xlib:wm-name window) data))
          (print (xlib:wm-normal-hints window)))))))

which means that somehow gravity is specified incorrectly.

Any insights?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://memri.org http://truepeace.org http://iris.org.il
http://mideasttruth.com http://ffii.org http://thereligionofpeace.com
Genius is immortal, but morons live longer.


diff -r c0d8b51788b8 modules/clx/new-clx/clx.f
--- a/modules/clx/new-clx/clx.f	Tue Apr 26 00:21:41 2011 -0700
+++ b/modules/clx/new-clx/clx.f	Wed Apr 27 18:21:12 2011 -0400
@@ -415,6 +415,7 @@ For further for grepability I use the fo
 #include "clisp.h"
 #include <X11/Xlib.h>
 #include <X11/Xutil.h>          /* XGetVisualInfo */
+#include <X11/Xatom.h>
 #include <X11/Xcms.h>   /* forXcmsCCCOfColormap() & XcmsVisualOfCCC() */
 #include <X11/Xauth.h>
 /* #include <X11/Xresource.h> */
@@ -5509,10 +5510,15 @@ DEFUN(XLIB:GET-PROPERTY,window property 
         if (boundp(*transform_f))
           pushSTACK(*transform_f); /* transform function .. */
 
+        /* http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml */
         switch (actual_format_return) {
-          case  8: pushSTACK(make_uint8(prop_return[i])); break;
-          case 16: pushSTACK(make_uint16(((uint16*)prop_return)[i])); break;
-          case 32: pushSTACK(make_uint32(((uint32*)prop_return)[i])); break;
+          case  8: /* the returned data is represented as a char array */
+            pushSTACK(fixnum(((char*)prop_return)[i])); break;
+          case 16: /* array of short int type and should be cast to that type */
+            pushSTACK(fixnum(((short*)prop_return)[i])); break;
+          case 32: /* array of longs (which in a 64-bit application will be
+                      64-bit values that are padded in the upper 4 bytes). */
+            pushSTACK(L_to_I(((long*)prop_return)[i])); break;
           default:
             NOTREACHED;
         }
@@ -5526,6 +5532,50 @@ DEFUN(XLIB:GET-PROPERTY,window property 
       pushSTACK(value1);
     }
 
+    if (actual_type_return == XA_WM_SIZE_HINTS) {
+        XSizeHints h;
+        long supplied_return = 0;
+        memset(&h,0,sizeof(h));
+        Status s = XGetWMSizeHints(display,w,&h,&supplied_return,property);
+        if (actual_format_return != 32) {
+            fprintf(stderr,"\nbad actual_format_return=%d\n",actual_format_return);
+            abort();
+        }
+        if (s == 0) {
+            fprintf(stderr,"\nXGetWMSizeHints failed\n");
+            abort();
+        }
+        if (nitems_return != 18) {
+            fprintf(stderr,"\nnitems_return=%d\n",nitems_return);
+            abort();
+        }
+        fprintf(stderr,"\nflags=%d  supplied_return=%d\n",h.flags,supplied_return); fflush(stderr);
+        ASSERT(h.flags == ((long*)prop_return)[0]);
+        ASSERT(h.x == ((long*)prop_return)[1]);
+        ASSERT(h.y == ((long*)prop_return)[2]);
+        ASSERT(h.width == ((long*)prop_return)[3]);
+        ASSERT(h.height == ((long*)prop_return)[4]);
+        ASSERT(h.min_width == ((long*)prop_return)[5]);
+        ASSERT(h.min_height == ((long*)prop_return)[6]);
+        ASSERT(h.max_width == ((long*)prop_return)[7]);
+        ASSERT(h.max_height == ((long*)prop_return)[8]);
+        ASSERT(h.width_inc == ((long*)prop_return)[9]);
+        ASSERT(h.height_inc == ((long*)prop_return)[10]);
+        ASSERT(h.min_aspect.x == ((long*)prop_return)[11]);
+        ASSERT(h.min_aspect.y == ((long*)prop_return)[12]);
+        ASSERT(h.max_aspect.x == ((long*)prop_return)[13]);
+        ASSERT(h.max_aspect.y == ((long*)prop_return)[14]);
+        ASSERT(h.base_width == ((long*)prop_return)[15]);
+        ASSERT(h.base_height == ((long*)prop_return)[16]);
+        ASSERT(h.win_gravity == ((long*)prop_return)[17]);
+        if (h.flags & PWinGravity
+            && (h.win_gravity > StaticGravity
+                || h.win_gravity < ForgetGravity)) {
+            fprintf(stderr,"\nbad gravity: %d\n",h.win_gravity);
+            abort();
+        }
+    }
+
     if (prop_return)
       X_CALL(XFree (prop_return));
 

[ clisp-Bugs-3292605 ] new-clx get-property unpacks properties incorrectly on 64bit

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

Bugs item #3292605, was opened at 2011-04-25 07:17
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&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: clx
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Spencer (dangerousben)
Assigned to: Bruno Haible (haible)
Summary: new-clx get-property unpacks properties incorrectly on 64bit

Initial Comment:
>From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).'  But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64.  Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine.

This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-27 16:05

Message:
1. actual_format_return is 32, not 64; value of 64 raises an exception
(NOTREACHED)
2. the text you are quoting comes from
http://www.x.org/releases/X11R7.5/doc/man/man3/XGetWindowProperty.3.html
and
http://www.x.org/releases/X11R7.6/doc/man/man3/XChangeProperty.3.xhtml
which say:
"If the returned format is 32, the property data will be stored as an
array of longs (which in a 64-bit application will be 64-bit values that
are padded in the upper 4 bytes)."
what could "padded in the upper 4 bytes" mean? how should it be handled?

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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 15:39

Message:
at any rate, on my 64-bit linux box, the following works without the patch
and breaks with it:

(xlib:with-open-display (dpy)
  (dolist (screen (xlib:display-roots dpy))
    (dolist (window (xlib:query-tree (xlib:screen-root screen)))
      (multiple-value-bind (data type format bytes-after)
          (xlib:get-property window :WM_NORMAL_HINTS)
        (when data
          (assert (eq type :WM_SIZE_HINTS))
          (assert (= format 32))
          (assert (= bytes-after 0))
          (assert (= (length data) 18))
          (print (list (xlib:wm-name window) data))
          (print (xlib:wm-normal-hints window)))))))

("Firefox"
 (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144
  4294862672 4294862752 2872256880 6587458)) 
*** - AREF: index 6587458 for
       #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST
:SOUTH-WEST
         :SOUTH :SOUTH-EAST :STATIC)
      is out of range


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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 12:08

Message:
thanks for the patch. do you have a test case?
The reason I am asking is that I am not quite sure it is quite correct.
(specifically, make_uint32(unsigned long) should be UL_to_I)

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

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

[ clisp-Bugs-3292605 ] new-clx get-property unpacks properties incorrectly on 64bit

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

Bugs item #3292605, was opened at 2011-04-25 07:17
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&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: clx
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Spencer (dangerousben)
Assigned to: Bruno Haible (haible)
Summary: new-clx get-property unpacks properties incorrectly on 64bit

Initial Comment:
>From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).'  But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64.  Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine.

This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-27 15:39

Message:
at any rate, on my 64-bit linux box, the following works without the patch
and breaks with it:

(xlib:with-open-display (dpy)
  (dolist (screen (xlib:display-roots dpy))
    (dolist (window (xlib:query-tree (xlib:screen-root screen)))
      (multiple-value-bind (data type format bytes-after)
          (xlib:get-property window :WM_NORMAL_HINTS)
        (when data
          (assert (eq type :WM_SIZE_HINTS))
          (assert (= format 32))
          (assert (= bytes-after 0))
          (assert (= (length data) 18))
          (print (list (xlib:wm-name window) data))
          (print (xlib:wm-normal-hints window)))))))

("Firefox"
 (532 0 0 635674972 0 0 0 0 0 4586067 10117896 18 4294862976 10121144
  4294862672 4294862752 2872256880 6587458)) 
*** - AREF: index 6587458 for
       #(:UNMAP :NORTH-WEST :NORTH :NORTH-EAST :WEST :CENTER :EAST
:SOUTH-WEST
         :SOUTH :SOUTH-EAST :STATIC)
      is out of range


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

Comment By: Sam Steingold (sds)
Date: 2011-04-27 12:08

Message:
thanks for the patch. do you have a test case?
The reason I am asking is that I am not quite sure it is quite correct.
(specifically, make_uint32(unsigned long) should be UL_to_I)

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

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

[ clisp-Bugs-3292605 ] new-clx get-property unpacks properties incorrectly on 64bit

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

Bugs item #3292605, was opened at 2011-04-25 07:17
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&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: clx
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Spencer (dangerousben)
Assigned to: Bruno Haible (haible)
Summary: new-clx get-property unpacks properties incorrectly on 64bit

Initial Comment:
>From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).'  But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64.  Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine.

This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-27 12:08

Message:
thanks for the patch. do you have a test case?
The reason I am asking is that I am not quite sure it is quite correct.
(specifically, make_uint32(unsigned long) should be UL_to_I)

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

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

Re: Windows installer replaces the PATH variable

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

> * Elliott Slaughter <ryy...@tz...> [2011-04-26 10:55:34 -0700]:
> On Mon, Apr 25, 2011 at 2:44 AM, Anton Vodonosov <avo...@ya...>wrote:
>>
>> 25.04.2011, 07:49, "Elliott Slaughter" <ell...@gm...>:
>> >
>> > Anton, could you try this fix?
>> > http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix2.exe
>>
>> Works for me. Thanks.
>
> Ok, should be fixed in Mercurial now.

Thanks. However, you forgot to add the ChangeLog entry.
You need to massage it into your patch (rather than make a separate commit).
Specifically, you need to
- roll back your change in your repo
- apply the patch
- add the ChangeLog entry
- commit
- push
this will work because I am about to roll back your change in the SF repo.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031
http://iris.org.il http://camera.org http://truepeace.org
http://www.memritv.org http://openvotingconsortium.org http://memri.org
Let us remember that ours is a nation of lawyers and order.

Re: Windows installer replaces the PATH variable

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

On Mon, Apr 25, 2011 at 2:44 AM, Anton Vodonosov <avo...@ya...>wrote:

>
>
> 25.04.2011, 07:49, "Elliott Slaughter" <ell...@gm...>:
> >
> > Anton, could you try this fix?
> > http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix2.exe
>
> Works for me. Thanks.
>

Ok, should be fixed in Mercurial now.

-- 
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-cvs Digest, Vol 59, Issue 14

[<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: Fixes for Windows installer PATH bug.
      (cli...@li...)


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

Message: 1
Date: Tue, 26 Apr 2011 07:21:57 +0000
From: cli...@li...
Subject: clisp: Fixes for Windows installer PATH bug.
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/c0d8b51788b8
changeset: 15355:c0d8b51788b89044a9084f014b5f7feaec19d043
user:      Elliott Slaughter <ell...@gm...>
date:      2011-04-26 00:21:41 -0700
description:
Fixes for Windows installer PATH bug.

diffstat:

 src/makemake.in                   |    4 +-
 win32msvc/nsis/add_to_path.nsh    |  245 ------------------------------
 win32msvc/nsis/env_var_update.nsh |  327 ++++++++++++++++++++++++++++++++++++++++
 win32msvc/nsis/install.nsi        |   40 ++++-
 4 files changed, 364 insertions(+), 252 deletions(-)



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

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd

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

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


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

[ clisp-Bugs-3292605 ] new-clx get-property unpacks properties incorrectly on 64bit

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

Bugs item #3292605, was opened at 2011-04-25 12:17
Message generated for change (Tracker Item Submitted) made by dangerousben
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3292605&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: clx
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ben Spencer (dangerousben)
Assigned to: Bruno Haible (haible)
Summary: new-clx get-property unpacks properties incorrectly on 64bit

Initial Comment:
>From the XGetWindowProperty man page: 'If the returned format is 32, the property data will be stored as an array of longs (which in a 64-bit application will be 64-bit values that are padded in the upper 4 bytes).'  But XLIB:GET-PROPERTY casts prop_return to a uint32 when actual_format is 64.  Attached patch casts it to long instead, which fixes the issue at least on my amd64 machine.

This was the ultimate cause of the issue described here (and explains why other clx implementations were apparently unaffected): http://sourceforge.net/mailarchive/forum.php?thread_name=4A954322.80106%40gnu.org&forum_name=clisp-devel

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

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

Re: Windows installer replaces the PATH variable

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

25.04.2011, 07:49, "Elliott Slaughter" <ell...@gm...>:
>
> Anton, could you try this fix?
> http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix2.exe

Works for me. Thanks.

Best regards,
- Anton

Re: Windows installer replaces the PATH variable

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

On Thu, Apr 21, 2011 at 1:11 AM, Anton Vodonosov <avo...@ya...>wrote:

>
>
> 21.04.2011, 11:20, "Elliott Slaughter" <ell...@gm...>:
>
> > I'm hoping to at least find a way to check dynamically if the string is
> too long and avoid smashing PATH. I don't know if there will be any better
> solution until a new version of NSIS comes out.
>
> An idea: try to set some temporary env variable, and then read it's value.
> It the variable wasn't smashed, then PATH will not be smashed too.
>

Anton, could you try this fix?

http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix2.exe

The installer script is identical to the last attempted fix, but I used the
8192-length-strings version of NSIS.

I decided not to add a dynamic check since past 8192 the Windows command
line breaks anyway. I did add a compile-time check so that we can be sure
the maintainer is using this special version of NSIS.

The fix tested out fine on my machine, but I'll wait for independent
confirmation before pushing the fix.

-- 
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-cvs Digest, Vol 59, Issue 13

[<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: * Makefile.devel (CP): new variable; do _not_ pass
      "-u" s... (cli...@li...)
   2. clisp: * Makefile.devel (LIBTOOL_VERSION): bump to 2.4
      (cli...@li...)
   3. clisp: * Makefile.devel (build-aux-update): get compile &
      ylwrap... (cli...@li...)
   4. clisp: get automake files (compile & ylwrap) from git instead
      of... (cli...@li...)
   5. clisp: * src/places.lisp (setf-VALUES-aux): even if subform
      sets... (cli...@li...)
   6. clisp: add CUSTOM:*ANSI* & EXT:CANONICALIZE
      (cli...@li...)
   7. clisp: delete a file which has never been used
      (cli...@li...)


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

Message: 1
Date: Fri, 22 Apr 2011 19:50:13 +0000
From: cli...@li...
Subject: clisp: * Makefile.devel (CP): new variable; do _not_ pass
	"-u" s...
To: cli...@li...
Message-ID:
	<hg....@vz...>
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/685108084147
changeset: 15348:685108084147e17383cccd9b3f87275b7087f63b
user:      Sam Steingold <sd...@po...>
date:      2011-04-21 10:24:13 -0400
description:
* Makefile.devel (CP): new variable; do _not_ pass "-u" so that
fresh checkouts will not override updating in build-aux-update et al

diffstat:

 Makefile.devel |  18 +++++++++---------
 src/ChangeLog  |   5 +++++
 2 files changed, 14 insertions(+), 9 deletions(-)



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

Message: 2
Date: Fri, 22 Apr 2011 19:50:15 +0000
From: cli...@li...
Subject: clisp: * Makefile.devel (LIBTOOL_VERSION): bump to 2.4
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/cad135c47ed3
changeset: 15349:cad135c47ed3f7d189811433407dda54e1bf46df
user:      Sam Steingold <sd...@po...>
date:      2011-04-21 10:24:32 -0400
description:
* Makefile.devel (LIBTOOL_VERSION): bump to 2.4

diffstat:

 Makefile.devel |  2 +-
 src/ChangeLog  |  1 +
 2 files changed, 2 insertions(+), 1 deletions(-)



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

Message: 3
Date: Fri, 22 Apr 2011 19:50:17 +0000
From: cli...@li...
Subject: clisp: * Makefile.devel (build-aux-update): get compile &
	ylwrap...
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/c80d9eb9343a
changeset: 15350:c80d9eb9343a5309a43f5f37e19747aef10f6611
user:      Sam Steingold <sd...@po...>
date:      2011-04-21 10:35:24 -0400
description:
* Makefile.devel (build-aux-update): get compile & ylwrap from a specific
automake version instead of whatever happens to be currently installed

diffstat:

 Makefile.devel |  12 ++++++++++--
 src/ChangeLog  |   2 ++
 2 files changed, 12 insertions(+), 2 deletions(-)



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

Message: 4
Date: Fri, 22 Apr 2011 19:50:18 +0000
From: cli...@li...
Subject: clisp: get automake files (compile & ylwrap) from git instead
	of...
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/1bea0c5c21cc
changeset: 15351:1bea0c5c21cc924bf1c0a65376b06349ef25a083
user:      Sam Steingold <sd...@po...>
date:      2011-04-21 10:46:08 -0400
description:
get automake files (compile & ylwrap) from git instead of getting the tarball

diffstat:

 Makefile.devel |  26 ++++++++++++--------------
 1 files changed, 12 insertions(+), 14 deletions(-)



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

Message: 5
Date: Fri, 22 Apr 2011 19:50:20 +0000
From: cli...@li...
Subject: clisp: * src/places.lisp (setf-VALUES-aux): even if subform
	sets...
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/7572a450c307
changeset: 15352:7572a450c30795908a221eaaf3981e141528437d
user:      Sam Steingold <sd...@po...>
date:      2011-04-22 15:48:39 -0400
description:
* src/places.lisp (setf-VALUES-aux): even if subform sets no values,
it should consume one assigned value (bug#3291585)

diffstat:

 src/ChangeLog   |   5 +++++
 src/NEWS        |   1 +
 src/places.lisp |  12 ++++++------
 tests/ChangeLog |   4 ++++
 tests/setf.tst  |   6 ++++++
 5 files changed, 22 insertions(+), 6 deletions(-)



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

Message: 6
Date: Fri, 22 Apr 2011 20:15:53 +0000
From: cli...@li...
Subject: clisp: add CUSTOM:*ANSI* & EXT:CANONICALIZE
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/7ba8b8359a44
changeset: 15353:7ba8b8359a4476d266d10fa04eb1f98a45fa85ce
user:      Sam Steingold <sd...@po...>
date:      2011-04-22 16:13:33 -0400
description:
add CUSTOM:*ANSI* & EXT:CANONICALIZE

diffstat:

 doc/Symbol-Table.text |  8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)



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

Message: 7
Date: Fri, 22 Apr 2011 20:55:32 +0000
From: cli...@li...
Subject: clisp: delete a file which has never been used
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/f541c61d44d3
changeset: 15354:f541c61d44d367b02dde9ae75dd7a3b8b4851eeb
user:      Sam Steingold <sd...@po...>
date:      2011-04-22 16:55:14 -0400
description:
delete a file which has never been used

diffstat:

 modules/clx/new-clx/clx-ini.lisp |  20 --------------------
 1 files changed, 0 insertions(+), 20 deletions(-)



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

------------------------------------------------------------------------------
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails

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

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


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

[ clisp-Bugs-3291585 ] (setf (values (values) b c) (...)) misplaces values

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

Bugs item #3291585, was opened at 2011-04-22 14:46
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3291585&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: belovedeagle (belovedeagle)
Assigned to: Sam Steingold (sds)
Summary: (setf (values (values) b c) (...)) misplaces values

Initial Comment:
Clisp 2.48 gives:
(setf (values (values) b c) (values 'x 'y 'z)) => nil; x; y
b => x
c => y
but should be:
(setf ...) => nil; y; z
b => y
c => z

(macroexpand '(setf (values (values) b c) form)) should be roughly the same as (macroexpand '(setf (values (values a) b c) form)) but clisp fails to include a (pop #:values-0000) for the first value place in the former situation:
[9]> (macroexpand '(setf (values (values) b c) form))
(LET*
 ((#:VALUES-2935 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2933 (POP #:VALUES-2935))
  (#:NEW-2934 (POP #:VALUES-2935)))
 (VALUES (VALUES) (SETQ B #:NEW-2933) (SETQ C #:NEW-2934))) ;
T
[10]> (macroexpand '(setf (values (values a) b c) form))
(LET*
 ((#:VALUES-2939 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2936 (POP #:VALUES-2939))
  (#:NEW-2937 (POP #:VALUES-2939)) (#:NEW-2938 (POP #:VALUES-2939)))
 (VALUES (VALUES (SETQ A #:NEW-2936)) (SETQ B #:NEW-2937) (SETQ C #:NEW-2938))) ;
T

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

>Comment By: Sam Steingold (sds)
Date: 2011-04-22 15:53

Message:
note that macroexpand-1 is more instructive in this case...

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

Comment By: Sam Steingold (sds)
Date: 2011-04-22 15:49

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

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

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

[ clisp-Bugs-3291585 ] (setf (values (values) b c) (...)) misplaces values

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

Bugs item #3291585, was opened at 2011-04-22 14:46
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3291585&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: belovedeagle (belovedeagle)
>Assigned to: Sam Steingold (sds)
Summary: (setf (values (values) b c) (...)) misplaces values

Initial Comment:
Clisp 2.48 gives:
(setf (values (values) b c) (values 'x 'y 'z)) => nil; x; y
b => x
c => y
but should be:
(setf ...) => nil; y; z
b => y
c => z

(macroexpand '(setf (values (values) b c) form)) should be roughly the same as (macroexpand '(setf (values (values a) b c) form)) but clisp fails to include a (pop #:values-0000) for the first value place in the former situation:
[9]> (macroexpand '(setf (values (values) b c) form))
(LET*
 ((#:VALUES-2935 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2933 (POP #:VALUES-2935))
  (#:NEW-2934 (POP #:VALUES-2935)))
 (VALUES (VALUES) (SETQ B #:NEW-2933) (SETQ C #:NEW-2934))) ;
T
[10]> (macroexpand '(setf (values (values a) b c) form))
(LET*
 ((#:VALUES-2939 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2936 (POP #:VALUES-2939))
  (#:NEW-2937 (POP #:VALUES-2939)) (#:NEW-2938 (POP #:VALUES-2939)))
 (VALUES (VALUES (SETQ A #:NEW-2936)) (SETQ B #:NEW-2937) (SETQ C #:NEW-2938))) ;
T

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

Comment By: Sam Steingold (sds)
Date: 2011-04-22 15:49

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

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

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

[ clisp-Bugs-3291585 ] (setf (values (values) b c) (...)) misplaces values

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

Bugs item #3291585, was opened at 2011-04-22 14:46
Message generated for change (Tracker Item Submitted) made by belovedeagle
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3291585&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: belovedeagle (belovedeagle)
Assigned to: Bruno Haible (haible)
Summary: (setf (values (values) b c) (...)) misplaces values

Initial Comment:
Clisp 2.48 gives:
(setf (values (values) b c) (values 'x 'y 'z)) => nil; x; y
b => x
c => y
but should be:
(setf ...) => nil; y; z
b => y
c => z

(macroexpand '(setf (values (values) b c) form)) should be roughly the same as (macroexpand '(setf (values (values a) b c) form)) but clisp fails to include a (pop #:values-0000) for the first value place in the former situation:
[9]> (macroexpand '(setf (values (values) b c) form))
(LET*
 ((#:VALUES-2935 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2933 (POP #:VALUES-2935))
  (#:NEW-2934 (POP #:VALUES-2935)))
 (VALUES (VALUES) (SETQ B #:NEW-2933) (SETQ C #:NEW-2934))) ;
T
[10]> (macroexpand '(setf (values (values a) b c) form))
(LET*
 ((#:VALUES-2939 (MULTIPLE-VALUE-LIST FORM)) (#:NEW-2936 (POP #:VALUES-2939))
  (#:NEW-2937 (POP #:VALUES-2939)) (#:NEW-2938 (POP #:VALUES-2939)))
 (VALUES (VALUES (SETQ A #:NEW-2936)) (SETQ B #:NEW-2937) (SETQ C #:NEW-2938))) ;
T

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

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

Re: Windows installer replaces the PATH variable

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

21.04.2011, 11:20, "Elliott Slaughter" <ell...@gm...>:

> I'm hoping to at least find a way to check dynamically if the string is too long and avoid smashing PATH. I don't know if there will be any better solution until a new version of NSIS comes out.

An idea: try to set some temporary env variable, and then read it's value. It the variable wasn't smashed, then PATH will not be smashed too.

Re: Windows installer replaces the PATH variable

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

On Wed, Apr 20, 2011 at 4:58 PM, Elliott Slaughter <
ell...@gm...> wrote:

> On Wed, Apr 20, 2011 at 4:53 PM, Anton Vodonosov <avo...@ya...>wrote:
>
>>
>>
>> 16.04.2011, 11:06, "Elliott Slaughter" <ell...@gm...>:
>> >
>> > Anton,
>> >
>> > Could you please try the following test installers? Since I am unable to
>> reproduce the bug, I can't meaningfully test this on my own.
>> >
>> > Installer (1) below is intended to fix the bug. Installer (2) is a
>> sanity check to make sure the bug is still present when the fix is absent.
>> >
>> > (1) http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix.exe
>> >
>> > (2)
>> http://elliottslaughter.net/files/clisp-2.49+-win32-install-orig.exe
>> >
>> > *Please* back up your PATH (user and system) variables before trying
>> either of the above.
>> >
>> > Note that the actually CLISP that gets installed is quite broken--there
>> is a dll missing, among other things.
>> >
>> > Thanks.
>> >
>> > --
>> > 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
>>
>> Hello Elliott,
>>
>> Both installers replace my PATH.
>>
>> I did some investigations and found the reason. I have very long value of
>> the PATH variable.
>>
>> If the PATH lenght >= 1024 characters, it is replaced by the installer.
>>
>
> Thank you for looking into this.
>
> I'll try to confirm your results and see if I can find a fix.
>

Unfortunately, it looks like the 1024 character limit is built into NSIS.

http://nsis.sourceforge.net/Talk:Environmental_Variables:_append,_prepend,_and_remove_entries

The prescribed solution to get around this is apparently to rebuild NSIS
from source, or use special binaries built. The binaries below set the limit
to 8192 characters.

http://nsis.sourceforge.net/Special_Builds

I don't like this situation at all; among other things it means that the
packager/maintainer needs to know about and use special builds of NSIS.
Also, the script (at least the way it is written right now) has no way of
making sure the builder is using the large string build of NSIS, and an
unsuspecting CLISP packager might accidentally use the normal NSIS build
without knowing. On top of that, the situation could theoretically reappear
(with 8192 length strings instead of 1024), although it might be highly
unlikely.

I'm hoping to at least find a way to check dynamically if the string is too
long and avoid smashing PATH. I don't know if there will be any better
solution until a new version of NSIS comes out.

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

On Wed, Apr 20, 2011 at 4:53 PM, Anton Vodonosov <avo...@ya...>wrote:

>
>
> 16.04.2011, 11:06, "Elliott Slaughter" <ell...@gm...>:
> >
> > Anton,
> >
> > Could you please try the following test installers? Since I am unable to
> reproduce the bug, I can't meaningfully test this on my own.
> >
> > Installer (1) below is intended to fix the bug. Installer (2) is a sanity
> check to make sure the bug is still present when the fix is absent.
> >
> > (1) http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix.exe
> >
> > (2) http://elliottslaughter.net/files/clisp-2.49+-win32-install-orig.exe
> >
> > *Please* back up your PATH (user and system) variables before trying
> either of the above.
> >
> > Note that the actually CLISP that gets installed is quite broken--there
> is a dll missing, among other things.
> >
> > Thanks.
> >
> > --
> > 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
>
> Hello Elliott,
>
> Both installers replace my PATH.
>
> I did some investigations and found the reason. I have very long value of
> the PATH variable.
>
> If the PATH lenght >= 1024 characters, it is replaced by the installer.
>

Thank you for looking into this.

I'll try to confirm your results and see if I can find a fix.

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

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

16.04.2011, 11:06, "Elliott Slaughter" <ell...@gm...>:
>
> Anton,
>
> Could you please try the following test installers? Since I am unable to reproduce the bug, I can't meaningfully test this on my own.
>
> Installer (1) below is intended to fix the bug. Installer (2) is a sanity check to make sure the bug is still present when the fix is absent.
>
> (1) http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix.exe
>
> (2) http://elliottslaughter.net/files/clisp-2.49+-win32-install-orig.exe
>
> *Please* back up your PATH (user and system) variables before trying either of the above.
>
> Note that the actually CLISP that gets installed is quite broken--there is a dll missing, among other things.
>
> Thanks.
>
> --
> 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

Hello Elliott,

Both installers replace my PATH.

I did some investigations and found the reason. I have very long value of the PATH variable.

If the PATH lenght >= 1024 characters, it is replaced by the installer.

Best regards,
- Anton

clisp-cvs Digest, Vol 59, Issue 12

[<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: * configure (makemake_args): when configure detects
      mingw... (cli...@li...)


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

Message: 1
Date: Mon, 18 Apr 2011 15:20:32 +0000
From: cli...@li...
Subject: clisp: * configure (makemake_args): when configure detects
	mingw...
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/2a3830525d34
changeset: 15347:2a3830525d34012562e26400c4665c07ae144732
user:      Sam Steingold <sd...@po...>
date:      2011-04-18 11:19:53 -0400
description:
* configure (makemake_args): when configure detects mingw/msys,
  pass --win32gcc to makemake
Reported by Elliott Slaughter <ell...@gm...>.

diffstat:

 configure     |  3 +++
 src/ChangeLog |  6 ++++++
 2 files changed, 9 insertions(+), 0 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 12
*****************************************

clisp-cvs Digest, Vol 59, Issue 11

[<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: tweak (cli...@li...)
   2. clisp: * src/compiler.lisp (c-LAMBDABODY): issue a
      style-warning... (cli...@li...)
   3. clisp: * src/compiler.lisp (c-GLOBAL-FUNCTION-CALL): issue a
      sty... (cli...@li...)
   4. clisp: (cdr (multiple-value-list (compile nil ...))) -->
      (multip... (cli...@li...)


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

Message: 1
Date: Fri, 15 Apr 2011 17:04:19 +0000
From: cli...@li...
Subject: clisp: tweak
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/3b2bfb7043c6
changeset: 15343:3b2bfb7043c61bd4b1b484b0f741cfc900527a07
user:      Sam Steingold <sd...@po...>
date:      2011-04-14 10:14:47 -0400
description:
tweak

diffstat:

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



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

Message: 2
Date: Fri, 15 Apr 2011 17:04:23 +0000
From: cli...@li...
Subject: clisp: * src/compiler.lisp (c-LAMBDABODY): issue a
	style-warning...
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/b573979456c9
changeset: 15344:b573979456c96da698bac482162eae3429da7142
user:      Sam Steingold <sd...@po...>
date:      2011-04-15 13:03:03 -0400
description:
* src/compiler.lisp (c-LAMBDABODY): issue a style-warning when lambda
list contains both &optional and &key

diffstat:

 doc/impbody.xml   |  15 +++++++++++++++
 src/ChangeLog     |   5 +++++
 src/NEWS          |   4 ++++
 src/compiler.lisp |   3 +++
 tests/macro8.tst  |   1 +
 5 files changed, 28 insertions(+), 0 deletions(-)



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

Message: 3
Date: Fri, 15 Apr 2011 20:02:34 +0000
From: cli...@li...
Subject: clisp: * src/compiler.lisp (c-GLOBAL-FUNCTION-CALL): issue a
	sty...
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/094ac643d551
changeset: 15345:094ac643d551cc9a0f3d9c934fc5062a99efc671
user:      Sam Steingold <sd...@po...>
date:      2011-04-15 16:02:15 -0400
description:
* src/compiler.lisp (c-GLOBAL-FUNCTION-CALL): issue a style-warning when
PARSE-NAMESTRING, MERGE-PATHNAMES, or READ-FROM-STRING, i.e., a function
which accept both &KEY arguments and an even number of &OPTIONAL arguments,
is, apparently, invoked with &KEY but without &OPTIONAL arguments

diffstat:

 src/ChangeLog     |   8 ++++++++
 src/compiler.lisp |  10 ++++++++++
 tests/ChangeLog   |   4 ++++
 tests/macro8.tst  |   3 +++
 4 files changed, 25 insertions(+), 0 deletions(-)



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

Message: 4
Date: Fri, 15 Apr 2011 20:56:59 +0000
From: cli...@li...
Subject: clisp: (cdr (multiple-value-list (compile nil ...))) -->
	(multip...
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/3fe45741d579
changeset: 15346:3fe45741d579f3eab4486b2e65b1cd17310253dd
user:      Sam Steingold <sd...@po...>
date:      2011-04-15 16:28:01 -0400
description:
(cdr (multiple-value-list (compile nil ...))) --> (multiple-value-list (compile 'x ...))

diffstat:

 tests/macro8.tst |  32 ++++++++++++++------------------
 1 files changed, 14 insertions(+), 18 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 11
*****************************************

Re: CLISP 2.49 build error on MinGW

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

On Fri, Apr 15, 2011 at 2:04 PM, Sam Steingold <sd...@gn...> wrote:

> > * Sam Steingold <fq...@ta...> [2011-04-15 15:12:31 -0400]:
> >
> >> * 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)
>
> please try the appended patch instead.
> you need to reconfigure.


Yup, fixed.

Thanks.

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

On Sun, Apr 10, 2011 at 9:37 PM, Elliott Slaughter <
ell...@gm...> wrote:

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

Anton,

Could you please try the following test installers? Since I am unable to
reproduce the bug, I can't meaningfully test this on my own.

Installer (1) below is intended to fix the bug. Installer (2) is a sanity
check to make sure the bug is still present when the fix is absent.

(1) http://elliottslaughter.net/files/clisp-2.49+-win32-install-fix.exe

(2) http://elliottslaughter.net/files/clisp-2.49+-win32-install-orig.exe

*Please* back up your PATH (user and system) variables before trying either
of the above.

Note that the actually CLISP that gets installed is quite broken--there is a
dll missing, among other things.

Thanks.

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

> * Sam Steingold <fq...@ta...> [2011-04-15 15:12:31 -0400]:
>
>> * 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)

please try the appended patch instead.
you need to reconfigure.

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X 11.0.60900031
http://camera.org http://thereligionofpeace.com
http://www.memritv.org http://palestinefacts.org http://jihadwatch.org
Heck is a place for people who don't believe in gosh.


diff -r 3fe45741d579 configure
--- a/configure	Fri Apr 15 16:28:01 2011 -0400
+++ b/configure	Fri Apr 15 17:03:28 2011 -0400
@@ -643,6 +643,9 @@ makemake_args="${makemake_args} ${subdir
 
 test -n "${target}" && target="${target} ${ac_cv_host} ${ac_cv_prog_CC}"
 makemake_args="${makemake_args} ${target} ${debug}";
+case ${ac_cv_host} in
+  *mingw32*)  makemake_args="${makemake_args} --win32gcc" ;;
+esac
 
 test -n "${cl_cv_have_ffcall}" || cl_cv_have_ffcall=notchecked
 cat <<EOF