Subject: [clisp-list] Re: [gmane.lisp.clisp.general] Re: Problems with new-clx xlib:put-image

From: Sam Steingold <[email-masked]>
Date: Thu Sep 25 12:32:02 2003

> * Barry Fishman <[email-masked]> [2003-09-25 11:13:22 -0400]:
>
> > did you see this message on clisp-list?
> 
> >> * Barry Fishman <[email-masked]> [2003-09-20 08:59:36 -0400]:
> >>
> >> Since the last CVS code reorganization my calls to xlib:put-image,
> >> using the new-clx module, do not seem to display the image correctly.
> >> My code works with previous CVS snapshots and with cmu lisp.
> 
> No.  I posted to the newsgroup gmane.lisp.clisp.general and have been
> looking there.

it appears that a bunch of my message to CLISP lists (posted via gmane)
have been lost - I re-sent those I could salvage recently.

> >> I get the right edge of the gremblin along the left edge of the
> >> window, the left edge of the gremblin along the right edge of the
> >> window, and just space in-between.
> 
> > did you try other images?
> 
> I did now.  When I try a larger image, the images look like it is
> shifted to the left with the missing left edge displayed on the right
> side of the image, and random dots along the bottom in the wrapped
> area.
> 
> Playing with the content of the bitmap file, it seems the data being
> displayed starts 4 bytes offset into the ximage.
> 
> I performed the following _ugly_ patch to "modules/clx/new-clx/clx.f"
> and the bitmap images seem to be displayed correctly:
> 
>  *** clx.c	2003-09-25 11:00:33.000000000 -0400
> --- clx.c-patched	2003-09-25 10:54:37.000000000 -0400
> ***************
> *** 6807,6813 ****
>       /* Now fetch data it *must* be a vector of card8 */
>       pushSTACK(STACK_7); funcall (O(object_xlib__image_x_data), 1);
>       if (simple_bit_vector_p (Atype_8Bit, value1)) {
> !       im.data = (char*) &TheSbvector (value1)->data[0];
>       } else {
>         pushSTACK(O(object__28array_20xlib__card8_20_28_2A_29_29));
>         pushSTACK(STACK_8);
> --- 6807,6813 ----
>       /* Now fetch data it *must* be a vector of card8 */
>       pushSTACK(STACK_7); funcall (O(object_xlib__image_x_data), 1);
>       if (simple_bit_vector_p (Atype_8Bit, value1)) {
> !       im.data = (char*) &TheSbvector (value1)->data[-4];
>       } else {
>         pushSTACK(O(object__28array_20xlib__card8_20_28_2A_29_29));
>         pushSTACK(STACK_8);

this is weird.

the xbm file has 220 bytes of data.  the X image data is 352 bytes long.
(to see that, add
  (format t "data (~S):~%~s~%" (type-of (xlib::image-x-data *gremblin*))
          (xlib::image-x-data *gremblin*))
to your MAIN function)
do you know whether this is correct?
apparently some padding is being done - incorrectly.
can you figure out where?
thanks!
-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
nobody's life, liberty or property are safe while the legislature is in session

---

From: Barry Fishman <[email-masked]>
Date: Mon Sep 29 06:24:12 2003

Sam Steingold <[email-masked]> writes:

>> ...

Yes, the size difference is because the line padding is changed from
8 bits to 32, when the file is read into memory.

> can you figure out where?

The data is correct, just 4 bytes off from where TheSvector seems to
think it is.  I don't know enough about CLISP internal structures
to know what is happening.

Its hard counting bits, but the following patch to the CLISP
2.31 release code will print out the image (correctly for
little-endian XImages) to *standard-output*:

============ PATCH ==============
*** clx.f-orig	2003-09-28 11:44:11.000000000 -0400
--- clx.f	2003-09-28 11:41:28.000000000 -0400
***************
*** 4182,4187 ****
--- 4182,4210 ----
    fehler (error, "Sorry, my implementation of XLIB:PUT-IMAGE is still not complete.");
  }
  
+ /* test function to print the contents of the bitmap */
+ void dump_image(XImage *image)
+ {
+    char *row;
+    int x, y;
+    int height = image->height;
+    int width  = image->width;
+    int line_len = image->bytes_per_line;
+ 
+    printf("Dumping image data (%d %d %d):\n", height, width, line_len);
+    for (y = 0; y < height; y++) {
+       printf("|");
+       row = image->data + (y * line_len);
+       for (x = 0; x < width; x++) {
+          if (row[x / 8] & (1 << (x % 8)))
+ 	    printf("*");
+ 	 else
+ 	    printf(" ");
+       }
+       printf("|\n");
+    }
+ }
+ 
  DEFUN(XLIB:PUT-IMAGE, drawable gcontext image \
        &key SRC-X SRC-Y X Y WIDTH HEIGHT BITMAP-P)
  { /* This is a *VERY* silly implementation.
***************
*** 4244,4250 ****
      /* Now fetch data it *must* be a vector of card8 */
      pushSTACK(STACK_7); funcall (`XLIB::IMAGE-X-DATA`, 1);
      if (simple_bit_vector_p (Atype_8Bit, value1)) {
!       im.data = (char*) &TheSbvector (value1)->data[0];
      } else {
        pushSTACK(`(ARRAY XLIB::CARD8 (*))`);
        pushSTACK(STACK_8);
--- 4267,4276 ----
      /* Now fetch data it *must* be a vector of card8 */
      pushSTACK(STACK_7); funcall (`XLIB::IMAGE-X-DATA`, 1);
      if (simple_bit_vector_p (Atype_8Bit, value1)) {
!       im.data = (char*) &TheSbvector (value1)->data[-4]; /* Was: [0]; */
! #if 1
!       dump_image(&im);  /* Lets look at what we have */
! #endif
      } else {
        pushSTACK(`(ARRAY XLIB::CARD8 (*))`);
        pushSTACK(STACK_8);
============ END OF patch ===========

Sorry, I had problems with attachments before and don't want to test
using them now.

My test program (which I did not post to the group before) and can
also output the lisp image to *standard-output* is:

======= badcase.lisp
#! /usr/local/bin/clisp -K full
;;;; badcase.lisp - simple load bitmap into window
;;;; $Id: badcase.lisp,v 1.3 2003/09/27 20:35:12 barry Exp $

;;;; Commentary
;;;    Simple hack to load a bitmap into a window using an XImage.

#+:cmu
(require :clx)
#+:cmu
(defvar *ARGS* nil)

;(load "clx-fix")

;;; Keep general x connection info global
(defparameter *display* nil
  "X11 Display object when connection is active.")
(defparameter *screen* nil
  "X11 Screen object when connection is active.")
(defparameter *root* nil
  "Root window on display when connection is active.")
(defparameter *gremblin* nil
  "Image displayed in window")

(defun open-x-display ()
  "Open default \":0.0\" display"
  (setf *display* (xlib:open-display "" :display 0))
  (setf *screen*  (car (xlib:display-roots *display*)))
  (setf *root*    (xlib:screen-root *screen*))
  (unless *root*
    (error "Failed to open display~%"))
  *root*)

(defun close-x-display ()
  (xlib:close-display *display*)
  (setf *display* nil))

(defun show-image (win gcon image)
  "Display image.  Called on exposure events."
  ;; (format t "-- Exposure --~%")
  (xlib:put-image win gcon image :x 0 :y 0
		  :width (xlib:image-width image)
		  :height (xlib:image-height image)
		  :bitmap-p t)
  (xlib:display-force-output *display*))

(defun handle-events (refresh-image)
  "Process events, passing function to refresh image on window"
  (xlib:event-case (*display*)

		   (:button-press (code window)
				  (case code
				    (3 t)))

		   (:selection-notify (window selection target property)
				      nil)

		   (:key-press (code window)
			       (case (xlib:keycode->keysym *display* code 0)
				 ;; 'q' keycode causes exit
				 (#o161 t)))

		   (:exposure (count window)
			      (if (= 0 count)
				  (funcall refresh-image window))
			      nil) ))

(defun dump-data (image)
  "Dump pixmap data as grid"
  (let ((data (xlib::image-x-data image))
	(width (xlib:image-width image))
	(height (xlib:image-height image))
	(bytes-per-line (xlib::image-x-bytes-per-line image)))
    (format t "Bitmap :width ~A :height ~A :bytes-per-line ~A~%"
	    width height bytes-per-line)
    (dotimes (yc height)
      (format t "|")
      (let ((rowpos (* bytes-per-line yc)))
	(dotimes (xc width)
	  (multiple-value-bind (byte-offset bit-offset)
	      (floor xc 8)
	    (format t "~A" (if (/= (logand (aref data (+ rowpos byte-offset))
					   (expt 2 bit-offset))
				   0)
				"*"
				" ")))))
      (format t "|~%"))))

(defun main ()
  "Say using via-voice whatever pasted in its window."
  ;; Read in background image
  (let ((bmfile (or (car *args*) "gremblin.xbm")))
    (setf *gremblin* (or (xlib:read-bitmap-file bmfile)
			 (error "Cannot read bitmap file: ~A~%" bmfile))))
  (format t "~A~%" *gremblin*)
;  (format t "data (~S):~%~s~%" (type-of (xlib::image-x-data *gremblin*))
;	  (xlib::image-x-data *gremblin*))
;  (dump-data *gremblin*)
  (open-x-display)

;; Set up background pixmap
  (let* ((width       (xlib:image-width        *gremblin*))
	 (height      (xlib:image-height       *gremblin*))
	 (black-pixel (xlib:screen-black-pixel *screen*))

	 (win (xlib:create-window :parent *root* :x 10 :y 10
				  :width width :height height
				  :background black-pixel
				  :event-mask '(:button-press
						:key-press
						:exposure)))

	 ;; Try for an appropriate color
	 (color (xlib:alloc-color (xlib:window-colormap win)
				  "Light Green"))
	 (gcon (xlib:create-gcontext :drawable win
				     :foreground color)))

    (setf (xlib:wm-name win) "Gremblin")

    (xlib:map-window win)
    (xlib:display-finish-output *display*)

    ;; Process event loop
    (handle-events (lambda (win) (show-image win gcon *gremblin*)))

    ;; Done
    (xlib:unmap-window win)
    (xlib:destroy-window win))

  (close-x-display))

#-cmu
(main)
======== END OF badcase.lisp ======

---

From: Sam Steingold <[email-masked]>
Date: Mon Sep 29 08:58:03 2003

> * Barry Fishman <[email-masked]> [2003-09-29 09:23:00 -0400]:
>
> think it is.  I don't know enough about CLISP internal structures to
> know what is happening.

TheSbvector()->data points to the start of the data in the
simple-byte-vector, see lispbibl.d:

typedef struct {
  LRECORD_HEADER /* self-pointer for GC, length in bits */
  uint8  data[unspecified]; /* Bits, divided into bytes */
} sbvector_;
typedef sbvector_ *  Sbvector;

data[-4] will grab the extra 32 bits from the header, on your platform
(IIUC, play with CPP or gdb to check!), it will be the "uintL tfl"
field (see VAROBJECT_HEADER).

I think that the problem is not in PUT-IMAGE, but in the routines that
load the image into the lisp object, specifically, in whatever routine
creates the byte vector.

could you please check what goes wrong there?

thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Oh Lord, give me the source code of the Universe and a good debugger!

---

From: Barry Fishman <[email-masked]>
Date: Wed Oct 1 09:12:05 2003

> could you please check what goes wrong there?

I don't quite understand the workings of CLISP's internal structure,
but it seemed unlikely that a basic internal accessor like TheSbvector
would be wrong without a lot more than PUT-IMAGE going wrong, and the
code path through the PUT-IMAGE C function looks correct (to me).  So
I did look closer at the xlib:read-bitmap-file function that reads the
bitmap file.

The xlib:read-bitmap-file function, being entirely in lisp, is
almost identical to the one as the standard CLX distribution.  The
code, is straight forward, and does seem to read my bitmaps into the
lisp IMAGE-X structure correctly, although CLX's data structures are a
bit different than the C XLIB way of doing things.  If you look at my
test program (in lisp), my DUMP-DATA function displays the bitmap in
ascii stars correctly, from the raw data in the xlib::image-x
structure.  So from the lisp side, the xlib::image-x-data vector is
correct.

If you look at my patches clx.f, I use the C function
dump_image(XImage) to dump the same raw data, filled into a local
XImage structure, as an picture in ascii stars on stdout.  When I
offset -4 bytes from the TheSbvector(value1)->data pointer, I get the
identical picture as the one displayed in the test program.

Therefore, everything seems to point back to TheSbvector(value1)->data
interface, or something else in the PUT-IMAGE function.

Just one other comment.  It seems that it might be simpler to make
PUT-IMAGE a lisp function which does any required repacking of the
image data (which isn't required for image-x structures) into a single
more C like XImage structure, and send the result to a C interface
function which just calls XCreateImage() and then XPutImage().  This
may sometimes be a bit slower, but where speed is critical the user
would be using Pixmaps and not XImages, and the lisp code would be a
lot easier to maintain.

Does this make sense?  I am starting such a rework myself, and will
probably soon find out.  However, this still doesn't resolve what
is going wrong in getting at the data pointer.
-- 
Barry Fishman

---

From: Sam Steingold <[email-masked]>
Date: Wed Oct 1 12:36:07 2003

> * Barry Fishman <[email-masked]> [2003-10-01 12:09:41 -0400]:
>

this is not what I observe:

$ ./configure --with-module=clx/new-clx --with-debug --build build-g
$ cd build-g
$ gdb
(gdb) full
(gdb) set language c
(gdb) break dump_image
(gdb) run -B . -M full/lispinit.mem -q -norc ../../bugs/badcase.lisp
...
(gdb) up
(gdb) zout mv_space[0]          ;; == value1
#(0 0 0 0 0 47 42 16 0 0 0 0 0 47 42 16 0 0 0 0 0 79 78 84 0 0 0 0 0 69 78 84 0
  0 0 0 0 0 5 0 128 31 0 240 3 151 93 0 64 48 0 24 4 47 42 16 0 32 255 9 0 47
  42 16 0 224 255 15 0 79 78 84 0 248 255 63 0 67 84 73 0 254 255 255 0 47 42
  16 0 255 255 255 1 79 68 85 128 255 255 255 3 77 69 0 128 255 255 255 3 24 0
  0 192 31 255 241 7 27 94 0 192 15 254 224 7 27 94 0 192 15 254 224 7 27 94 0
  192 31 255 241 7 27 94 0 192 255 255 255 7 27 94 0 128 255 255 255 3 27 94 0
  128 255 255 255 3 27 94 0 0 255 255 255 1 27 94 0 0 254 255 255 0 27 94 0 0
  248 255 63 0 255 255 127 0 224 255 15 0 255 255 127 0 0 255 1 0 255 255 127 0
  0 199 1 0 5 0 0 0 0 198 0 0 67 50 16 0 0 198 0 0 26 94 0 0 0 198 0 0 48 42 16
  0 0 198 0 0 255 255 127 0 0 130 0 0 255 255 127 0 0 130 0 0 1 0 0 0 0 130 0 0
  48 42 16 0 0 130 0 0 104 38 16 0 0 130 0 0 48 42 16 0 254 131 255 0 1 0 0 0
  255 199 255 1 48 42 16 0 254 131 255 0 48 42 16 0 0 0 0 0 0 0 0 0 0 0 0 0 142
  227 63 0 0 0 0 0 26 94 0 0 0 0 0 0 48 42 16 0 0 0 0 0 179 46 16)
(gdb) zout STACK[-8]            ;; == STACK_7
#S(XLIB:IMAGE-X :WIDTH 40 :HEIGHT 44 :DEPTH 1 :PLIST (:NAME :M-GRELB)
   :FORMAT :Z-PIXMAP :BYTES-PER-LINE 8 :BITS-PER-PIXEL 1 :BIT-LSB-FIRST-P T
   :BYTE-LSB-FIRST-P T
   :DATA
   #(0 0 0 0 0 47 42 16 0 0 0 0 0 47 42 16 0 0 0 0 0 79 78 84 0 0 0 0 0 69 78
     84 0 0 0 0 0 0 5 0 128 31 0 240 3 151 93 0 64 48 0 24 4 47 42 16 0 32 255
     9 0 47 42 16 0 224 255 15 0 79 78 84 0 248 255 63 0 67 84 73 0 254 255 255
     0 47 42 16 0 255 255 255 1 79 68 85 128 255 255 255 3 77 69 0 128 255 255
     255 3 24 0 0 192 31 255 241 7 27 94 0 192 15 254 224 7 27 94 0 192 15 254
     224 7 27 94 0 192 31 255 241 7 27 94 0 192 255 255 255 7 27 94 0 128 255
     255 255 3 27 94 0 128 255 255 255 3 27 94 0 0 255 255 255 1 27 94 0 0 254
     255 255 0 27 94 0 0 248 255 63 0 255 255 127 0 224 255 15 0 255 255 127 0
     0 255 1 0 255 255 127 0 0 199 1 0 5 0 0 0 0 198 0 0 67 50 16 0 0 198 0 0
     26 94 0 0 0 198 0 0 48 42 16 0 0 198 0 0 255 255 127 0 0 130 0 0 255 255
     127 0 0 130 0 0 1 0 0 0 0 130 0 0 48 42 16 0 0 130 0 0 104 38 16 0 0 130 0
     0 48 42 16 0 254 131 255 0 1 0 0 0 255 199 255 1 48 42 16 0 254 131 255 0
     48 42 16 0 0 0 0 0 0 0 0 0 0 0 0 0 142 227 63 0 0 0 0 0 26 94 0 0 0 0 0 0
     48 42 16 0 0 0 0 0 179 46 16)
   :UNIT 32 :PAD 32 :LEFT-PAD 0)

this is different from what is printed elsewhere:

#S(IMAGE-X :WIDTH 40 :HEIGHT 44 :DEPTH 1 :PLIST (NAME M-GRELB) :FORMAT Z-PIXMAP
   :BYTES-PER-LINE 8 :BITS-PER-PIXEL 1 :BIT-LSB-FIRST-P T :BYTE-LSB-FIRST-P T
   :DATA
   #(0 0 0 0 0 10 42 16 0 0 0 0 0 11 42 16 0 0 0 0 0 79 78 84 0 0 0 0 0 69 78
     84 0 0 0 0 0 0 5 0 128 31 0 240 3 151 93 0 64 48 0 24 4 11 42 16 0 32 255
     9 0 11 42 16 0 224 255 15 0 79 78 84 0 248 255 63 0 67 84 73 0 254 255 255
     0 11 42 16 0 255 255 255 1 79 68 85 128 255 255 255 3 77 69 0 128 255 255
     255 3 24 0 0 192 31 255 241 7 27 94 0 192 15 254 224 7 27 94 0 192 15 254
     224 7 27 94 0 192 31 255 241 7 27 94 0 192 255 255 255 7 27 94 0 128 255
     255 255 3 27 94 0 128 255 255 255 3 27 94 0 0 255 255 255 1 27 94 0 0 254
     255 255 0 27 94 0 0 248 255 63 0 255 255 127 0 224 255 15 0 255 255 127 0
     0 255 1 0 255 255 127 0 0 199 1 0 5 0 0 0 0 198 0 0 31 50 16 0 0 198 0 0
     26 94 0 0 0 198 0 0 11 42 16 0 0 198 0 0 255 255 127 0 0 130 0 0 255 255
     127 0 0 130 0 0 1 0 0 0 0 130 0 0 12 42 16 0 0 130 0 0 67 38 16 0 0 130 0
     0 12 42 16 0 254 131 255 0 1 0 0 0 255 199 255 1 11 42 16 0 254 131 255 0
     12 42 16 0 0 0 0 0 0 0 0 0 0 0 0 0 142 227 63 0 0 0 0 0 26 94 0 0 0 0 0 0
     12 42 16 0 0 0 0 0 143 46 16)
   :UNIT 32 :PAD 32 :LEFT-PAD 0)
data ((SIMPLE-ARRAY (UNSIGNED-BYTE 8) (352))):
#(0 0 0 0 0 10 42 16 0 0 0 0 0 11 42 16 0 0 0 0 0 79 78 84 0 0 0 0 0 69 78 84 0
  0 0 0 0 0 5 0 128 31 0 240 3 151 93 0 64 48 0 24 4 11 42 16 0 32 255 9 0 11
  42 16 0 224 255 15 0 79 78 84 0 248 255 63 0 67 84 73 0 254 255 255 0 11 42
  16 0 255 255 255 1 79 68 85 128 255 255 255 3 77 69 0 128 255 255 255 3 24 0
  0 192 31 255 241 7 27 94 0 192 15 254 224 7 27 94 0 192 15 254 224 7 27 94 0
  192 31 255 241 7 27 94 0 192 255 255 255 7 27 94 0 128 255 255 255 3 27 94 0
  128 255 255 255 3 27 94 0 0 255 255 255 1 27 94 0 0 254 255 255 0 27 94 0 0
  248 255 63 0 255 255 127 0 224 255 15 0 255 255 127 0 0 255 1 0 255 255 127 0
  0 199 1 0 5 0 0 0 0 198 0 0 31 50 16 0 0 198 0 0 26 94 0 0 0 198 0 0 11 42 16
  0 0 198 0 0 255 255 127 0 0 130 0 0 255 255 127 0 0 130 0 0 1 0 0 0 0 130 0 0
  12 42 16 0 0 130 0 0 67 38 16 0 0 130 0 0 12 42 16 0 254 131 255 0 1 0 0 0
  255 199 255 1 11 42 16 0 254 131 255 0 12 42 16 0 0 0 0 0 0 0 0 0 0 0 0 0 142
  227 63 0 0 0 0 0 26 94 0 0 0 0 0 0 12 42 16 0 0 0 0 0 143 46 16)

this means that the DATA slot of the IMAGE-X structure gets corrupted
somewhere, probably in C.

note also the different :PLIST lists!

[OTOH, I am an awful bit-pusher, and I am likely to be missing the
point here, please bear with me]

> I did look closer at the xlib:read-bitmap-file function that reads the

Note that the CLISP core gets TheSbvector() et al from lispbibl.d while
modules, including new-clx, get them from clisp.h.
I just looked at both build-g/clisp.g (generated by genclisph.d) and
build-g/lispbibl.h ("make lispbibl.h") and they appear to be in sync.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Modern man is the missing link between apes and human beings.

---

From: Barry Fishman <[email-masked]>
Date: Thu Oct 2 10:43:03 2003

> this is not what I observe:

I followed your build and debug procedure,  but got different results:

=========== BEGIN DEBUG LOG =============
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux".
Breakpoint 1 at 0x806867a: file eval.d, line 4834.
Breakpoint 2 at 0x8065f3a: file eval.d, line 3921.
Breakpoint 3 at 0x8062674: file eval.d, line 2805.
Breakpoint 4 at 0x804ff12: file spvw_garcol.d, line 2617.
Breakpoint 5 at 0x80524f2: file spvw.d, line 627.
Breakpoint 6 at 0x804c826: file spvw.d, line 483.
Breakpoint 7 at 0x804c8b6: file spvw.d, line 494.
Hardware watchpoint 8: back_trace
Num Type           Disp Enb Address    What
1   breakpoint     keep n   0x0806867a in funcall at eval.d:4834
        zout fun
2   breakpoint     keep n   0x08065f3a in apply at eval.d:3921
        zout fun
3   breakpoint     keep n   0x08062674 in eval at eval.d:2805
        zout form
4   breakpoint     keep n   0x0804ff12 in gar_col at spvw_garcol.d:2617
5   breakpoint     keep y   0x080524f2 in fehler_notreached at spvw.d:627
6   breakpoint     keep y   0x0804c826 in SP_ueber at spvw.d:483
7   breakpoint     keep y   0x0804c8b6 in STACK_ueber at spvw.d:494
8   hw watchpoint  keep n              back_trace
        zbacktrace
        continue
.gdbinit:133: Error in sourced command file:
Function "sigsegv_handler_failed" not defined.
(gdb) full
Breakpoint 1 at 0x808f846: file eval.d, line 4834.
Breakpoint 2 at 0x808d106: file eval.d, line 3921.
Breakpoint 3 at 0x8089840: file eval.d, line 2805.
Breakpoint 4 at 0x80770de: file spvw_garcol.d, line 2617.
Breakpoint 5 at 0x80796be: file spvw.d, line 627.
Breakpoint 6 at 0x80739f2: file spvw.d, line 483.
Breakpoint 7 at 0x8073a82: file spvw.d, line 494.
Breakpoint 9 at 0x804d482: file clx.f, line 481.
Breakpoint 10 at 0x804d4fe: file clx.f, line 488.
(gdb) set language c
(gdb) break dump_image
Breakpoint 11 at 0x805e07a: file clx.f, line 4968.
(gdb) run -B . -M full/lispinit.mem -q -norc badcase.lisp 
Starting program: /home/barry/src/gen/clisp/full/lisp.run -B . -M full/lispinit.mem -q -norc badcase.lisp
STACK depth: 16363
#S(IMAGE-X :WIDTH 40 :HEIGHT 44 :DEPTH 1 :PLIST (NAME M-GRELB) :FORMAT Z-PIXMAP
   :BYTES-PER-LINE 8 :BITS-PER-PIXEL 1 :BIT-LSB-FIRST-P T :BYTE-LSB-FIRST-P T
   :DATA
   #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     0 0 0 128 31 0 240 3 0 0 0 64 48 0 24 4 0 0 0 0 32 255 9 0 0 0 0 0 224 255
     15 0 0 0 0 0 248 255 63 0 0 0 0 0 254 255 255 0 0 0 0 0 255 255 255 1 0 0
     0 128 255 255 255 3 0 0 0 128 255 255 255 3 0 0 0 192 31 255 241 7 0 0 0
     192 15 254 224 7 0 0 0 192 15 254 224 7 0 0 0 192 31 255 241 7 0 0 0 192
     255 255 255 7 0 0 0 128 255 255 255 3 0 0 0 128 255 255 255 3 0 0 0 0 255
     255 255 1 0 0 0 0 254 255 255 0 0 0 0 0 248 255 63 0 0 0 0 0 224 255 15 0
     0 0 0 0 0 255 1 0 0 0 0 0 0 199 1 0 0 0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0
     0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0
     0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 254 131 255 0 0
     0 0 0 255 199 255 1 0 0 0 0 254 131 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
   :UNIT 32 :PAD 32 :LEFT-PAD 0)

