Hi,

Valter Mazzola writes:

This script isn't able to save correctly the logo in png format, i've tried othe formats but seesm there are bug in gimp.

I'd say the bug is in your script. But then you could argue that the bug is in gimp-perl since it's syntax defers from the one that is documented :-(

file_png_save(RUN_NONINTERACTIVE, $img, $activelayer, $fname, $fname, 0, 9, 0, 0, 0, 0, 0);

in gimp-perl, you need to omit the image if the drawable ($activelayer) is already specified.

Salut, Sven

On Mon, Feb 24, 2003 at 06:38:42PM +0100, Sven Neumann wrote:

I'd say the bug is in your script. But then you could argue that the bug is in gimp-perl since it's syntax defers from the one that is documented :-(

I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work.

Also, it should be clear even to you that some languages look diferent to others. I remember that a PDB call uses different syntax in C than in script-fu, for example.

Yes, both might be documented, and the same is true for the perl interface. Since you certainly _are_ aware of all that, what's your point?

Maybe I should add dummy array-length arguments to all calls involving arrays, because other languages can't handle that?

file_png_save(RUN_NONINTERACTIVE, $img, $activelayer, $fname, $fname, 0, 9, 0, 0, 0, 0, 0);

in gimp-perl, you need to omit the image if the drawable ($activelayer) is already specified.

Actually, you don't. Actually, the script works fine on a standard debian installation (gimp-1.2 1.2.3-2, with the debian gimp-pelr etc..), WHEN I add sleeps at the right place.

What's buggy is, again, script-fu, which returns long before the script has run. And the script doesn't work unless you create another image, because it doesn't like image ids of zero.

The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever). But obviously it's much more fun to blame gimp-perl for bugs in script-fu, or claim thats cript-fu was never written to be used as a gimp-plug-in, or other fun stuff.

Boys, I am really fed up with that never-ending and mindless perl-bashing. If you can't try to help people without shoveling mistakes and bugs around, then please, keep your mouth shut. Or at leats use your brain once in a while.

Blaming perl is *not* the solution. Blaming script-fu *is* right.
Fixing script-fu *is* the solution.

Hi,

writes:

I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work.

sorry, I heard that it wouldn't work and I remembered the PDB explorer to document the "rather idiotic" PDB-syntax.

What's buggy is, again, script-fu, which returns long before the script has run. And the script doesn't work unless you create another image, because it doesn't like image ids of zero.

The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever).

I don't remember to have seen a bug-report about this. If it would have been reported we might have even looked into fixing it in the meantime. I'm not sure however if we will ever manage to fix all Script-Fu problems since it has indeed some rather fundamental flaws.

Salut, Sven

Hi,

when I saw your mail, I remembered that I haven't yet told you that we finally moved gimp-perl out of the gimp HEAD branch into its own CVS module called gimp-perl. Hoepfully someone will find the time to resurrect its functionality and make it work with GTK+-2.x and GIMP-1.3.

Salut, Sven

On Wed, Feb 26, 2003 at 07:53:31PM +0100, Sven Neumann wrote:

I would prefer if people who could know it better would stop claiming such bullshit. The perl-syntax is well-documented, and even if you insist on using the rather idiotic PDB-syntax, it does work.

sorry, I heard that it wouldn't work and I remembered the PDB explorer to document the "rather idiotic" PDB-syntax.

Well, sure, but even if you believed that there was no reason to write what you wrote. So what are you sorry for? You do that in about every mail that has something to do with perl, in case you didn't realize it.

