On Tue, Feb 22, 2011 at 11:47:58AM +0000, Nelson A. de Oliveira wrote:

Hi!

While running the camouflage pattern plugin I saw an error:

===== Error while executing script-fu-camo-pattern: Error: ( : 1) Invalid number of arguments for gimp-image-insert-layer (expected 4 but received 3)
=====

The attached patch fix this (and also fix the usage of some deprecated procedures).

circuit.scm was repaired very recently (38 hours ago) in GIMP's git tree: http://git.gnome.org/browse/gimp/commit/?id=b19645db4954a8fc8db83817dc7cd2e45e840efb along with a few others.

i recently opened a bug report with some patches for this same kind of updates to different script-fus:
https://bugzilla.gnome.org/show_bug.cgi?id=642939 if you would like to put your patches there, it might be easier for whoever to get them from there when the time is right or whatever has to happen for scripts to be updated.

if i remember correctly, commit permission is a privelege more than a ticket to ride, or whatever....

and thanks, if no one else does this, i will be glad to apply them to my copy.

carol

Nelson A. de Oliveira wrote:

While running the camouflage pattern plugin I saw an error:

Thank you Nelson (and Carol) for the reports and patches regarding Script-Fu scripts. The GIMP API has been undergoing some big changes in this development cycle and the Script-Fu scripts have not fully caught up with all the changes.

I usually do much of the work to update Script-Fu scripts to the latest API as I have a Perl based script that automates the update procedure. This script uses information generated by running other Perl based scripts against a PDB dump from GIMP. I am in the process of updating my update script but its a big job this time. There are 107 changes to the PDB since the release of the 2.6 version of GIMP and three different types of changes that have to be handled across 100 scripts.

The first change is the common one where deprecated procedures just need minor updates (ie. changing to the procedure name to the replacement procedure). The other two changes involve PDB procedures with some parameters now set via context functions and the introduction of the item API. These last two changes will require more work to handle in an automated manner.

Until recently some deprecated procedures referred to a replacement procedure that did not exist. This has been fixed so the PDB is complete and stable enough for now to begin the work to update my update script. I will be reviewing the updates originally made to the scripts for 2.7 API as I have seen some changes to the called procedures are not correct as of the current API.

Until now, updating the scripts can usually be done in about 15 minutes starting from the running of GIMP to get a current dump of the PDB (if there are no other unusual changes). I will be doing the work for 2.7/2.8 in two stages with the simple changes as the first stage and the changes involving context and item API as the second stage. I'm currently working on two other projects so I'm doing this as time permits.

On Tue, 2011-02-22 at 16:50 -0500, Kevin Cozens wrote:

Until now, updating the scripts can usually be done in about 15 minutes starting from the running of GIMP to get a current dump of the PDB (if there are no other unusual changes).

What would it take to provide this as an online service, for people with existing scripts?

Liam

On Tue, Feb 22, 2011 at 04:50:14PM -0500, Kevin Cozens wrote:

Nelson A. de Oliveira wrote:

While running the camouflage pattern plugin I saw an error:

I usually do much of the work to update Script-Fu scripts to the latest API as I have a Perl based script that automates the update procedure. This script uses information generated by running other Perl based scripts against a PDB dump from GIMP. I am in the process of updating my update script but its a big job this time. There are 107 changes to the PDB since the release of the 2.6 version of GIMP and three different types of changes that have to be handled across 100 scripts.

Using Perl to fix Script-fu -- this kind of thing always makes me laugh a little....

The first change is the common one where deprecated procedures just need minor updates (ie. changing to the procedure name to the replacement procedure). The other two changes involve PDB procedures with some parameters now set via context functions and the introduction of the item API. These last two changes will require more work to handle in an automated manner.

Nelson's patch fixes a lot of these, I was surprised to see so many there compared to what had been attached to the email.