Breakpoint 11, dump_image (image=0xbfffb6d0) at clx.f:4968
4968	  skipSTACK(1);
Warning: the current language does not match this frame.
(gdb) up
#1  0x0805e740 in C_subr_xlib_put_image () at clx.f:5063
5063	        /* Q: Should we raise a x-error-sonstwas condition here? */
(gdb) zout mv_space[0]
#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 128 31 0 240 3 0 0 0 64 48 0 24 4 0 0 0 0 32 255 9 0 0 0 0 0 224 255 15 0 0
  0 0 0 248 255 63 0 0 0 0 0 254 255 255 0 0 0 0 0 255 255 255 1 0 0 0 128 255
  255 255 3 0 0 0 128 255 255 255 3 0 0 0 192 31 255 241 7 0 0 0 192 15 254 224
  7 0 0 0 192 15 254 224 7 0 0 0 192 31 255 241 7 0 0 0 192 255 255 255 7 0 0 0
  128 255 255 255 3 0 0 0 128 255 255 255 3 0 0 0 0 255 255 255 1 0 0 0 0 254
  255 255 0 0 0 0 0 248 255 63 0 0 0 0 0 224 255 15 0 0 0 0 0 0 255 1 0 0 0 0 0
  0 199 1 0 0 0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0 0 0 0 0 198
  0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0
  0 0 0 0 130 0 0 0 0 0 0 254 131 255 0 0 0 0 0 255 199 255 1 0 0 0 0 254 131
  255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
  0 0 0 0 0 0 0)
{one_o = 540662617}
(gdb) zout STACK[-8]
#S(XLIB:IMAGE-X :WIDTH 40 :HEIGHT 44 :DEPTH 1 :PLIST (:NAME :M-GRELB)
   :FORMAT :Z-PIXMAP :BYTES-PER-LINE 8 :BITS-PER-PIXEL 1 :BIT-LSB-FIRST-P T
   :BYTE-LSB-FIRST-P T
   :DATA
   #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     0 0 0 128 31 0 240 3 0 0 0 64 48 0 24 4 0 0 0 0 32 255 9 0 0 0 0 0 224 255
     15 0 0 0 0 0 248 255 63 0 0 0 0 0 254 255 255 0 0 0 0 0 255 255 255 1 0 0
     0 128 255 255 255 3 0 0 0 128 255 255 255 3 0 0 0 192 31 255 241 7 0 0 0
     192 15 254 224 7 0 0 0 192 15 254 224 7 0 0 0 192 31 255 241 7 0 0 0 192
     255 255 255 7 0 0 0 128 255 255 255 3 0 0 0 128 255 255 255 3 0 0 0 0 255
     255 255 1 0 0 0 0 254 255 255 0 0 0 0 0 248 255 63 0 0 0 0 0 224 255 15 0
     0 0 0 0 0 255 1 0 0 0 0 0 0 199 1 0 0 0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0
     0 0 0 0 198 0 0 0 0 0 0 0 198 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0
     0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 0 130 0 0 0 0 0 0 254 131 255 0 0
     0 0 0 255 199 255 1 0 0 0 0 254 131 255 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
     0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
   :UNIT 32 :PAD 32 :LEFT-PAD 0)
{one_o = 540662977}
(gdb) cont
Continuing.

