Table Of Contents
|1.||17 Jan 2000 - 23 Jan 2000||(6 posts)||Incorrect Behaviour When File Plugins Cancelled|
|2.||17 Jan 2000 - 23 Jan 2000||(3 posts)||Certain Images Crash Tiff Plug-In|
|3.||21 Jan 2000||(4 posts)||A Reprimand For Adding New Plug-Ins|
|4.||21 Jan 2000 - 26 Jan 2000||(17 posts)||Feedback on Logulator And Innerbevel|
|5.||24 Jan 2000 - 26 Jan 2000||(15 posts)||Removing The Stack Trace When Gimp Crashes|
Mailing List Stats For This Week
We looked at 141 posts in 532K.
There were 57 different contributors. 20 posted more than once. 19 posted last week too.
The top posters of the week were:
1. Incorrect Behaviour When File Plugins Cancelled
17 Jan 2000 - 23 Jan 2000 (6 posts) Archive Link: "Plugin -> Cancel -> EXECUTION_ERROR"
People: Michael Natterer, Marc Lehmann, Sven Neumann, Sven Neumann ,
Michael Natterer explained the problem to the list:
while browsing and hacking many plugins I noticed that pressing "Cancel" in a plugin dialog causes the plugin's return value to be set to STATUS_EXECUTION_ERROR.
While this has no effect in normal plugins, it causes a "save failed" message box to appear for all save plugins. I find this really annoying, because pressing cancel is just a normal mode of operation, not an error.
Well, none of the current return values gives gimp a hint that "Cancel" was pressed. I suggest to add "STATUS_CANCEL" to the enum which could be treated specially.
Marc Lehmann wrote that "I'm not completely sure, but since there simply is no way to cleanly "cancel" plug-ins, it really _is_ an error what is happending, and the save definitely failed (and might leave all sorts of garbage around!)."
Sven Neumann clarified the situation:
Why shouldn't it be possible to cleanly cancel a save from the Save dialog? Cancelling it later while the save is in progress is another thing, but that's not what Michael was talking about.
IMHO the "Save failed" message is really annoying and adding a STATUS_CANCEL for this purpose might be worth the effort.
2. Certain Images Crash Tiff Plug-In
17 Jan 2000 - 23 Jan 2000 (3 posts) Archive Link: "some tiff image kills the tiff plug-in"
People: Marc Lehmann, Nick Lamb,
Marc Lehmann wrote in to say, "I've got an 34k tiff file that xv cannot load (many errors), and gimp gives an error message "Falling back to RGBA, image might be inverted" (two times) and then the tiff-plug-in segfaults."
Nick Lamb replied that "This (the segfault) is now fixed in CVS. Stupid one line thinko."
3. A Reprimand For Adding New Plug-Ins
21 Jan 2000 (4 posts) Archive Link: "Addition of new plug-ins"
People: Sven Neumann, Manish Singh, Garry R. Osgood, Kelly Lynn Martin, Sven Neumann ,
Sven Neumann warned the list that "tonight two new plug-ins were checked into the tree. I now that we have not officially declared a plug-in freeze, but I think it was somehow clear that it is too late to add new plug-ins."
Manish Singh replied:
Yes, plugins should be frozen now.
I've removed them.
Garry R. Osgood added that "To be fair, I don't recall a posting enumerating what these 'new standards' may be; if I'm wrong, apologies and please correct me. If one is wanting, your list of (1) consistent interface (2) coding standards (GNU or close relatives) (3) Internationalized is a decent start."
Kelly Lynn Martin also replied that
I haven't looked but I assume this is my kaleidoscope plugin. I haven't approved it being added to CVS, and if nobody removes it before I get around to it I'll do so myself. If nothing else, the UI needs a lot of work before it should go in a production version.
Somebody please kick Martin in the butt for me.
4. Feedback on Logulator And Innerbevel
21 Jan 2000 - 26 Jan 2000 (17 posts) Archive Link: "End-user feedback: Perl logulator & innerbevel"
People: , Marc Lehmann, Sven Neumann, Sven Neumann
Mike started the longest thread for this week by saying:
I've been using the Perl plug-in logulator for logos for quite a while, and I ran into several (probably) little troubles, but I am clueless on whether other people are having them, so I would like to call for someone to share their experiences and tests of this powerful and nice tool. I am really incredibly curious to know whether someone out there have got a perfectly running copy of the logulator...
I am running a quite (IMHO) updated linux box, with latest gtk+ (1.2.6), Perl Gtk (0.7000), and perl (5.000_03), gimp (cvs tree 17Jan00, with a nice fix of the layers dialog bug , which made the latest 1.1.15 release hardly reliable). I am running the same gimp version and libs and perl modules on two linux boxes, one (A) with a self compiled perl under egcs-1.1.1, the other with a SuSe Linux 6.2 shipped perl (B). 1) The Xtns/Render/Inbevel plug-in runs fine on A and B, but on B if I invoke the layers dialogue after it has normally and gracefully exited, a gimp sigsegv follows (argh). On A instead this message is issued: Gdk-CRITICAL **: file gdkwindow.c: line 1390 (gdk_window_get_size): assertion `window != NULL' failed. The layers window is then opened, but the three layers resulting have an incredibly long name, which corresponds to a full path to a file in the perl directory, ending with #<number> [I'll paste this long path if someone will answer me ;)].
2) The logulator shows problems when invoking the SOTA Chrome, the Glossy and Neon scripts, the Particle trace script, The Web header logo script (last one in the menu). a) In the SOTA Chrome script, the chrome factor bar won't accept other values than the default one (0.8). b) The Glossy script is also tricky, because it will stop if the 'Accept bumpmap defaults' is checked, with an error message to the STDERR, stating that another process is waiting for input ("shouldn't happen" ends the message). Furthermore the Flatten image option doesn't work, and the image is 'always' flatted, even when the button isn't pressed (default). c) The Neon script is the most mysterious, though... Basically, with a text layer with a font which isn't so big as the default Blippo 150px, an error 'logulator: gimp_edit_fill procedural database execution failed at line 1902 (ERROR)' is issued. I've tried some humble hacking around in the logulator itself, and discovered something: if I run the script over a big enough text layer, it tends to work (but not consecutively, and not using different fonts). I also was successful trying to resize the layer and shrink it by some (10-20) pixels than the image... In latter case the gimp_selection_shrink at line 1917 failed next. The oddest here is that while in the trace a few lines above gimp_selection_shrink(0, 0.51) () seems to work fine, when later (l. 1917) it is called by the script, the second parameter isn't 0.51 any further, but '0'... How is this possible? When it stops, the $inc_shrink value is all the time 0.51, but gimp_selection_shrink is called with (0,0)... d) In the Particle Trace script no errors are issued, but unfortunately the final result hasn't much to do with the one obtained running the script-fu original script... The green despeckled text gets covered by the shadow (is this relating to the despeckle plug-in?) e) In the last script, finally, Web Header Logo, an error is issued because the gimp_color_picker isn't called with enough parameters. I added the needed parameters according to PDB, and the script worked, but I never understood whether the gray (?) background I obtained was really in the mind of the person who initially wrote the script! ;)
I've already been in contact with Marc Lehman, the creator and mantainer of the Perl Plug-in, who suggested me I could have hit here the script-fu bug. Shall we conclude that the perl plug-in will never work without a new version of script-fu? So my question is, whether some of the gimp developers are interested in fixing this up, since the perl plug-in is really making of gimp an even more powerful and astonishing tool than it ever was.
Marc Lehmann replied, saying:
Good ;) However, it seems that scripts converted from script-fu to perl have a large tendency to crash the gimp (yes, in ever unpredictable ways).
The layers dialog was (is?) pretty much broken at some days ;) This is probbaly being fixed soon.
In the meantime, your bug-report has vastly improved ;-> Only the case b) seems to be "the script-fu bug" itself.
Glossy will not work until script-fu is fixed (there are, I think one or two others who depend on script-fu as well). I don't believe in script-fu getting fixed before 1.2, though.
Sven Neumann replied to Marc, saying that "I won't unless someone tells us what he thinks is broken. Of course it will get fixed then since it would be stupid to release 1.2 if there are any known Script-Fu bugs in there."
Marc Lehmann answered Sven:
Well, telling "us" about it didn't help in the past, so why should it now? "us" should mean "the script-fu maintainer", and not me nor you.
I, for example, reported that bug and how to reproduce it in minute detail at least 3 times (maybe even more) during the last 15 months(!).
So yes, I do not believe that script-fu will work in 1.2. I also believe that script-fu needs a real maintainer who cares for it, not somebody like you who should better do other things.
Fact is, however, that script-fu is basically unmaintained. The bugs that I reported during the last year did not get fixed (with rare exceptions when you, mitch or me did it), and it is less then clear who is "responsible" for that plug-in.
Sven Neumann again replied to Marc to say:
Well, since nobody wanted to take the job and I do like Script-Fus I registered myself as Script-Fu maintainer a while ago. I have since then (and before) tried to fix all Script-Fu related bugs that I knew of. Have a look at the bug-tracking system. IIRC there's not a single open Script-Fu bug listed there. I do however see some Perl-related bugreports, but I'm starting to get off-topic...
Oops, then I must have thought it was related to the other bugs that got fixed. I can't remember a detailed bugreport however. You should know that to be sure that a bug gets attention and isn't forgotten there is only one proper way to report it: use the bug-tracker on bugs.gnome.org.
I really don't know what bug you are talking about actually, so please, would you take the time to file a proper bugreport?
Marc explained the lack of bug reports because:
I must admit that I have no idea how to edit bugreports or do anything else about them. I did *try*, but the pages are not very helpful in explaining how to use them.
I filed it, it got ignored. I reported it to the list, it got ignored. I did more to get that bug fixed than you could expect from anybody (because _I_ get asked about it twice a month)! I tried to contact people personally about that bug (and a couple of others) about that bug, and nobody reacted.
Sven Neumann explained the system:
Each and every one working actively on the gimp should make herself familiar with the bug-tracker, should be subscribed to email@example.com and should look into the buglist frequently.
In a later e-mail, Marc posted that
the most critical one is:
"start a script-fu plug-in noninteractively, and things start burning".
start burning means: either script-fu segfaults, gimp segfaults, both segfault, perl gets an error but gimp runs unstable etc...
There are probbaly two bugs here: the first one causes script-fu to return garbage, and the second one (in gimp) allows gimp to become unstable because script-fu returned garbage.
5. Removing The Stack Trace When Gimp Crashes
24 Jan 2000 - 26 Jan 2000 (15 posts) Archive Link: "Remove the Stack Trace..."
People: Jens Lautenbacher, Daniel Egger, Glyph Lefkowitz, Austin Donnelly, Raphael Quinet, Manish Singh, Marc Lehmann,
Jens Lautenbacher wrote to the list, saying
I would like to kindly suggest that we at least give a configure option to avoid the stacktrace stuff that happens when gimp crashes.
I'm currently developping a distributed perlfu server and it would make life much much easier if gimp would simply crash without hanging still around only due to a segfault handler.
I also remember having big problems with a segfaultet gimp started from the gnome panel (or any other non-shell commandline means) and gimp crashing while still having grabed the mouse.
I know that the stack trace thing is useful, I only want to have an option to avoid it WITHOUT the need to always fiddle the source code.
If I knew a bit more about configure (I know next to nothing) I would do it myself IF we could reach consensus that it woudl be a Good Thing(TM).
Daniel Egger noted that "Starting it with gdb will avoid the handler."
Glyph Lefkowitz agreed with Jens:
YES. Especially with the grabbed mouse. I am casting my vote for this 100%, little as it may be worth =)
Since the only advantage of this is the stack-trace for non-developers, why don't we just have it dump stack, then die, by default, unless you're running it under GDB or with a --do-annoying-stack-trace-crap option? I usually launch GIMP from a button, although nowadays I am actually running xterm -iconic -e gimp, so that when it dies I can just kill the xterm. (and hope that it wasn't grabbing the pointer...)
Austin Donnelly cast his vote for Glyph's suggestion, "This sounds sensible, but also add a check on istty(stdout) being true. No point taking forever doing a backtrace if no-one's going to see it."
Raphael Quinet corrected Austin, saying
If I am not mistaken, the call to isatty() is already done inside glib. In glib (gerror.c), if the current terminal is not a tty, then the program will immediately exit instead of asking for a stack trace or whatever.
I know a bit of configure, so if nobody else is interested in implementing this simple change (a couple of lines, I think), then I will do that tomorrow.
Manish Singh had some suggestions:
How about --enable-stack-trace=[yes/no/query] and set it to query by default. We'll set the default to no for stable releases.
This should just set the default setting that gimp uses at runtime. There should be runtime options that parallel to override.
Daniel added that "I will check the behaviour and if it really blocks when not called from a terminal I will remove this "feature" for our next distribution otherwise it will stay because it gives a good start for bugreports even if compiled without debugging information."
Marc Lehmann had some additional ideas:
The consensus was to remove it in release versions. So if the only advantage is for non-developers, why not remove it altogether?
(It must be removed from the plug-in anyway, since it cribbles over the signal handlers prepared by the plug-in, rendering signal handling useless).
BTW: the stacktrace option has never worked on my machine(s), unless you call "endless loop" working. Also, I could never get out of that signal handler. Gimp just started to suck 100% cpu time when I tried to "e"xit.
I doubt that this thing is useful for anybody (I tried it even on a stock redhat 6.1 system). It is a constant annoyance.
In another message, Marc said that
A configure option is a bad choice, simply because you cannot change it without recompiling. That means that some packages' INSTALL file will read like this:
"if you want to use this package, you need to recompile your gimp".
This impairs usefulness of gimp quite a lot, since only a minority of users will recompile their gimp.
Raphael Quinet clarified his position:
Here is how I see it:
Marc had some criticisms of Raphael's ideas:
Sorry, but _developers_ can always use gdb on the corefile. Having a signal handler just destroys the stack frame (and the backtrace) in many cases (here it almost always does).
The problem is that (shell-started) perl plug-ins always suffer from the backtrace, so a configure option wouldn't help.
Why is that signal handler installed at all, I ask? The signal destroys the stacktrace anyway. Why catch sigsegv at all? Why _exit_, and not dump core with all trace and ip information intact?
A commandline option would also have no effects on the plug-ins itself, which suffer from exactly the same problem.
I buy the argument that users can do bug reports better with an automatic stacktrace, but I don't buy that it makes it easier for developers.
Your proposal is a very good first step, and something lie that would be a workaround for the problems. However, I still think that the stacktrace code has done more harm than use, and I will never understand why mindlessly scribbling over 8 signals just because you are a gimp plug-in is ever going to help.
Daniel Egger had a solution for Marc:
You are absolutely right there.... so I would suggest disabling it for normal use and enable it for distributions....
I know you like those small patchlets... so here is your personal one... :))
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.