https://bugzilla.gnome.org/show_bug.cgi?id=642938 has patches for at least one of the scripts that are in Nelson's big patch. These script-fu look for brushes that GIMP no longer installs. Putting the brushes back would be a solution for the breakage. Removing the scripts would also be a solution. I rewrote the scripts to make a vector brush and dispose of it which is (in my opinion) more of a gimp-2ish solution.

I am curious to know what you had been thinking about as a solution for this script problem.

Until recently some deprecated procedures referred to a replacement procedure that did not exist. This has been fixed so the PDB is complete and stable enough for now to begin the work to update my update script. I will be reviewing the updates originally made to the scripts for 2.7 API as I have seen some changes to the called procedures are not correct as of the current API.

commit e062acbc642cf0cfa601595ddb0524be11354dd9 from last October broke several of the s-fu, and i cannot remember if this was before the deprecated procedures were removed or not. I am assuming that the commiter was not your perl script, but they have been broken since then.

Until now, updating the scripts can usually be done in about 15 minutes starting from the running of GIMP to get a current dump of the PDB (if there are no other unusual changes). I will be doing the work for 2.7/2.8 in two stages with the simple changes as the first stage and the changes involving context and item API as the second stage. I'm currently working on two other projects so I'm doing this as time permits.

Actually, I was told that one of the reasons for these scripts was to see how to accomplish things via scripting. Manually making these patches has done exactly this for me and I regret not looking at them sooner.

When I look at the Changelogs, I thought that you had made the changes to these scripts manually and felt kind of pleasently humbled. I will feel differently now.

Nelsons patch seems to have been script-matically made, several of the patched scripts will still produce deprecated errors.

carol

Liam R E Quin wrote:

What would it take to provide this as an online service, for people with existing scripts?

It wouldn't take much to put it online. A webpage where the original script can be pasted and a webserver that can run Perl scripts.

It won't be able to update for all scripts as the update script only uses regular expressions to make the needed changes. It will handle updating deprecated functions where the arguments provided are constants or variable names. It won't work if an argument for a procedure was an expression (for example "(* width 2)"). For something like that, the script output by the update script would be broken.

On Tue, 2011-02-22 at 23:22 -0500, Kevin Cozens wrote:

Liam R E Quin wrote:

What would it take to provide this as an online service, for people with existing scripts?

It wouldn't take much to put it online. [...]

It won't be able to update for all scripts

Hmm, maybe we should consider providing a compatibility library then, so people can add one line at the start of a script?

On Tue, Feb 22, 2011 at 11:31:40PM -0500, Liam R E Quin wrote:

On Tue, 2011-02-22 at 23:22 -0500, Kevin Cozens wrote:

Liam R E Quin wrote:

What would it take to provide this as an online service, for people with existing scripts?

It wouldn't take much to put it online. [...]

It won't be able to update for all scripts

Hmm, maybe we should consider providing a compatibility library then, so people can add one line at the start of a script?

Marc Lehmann, 1997 or 1998 -- take a look at gimp-1.0 and gimp-1.2 c plugins, there seemed to be a huge effort by some authors to include some (i am not certain of the wording here) CONSISTENT_ENUMS detailing plugin information which included default settings. There was also an effort then to include version information -- in the date registration thingie.

there was gimp-0.60 [then not publically documented miracles] then gimp-0.9 and its pdb. and that is the best it has ever gotten for plugins managment.

i would really really like to have some gimp source from between gimp-0.60 and gimp-0.9 -- if anyone has kept something like that around. perhaps federico has one on his first cellphone....

carol

Carol Spears wrote:

i would really really like to have some gimp source from between gimp-0.60 and gimp-0.9 -- if anyone has kept something like that around.

You will have to do a bit of digging to find anything between those two releases. Old versions of GIMP source are available via GIMP's FTP server in the "historical" directory. There is source code for versions 0.54, 0.60, 1.0, and 1.2 in addition to the 2.x releases. The git repo only goes back to 1997 and the 0.99 versions.