;; Image (bitmap) 40x44x1, bpl= 8, pad= 32:
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                       *|
;|**                                    * |
;|  *                                     |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|*                                      *|
;|**                                     *|
;|**                                    **|
;|***                                   **|
;|***                                   **|
;|***                                   **|
;|***                                   **|
;|***                                    *|
;|**                                     *|
;|**                                      |
;|*                                       |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|*                                       |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                        |
;|                                *     **|

Program exited normally.
===================  END DEBUG LOG ====================

All of the debug information seems correct when I do it, although
the bitmap I display is still wrong.

I am unsure of why your gremblin data is so different than mine!

If I offset the data using my kludge:
 
      im.data = (char*) &TheSbvector (value1)->data[-4];

The debug log is identical, except:

*** unpatched.log	2003-10-02 12:30:12.000000000 -0400
--- patched.log	2003-10-02 12:43:20.000000000 -0400
***************
*** 109,153 ****
  ;|                                        |
  ;|                                        |
  ;|                                        |
- ;|                                       *|
- ;|**                                    * |
- ;|  *                                     |
  ;|                                        |
  ;|                                        |
  ;|                                        |
  ;|                                        |
- ;|*                                      *|
- ;|**                                     *|
- ;|**                                    **|
- ;|***                                   **|
- ;|***                                   **|
- ;|***                                   **|
- ;|***                                   **|
- ;|***                                    *|
- ;|**                                     *|
- ;|**                                      |
- ;|*                                       |
  ;|                                        |
  ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|*                                       |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                        |
