Menu
▾
▴
Re: image/binary patch updated
|
From: Daniel J S. <dan...@ie...> - 2003-11-10 20:58:13
|
[Folks... tell me if this email is too big to be submitting
to the mailing list. Are people able to see the PNG
images in their browsers?]
Ethan Merritt wrote:
>On Monday 10 November 2003 09:30, you wrote:
>
>
>>Ethan A Merritt wrote:
>>
>>
>>>I'll try to test it on an alpha next week (other endian, 64-bit).
>>>
>>>
>>That will be interesting. Let me know how it goes.
>>
>>
>
>First report: not so good.
>
Well, not too bad either. I'm encouraged the images
look reasonable.
>There are additional warnings during compilation for datafile.c and gplt_x11.c
>
>cc -DHAVE_CONFIG_H -I. -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include -g -c datafile.c
>cc: Warning: datafile.c, line 3156: In this statement, the expression "*pchar=*++pchar" modifies "pchar", and fetches its value in a computation that is not used to produce the modified value without an intervening sequence point. This behavior is undefined.
> *pchar = *++pchar;
>------------------------^
>
I will change that in the code. But if you want, try
changing, in your code, the three lines in that loop to
char temp = *pchar;
*pchar = *(pchar+1);
*++pchar = temp;
>cc -DHAVE_CONFIG_H -I. -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/3.8j\" -DCONTACT=\"bug...@da...\" -DHELPFILE=\"/usr/local/share/gnuplot/3.8j/gnuplot.gih\" -I/usr/local/include -g -c gplt_x11.c
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_rshift" is "short", which is not compatible with "unsigned short".
> R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2435: In this statement, the referenced type of the pointer value "&R_lshift" is "short", which is not compatible with "unsigned short".
> R_msb_mask = BitMaskDetails(vis->red_mask, &R_rshift, &R_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_rshift" is "short", which is not compatible with "unsigned short".
> G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2436: In this statement, the referenced type of the pointer value "&G_lshift" is "short", which is not compatible with "unsigned short".
> G_msb_mask = BitMaskDetails(vis->green_mask, &G_rshift, &G_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_rshift" is "short", which is not compatible with "unsigned short".
> B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>cc: Warning: gplt_x11.c, line 2437: In this statement, the referenced type of the pointer value "&B_lshift" is "short", which is not compatible with "unsigned short".
> B_msb_mask = BitMaskDetails(vis->blue_mask, &B_rshift, &B_lshift);
>-----------------------------------------^
>
The above warnings I can fix by just declaring chars and
uchars correctly. I can get to it this evening. But the
graphics card details you printed below look reasonable.
>Attached are some screen shots from the X11 output.
>Tux starts out looking a bit ill, and gets worse from there.
>
>Terminal output during the first demo (tux_1) is
> vis->visualid: 0x23 vis->class: 4 vis->bits_per_rgb: 8
> vis->red_mask: ff0000 vis->green_mask: ff00 vis->blue_mask: ff
> ImageByteOrder: 0
>
There certainly is a problem with the graphics mapping.
(The sort of thing seen before.) It looks like the usual
masks, but there seems to be a lot of variation just exactly
what bits within that mask do what. And the mangled
image is not good. (Not seen before.) I can only assume
that has to do with the decoding of data. These may all
have something to do with the signed/unsigned warnings
above.
The blue channel seems to come out correctly. No
surprise since that is the one with the mask associate
with the rightmost bits.
>The PNG output looks OK, so I think this part of it is due to problems in
>gplt_x11.c
>
Yes, definitely.
>However, the program then dies on a floating exception from the
>1st binary data demo, right after printing:
>
Not so good. But these usually aren't so hard to
track down. Gnuplot crashes for PNG as well I assume.
That particular example is a rather innocuous one. I wonder
what happened. Could you please try a few things in
image.dem to isolate the problem just a bit more? Try
inputting the lines one at a time. Try skipping that example.
Etc.
> The following binary data sizes are machine dependent:
>
> name (size in bytes)
>
> "char" "schar" "c" (1)
> "uchar" (1)
> "short" (2)
> "ushort" (2)
> "int" "sint" "i" "d" (4)
> "uint" "u" (4)
> "long" "ld" (8)
> "ulong" "lu" (8)
> "float" "f" (4)
> "double" "lf" (8)
>
> The following binary data sizes attempt to be machine independent:
>
> name (size in bytes)
>
> "int8" "byte" (1)
> "uint8" "ubyte" (1)
> "int16" "word" (2)
> "uint16" "uword" (2)
> "int32" (4)
> "uint32" (4)
> "float32" (4)
> "float64" (8)
>
Well hey! This is very nice. This is probably the first case
where the doubles, longs and ulongs are 8 bytes. Also, notice
that the "machine independent" code did what it is supposed
to do. However, it looks like an "int64" and "uint64" are needed.
>I am not sure yet whether this is due to the error message from
>datafile.c, or whether it is something more fundamental.
>
At first glance, it doesn't look like that command would
be the problem. That is part of the PDP endian, which
I suspect isn't being reached in this case.
Let me think these over.
Thanks,
Dan
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
--
Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/
|
