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
development?
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
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
