Greetings, everyone.

For some months now I have been working on a new plug-in for the 2.1 version of GIMP. I have been calling this new plug-in Tiny-Fu. Some of the people on this list who use the #gimp IRC channel have already heard about this plug-in.

Tiny-Fu is a plug-in for the 2.1 (and later) series of the GIMP. It is essentially a modified version of the Script-Fu plug-in but with some major differences. The main difference is in the Scheme interpreter being used.

I have created a web page for Tiny-Fu. The URL for the page is: http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html A tarball of Tiny-Fu is available but at the moment it must be hooked in to the GIMP 2.1 source tree using the supplied patch file. A standalone version will be available later.

The web page contains additional information about the plug-in as well as the status of the work being done on it. Currently it is somewhere between the alpha and beta stage of development. It ran its first script in April of this year (ts-helloworld.sct) and as of July 6, I have updated 57 of the 96 Script-Fu scripts to work with Tiny-Fu.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 01:18 PM 07/06/2004, Sven Neumann wrote:

We talked about script-fu and tiny-fu at GIMPCon and agreed that we'd like to see Script-Fu removed from the GIMP source tree as soon as Tiny-Fu is available as a separate package that can replace it.

The Tiny-Fu tarball can exist in the GIMP source tree just as Script-Fu does now since its of a comparable size. Having it as a separate package would make it easier for others to try it who aren't building GIMP from source.

This
could happen for GIMP 2.2 provided that Tiny-Fu is ready by that time.

