[Xastir] Print and/or screen dump

[Tim Gimmel]

I've been trying to follow the thread about the print problem. As you
may or may not know my web page uses the snapshots feature.  I noticed
about the time of 1.4.2 that it broke.
Here is some debug output:
Loading imagemap: /home/tim/.xastir/tmp/map.gif

Image: /home/tim/.xastir/tmp/map.gif
Image size 1276 888
XX: 0 YY:0 Sx 431.338039 1 Sy 340.383315 1
Image size 1276 888
Unique colors = 14
XX: 0 YY:0 Sx 431.338039 1 Sy 340.383315 1
image matte is 0
Taking Snapshot
Creating /home/tim/.xastir/tmp/snapshot.xpm
ERROR writing /home/tim/.xastir/tmp/snapshot.xpm
Caught Signal USR1, Doing a snapshot! Signal No 10
Caught Signal USR1, Doing a snapshot! Signal No 10

This is running with debug level of 512.  As you can see after xastir
loaded I sent a couple of USR1's to force a snapshot and I did not get
it. I went ahead and changed the mode of the .xastir and tmp directories
to 777 just to make sure it was not a problem with permissions.  When I
send the signal its not even getting to the snapshot portion in maps.c,
else we would see the "Taking Snapshot".  I noticed that the code in
maps.c has changed considerably.  It looks as there has been quite a lot
of threading support added.  
I downloaded from cvs this evening and that is what I am currently
running now.  If you fellows need any info, please let me know.

Thanks,
Tim
KB4AMA

On Tue, 2004-12-28 at 10:57 -0700, Tom Russo wrote:
> On Tue, Dec 28, 2004 at 12:29:56PM -0500, we recorded a bogon-computron collision of the <kd1yv at arrl.net> flavor, containing:
> > Tom Russo wrote:
> > 
> > >On Tue, Dec 28, 2004 at 08:36:39AM -0800, we recorded a bogon-computron 
> > >collision of the <archer at eskimo.com> flavor, containing:
> > >[SNIP]
> > > 
> > >
> > >>>#define XpmColorFailed  -4
> > >>>
> > >>>Given the return value in the fprintf, you'd be able to see why it says 
> > >>>it's
> > >>>failing.  That might not tell you how to make it succeed, but if it's
> > >>>OpenFailed or FileInvalid it might point the way.  If it's ColorError, 
> > >>>NoMemory
> > >>>or ColorFailed I don't know how to fix it.
> > >>>     
> > >>>
> > >>If you think the Xpm define's might be somewhat uniform across
> > >>platforms, we could put in code that spits out the text to go along
> > >>with the integers.  If not, perhaps we could just dump out the int
> > >>itself like you have above.  No matter what it's good to tell the
> > >>user more.
> > >>   
> > >>
> > >
> > >Actually, there's apparently an XpmErrorMessage routine that interprets the
> > >return codes and returns a string with an error message in it.  I think
> > >that's probably the way to go.
> > >
> > >If I have a chance today I'll do that.  Of course I can't really test it 
> > >---
> > >that routine never has failed for me.
> > >
> > Tom, Curt,
> > 
> > It is still failing for me.  I put in the earlier test that Tom 
> > suggested, and get a -1, although that still does not really tell me why 
> > it can't open the file.  If you tell me where and how to splice in the 
> > code to get the xpm error message, I can give it a try.
> 
> I don't think it'll help you --- all it'll do is say "File Open Failed" instead
> of "-1".  If you still want to try it the easy thing to do would be to replace 
> the line:
>   fprintf(stderr,"ERROR  %d writing %s\n", xpmretval, xpm_filename );
> with:
>   fprintf(stderr,"ERROR writing %s: %s\n", xpm_filename, 
>                   XpmGetErrorString(xpmretval));
>  
> I think.  That's just what the sparse online xpm documentation says, I haven't 
> tested it or even tried inserting that call --- caveat hacktor.
> 
> But at least you now know that the actual error is that the xpm library
> can't open the file for output.  That's not *much* help, but it narrows down
> the search area.  
>