- ;|                                *     **|
  
  Program exited normally.
--- 109,153 ----
  ;|                                        |
  ;|                                        |
  ;|                                        |
  ;|                                        |
+ ;|       ******               ******      |
+ ;|      *     **             **     *     |
+ ;|             *  *********  *            |
+ ;|             ***************            |
+ ;|           *******************          |
+ ;|         ***********************        |
+ ;|        *************************       |
+ ;|       ***************************      |
+ ;|       ***************************      |
+ ;|      *******   *********   *******     |
+ ;|      ******     *******     ******     |
+ ;|      ******     *******     ******     |
+ ;|      *******   *********   *******     |
+ ;|      *****************************     |
+ ;|       ***************************      |
+ ;|       ***************************      |
+ ;|        *************************       |
+ ;|         ***********************        |
+ ;|           *******************          |
+ ;|             ***************            |
+ ;|                *********               |
+ ;|                ***   ***               |
+ ;|                 **   **                |
+ ;|                 **   **                |
+ ;|                 **   **                |
+ ;|                 **   **                |
+ ;|                 *     *                |
+ ;|                 *     *                |
+ ;|                 *     *                |
+ ;|                 *     *                |
+ ;|                 *     *                |
+ ;|         *********     *********        |
+ ;|        ***********   ***********       |
+ ;|         *********     *********        |
  ;|                                        |
  ;|                                        |
  ;|                                        |
  ;|                                        |
  ;|                                        |
  
  Program exited normally.

