[Gimp-developer] Tiny-Fu status and information
I fail to see why Tiny-fu can't be made backwards compatible with SIOD; at least sufficiently enough to justify a direct substitution. If compatibility is assumed as a premise (and the appropriate changes to Tiny-fu implemented), the differences that Kevin Cozens described all but disappear. Quote from Kevin: Differences and problems compared to Script-Fu 1. The filenames of Tiny-Fu scripts must end in .sct to avoid conflicts with Script-Fu scripts. 2. Scripts must use Tiny-Fu/tiny-fu instead of Script-Fu/script-fu in public function names and in the register block. 3. Variables must be defined before first use. 4. Local variables are local in scope and not global as they are in Script-Fu. 5. Parsing (and execution of scripts?) seems a bit slower compared to Tiny-Fu. 6. Tiny-Fu includes many of the SIOD functions via a compatability layer. 1. Don't require the .sct extension; make Tiny-fu execute .scm files. 2. If Tiny-fu is backwards compatible then there is no need to differentiate the function names. 3. This is good programming practice, anyway, and enforcing it is not a horrendous idea. 4. Same comment as for #3. 5. Speed isn't a great concern either way. 6. Nothing wrong with this. If this compatibility layer is implemented as an extension, it could eventually be deprecated. The main difficulty would seem to be with concerns #3 and #4; they would be most likely to break existing scripts. I would propose the following project to address this issue (I have seen similar proposals made previous in the mailing list, in particular for the SoC): Create a more advanced and coordinated Plug-in Registry which would be the official repository for Script-fu plug-ins (IMO, there is no need to change the Script-fu name because the interpreter is changed from SIOD to Tiny Scheme). This repository could perhaps be a Source Forge project; but something a bit more advanced than the current Registry (e.g., supporting of versions and packages). Errors that result from compatibility issues would prompt the user with the message that they must upgrade their script. If something similar to the ss sockets extension (available to SIOD but not the GIMP's Script-fu) were supported, perhaps this upgrade process could be automated, fetching the appropriate files from the previously mentioned repository. Eventually, the repository should hold Tiny Scheme versions of all worthwhile existing scripts and any new submissions should be verified for Tiny Scheme consistency. I very much enjoy working with Script-fu and would be willing to volunteer to assist in updating scripts (the GPLed ones) and maintaining the Script-fu portion of such a repository (such a repository should probably also support the GIMP's other scripting languages). I am not confident of my skills in actually creating such a repository but perhaps someone else is. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tiny-Fu status and information
On Fri, 02 Jun 2006 07:49:05 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Thu, 2006-06-01 at 00:34 -0400, Kevin Cozens wrote: What next? Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under Differences to be easily solved. How would this solve the issues? Do you propose that the installation of script-fu or tiny-fu is mutually exclusive? This would of course be the ideal solution. I do not think that it would be the ideal solution. I have been running the latest versions of Script-Fu and Tiny-Fu together for several months now and I enjoyed the fact that I could easily compare their behavior without having to maintain separate GIMP installations (well, besides the ones for HEAD vs. stable 2.2.x). From my point of view, the ideal solution would be this: - Remove Script-Fu from the gimp module and create a gimp-script-fu module. - Declare that Script-Fu is deprecated (but still available as a separate package for those who really want it). - Distribute Tiny-Fu in the gimp tarball so that it becomes the default Scheme interpreter. Note that the last point does not require merging both modules. This could be done by changing the make dist target in the gimp so that it checks for the presence of the tiny-fu module and bundles the whole thing together. This is the ideal solution, even if it may be controversial. We know that the vast majority of the users will not install a new scheme interpreter if it is not part of the default package. We also know that the Linux distributors and packagers for other platforms will simply follow our tarball structure instead of bundling things together (some distributions provide support for suggested or recommended packages, but again many users do not bother installing these additional packages). So as long as Script-Fu is part of the gimp package, it will prevent Tiny-Fu from being widely adopted. The fact that I was the first one to report the problems in bug #342578 although the problem had existed for several months should tell something about the current adoption of Tiny-Fu. On the other hand, the advantages that Kevin listed for Tiny-Fu over the old interpreter are real and very useful: support for UTF-8, better debugging, etc. Anything that can be done to encourage people to switch from Script-Fu to Tiny-Fu would be a good thing, IMHO. But since you say that tiny-fu is never going to be able to run all script-fu scripts unmodified, the chance that anyone would install tiny-fu in favor of script-fu seems rather small. The changes required are rather small. The main requirements are to rename the *.scm files to *.sct and to replace script-fu-* by tiny-fu-* in the files (both of these are easy). The other changes such as making sure that variables are declared and in the correct scope are only applicable to a few scripts and should have been done in the first place anyway, even for script-fu. And in any case, these changes are only necessary for those who have written their own scripts or downloaded them separately. We have broken more things in the past for Script-Fu itself (e.g., PDB changes) so I do not think that the transition from Script-Fu to Tiny-Fu would be more painful than what he have done previously. If we allow both interpreters to be installed together (which is currently the case), then it would be possible to distribute Script-Fu as an optional package. Those who do not want or cannot update their old scripts could install the optional Script-Fu package to be able to run them. It would simply reverse the current situation by making Tiny-Fu the default and this would be a Good Thing. In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen. With the Python binding maturing, it could become the default GIMP script interpreter. But people will still want to be able to run some script-fu script occasionally. Whatever comes bundled in the tarball will become the default GIMP script interpreter. In the past, we had Script-Fu and Perl-Fu/Gimp-Perl. Then the Perl bindings started to be distributed as a separate package and people stopped using them rather quickly. The opposite happened for the Python bindings. We can also observe the same thing for many other plug-ins such as gimp-gap, etc. In summary, regardless of what we claim is required, recommended or suggested, the main thing that matters is what comes inside the official gimp tarball. After having tried both Script-Fu and Tiny-Fu for several months, I would like to get rid of Script-Fu as soon as possible. -Raphaël ___
Re: [Gimp-developer] Tiny-Fu status and information
Hi, On Thu, 2006-06-01 at 00:34 -0400, Kevin Cozens wrote: What next? Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under Differences to be easily solved. How would this solve the issues? Do you propose that the installation of script-fu or tiny-fu is mutually exclusive? This would of course be the ideal solution. But since you say that tiny-fu is never going to be able to run all script-fu scripts unmodified, the chance that anyone would install tiny-fu in favor of script-fu seems rather small. In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen. With the Python binding maturing, it could become the default GIMP script interpreter. But people will still want to be able to run some script-fu script occasionally. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Tiny-Fu status and information
Greetings, all. The topic of Tiny-Fu as a replacement for Script-Fu surfaced once again. This time in comment #2 of bug #329443 in Bugzilla. This was followed up in comment #4 with: In response to comment #2: I have no idea what Kevin is waiting for. It seems that he lost interest in doing this change. I also have no idea if he has restored Script-Fu compatibility. Last I checked this wasn't the case and Tiny-Fu wasn't ready to replace Script-Fu. I wasn't waiting for anything but I'm not going to make such a big change to GIMP without an ok and plan on how this should be done from the core developers. I also haven't lost interest in Tiny-Fu. I was busy on an important project for a client for the better part of a year. Once that project slowed down and I had some free time once again I was working on some other projects that had been put off for a while. Basic information about, and status of, Tiny-Fu Tiny-Fu is stable and has been working well for some time now for both the 2.2 and CVS versions of GIMP. Most of the recent changes being made were to keep in line with changes made in Script-Fu. All of the scripts which accompany Script-Fu are available and working for Tiny-Fu except for the spyrogimp script. Tiny-Fu is not, and will not be, a 100% compatible drop-in replacement for Script-Fu due to differences in the Scheme interpreter used vs. the one used in Script-Fu. Differences and problems compared to Script-Fu 1. The filenames of Tiny-Fu scripts must end in .sct to avoid conflicts with Script-Fu scripts. 2. Scripts must use Tiny-Fu/tiny-fu instead of Script-Fu/script-fu in public function names and in the register block. 3. Variables must be defined before first use. 4. Local variables are local in scope and not global as they are in Script-Fu. 5. Parsing (and execution of scripts?) seems a bit slower compared to Tiny-Fu. 6. Tiny-Fu includes many of the SIOD functions via a compatability layer. Comments regarding the above points 1. The tools used to extract strings marked for translation do not recognize the .sct extension as indicating a file containing Scheme code. This means that no strings are extracted from the scripts unless you patch intltools. 2. This means a certain minor amount of work is required for any script which is to be run with Tiny-Fu. 3. This results in another incompatability with Script-Fu as it allows variables to be used that were not previously defined. 5. This may be due in part to the support for UTF-8. 6. Not all of the SIOD functions available in Script-Fu are available in Tiny-Fu. Also, due to differences between the two interpreters some SIOD functions can not be implemented in Tiny-Fu. Advantages of Tiny-Fu vs. Script-Fu o Uses a Scheme interpreter which is still being developed. o Easier to debug scripts by turning tracing on and off. o Better compliance with the R5RS Scheme standard making it a little easier to use if you are already familiar with Scheme. o Handles UTF-8 coded characters and strings. o String arrays are handled as arrays just like the other array types. This can save a lot of data nodes (ie. memory) compared to using a list which is used in Script-Fu. o Extra date, time, and file-handling routines. Also regex based pattern matching. A contact sheet script demonstrates some of the new possibilities for scripts that may not be possible to write with standard Script-Fu. o Support for SF-RADIO parameter in register blocks This is a work in progress and is not yet in CVS. It should be ready soon. o Ability to use run-time loadable extensions. This feature is currently disabled. I am considering re-enabling it as part of the work for version 2.0 of Tiny-Fu. What next? Script-Fu should be removed from the GIMP source tree and made available as a separately developed project. This would allow the first two issues listed under Differences to be easily solved. It would also make it easier to transition from Script-Fu to Tiny-Fu. Packagers and users would be free to choose whether they wanted to continue using Script-Fu or if they would prefer to use the newer Tiny-Fu plug-in. There have been some previous discussions about removing Script-Fu from the main GIMP source tree. It would be up to packagers of GIMP as to how they will package it and which projects in CVS they include in their packages. The GIMP web site can provide information as to the moving of Script-Fu out of the main source tree in to a separate tree. In regards to some people thinking that moving Script-Fu out of the GIMP source tree is going to make some people feel Script-Fu is being retired they would be correct. A number of the GIMP developers have been wanting Script-Fu to die for some time. It has just been a question of when, rather than if, it will happen. I think that about covers the issues relating to Tiny-Fu. What is needed now is some consensus as to how best to proceed in light of the 2.4 release of