The only solution is to avoid script-fu whereever possible. It has been horribly buggy since many years (I don't remember it being working ever).

I don't remember to have seen a bug-report about this.

I think it gets reported here or on gimp-user every few months since at least 2000. You probably ignored it because there is often perl code in it, and it's easy to dismiss it as yet another perl problem. It's basically become a FAQ even.

meantime. I'm not sure however if we will ever manage to fix all Script-Fu problems since it has indeed some rather fundamental flaws.

That's true, and I can fully understand that. What I cannot understand is why you reflect these problems on perl again and again.

On Wed, Feb 26, 2003 at 10:24:13PM +0100, Valter Mazzola wrote:

i'm using mandrake 9.0 and gimp 1.2.3 , removed mail() in exit, but the saved logo is totally different than the gimp do interactively.

Try to call flatten on the resulting image before saving ($image->flatten). If that doesn't help, then add a sleep 3 or so after the call to script-fu and keep your fingers crossed.

If that doesn't help either you might look at scm2perl and convert the scheme plug-in to perl (followed by a lot of small adjustments, as script-fu scripts are often rather unclean, due to the lakc of type-safeness of the language).

ok but io want to create logos using existing script-fu logo script? it's possible ????

With a lot of hacks, it's usually possible. But it often depends on the particular script. It also sometimes helps to open a new image+drawable before calling script-fu, as some scripts seem to have problems with image or drawable ids of zero. Equally often it helps to not have any windows open, as some scripts only work _if_ they open the very first image and/or drawable.

Most of these _should_ problems be fixed in 1.2.3, but some probably were overlooked, and debugging these scripts is no fun.

I want to do serious scripting work with gimp, similar to cool text.com, can you help me to decide in what direction i should go ?

Maybe ask whoever does cooltext.com, they certainly had either similar problems or do it difefrently (e.g. with the script-fu server, however, don'T use it unless you have properly firewalled it).

I have not obtained deterministic results till now.

That's, indeed, what most people find out quickly when they get in contact with script-fu.

Script-fu, perl-fu , interactions between them, outdated documentations ???

I am sorry, you must be fairly confused by now ;) Actually, it's because script-fu doesn't really behave like any other gimp plug-in. The fact that nobody regularly calls script-fu in normal work (there are few, if any, generic script-fu scripts, so there is rarely need to call them from other plug-ins) obviously made script-fu very low priority over the years.

The only people who do call script-fu from a plug-in are mostly people who write logo-generators (like you do), and they often use perl.

On Wed, Feb 26, 2003 at 07:56:05PM +0100, Sven Neumann wrote:

when I saw your mail, I remembered that I haven't yet told you that we finally moved gimp-perl out of the gimp HEAD branch into its own CVS module called gimp-perl. Hoepfully someone will find the time to resurrect its functionality and make it work with GTK+-2.x and GIMP-1.3.

Well, I must admit that I am not really keen on working on gimp-perl in gimp-cvs anymore, anyways. The continuous mobbing made the air somewhat bigheaded up there.

On Wed, 26 Feb 2003 22:24:13 +0100, Valter Mazzola wrote:

ok but io want to create logos using existing script-fu logo script? it's possible ????

Yes. One solution that does work with the current and future versions of the GIMP is to write your whole script in Script-Fu. Do not try to call Script-Fu from Perl (or from any other plug-in, for that matter) because you will not get the expected results. Instead, write everything in Script-Fu and you will get your logo as expected.

Note that I am not engaging in any kind of Perl-bashing here: Perl is my language of choice whenever I have to write some scripts or even some rather complex programs. But as it stands currently, Gimp-Perl has some problems (some of them inherited from Gtk-Perl bugs on some platforms, some others due to the build/install process and some others due to the fact that it is not maintained anymore) and will probably not be included in the next release of the GIMP. So although Perl is a fine language, the safest solution for the moment is to use Script-Fu, which is less powerful but works well with the current and future versions of the GIMP.

The bug report describing the incorrect behavior of Script-Fu when called from other plug-ins can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=50649

So the short but confusing conclusion is: - Script-Fu is broken (bug #50649)
- Gimp-Perl is broken and is not maintained - The problem you see is mainly due to the script-fu bug mentioned above and not to a problem in Perl, but the best solution is to use Script-Fu only.

-Raphaël

On Thu, 27 Feb 2003 14:37:36 +0100, Valter Mazzola wrote:

Dear Raphaël

can you make an example script that calls a script-fu- logo scripts and save it?

for example this one doesn't save correctly the image:

(begin (let*
(
(image (car ( (script-fu-alien-glow-logo "hello hello" 150 "-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*" '(255 0 0)) )) ) ; (image (car (gimp-file-load 0 "/root/clock.gif" "/root/clock.gif"))) (drawable nil)
)

(set! drawable (car (gimp-image-flatten image))) (gimp-file-save 1 image drawable "/root/a.png" "/root/a.png") (gimp-image-delete image)
) ;let
)

There are a few problems in your script, such as the extra parenthesis before the call to script-fu-alien-glow-logo. Also, one thing that is not really obvious is that the script returns one more than the index of the new image (don't ask me why). So here is a modified version of the script that should work:

(define (script-fu-blahblah outfile) (let* ((img (- (car (script-fu-alien-glow-logo "hello hello" 150 "-*-utopia-bold-r-*-*-150-*-*-*-*-*-*-*" '(255 0 0))) 1)) (drawable (car (gimp-image-flatten img)))) (gimp-convert-indexed img 1 0 255 0 1 "") (file-png-save 1 img drawable outfile outfile 0 9 0 0 0 0 0)))

You can also register this script in the menus:

(script-fu-register "script-fu-blahblah" "/Xtns/Script-Fu/Blahblah"
"Blah blah blah!"
"me"
"me"
"2003-02-27"
""
SF-FILENAME "Outfile" "outfile.png")

Or if you want to invoke it directly from the command line in batch mode, then you can replace the "(define ...)" with "(begin ...)" as you did in your example and directly replace the value of "outfile" with the name of the file in which you want to save the results.

-Raphaël

On Thu, Feb 27, 2003 at 02:04:51PM +0100, Raphaël Quinet wrote:

Note that I am not engaging in any kind of Perl-bashing here: Perl is my

Indeed, you aren't. However, you get a lot of things wong:

- Gimp-Perl is broken and is not maintained

Well, I don't know of anything like "gimp-perl is broken". I think that build problems that are due to people using the wrong compiler (like on irix), or problems with gtk-perl (that I am still not aware of) do not warrant such wording as "gimp-perl is broken".

Also, gimp-perl not being maintained is news to me. Who claims this?? I was under the impression that I was the maintainer, and I certainly still maintain it. Where do you have this "gimp-perl is not maintained"? Or has the maintainer silently changed without the maintainer knowing it?

I really wonder what is going on here, but there is a great deal of confusion and misinformation going on...

On 2003-02-28 at 0102.48 +0100, Marc A. Lehmann typed this:

I really wonder what is going on here, but there is a great deal of confusion and misinformation going on...

i miss the perl plug-ins in gimp-1.3.

are the developers, like me, waiting for someone to make gtk2 perl work?

carol

Hi,

writes:

Well, I must admit that I am not really keen on working on gimp-perl in gimp-cvs anymore, anyways. The continuous mobbing made the air somewhat bigheaded up there.

Marc, there has been no mobbing going on (despite your continous ranting perhaps). There are two reasons for moving gimp-perl into a separate module:

(1) It doesn't work with GIMP-1.3 and noone seemed to work on getting this fixed. Since we want to release soon, we were forced to do something. Having gimp-perl in a seperate module allows to have it maintained independently of the main GIMP package.

(2) There are a couple of severe problems with the build that have been outstanding for a very long time and noone did anything about them. In particular I'm speaking of:

http://bugzilla.gnome.org/show_bug.cgi?id=20052 http://bugzilla.gnome.org/show_bug.cgi?id=35694 http://bugzilla.gnome.org/show_bug.cgi?id=79751 http://bugzilla.gnome.org/show_bug.cgi?id=81791 http://bugzilla.gnome.org/show_bug.cgi?id=104726

I expect that some of these problems are more easily fixed in a separate module since integration of the perl build environment into the GIMP build environment has proven to be non-trivial.

Salut, Sven

On Fri, 28 Feb 2003 01:02:48 +0100, wrote:

On Thu, Feb 27, 2003 at 02:04:51PM +0100, Raphaël Quinet wrote:

- Gimp-Perl is broken and is not maintained

Well, I don't know of anything like "gimp-perl is broken". I think that build problems that are due to people using the wrong compiler (like on irix), or problems with gtk-perl (that I am still not aware of) do not warrant such wording as "gimp-perl is broken".

Even if the problems were only due to the build/install process, I think that it would be appropriate to say that "gimp-perl is broken". The result is that it is not possible for some users to use gimp-perl. And although gimp-perl works for most people in the 1.2.x releases, this is not the case for GIMP 1.3.x, in which gimp-perl is really "broken". I am not blaming you for that, but the current version is simply not working.

Some of the build or installation problems are not specific to gimp-perl and are shared by all programs that have to install Perl modules. One example that comes to my mind is that most UNIX systems other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl with the OS (pre-installed or available as an optional package). This version is compiled with the vendor's compiler, which is not installed by default. Those who do not want to pay extra for the vendor's compiler install some version of gcc. But then this causes problems while compiling or linking Perl modules because the compilers are different. Another problem is for non-root users who install everything in a non-standard directory but still have problems with the Perl modules that cannot be installed because the user does not have write access to the Perl directories. It is possible to avoid these problems by building and installing a second version of Perl or by installing the Gimp-Perl files in a private directory and playing with @INC, but this is not trivial.

From that point of view, it would make sense to distribute the Perl

plug-ins as a separate package. Regardless of its merits, this part of the GIMP has typically caused more installation problems than the other parts. Distributing it separately will ensure that more people can easily get a basic GIMP installation working.

Now, regarding the problems with Gtk-Perl, this is something that I experienced: I tried to fetch it from CPAN and build it on Solaris 2.6, using Perl 5.8.0. I got many errors while compiling and linking. In the end, it compiled but I got random crashes in any script that was using the Gtk module. I spent a few hours trying to fix that, but in the end I gave up. Also, the current version of Gtk-Perl has lots of optional dependencies on various GNOME components, libxml and other things. It also depends on XML::Writer and XML::Parser. Since this system did not have any of these, I had to supply a nice list of options (the order of some of them is significant): o conf makepl_arg "--without-gtkhtml --without-gtkglarea --without-gdkimlib --without-gtkxmhtml --without-gnome --without-gnomeprint --without-applets" So building Gtk-Perl is not very easy. It works on Linux, though (with the old GTK+ 1.2.10).

Also, gimp-perl not being maintained is news to me. Who claims this?? I was under the impression that I was the maintainer, and I certainly still maintain it. Where do you have this "gimp-perl is not maintained"? Or has the maintainer silently changed without the maintainer knowing it?

Of course, you are still the maintainer. But in practice, the Perl part in GIMP 1.3 is not actively maintained. Currently, it just does not work with the current versions of libgimp, GTK+ 2.x, etc. Also, I just saw Sven's message listing some of the bugs that are still open. Those affected by these bugs are probably thinking that the Perl part is not actively maintained. This happens to other parts of the GIMP as well: there are several long-standing bugs in some plug-ins or parts of the core. Even if they have an official maintainer, there is not much happening in some areas.

I really wonder what is going on here, but there is a great deal of confusion and misinformation going on...

I don't think that it is intentional.

-Raphaël

On Fri, Feb 28, 2003 at 01:06:41AM -0500, Carol Spears wrote:

On 2003-02-28 at 0102.48 +0100, Marc A. Lehmann typed this:

I really wonder what is going on here, but there is a great deal of confusion and misinformation going on...

i miss the perl plug-ins in gimp-1.3.

Well, the whole disucssion was about gimp-1.2, and it certainly works for that version (the current release, btw).

gimp-perl indeed does not work with the cvs gimp.

On Fri, Feb 28, 2003 at 01:53:59PM +0100, Raphaël Quinet wrote:

Even if the problems were only due to the build/install process, I think that it would be appropriate to say that "gimp-perl is broken". The result is that it is not possible for some users to use gimp-perl. And although gimp-perl works for most people in the 1.2.x releases, this is not the case for GIMP 1.3.x, in which gimp-perl is really "broken". I am not blaming you for that, but the current version is simply not working.

Sorry, but your definition is simply useless. Gimp itself (and any other software package) does not work for many users, and calling every software package "broken", while, according to your definition, would be true, is simply not useful. It really makes no sense to define "broken" as "every software package in existence". If people would use such a useless definition they would have no way of talking about "really" broken software, since the word "broken" would have no information content whatsoever.

other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl while compiling or linking Perl modules because the compilers are different.

Well, this is obviously a configuration problem on the system in question. Nobody would assume that it should work to link windows dlls together with glibc and get something useful out of it, or configure gimp with compiler switches the compiler can't understand. The fix is to fix the configuration. Nothing is broken, it all works fine if the build environment is non-broken.

Another problem is for non-root users who install everything in a to the Perl directories. It is possible to avoid these problems by building and installing a second version of Perl or by installing the

It's also possible to avoid this problems by setting the prefix, nothing complicated like you say is neccessary.

From that point of view, it would make sense to distribute the Perl

plug-ins as a separate package.

It makes sense from a social standpoint, too. It might get rid of occasions where some of the main gimp developers who obviously have a problem with the language perl can spread FUD.

Now, regarding the problems with Gtk-Perl, this is something that I experienced: I tried to fetch it from CPAN and build it on Solaris 2.6, using Perl 5.8.0.

Well, gtk-perl, while extremely useful, is not neccessary to build gimp-perl. Many people use scripts to remotely control the gimp (and gimp-perl is about the only secure way to do that, afaics), and a gui is often not necessary for server operation.

Those affected by these bugs are probably thinking that the Perl part is not actively maintained.

Well, I can't help that. The problem is that people who DO KNOW THIS spread misinformation, which doesn't at all help these people. It's one thing when people are misinformed because they don't get information, it's a completely different thing if people get told that "gimp perl is unmaintained and broken" by people whom they assume are authorities on the subject, while the opposite is the case.

as well: there are several long-standing bugs in some plug-ins or parts of the core. Even if they have an official maintainer, there is not much happening in some areas.

Yes, gimp is simply broken, according to your definition. This of course also included version 1.2.

I don't share your definition of broken, though, and I think gimp-1.2 is not really broken.

I also think your definition is not at all understood by most users, so telling them "gimp is broken" is not helping them in any way, they will just get confused.

This is *backwards*.

confusion and misinformation going on...

I don't think that it is intentional.

Well, maybe not, but I am pretty sure that your claiming that everything is broken is not helping users.

On Fri, Feb 28, 2003 at 11:12:57AM +0100, Sven Neumann wrote:

Marc, there has been no mobbing going on (despite your continous

Just about every of your mails you wrote that has anything to do with gimp-perl contains some (usually little) amounts of FUD. It might not be intentional, but it's scary that people like you have the need for this.

If you feel that I am ranting unwarranted then I cannot help you. Despite me telling you a lot olf times ("rants"), you continue spreading FUD. Since I regard you as the main gimp developer right now, I take this as an official sign to really go away.

I mean, I told you... you give a shit and continue... What else can I do to make you behave less anti-social?

ranting perhaps). There are two reasons for moving gimp-perl into a separate module:

I don't question these reasons at all, btw. Moving gimp-perl, however, is not the reason why I felt mobbed at all.

(2) There are a couple of severe problems with the build that have

I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me).

I expect that some of these problems are more easily fixed in a separate module since integration of the perl build environment into the GIMP build environment has proven to be non-trivial.

Well, this is true, but this is also partly because people who go in and change things fix most of the plug-ins but don't even attempt to do a one-line variable change inside gimp-perl.

Hi,

writes:

(2) There are a couple of severe problems with the build that have

I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me).

it seems we suffer from the same problem: I've told you about these problems several times and it seems you forgot about it. So did I forget that there was a problem calling Script-Fu from anything but Script-Fu. Perhaps us two just have too many things to care about...

Salut, Sven

On Fri, Feb 28, 2003 at 06:07:22PM +0100, Sven Neumann wrote:

Hi,

writes:

(2) There are a couple of severe problems with the build that have

I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me).

it seems we suffer from the same problem: I've told you about these problems several times and it seems you forgot about it.

It seems this is wrong and only you forgot about it. I went through all bug reports you ever told me about and fixed, or at leats tried to fix them in good faith. I remember having given you feedback on them, too, but maybe in the last year or so some mails slipped through, I don't know.

forget that there was a problem calling Script-Fu from anything but Script-Fu.

Well, you keep forgetting it, don't you? In any case, arguing about open bug reports (that are long fixed) isn't going to get us anyhwere.

Perhaps us two just have too many things to care about...

Perhaps. But I don't go out in the public and keep claiming wrong things when I _know_ that I _do not_ know.

http://bugzilla.gnome.org/show_bug.cgi?id=20052

This bug report is rather outdated and supposedly fixed since MANY years.

http://bugzilla.gnome.org/show_bug.cgi?id=35694

Same issue here.

http://bugzilla.gnome.org/show_bug.cgi?id=79751

Oops, this is certainly not something you told me about ever.

http://bugzilla.gnome.org/show_bug.cgi?id=81791

This also is rather valid - I missed the change from overwriting prefix to destdir.

http://bugzilla.gnome.org/show_bug.cgi?id=104726

Well, this is another case of broken compilation environment (gcc doesn't support the native asm syntax and compiler switches).

In any case, the two bugs are really easy to fix - I don't think you ever told me about those.

Yes, it's not at all your duty to tell me about these - I am not at all arguing about that, or wanting you to invest even more time and work.

My problem is that you are investing too much time with misinformation - something that is relatively easy to avoid, especially since I do tell you about this regularly (oh sorry, for you it's ranting - no wonder you keep ignoring it).

On Fri, 28 Feb 2003 16:19:01 +0100, wrote:

(2) There are a couple of severe problems with the build that have

I didn't know this (but I don't use the bugtracker, since despite a lot of tries I never got an account there, so it's rather useless for me).

Strange. I had no problem creating an account some time ago: http://bugzilla.gnome.org/createaccount.cgi Submitting your e-mail address using this form is the only thing you need to be able to add comments to any bug report. If you also want to be able to confirm bug reports, to close them or to re-assign them, then you should send a request to bugmaster@gnome.org after you account has been created. It may take a couple of days before this request is honored, but in the meantime you can already use your account to add your comments in any bug report.

-Raphaël

On Fri, 28 Feb 2003 09:52:18 +0100, Valter Mazzola wrote:

Your script is
Perfect Raphaël !

Thanks!

I've other questions:
1) When i run the script, i've a gimp window with the image created. I want to close it before leaving the script, I've done a (gimp-delete-image img) BUIT WITH NO effects.

Search in the DB browser for "gimp-display-delete". This is probably what you want. Leep in mind that an image can have multiple views/displays.

2) Can i activate gimp with no visual interface at all AND the script-fu server from the command line and but in in background under linux ?

Hmmm... If "gimp -i" or "gimp --no-interface" does not do what you want, you can run it with a virtual display such as Xvfb. This is explained in this tutorial: http://gug.sunsite.dk/tutorials/tomcat17/

Also, search for "server" in the DB browser. You will find the documentation of "extension-script-fu-server".

-Raphaël

Hi,

writes:

http://bugzilla.gnome.org/show_bug.cgi?id=20052

This bug report is rather outdated and supposedly fixed since MANY years.

Now closed at your request.

http://bugzilla.gnome.org/show_bug.cgi?id=35694

Same issue here.

Same here.

http://bugzilla.gnome.org/show_bug.cgi?id=79751

Oops, this is certainly not something you told me about ever.

I certainly did; I even added your email to the Cc: which should have caused bugzilla to send you an email about it.

http://bugzilla.gnome.org/show_bug.cgi?id=81791

This also is rather valid - I missed the change from overwriting prefix to destdir.

If you ever come around to fix this, will you please notice us about your change so we can avoid to have the bug-report open for some more years.

http://bugzilla.gnome.org/show_bug.cgi?id=104726

Well, this is another case of broken compilation environment (gcc doesn't support the native asm syntax and compiler switches).

Now closed as invalid.

Yes, it's not at all your duty to tell me about these - I am not at all arguing about that, or wanting you to invest even more time and work.

I'm sure you know how to query Bugzilla for the gimp-perl component of the gimp module.

Salut, Sven

PS: Thanks to the three bugs closed due to our little flame-war we are now down to rank 7 in the Bugzilla Hall of Shame (http://bugzilla.gnome.org/weekly-bug-summary.html). Thanks! :-)

On Fri, 28 Feb 2003 16:11:46 +0100, wrote:

On Fri, Feb 28, 2003 at 01:53:59PM +0100, Raphaël Quinet wrote:

Even if the problems were only due to the build/install process, I think that it would be appropriate to say that "gimp-perl is broken". The result is that it is not possible for some users to use gimp-perl. And although gimp-perl works for most people in the 1.2.x releases, this is not the case for GIMP 1.3.x, in which gimp-perl is really "broken". I am not blaming you for that, but the current version is simply not working.

Sorry, but your definition is simply useless. Gimp itself (and any other software package) does not work for many users, and calling every software package "broken", while, according to your definition, would be true, is simply not useful. It really makes no sense to define "broken" as "every software package in existence". If people would use such a useless definition they would have no way of talking about "really" broken software, since the word "broken" would have no information content whatsoever.

Well, OK, this is a rethoric issue. But this part of my comment started with "Even if the problems were only due to...". The other part of my comment was about GIMP 1.3.x. This is the part in which Gimp-Perl is really "broken" because nobody can use it. Although the last stable version is still GIMP 1.2.3 (soon 1.2.4), we are having this discussion on the developers' mailing list so I would expect that most subscribers care about the status of the current version, which is GIMP 1.3.x (or CVS HEAD). GIMP 1.3.x will hopefully become the next stable relase during this year, and it does not have a working Gimp-Perl yet.

other than Linux (Solaris, IRIX, AIX, etc.) include a version of Perl while compiling or linking Perl modules because the compilers are different.

Well, this is obviously a configuration problem on the system in question. Nobody would assume that it should work to link windows dlls together with glibc and get something useful out of it, or configure gimp with compiler switches the compiler can't understand. The fix is to fix the configuration. Nothing is broken, it all works fine if the build environment is non-broken.

This issue is not as simple as you make it look like. It may be possible (but not necessarily easy nor elegant) for the Gimp-Perl Makefile to switch compilers and compiler flags depending on what part of the code is being compiled. Using always the compiler flags provided by Perl is not necessarily a good idea, especially if the user does not have access to the compiler that was used for compiling Perl. This may require some tricks (such as extracting the right flags for -I, -L and so on) but it may solve some of the problems as long as the object files from different compilers can be linked together.

Also, I could also argue that your definition of a "non-broken" environment is a bit too strict. Except for Perl modules, there are no problems in compiling and linking some software with libraries produced by different compilers. It's not as if we were trying to link windows dlls and glibc together: here we are talking about linking object files and libraries that are designed for the same platform and use the same basic format (ELF, for example).

So for many people (again, mostly on non-Linux platforms), Gimp-Perl is the part in which the GIMP build process breaks. The other plug-ins depend only on simple libraries such as the JPEG or PNG libraries and there are usually less problems with that (regardless of the compiler used). As I wrote in my previous message, this problem is due to the way Perl modules are built and it is not specific to Gimp-Perl. The same problems can also occur when trying to build mod_perl for Apache, for example. It may be possible to implement some hacks in Gimp-Perl that allow it to work regardless of the compiler used, but this will not be easy.

Another problem is for non-root users who install everything in a to the Perl directories. It is possible to avoid these problems by building and installing a second version of Perl or by installing the

It's also possible to avoid this problems by setting the prefix, nothing complicated like you say is neccessary.

Yes, that's what I mentioned in the next line of my reply (which you unfortunately forgot to include in your quote): it is possible to install the modules in a separate directory, but then you have to make sure that it appears in @INC. So you may have to set the environment variable PERL5LIB.

[...]

confusion and misinformation going on...

I don't think that it is intentional.

Well, maybe not, but I am pretty sure that your claiming that everything is broken is not helping users.

I understand your frustration about this. Anyway, I hope that you will be able to solve the problems with Gimp-Perl in CVS.

-Raphaël

On 28 Feb 2003, at 18:35, Raphaël Quinet wrote:

On Fri, 28 Feb 2003 16:19:01 +0100, wrote: > > (2) There are a couple of severe problems with the build that have > > I didn't know this (but I don't use the bugtracker, since despite a lot of > tries I never got an account there, so it's rather useless for me).

Strange. I had no problem creating an account some time ago: http://bugzilla.gnome.org/createaccount.cgi Submitting your e-mail address using this form is the only thing you need to be able to add comments to any bug report. If you also want to be able to confirm bug reports, to close them or to re-assign them, then you should send a request to bugmaster@gnome.org after you account has been created. It may take a couple of days before this request is honored, but in the meantime you can already use your account to add your comments in any bug report.

I vaguely remember that Bugzilla needed JavaScript or Cookies or some other extra technology to be enabled before you could use it. It's not set-up very well.

On Fri, Feb 28, 2003 at 08:05:04PM +0100, Raphaël Quinet wrote:

Please don't call this rethorics - if you do, you are measuring different things differently, which is not at all fair.

this discussion on the developers' mailing list so I would expect that most subscribers care about the status of the current version, which is GIMP 1.3.x (or CVS HEAD). GIMP 1.3.x will hopefully become the next stable relase during this year, and it does not have a working Gimp-Perl yet.

Actually, we were having this discussion with somebody who uses gimp-1.2, and for whom gimp-perl _does_ work, as much as you can expect, that is.

gimp-developers is IMHO well-suited for discussion about gimp-1.2, otherwise there would be no forum for bugfixes etc. with respect to gimp-1.2, and people certainly do care about fixing bugs and devloping gimp-1.2 into an even more stable form.

This issue is not as simple as you make it look like. It may be possible (but not necessarily easy nor elegant) for the Gimp-Perl Makefile to switch compilers and compiler flags depending on what part of the code is being compiled.

On IRIX, it isn't (compilers _are_ link-incompatible). On other platforms you will find that just switching compiler flags won't help, as perl uses different versions of it's macros depending on compiler and configuration, and will not work properly no matter what.

And I don't at all think it's reasonable to get this to work anywhere, since, if NO perl module can be compiled, then the right place to fix it is not in gimp-perl, but in the general configuration (And it's easy, just supply your own version of perl that is capable of compiling and linking).

I mean, I simply don't see why a perl module should be able to reconfigure an already instaleld perl on every possible configuration, when this configuration step is done by perl already - duplicating it is just a maintainance nightmare, and won't help other modules. I mean, it's way easier to just ship perl together with gimp and always use it's own version....

Also, I could also argue that your definition of a "non-broken" environment is a bit too strict. Except for Perl modules, there are no problems in compiling and linking some software with libraries produced by different compilers.

Well, if _no_ perl module (that uses non-perl code) can be installed on that environment, I think it's "broken", in the sense that you can't build perl modules.

It's still way less strict than your definition of broken, though.

It's not as if we were trying to link windows dlls and glibc together: here we are talking about linking object files and libraries that are designed for the same platform and use the same basic format (ELF, for example).

No, we are talking about _source_ configured for a particular compiler and things like building dynamic objects, which is not very common (it's not the same as building a shared library, for example), and certainly differes a lot between platforms. Especially when you find that some platforms have funny dependency issues regarding which shared library is linked with which dynamic object to which binary. HPUX is the prime offender, but even "sane" ELF machines like IRIX all need various compiler-specific workarounds (not to mention n32 vs. n64 vs....).

So for many people (again, mostly on non-Linux platforms), Gimp-Perl is the part in which the GIMP build process breaks.

Yes, so gimp is broken (according to your definition). However, the same logic applies to a compiler that cannot compile gimp because it requires pre-iso-c89 or has bugs that keep it from working.

In any case, it's not reasonable to be able to build gimp-perl with a perl that isn't able to build any modules. No matter how you argue, I fail to see why this should be different - if a user cannot supply a working perl, he should --disable-perl or ask thed evelopers to try and _detect_ this case and diable it.

The expectation to make a perl module work with a broken installation of perl (which I define as: perl modules can't be build because the compiler is missing) is and will always be unreasonable.

Mind you, I have IRIX and hpux machines, and gimp-perl _works_ _fine_ on them. So your claim that users can't use it on these machines is wrong. You just have to provide the build environment to build perl modules, and if you don't have the compiler, then provide gcc and a perl that works with it.

Especially on irix, where the bundled perl is old and doesn't work properly with many of irix' own scripts.

plug-ins depend only on simple libraries such as the JPEG or PNG

Yes, perl is not a library at all. it's rather big and rather optimised for it's build environment.

For example you wouldn't expect to be able to link with a libjpeg if you used a different header file than the one supplied (it checks for structure sizes etc. at runtime, but it's no fun).

mod_perl for Apache, for example. It may be possible to implement some hacks in Gimp-Perl that allow it to work regardless of the compiler used, but this will not be easy.

It really is not feasible on most platforms (exceptions probably do exist), and a much easier fix is available: just fix your perl, or don't use gimp-perl.

It's also possible to avoid this problems by setting the prefix, nothing complicated like you say is neccessary.

Yes, that's what I mentioned in the next line of my reply (which you unfortunately forgot to include in your quote): it is possible to install the modules in a separate directory, but then you have to make sure that it appears in @INC. So you may have to set the environment variable PERL5LIB.

Well... What do you expect? That perl does a "find /" and looks for modules everytime it is run? If you want to be funny and move files around then you should be happy if you cna get it to work.

I mean, what you are talking about is the same as moving gimps library files to a completely different location without gimp telling it - is it really possible? (Just for a test, move the scripts and libgimp* away and check).

It's simply not reasonable to have this working magically. If youc all it broken then, please, apply the same deifnitino to gimp or other projects - I am sure you will find out nobody will share your peculiar definition of broken.

Mind you, my problem is telling people who have a working gimp-1.2 + a working gimp-pelr that gimp-perl is "broken". That's not a big disservice to these people, as it doesn't help them.

I understand your frustration about this. Anyway, I hope that you will be able to solve the problems with Gimp-Perl in CVS.

As I said, I don't think I will work with the gimp in cvs anymore, but I sitll plan to support gimp-1.4 with gimp-perl (most probably by using the Gtk module with gtk-1.2).

On Fri, Feb 28, 2003 at 06:35:26PM +0100, Raphaël Quinet wrote:

Strange. I had no problem creating an account some time ago: http://bugzilla.gnome.org/createaccount.cgi

Well, I registered a long time ago (I think under a differrent URL). The problem is:

then you should send a request to bugmaster@gnome.org after you account

I originally was referred to martin baulig (I think), and tried to contact him, to no avail (yes, that's years ago). The I was refrred to one other person (who also didn't respond). I also tried the above address, but nothing happened, either.

I might try again (and would probably succeed eventually), but I tried once a year in vain (not last year), and I am somewhat... tired :()

You know, I am really frustrated by this "developer community". I would have hoped that people like sven (or you, even if it's not your intent) eventually would stop their (mild) perl-bashing, but it's not at all fun to try to dveelop within a community that shows you again and again that they don't care for your project, spread misinfirmation (wether by intent or not), and generally aren't helpful.

Really, claiming gimp-perl is broken despite soo many people using and relying on it for years _was_ wearing me out.

On Fri, Feb 28, 2003 at 08:30:09PM +0100, Branko Collin wrote:

I vaguely remember that Bugzilla needed JavaScript or Cookies or some other extra technology to be enabled before you could use it. It's not set-up very well.

Just another FUD example.

You don't need JS (though it may improve user experience in a few places).

You need cookies to log in, so you generally need cookies to change anything (what brower do you use? bugzilla works even in lynx).

You don't need anything to search for bugs, wget is enough if you know what you are searching for.

Yeti

On 2003-02-26 at 1956.05 +0100, Sven Neumann typed this:

Hi,

when I saw your mail, I remembered that I haven't yet told you that we finally moved gimp-perl out of the gimp HEAD branch into its own CVS module called gimp-perl. Hoepfully someone will find the time to resurrect its functionality and make it work with GTK+-2.x and GIMP-1.3.

Salut, Sven

does this mean that someone who actually likes perl can take it over and handle it properly?

carol

On Fri, Feb 28, 2003 at 07:30:35PM +0100, Sven Neumann wrote:

http://bugzilla.gnome.org/show_bug.cgi?id=79751

I certainly did; I even added your email to the Cc: which should have caused bugzilla to send you an email about it.

Hmm.. well, then it was as I said and I didn't notice it (however, it really wasn't repeatedly...)

http://bugzilla.gnome.org/show_bug.cgi?id=81791

If you ever come around to fix this, will you please notice us about

I just checked in this one-line change. If it really all that was required, then it's solved now and could be closed.

PS: Thanks to the three bugs closed due to our little flame-war we are now down to rank 7 in the Bugzilla Hall of Shame (http://bugzilla.gnome.org/weekly-bug-summary.html). Thanks! :-)

Well, nobody said it's totally useless to quarrel sometimes, at least there is the chance of getting somrthing moving again...

Hmm.. rank 6 will be difficult to reach, though.

On Fri, Feb 28, 2003 at 10:07:30PM +0100, Marc A. Lehmann wrote:

On Fri, Feb 28, 2003 at 09:19:17PM +0100, "David Necas (Yeti)" wrote:

You need cookies to log in, so you generally need cookies to change anything (what brower do you use? bugzilla works even in lynx).

Well, certainly lynx doesn't send cookies if you tell it not to. I don't know a browser that always sends cookies, anyways.

(Yes, you know that, but assuming that everybody happily lets himself monitor using cookies is not reflecting reality ;)

It's OT, but you started about reality:

Default lynx behaviour is to ask about each cookie. You can decide to accept exactly the log-in one (it sends a few more). You can make sure it's deleted after session. You can then set your cookie preferencies in the config.

The reality is, you have to prove yourself to make any changes, and this is a very logical requirement. The stronger authentization, the better you are monitored. You can't be monitored less.

If you are so paranoiac you don't accept cookies from bugzilla.gnome.org, then I can't understand why you bother to read any mail not signed by some trusted GnuPG key (namely gimp-dev), not speaking about responding to them. We are probably all evil hackers monitoring your mailing behaviour.

Yeti

It's OT, but you started about reality:

I didn't start anything. A very important rule to follow on the 'net or anywhere else: do _NOT_ forward private mails to public forums.

;)

bugzilla.gnome.org, then I can't understand why you bother to read any mail not signed by some trusted GnuPG key (namely gimp-dev)

Did I say anything about that issue? Maybe I really do bother... I regularly have problems explaining to people why a gpg key that is not signed or verified by anybody (self-signature not counted) is still very useful and still has all the same identification qualities as a "trusted" (or better: verified by showing your ID card) gpg key.

(A trusted key, btw, is something that actually _weakens_ your security. If you are paranoic you should never trust _any_ key. And as a general rule of thumb: if you trust anybody or anything, you are not really paranoic ;)

not speaking about responding to them. We are probably all evil hackers monitoring your mailing behaviour.

Well, that's probably not true, but wether I am paranoic or not, I _do_ respect it when people send me private (off-topic) mails and don't forward them...

F'up in private again, please ;)

fre 2003-02-28 klockan 18.28 skrev pcg@goof.com:

http://bugzilla.gnome.org/show_bug.cgi?id=79751

Oops, this is certainly not something you told me about ever.

The "bug activity" log for this report (available as a link from the page) very clearly shows that sven@gimp.org added a cc: to pcg@goof.com for this bug report almost a year ago, 2002-04-24...