> somewhere, probably in C.

The C raw data pointer is wrong by 4 bytes (in my test), but the data
bits themselves seem to be OK.  I don't think the DATA slot of the
IMAGE-X structure is corrupted, since it still appears correct (from
lisp) after the program is run.  The only thing (confirmed) wrong is
the data pointer computed internal to the put-image function.

> note also the different :PLIST lists!

Are we looking at symbol names rather than the symbols themselves in
the debug log?

> point here, please bear with me]

I appreciate the time you have spent on this.  Initially, I thought
that it was something simple, that more experienced eyes would
have seen right away.

I am going to continue to work on the problem, but first I am going to
spend some time better acquainting myself with the CLISP FFI.
-- 
Barry Fishman

---

From: Sam Steingold <[email-masked]>
Date: Thu Oct 2 12:31:05 2003

> * Barry Fishman <[email-masked]> [2003-10-02 13:39:31 -0400]:
>

the fact that you and I get different results means, IMO, that the
whole structure is corrupted somewhere.

> Are we looking at symbol names rather than the symbols themselves in

both of us see :PLIST (NAME M-GRELB) instead of :PLIST (:NAME :M-GRELB).
this indicates  something terrible.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
usually: can't pay ==> don't buy. software: can't buy ==> don't pay

---

From: John Booher <[email-masked]>
Date: Thu Oct 2 13:10:07 2003

