gimp swapfiles
hi everybody! i'm using gimp in network and in --no-interface and --batchmode ! i never exit gimp, and it generate me too many swapfiles ! how can i do to purge ths files without exiting Gimp ? thank you ! Fethi, Simply. ___ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr
Re: calling script-fu from perl script
On Sun, Sep 10, 2000 at 10:39:26PM -0500, "Michael J. Hammel"
[EMAIL PROTECTED] wrote:
Not in the current architecture. The caller is blocked until the called
plug-in has finished.
That would be the preferred design, but my tests don't seem to bear this
out. Again, I could be misinterpreting the results, though I'm fairly
certain I'm not.
You must, since if this were true we could expect a lot more breakage, but to
the contrary it's only script-fu. Also, the API for plug-ins looks like this:
function run_callback()
{
... parse agruments
... execute script
... create result values
return;
}
Only when the plug-in returns results values are passed back. There
is currently no way for a plug-in to both return from the call AND do
something.
script_fu_old_photo($drawable, 0, 1, 1, 1, 0);
Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is
passed in. Using the drawable after that was a bug in your (original) code
(this is a very common bug).
## $drawable no longer valid
$drawable = gimp_image_get_active_layer($img);
## $drawable valid again
If I remove the sleep() call then Gimp crashes
The bug here is that Gimp crashes while it shouldn't, but this is more
a cosmetic problem (it's still easy to crash the gimp using illegal pdb
calls, unfortunately).
only 1 second, various results occur. If I don't use the call to
gimp_image_get_active_layer(), with or without the delay, then Gimp crashes.
The problem seems to be that old_photo calls flatten, and this might
change a lot of internal structures. the right fix would be to make
old-photo return the newly created layer/image/whatever, but AFAIK
script-fu is unable to return anything to the caller (scirpt-fu was never
designed to be called from the outside, obviously).
tells me that the blocking you mention isn't happening. In fact, I can
watch part of the drop shadow actually being performed on the image *before*
any visible results from old_photo happen - all before Gimp crashes. Weird,
but that's what I'm seeing.
I doubt that this has something to do with the plug-in API. Most probably
some pdb function only starts the rendering (AFAIK there was some
semi-recent change to push some long-running-ops into the background, so I
guess some locking there is missing).
True. Still, my misuse of a valid drawable was unexpected for the Gimp. There
may be some error checking that could be done to prevent the crash,
Well, it's not as if a the developers didn't put a lot of effort into
argument checking. It is definitely much more difficult to crash the gimp
now than half a year ago ;)
this can't be addressed before 1.2 is released) to make a note that
serializing of calls to plug-ins from plug-ins is not guaranteed.
This is highly unlikely. the current set of perl plug-ins call a lot of
other plug-ins (including pelr ones) without a problem. I am quite certain
it's either an uncommon operation or yet another script-fu-breakage, for
example, script-fu is the only plug-in that stays in memory all the time,
even if not used, and uses temporary pdb functions instead of normally
registered calls (that's why it's so slow on startup). This could be the
key...
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Compilation and installation instructions
On Sat, 9 Sep 2000, Marc Lehmann [EMAIL PROTECTED] wrote:
On Thu, Sep 07, 2000 at 06:13:07PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
the user installing the package is not the same as the one building
it. Some of these problems have been mentioned by Michael J. Hammel
two weeks ago ("install issue over NFS").
AFAICR this was stricly perl-related. Since Sven hacked the
perl-po-process into using the "standard" mechanism now it *should*
work. Could anybody re-run the test to verify that this indeed works now?
I cannot get the latest CVS version (firewall problems) but I will
test again as soon as 1.1.26 is out. Anyway, the problems with
libgimpi.a are not specific to Perl and the CVS Changelog from Bonsai
does not mention any recent changes to the corresponding files, so I
assume that this part is still broken.
- Due to some strange hacks in libgimp/Makefile, the libgimp library
requires that you use "make" twice in order to have its dependencies
satisfied (the "evil hack" mentioned in that file does not seem to
work for me, although I am using GNU make).
Does this only happen on parallel builds or on normals builds as
well? I only gte problems when doing parallel builds (there is a
still-open-bug-report about the latter problem).
I suppose that you are refering to this bug that you reported in May:
http://bugs.gnome.org/db/11/11900.html
My problem happens on normal builds: "make" with no arguments. This
is GNU make 3.78.1 running on Solaris 2.6. I have seen the same
problem happening under several versions of Linux (also running GNU
make) and other version of Solaris, so I think that the bug affects
almost everybody. Actually, I would like to know if there is anybody
who does *not* have this problem.
Here is how to test it:
- Get a clean source tree (extract the released .tar.gz file in an
empty directory or do a "make distclean" if you are using CVS).
- Run "./configure" with your favourite options. But do not use the
option "--disable-static" because the bug is probably related to
the static libraries.
- Type "make" once.
- Type "make" a second time. If *anything* is rebuilt (specifically,
libgimp/libgimpi.a and app/gimp), then you are affected by the bug.
- The Perl plug-in incorrectly uses the installed header files instead
of using the ones coming with the package. This means that although
This comes up again and again, however, this bug has been fixed many many
many months ago.
I am sure that the bug was still there in 1.1.24 (released at the end
of June), because all Perl scripts crashed with a dynamic linking
error (missing symbol) due to the changes in libgimp. I don't know if
it is still in 1.1.25 because the Gimp header files didn't change much
since the previous version so I didn't see any errors when I installed
the new version over the old one. Do you know if the bug was fixed
between 1.1.24 and 1.1.25?
the Makefiles would be the best solution but this is probably not so
easy, especially if I do not understand the reason why these hacks
were inserted in the build system. Could anybody enlighten me?
AFAIK, at least the libgimp hacks come from the fact that libtool has had
(and still has) various bugs and design problems, and also has problems on
various platforms.
As I said in my previous message, I am willing to help fixing these
bugs, but I currently do not understand what problems the libgimpi.a
hacks are trying to solve. Is there any reason for that or is it just
because it worked once and nobody dared touching it later?
The (former) perl-po problems come from the fact that libintl doesn't
support perl, nor can it be configured without serious hacking to support
perl. What was recently done was to screw standalone po-support for perl
and make it a "only when built inside the gimp tree"-feature, so that, at
least for gimp-1.2, there are chances of working properly, at the cost of
not being able to upgrade until I reinvented the old mechanism again.
Well, it's a pity to break one of the two options, but I think that it
is better to get the compilation inside the Gimp tree working properly
even if it means that the upgrade would be a bit more difficult.
-Raphael
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 01:15:18AM +0100, Nick Lamb [EMAIL PROTECTED] wrote: If the abovce is true and the file format indeed supports this (in the spec, if any), then this is not an "error" but "valid but uncommon". Ah no, writing images to TGA with "flip-vertical" flag set is both valid and common, almost universal in fact. But not being willing or able to load top-down images like Gimps would be an uncommon error, Ah! ;) Still gimp would not support uncommon errors by giving the user more freedom. wacky things you legally _can_ write to a TGA file, I am offering the opinion that we should generally shield users from the dozens of valid yet unimportant TGA options, and set them for our convenience, as we do with TIFF. This is windows thinking a lot. Not implementing something because it is costing a lot of time would be understandable, but not offering features because the user might be too dumb is never a good idea (IMHO). [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ... [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G Make sa lot of sense to me. TGA images are a common format for programs that have special requirements (like a special layout). [ ] Mysteriously allocate but don't use colourmap [ ] Make alternate scanlines inverted for some reason [ ] Write four channels, but then only use three These are of a something different quality, though. working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Well, we could also always write png's with compression=9, for example, as the resulting image is the same in all cases ;) Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. A very good reason _not_ to is that it might be pretty unimportant, so coding these features might be a waste of time... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: calling script-fu from perl script
Thus spoke Marc Lehmann script_fu_old_photo($drawable, 0, 1, 1, 1, 0); Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is passed in. Using the drawable after that was a bug in your (original) code (this is a very common bug). True. Still, I fixed that bug and still needed a delay to prevent crashing. And the delay had to be at least 2 seconds - 1 second delays caused strange results. The problem seems to be that old_photo calls flatten, and this might change a lot of internal structures. the right fix would be to make old-photo return the newly created layer/image/whatever, but AFAIK script-fu is unable to return anything to the caller (scirpt-fu was never designed to be called from the outside, obviously). This would be better, but it still doesn't account for what I see happen - which is the second plug-in getting called before the first has finished. This is highly unlikely. the current set of perl plug-ins call a lot of other plug-ins (including pelr ones) without a problem. I am quite certain it's either an uncommon operation or yet another script-fu-breakage, for example, script-fu is the only plug-in that stays in memory all the time, even if not used, and uses temporary pdb functions instead of normally registered calls (that's why it's so slow on startup). This could be the key... I tried this test with perl-fu and C plug-in calls but couldn't reproduce it. It may be limited to calls to Script-Fu plug-ins. I'm not positive of this because few of the perl-fu and C plug-ins 1) take very long to process *and* 2) generate additional layers in the manner of Old Photo. In any case, the problem is pretty consistant with Script-Fu scripts. I tried a number of them. -- Michael J. Hammel | The Graphics Muse | If ignorance is bliss, why aren't more [EMAIL PROTECTED] | people happy? http://www.graphics-muse.com
Re: TGA plug-in patch
[EMAIL PROTECTED] (2000-09-11 at 1538.29 +0200): wacky things you legally _can_ write to a TGA file, I am offering the opinion that we should generally shield users from the dozens of valid yet unimportant TGA options, and set them for our convenience, as we do with TIFF. This is windows thinking a lot. Not implementing something because it is costing a lot of time would be understandable, but not offering features because the user might be too dumb is never a good idea (IMHO). Specially for those of use that like Unix tools cos they allow more things than other tools. If the user is Window style he knows what to do: click "OK". But I preffer choice, cos sometimes it saves your day in a few seconds. I want to open / save everything, and leave headaches for other OSs. IMHO this should not implemented now, Gimp is frozen and this can or can not be a bug (varies with personal opinion, and even if you say it is a bug, a new release would be cool anyway). But I would like to see the options in future versions. GSR
Re: Compilation and installation instructions
Thus spoke Raphael Quinet almost everybody. Actually, I would like to know if there is anybody who does *not* have this problem. Here is how to test it: - Type "make" once. - Type "make" a second time. If *anything* is rebuilt (specifically, libgimp/libgimpi.a and app/gimp), then you are affected by the bug. Just FYI - I've seen this for quite some time but didn't realize it was a problem till I tried to figure out why it didn't work across NFS. In my case, I run "make" and "make install" (the latter as root, which exposes the rebuild issue on the NFS mounted partition). I primarily noticed that perl rebuilds that .po~ file (something like that), but only because it happened to be one of the last things done during the install and happened to still be visible in the xterm. If you sit and watch the "make install" you'll see it build other things. -- Michael J. Hammel The Graphics Muse [EMAIL PROTECTED] http://www.graphics-muse.com -- He doesn't have ulcers, but he's a carrier. -- From a real employee performance evaluation.
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 04:33:13PM +0200, "Guillermo S. Romero / Familia Romero" [EMAIL PROTECTED] wrote: can not be a bug (varies with personal opinion, and even if you say it is a bug, a new release would be cool anyway). But I would like to see the options in future versions. This is a wonderful case for "he who needs it sends a patch2 ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Compilation and installation instructions
On Mon, Sep 11, 2000 at 05:20:13PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote: of June), because all Perl scripts crashed with a dynamic linking error (missing symbol) due to the changes in libgimp. This had been caused by the upgrade to the newer API, not by changes in the header files (or at leats not the usual changes ;) the new version over the old one. Do you know if the bug was fixed between 1.1.24 and 1.1.25? no, it was fixed a much longer time ago. Look at the compiler switches (here I get): gcc -c -I/localvol2/cvs/gnome/gimp/plug-ins/perl -I../../.. -I/localvol2/cvs/gnome/gimp/plug-ins/perl/../.. -I/usr/app/lib/glib/include -I/usr/app/include -I/usr/app/lib/glib/include -I/usr/app/include -I/usr/X11R6/include -I/usr/app/include -DGTK_DISABLE_COMPAT_H -I/usr/app/lib/perl5/PDL/Core -g -Os -g -pipe -mpentium -mcpu=pentium -I/usr/local/include -I/usr/app/include -fstrict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Os -funroll-all-loops -mpentium -DVERSION=\"1.201\" -DXS_VERSION=\"1.201\" -fpic -I/usr/app/lib/perl5/CORE -Ddatadir="\"/usr/app/share\"" -DHAVE_PDL=1 Lib.c the second -I points directly to topdir. A common mistake is to configure plug-ins/perl seperately, in which case the perl module will assume a standalone build, which makes it seem work, but with the described symptoms. bugs, but I currently do not understand what problems the libgimpi.a hacks are trying to solve. Is there any reason for that or is it just because it worked once and nobody dared touching it later? I think the problem is getting the overall dependency right with automake. the hack doesn't seem to be necessary on linux, but maybe on some other systems(?) and was therefore never taken out. Well, it's a pity to break one of the two options, but I think that it is better to get the compilation inside the Gimp tree working properly even if it means that the upgrade would be a bit more difficult. Well, there was only a single outstanding issue with the Makefile.PL, but the new way has the definite advantage that I am no longer directly liable for it ;- -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: TGA plug-in patch
[EMAIL PROTECTED] (2000-09-11 at 1933.24 +0200): is a bug, a new release would be cool anyway). But I would like to see the options in future versions. This is a wonderful case for "he who needs it sends a patch2 ;) He send them first. ;] GSR
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 07:33:24PM +0200, Marc Lehmann wrote: This is a wonderful case for "he who needs it sends a patch2 ;) *ahem* I thought the initial message _did_ have a patch included? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
building things twice
I just tried to reproduce it again (make distclean/configure/make, with enabled perl), and indeed, I got this on the second make run: Makefile:594: warning: overriding commands for target `makefile.mingw' Makefile:322: warning: ignoring old commands for target `makefile.mingw' rm -f libgimpi.a ar cru libgimpi.a gimpenv.o gimpchainbutton.o gimpcolorbutton.o gimpcolorspace.o gimpdialog.o gimpfileselection.o gimphelpui.o gimpmatrix.o gimppatheditor.o gimppixmap.o gimpprotocol.o gimpquerybox.o gimpsignal.o gimpsizeentry.o gimpunitmenu.o gimputils.o gimpvector.o gimpwidgets.o gimpwire.o gimpparasite.o gimpparasiteio.o ranlib libgimpi.a make[2]: Leaving directory `/localvol2/cvs/gnome/gimp/libgimp' Making all in app Makefile:599: warning: overriding commands for target `makefile.mingw' Makefile:351: warning: ignoring old commands for target `makefile.mingw' /bin/sh ../libtool --mode=link gcc -g -Os -g -pipe -mpentium -mcpu=pentium -Wall -o gimp -export-dynamic -export-symbols ./gimp.sym about_dialog.o airbrush.o app_procs.o asupsample.o batch.o bezier_select.o blend.o blob.o boundary.o brightness_contrast.o brush_edit.o brush_scale.o brush_select.o brush_select_cmds.o brushes_cmds.o bucket_fill.o by_color_select.o channel.o channel_cmds.o channels_dialog.o channel_ops.o channel_ops_cmds.o clone.o color_area.o color_balance.o color_cmds.o color_notebook.o color_panel.o color_picker.o color_select.o color_transfer.o colormaps.o colormap_dialog.o commands.o context_manager.o convert.o convert_cmds.o convolve.o crop.o cursorutil.o curves.o datafiles.o desaturate.o devices.o dialog_handler.o disp_callbacks.o display_cmds.o docindex.o dodgeburn.o draw_core.o drawable.o drawable_cmds.o edit_cmds.o edit_selection.o ellipse_select.o eraser.o errorconsole.o errors.o equalize.o fileops.o fileops_cmds.o flip_tool.o floating_sel.o floating_sel_cmds.o file_new_dialog.o free_select.o fuzzy_select.o gdisplay.o gdisplay_color.o gdisplay_color_ui.o gdisplay_ops.o general.o gimage.o gimage_mask.o gimpbrush.o gimpbrushgenerated.o gimpbrushlist.o gimpbrushpipe.o gimpcontext.o gimpcontextpreview.o gimpdnd.o gimphelp.o gimphistogram.o gimplist.o gimplut.o gimpparasite.o gimpprogress.o gimprc.o gimprc_cmds.o gimpui.o gimpunit.o global_edit.o gradient.o gradient_select.o gradient_select_cmds.o gradients_cmds.o gtkwrapbox.o gtkhwrapbox.o gtkvwrapbox.o guides_cmds.o gximage.o help_cmds.o histogramwidget.o histogram_tool.o hue_saturation.o image_cmds.o image_map.o image_new.o image_render.o indicator_area.o info_dialog.o info_window.o ink.o interface.o internal_procs.o invert.o iscissors.o layer.o layer_cmds.o layer_select.o layers_dialog.o lc_dialog.o levels.o lut_funcs.o magnify.o main.o measure.o menus.o message_cmds.o misc_cmds.o module_db.o move.o nav_window.o ops_buttons.o palette.o palette_cmds.o palette_select.o paint_core.o paint_funcs.o paintbrush.o parasite_cmds.o parasitelist.o path.o paths_cmds.o paths_dialog.o pattern_select.o pattern_select_cmds.o patterns.o patterns_cmds.o pencil.o perspective_tool.o pixel_processor.o pixel_region.o plug_in.o plug_in_cmds.o posterize.o preferences_dialog.o procedural_db.o procedural_db_cmds.o qmask.o rect_select.o regex.o resize.o rotate_tool.o scale.o scale_tool.o scan_convert.o scroll.o selection.o selection_cmds.o session.o shear_tool.o smudge.o temp_buf.o text_tool.o text_tool_cmds.o threshold.o tile.o tile_cache.o tile_manager.o tile_swap.o tips_dialog.o tool_options.o tools.o tools_cmds.o transform_core.o transform_tool.o undo.o undo_cmds.o undo_history.o unit_cmds.o user_install.o xcf.o libgimpim.a ../libgimp/libgimpi.a -L/usr/app/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lpthread -L/usr/app/lib gcc -g -Os -g -pipe -mpentium -mcpu=pentium -Wall -o gimp about_dialog.o airbrush.o app_procs.o asupsample.o batch.o bezier_select.o blend.o blob.o boundary.o brightness_contrast.o brush_edit.o brush_scale.o brush_select.o brush_select_cmds.o brushes_cmds.o bucket_fill.o by_color_select.o channel.o channel_cmds.o channels_dialog.o channel_ops.o channel_ops_cmds.o clone.o color_area.o color_balance.o color_cmds.o color_notebook.o color_panel.o color_picker.o color_select.o color_transfer.o colormaps.o colormap_dialog.o commands.o context_manager.o convert.o convert_cmds.o convolve.o crop.o cursorutil.o curves.o datafiles.o desaturate.o devices.o dialog_handler.o disp_callbacks.o display_cmds.o docindex.o dodgeburn.o draw_core.o drawable.o drawable_cmds.o edit_cmds.o edit_selection.o ellipse_select.o eraser.o errorconsole.o errors.o equalize.o fileops.o fileops_cmds.o flip_tool.o floating_sel.o floating_sel_cmds.o file_new_dialog.o free_select.o fuzzy_select.o gdisplay.o gdisplay_color.o gdisplay_color_ui.o gdisplay_ops.o general.o
Re: TGA plug-in patch
On Mon, Sep 11, 2000 at 03:38:29PM +0200, Marc Lehmann wrote: Ah! ;) Still gimp would not support uncommon errors by giving the user more freedom. Allowing users to needlessly create bizarre image files that will then cause them trouble in other packages is just _asking_ for trouble. This is windows thinking a lot. Not implementing something because it is costing a lot of time would be understandable, but not offering features because the user might be too dumb is never a good idea (IMHO). Fine, I'll put the "PC vs Mac" option back into Gimp's TIFF filter and mail you all the confused whining from users. :) working image app... I want to have a genuine REASON to add any options like this before I risk confusing users further. Well, we could also always write png's with compression=9, for example, as the resulting image is the same in all cases ;) What an appropriate choice. Check out PS 4.0 and see what the equivalent dialog says there. There sure are a lot more options in the compression section. An Adobe engineer probably spent a few hours on that dialog. Unfortunately what they come down to is that you can choose to make PS4 do a lot worse than Gimp, or nearly as good. Since Gimp is already as good as Gimp, having options to make it worse seems pointless, no? Photoshop 5.0 abandons the unnecessary extra options AFAIK. Still, your point is taken, some behaviour that's not directly visible to the user needs to be reflected in the options. I agree, but it's not universally true that more options is good. Still, a good reason may be forthcoming and if it is I'll happily integrate this patch or one like it. A very good reason _not_ to is that it might be pretty unimportant, so coding these features might be a waste of time... Some options do not appear to buy anything except additional code complexity. I differ with Marc here, I don't mind coding it, but I do object to untested code paths. I'm not going to write a test suite to check the umpty-zillion possible alternatives if we try all the options. So even though this TGA patch is "free", I still don't expect to apply it without a good reason. Nick.
Re: TGA plug-in patch
Including a nine yard long list of options in every dialog is bad. But let us not forget that we have a rich legacy of Unix heritage to uphold. What that means to me is giving the power user the option of taking enough power to burn out every synapse in her body, if she so desires... just don't make it *too* easy for her to get at it. The PDB is a terrific junk heap of an interface. If you want to provide some obscure options, I think that's the place to do it. Anyone weird enough to want them can homebrew (and/or distribute) a script to use what's there. And the rest of us, who see in the red-to-violet spectrum, have no more than two eyes per head, and have deep-seated notions about which way is "up", will keep control of the mainstream interface for our own selfish desires. This message has been sponsored in part by the "Software for Terrans" campaign, Keeping Free Software Free -- for Humans. -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [EMAIL PROTECTED]
