You are here

Home › Forums › Plugins & Scripts

Intermittent color set bug WAS Error handler example code?

April 28, 2009 - 06:40 — Charles Belov

Is there any sample code around showing how to use pdb-set-error-handler and pdb-get-error-handler to detect and do something alternate to just failing with an error dialog? All I can Google is a suggestion from Sven to use these to intercept errors--a good idea--but no examples on how to do that.

My script-fu is occasionally/rarely getting the message "Error: invalid type for argument 1 to gimp-context-set-foreground or gimp-context-set-background. These functions only have one argument, a color. So somehow it is occasionally dropping the color. The weird part is that if I re-run the script-fu using the same options, I don't get the error. It's like Script-Fu hiccupped or something. So I'd like to capture what the value of the item was when I got the error, say to capture it and print it out.

At the very least I'd like to avoid leaving a stray selection.

But I don't even know how to start. Any pointers?

Or would I be better off with throw and catch?

Forums: 
Plugins & Scripts
April 28, 2009 - 16:15 — RobA

Hi Charles- This is definitely a bug in either tinyscheme or in the tiny-fu implementation. It seems to happen more often on windows than linux, but it still happens on linux. I am assuming you are setting a colour list to a variable, and then later using the gimp-context-set-foreground or gimp-context-set-background calls to set it. (These calls never error if provided explicitly with a colour list). I have not been able to get the error handling to work in this case. In my flatting tools script I found this happened when I was randomly assigning colours from the palette. I worked around it in the colour assignment code using a length check on the colour to make sure it has three items in its list like so (simplified for clarity): (set! nextcolour (car (gimp-palette-entry-get-color inPalette (rand numcolours)))) ; random palette colour (while (< (length nextcolour) 3) ; bug (set! nextcolour (car (gimp-palette-entry-get-color inPalette (rand numcolours)))) ; random palette colour, ) Hope that helps. -Rob A>
April 30, 2009 - 08:45 — Charles Belov

Yes, I am setting a variable to a random color. (set! tlColor (list (rand 255) (rand 255) (rand 255))) And you can add X11 on a Mac to the list of platforms it occurs on.
April 30, 2009 - 17:30 — RobA

Charles- So try looping with a test on the list length: (set! tlColor (list (rand 255) (rand 255) (rand 255))) (while (< (length tlColor) 3) (set! tlColor (list (rand 255) (rand 255) (rand 255))) ) That should prevent you from getting past that point without all three colours defined and prevent the downstream error. -Rob A>
May 16, 2009 - 22:08 — Charles Belov

Thanks! I spoke too soon about the random function being the source of the problem. It was the color pick function. So I came up with a safe color pick wrapper function. ; Safe gimp-image-pick-color wrapper ; to work around possible random image pick color bug ; see http://registry.gimp.org/node/15781#comment-3003 (define (safe-gimp-image-pick-color image drawable x y sample-merged sample-average average-radius) (let* ( (tempColor (car (gimp-image-pick-color image drawable x y sample-merged sample-average average-radius))) ) (while (< (length tempColor) 3) (set! tempColor (car (gimp-image-pick-color image drawable x y sample-merged sample-average average-radius))) ) (list tempColor) ) ) Sample call of this wrapper function: (gimp-context-set-foreground (car (safe-gimp-image-pick-color img layer selectionX1 rowY FALSE FALSE 0))) The problem of course with testing something to work around a rare intermittent bug is that there is no easy way to be sure that the bug has occurred. I suppose I could pass back a 2nd list item if the bug occurred, but since I can't force the bug to reproduce I'm not sure how useful that would be.
May 17, 2009 - 09:29 — Charles Belov

First off, I replaced the check for < 3 with (while (not (= (length tempColor) 3)) since more than 3 colors would be suspect as well. But then I wanted to be able to log a bug, so I added (gimp-message (list->string (car(tempColor)))) (quit) and I can't get the quit to happen. While this is an intermittent bug, it normally will show up within a few runs of my script-fu, which runs the color pick operation at least twice as many times as there are pixels in the height or width of the image the script runs against. But now that I have the wrapper, no bug. Again, one can never be sure an intermittent bug is gone, but it sure appears to be. Old, pre-bug code: (gimp-context-set-foreground (car (gimp-image-pick-color img layer colX1 rowY1 FALSE FALSE 0))) (gimp-context-set-background (car (gimp-image-pick-color img layer colX2 rowY2 FALSE FALSE 0))) New, post-bug code: (gimp-context-set-foreground (car (safe-gimp-image-pick-color img layer colX1 rowY1 FALSE FALSE 0))) (gimp-context-set-background (car (safe-gimp-image-pick-color img layer colX2 rowY2 FALSE FALSE 0))) Weird. Good for my script. Bad for my bug reporting.
Subscribe to Comments for &quot;Intermittent color set bug WAS Error handler example code?&quot;

Unless otherwise noted, the rights for the individual plugins are with their respective authors. Logo image by Jakub Steiner.