How would I call a script (sh or python) from lisp?

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: Marco Antoniotti <[email-masked]>
Date: Thu Oct 2 15:59:02 2003

> How would I call a script (sh or python) from lisp?

The long answer is:
it depends on the particular implementation you are using.  For CLisp 
you should be able to do

	(ext:execute "/bin/sh" "myscript.sh" "arg1" "arg2" ... "argN")

Other implementations have a different command to run a shell command.

The short answer is:
You don't.  You are way better off just using Common Lisp :)

Cheers

marco

> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> clisp-list mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/clisp-list
>
--
Marco Antoniotti
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

---

From: Sam Steingold <[email-masked]>
Date: Tue Oct 7 08:03:13 2003

> * John Booher <[email-masked]> [2003-10-02 13:09:13 -0700]:
>

CLISP-specific: <http://clisp.cons.org/impnotes.html#shell>
cross-implementation: <http://clocc.sourceforge.net/dist/port.html>
CLOCC/PORT/shell.lisp

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))

---

From: Sam Steingold <[email-masked]>
Date: Tue Oct 7 09:20:04 2003

> * Sam Steingold <[email-masked]> [2003-10-02 15:30:19 -0400]:
>

Ironically, I was right - the problem was elsewhere.
I just fixed it in the CVS, the patch is appended.