It would be helpful to know of anything that might block this. Other than the lack of support for binary data (ie. it can't work with GIMP parasites) at the moment, and the translation files need to be updated, I think Tiny-Fu is in as good a shape (if not better in some ways) than Script-Fu.

I have a couple of questions about Tiny-Fu.

No, problem. I don't really have an FAQ yet so your questions can help me create one.

(1) Is Tiny-Fu supposed to run scripts written for Script-Fu?

The answer is yes, however...

I wanted to keep Script-Fu on my machine while working on Tiny-Fu. As a result, I had to make them co-exist. The scripts run by Tiny-Fu must end in .sct rather than .scm as they do for Script-Fu. Also, any references to Script-Fu in scripts must be changed to Tiny-Fu (preserving case).

Once those changes have been done, some scripts will work as is. Some scripts need to have variables defined before first use. Some scripts (especially those that work with GIMP parasites, use arrays, or use features of Scheme unique to the SIOD interpreter) will need other changes. The web page contains some information about updating a Script-Fu script for use with Tiny-Fu.

If so,
will this be some kind of compatibility layer or perhaps just a script that helps to convert old scripts?

A script could be created to handle the simpler changes required to make a Script-Fu script work with Tiny-Fu but some scripts will still require changes to be made by hand.

(2) Is Tiny-Fu supposed to run as a permanent extension like the current Script-Fu implementation or will it start a new interpreter when needed and exit when the script is done?

I made a full copy of Script-Fu as the starting point for Tiny-Fu. It currently works just like Script-Fu does but that doesn't meant it can't (or won't) change in the future.

(3) Somewhat related to question (2), will Tiny-Fu allow scripts to be run concurrently?

[snip]

That would put more pressure on making the core reentrant.

This quote from the TinyScheme authors web site might help. "As an embedded interpreter, it [TinyScheme] allows multiple interpreter states to coexist in the same program, without any interference between them."

With the recent changes to GIMP regarding context and the fact I access all features of the TinyScheme interpreter via its interface mechanism, it should be possible to have scripts run concurrently.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 02:18 PM 07/06/2004, Markus wrote:

TinyScheme does not support arrays at the moment - do you plan to implement this feature (i.e., fork TinyScheme), or is such a feature planned by the TinyScheme developers?

No, I do NOT want to fork TinyScheme. I am trying to keep patches to TinyScheme which would be only be required for use with Tiny-Fu to a minimum. Some TinyScheme patches I currently have will be passed back to the author of TinyScheme so others can benefit from those changes and/or bug-fixes.

Arrays as used with SIOD are not defined in the R5RS (the current document defining the Scheme language). I have chosen to use lists instead.

Otherwise, I can convert scripts that are currently using arrays to use lists instead if you have not already done so.

I have no objections if you would like to update some of the scripts which use arrays. I would suggest you contact me before hand so I can provide a list of the scripts which need to be updated to avoid duplicating work.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 03:27 PM 07/06/2004, Joao wrote:

One of the major showstopers for script-fu as of lately is it inability to handle UTF-8 strings. Is tiny scheme able to do so?

No, TinyScheme does not handle UTF-8 strings. UTF-8 support is already on the ToDo list since Sven already raised the issue on #gimp.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

On Tue, 2004-07-06 at 19:45, Sven Neumann wrote:

The fact that the PDB uses arrays doesn't necessarily mean that a language binding such as Tiny-Fu needs to represent them as arrays. One of the most annoying bits of Script-Fu is that it forces you to work with arrays even though the natural choice for a scheme dialekt would be lists. If Tiny-Fu cannot provide backward-compatibility, then it should overcome this mistake and map the PDB API to lists.

Tiny-Fu makes no attempt to provide backwards compatability with the SIOD Scheme interpreter way of doing things. It expects scripts to follow the current Scheme standard as defined in the R5RS document.

Since the R5RS does not define an array type, any script which uses arrays either internally or when dealing with PDB calls needs to be modified to use a list. The marshalling code of Tiny-Fu converts between PDB *ARRAY and Scheme lists as needed. The alternative would be to use a Scheme vector but instead of a list. Using a list seemed like the simplest approach.

At 05:17 AM 07/07/2004, Shlomi Fish wrote:

Are you sure using lists instead of vectors is the right thing to do? Lists are linked lists and as such accessing the i'th element is O(i). In vectors it is O(1). This can cause an order of complexity increase in handling them.

No, I'm not sure. For the few scripts I looked at (and for ease of implementation), using a list was the easier route to have something functional during the early development stages. Using vectors instead of a simple list would mean the ability to use functions which would provide rough equivalents to the SIOD interpreters array manipulation functions.

In any case, this may not be an issue, because a programmer can temporarily use a vector, and convert it to a list before calling the PDB entries.

Conversion is simple through the use of vector->list and list->vector.

I will take a closer look at using vectors. It will simplify the work needed to update old Script-Fu scripts for use with Tiny-Fu. I will start by converting between list and vector. If the approach works well, I will bit the bullet and update the marshalling code to use vectors for the *ARRAY types.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 08:09 PM 07/07/2004, Markus Triska wrote:

I also opt for vector because apart from being the natural Scheme equivalent to PDB's one-dimensional arrays, it makes writing plug-ins easier for people that have no to little practice in converting common "for/while" loops using tail-recursion, and current scripts would work practically unmodified, without explicit conversions list->vector that would only cost time (with everybody ending up calling these instead of working on lists most of the time).

By using vectors I was able to very quickly update the portion of those scripts which used SIOD array functions. I have not changed the Tiny-Fu marshalling code yet but I will do that soon and release a new tarball.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 01:38 PM 07/09/2004, you wrote:

Now since there is essentially a one-to-one correspondence between Tiny-Fu's vectors and Script-Fu's "arrays", it might be worth considering adding compatibility definitions to "init.scm" (similar to gimpcompat.h for plug-ins), that would, depending on a certain "compatibility"-switch in a configuration file (or in "init.scm" itself, but I don't know if every user will get a copy or you will install the file in /usr/gimpsomething...), "define ...." the current array operations and map them to corresponding vector functions. You could then (depending on said switch) also re-define set! to use "define" if a variable is not "defined?".

I don't really want a "compatibility"-switch. Instead, old Script-Fu scripts should be updated so they do things the way they are supposed to be done in Scheme rather than how the old SIOD interpreter let script writers get away with some things (ie. not defining variables). It forces a review of the code. For example, I noticed that one script defined an internal routine to compute a least common multiple rather. I deleted the routine and used the standard Scheme routine 'lcm'.

I am planning on putting together a Perl script that will take a Script-Fu script and update as much of it as possible for use with Tiny-Fu. I know of quite a few mappings from SIOD to TinyScheme that can be applied. Pre-defining variables and changing while loops to do loops will still have to be done by hand.

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

At 06:00 AM 07/10/2004, Sven wrote:

Kevin Cozens writes:

I don't really want a "compatibility"-switch. Instead, old Script-Fu scripts should be updated so they do things the way they are supposed to be done in Scheme rather than how the old SIOD interpreter let script writers get away with some things (ie. not defining variables).

I understand your reasons but a compatibility mode (if that is feasible at all) would allow us to ditch Script-Fu in favor of Tiny-Fu. If no such mode is available we will have to continue to ship Script-Fu for quite a while.

Many (most?) of the needed changes between SIOD and TinyScheme could be handled via a set of additional define statements in a separate file included from the main TinyScheme init file. Handling the while loop should be possible but that requires a non-trivial Scheme define. All of these additional defines should be flagged in documentation as deprecated.

That just leaves the problem of variables used in a set! statement which are not defined before first use. Tiny-Fu displays an error message stating "unbound variable" along with the name of the variable when this situation is encountered. The solution is to add a line to the let block with the name of the variable in parenthesis (no initial value is required). A few of the standard Script-Fu scripts had a define that used set! but no let statement so a let had to be added first. I don't see how this can be handled automatically without a change to TinyScheme itself.

Script-Fu scripts written for GIMP 1.2 won't work under GIMP 2.x without some changes due mainly to differences in the API. In what version of GIMP would it be possible to have the compatibility features of Tiny-Fu removed?

Cheers!

Kevin. (http://www.interlog.com/~kcozens/)

Owner of Elecraft K2 #2172 |"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg

On Sat, 2004-07-10 at 19:19, Markus Triska wrote:

I have explained this above - re-define "set!" to use the TinyScheme "defined?" command to see if a variable is already defined, and if this is not the case, define it.

Now I understand what you were getting at earlier. That would work only I don't see defined? as being available in the R5RS. However, a check of the interpreter indicates it does have such a function so this should be doable even if it is outside the current standard (perhaps its in of the suggested additions and will be part of R6RS currently being developed).

I think I may be able to use that to deal with the missing symbol-bound? function of SIOD.