I'd like to apologize to the list. I had responded to Kevin off-list because most of my questions were specific to the upstream TinyScheme project and had only peripheral impact to Script-fu development. I probably should have posted to the list anyway (I have attached the contents of my original response if anyone is interested).

Quoting Kevin Cozens <ke...@ve3syb.ca>:

What would be the best way for me to participate in TinyScheme

The official webpage for TinyScheme is http://tinyscheme.sourceforge.net/.
It is a SourceForge project so there is a mailing list, bug tracking system,
and a version controlled source code repository.

Thanks for that info. I have joined the mailing list and look forward to greater participation now that I am aware of the proper channels (congratulations on your appointment as a project leader).

It would probably be helpful if the TinyScheme website (http://tinyscheme.sourceforge.net/home.html) contained a direct link to the project's SourceForge resource page (http://sourceforge.net/projects/tinyscheme/). I realize I can be dense at times, I was completely unaware of the mailing list, bug tracker, and forums existence despite searching for such things on several occasions over the last few years (I mistakenly concluded that TinyScheme was a merely "privately developed" project).

There are a number of things that need to be done. I will to set up a wiki
so there is a place for information about the project.

I would be happy to contribute to such a wiki, and volunteer to help administer it if you should like.

The changes to TinyScheme used in Script-Fu don't have to be limited but
they have to be made carefully. ... TinyScheme has to stay tiny so it
can't just be changed to start using functions from glib.

One option to adding features that aren't that important to have, or which
would be for GIMP/Script-Fu use only, is to use run-time loadable extensions.

There are so many good Scheme implementations out there -- Chicken, Racket, Bigloo, and GUILE seems to be making a resurgence -- that I do not foresee any desirability to greatly increasing TinyScheme's capabilities. I'm mainly interested in bug fixes and just a couple targeted enhancements which could readily be implemented with the run-time extensions.

For Script-fu, I think it is critical that it not change too drastically over time and that scripts do not come to rely upon features which are not provided by the software delivered with GIMP (or hard dependencies thereof), whether as TinyScheme extensions or external libraries.

To the topic of this thread, I think it would be foolhardy to remove Script-fu from GIMP anytime in near future and I am pleased to hear you also assert that. The issue is not whether "better" programming languages exist, but that Script-fu scripts can be relied upon to easily be installed and readily function with any distribution of GIMP on any platform. As long as Script-fu provides this cross-platform support and maintains its small memory footprint (~500Kb by my estimation), there is little to advocate its removal.

By the same token, if Script-fu scripts were to start proliferating which relied upon third-party libraries or customized compilations of GIMP (wherein unofficial TinyScheme extensions were employed) then Script-fu would lose one of its most important advantages over plug-ins written in C, Python, Perl, other implementations of Scheme, etc.

Should any other extension language aspire to replace Script-fu, it first should have to satisfy this "works with every GIMP" characteristic of Script-fu. Any GIMP feature which depends upon the operating system including the language support -- or the user installing such support characteristic -- is a tentative feature at best. Unless the language implementation ships with GIMP, this is unlikely to occur. Python probably comes closest, but even it is not deployed in a standardized manner across all platforms. This is more owing to version differences than platform differences, but net result is still the same -- it is not ensured that a Python plug-in that works on one OS will work on another (including different different distributions of GNU/Linux).

That is not to say there is anything wrong with any of these other languages (or other implementations of Scheme), but Script-fu is currently providing extensibility to GIMP that no other language has been able to match (and likely never able to). Continue to advocate your language of choice and freely share your plug-ins written in that language, ignoring that Script-fu even exists. However, if anyone wishes to advocate the *removal* of Script-fu then they should start by providing a self-contained implementation of the substitute language which can ship with GIMP, and be willing to support that implementation as Script-fu has been maintained over the years.

Quoting Kevin Cozens <****@******.**>:
> There won't be any changes to see in the Tiny-Fu repository for a while as
> I'm busy on other projects. Tiny-Fu shouldn't be used with a recent version
> of GIMP. It is out-of-date and is only for testing some future changes to
> how Scheme scripts will be run. Eventually I will bring Tiny-Fu up-to-date
> with all of the changes made to Script-Fu and start work on the 2.0 version.

I am replying off-list intentionally because my questions have more to do with 
TinyScheme itself than Script-fu.

What would be the best way for me to participate in TinyScheme development? Are 
you now the focal point for this? Is there a bug reporting procedure in place? 
Or a mailing list to discuss things (should gimp-dev be used for this)?

I realize (and endorse) that changes to Script-fu/TinyScheme should be quite 
limited, however, there are a couple of issues* that I'd like to address and I 
am not sure how to go about it. It is not that I expect you to do the work, but 
I'd like to discuss it with you.

If you do not have time at the moment, perhaps you could just make an 
announcement on gimp-dev when you start work on a new release so that I might 
try to assist.

* File I/O in Script-fu seems to be a little buggy. I have not been able to 
track down the problem, but it seems that 'read-char' occasionally fails when 
reading files ("set-input-port needs one argument"). It happens somewhat rarely 
and it is entirely inconsistent on when it occurs. I haven't been successful in 
determining the cause, nor have I tested TinyScheme itself to see if the 
problem exists upstream.

Also, I would be interested in adding functions to TinyScheme for reading and 
writing raw characters. Currently, the read-char and write-char functions do 
UTF-8 conversions and this makes it impossible to deal with binary data files.

Finally, I'd like to add bitwise logical operators to TinyScheme. I realize 
they are not part of R5Rs but they are useful and macro implementation is 
ridiculously slow. 
Gimp-developer mailing list

Reply via email to