thanks a lot for your testing and bug reporting!

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
The only thing worse than X Windows: (X Windows) - X

--- genclisph.d.~1.81.~	2003-10-02 10:39:28.460056500 -0400
+++ genclisph.d	2003-10-07 12:12:55.015347800 -0400
@@ -776,14 +776,14 @@
     #endif
   #endif
   printf("typedef union { dfloat eksplicit; } dfloatjanus;\n");
-# printf("typedef struct { LRECORD_HEADER uintL  length; } sarray_;\n");
+# printf("typedef struct { LRECORD_HEADER } sarray_;\n");
 # printf("typedef sarray_ *  Sarray;\n");
-  printf("typedef struct { LRECORD_HEADER uintL  length; uint8  data[unspecified]; } sbvector_;\n");
+  printf("typedef struct { LRECORD_HEADER uint8  data[unspecified]; } sbvector_;\n");
   printf("typedef sbvector_ *  Sbvector;\n");
  #ifdef UNICODE
-   printf("typedef struct { LRECORD_HEADER uintL  length; uint32  data[unspecified]; } sstring_;\n");
+   printf("typedef struct { LRECORD_HEADER uint32  data[unspecified]; } sstring_;\n");
  #else
-   printf("typedef struct { LRECORD_HEADER uintL  length; uint8  data[unspecified]; } sstring_;\n");
+   printf("typedef struct { LRECORD_HEADER uint8  data[unspecified]; } sstring_;\n");
  #endif
  printf("typedef sstring_ *  Sstring;\n");
  printf("typedef struct { LRECORD_HEADER gcv_object_t data[unspecified]; } svector_;\n");

---

From: Barry Fishman <[email-masked]>
Date: Wed Oct 15 09:03:14 2003

> I just fixed it in the CVS, the patch is appended.

Sorry about the late reply, but I have not been able to retrieve a
CVS version until today.

The bitmap is displayed correctly now.  Thank you.