I thought I'd comment with some of my opinions on the proposal/project presented by Andreas_P. I have included the original post in its entirety at the end of this mail (as it's been a while since it was made). Over the years, GIMP's plug-in/extension system has remained fairly language agnostic. In addition to the original C and Script-fu, there have been implementations for Perl, Java, Python, C#(Mono), Lua, Javascript, and Ruby. There should be no real objection should someone wish to provide support for Yet Another language or even another dialect/implementation. However, should the goal be incorporation within the "official" GIMP distribution -- or supplanting of Script-fu with another Scheme implementation -- then it would be necessary to gain a broader acceptance from the project's developers. Script-fu, both the original SIOD-based and the current TinyScheme-based implementations, is inarguably limited in capability, but it is important to understand the reasons behind the limitations when considering alternative GIMP extension languages. In many ways, Script-fu's limitations prove to be beneficial and offer advantages over other, more capable alternatives. Hardly any of the limitations are particularly attributable to the fact that Script-fu uses Scheme as its basis, other than perhaps Scheme's non-algebraic syntax for formulas and its lack of popularity amongst the general programming community. (There may be some issues that result from the specific Scheme implementation; e.g., unit testing support). Script-fu's main limitations are that it is restricted from interfacing directly with libgimp -- it only has access to functionality as provided by the Procedural DataBase (PDB) -- and that it does not support usage of external libraries or modules (e.g., SF can't produce a customized GTK dialog window or employ a third-party FFT algorithm). These limitations are both artificial and by design (TinyScheme supports extensions and external bindings, but access to these is disabled in Script-fu). Nonetheless, it is because of this restriction that a Script-fu script can be relied upon to work with all platforms without any dependency on libraries/functionality not included in a GIMP install. While Python-fu may itself be bundled with the official GIMP distribution (and thus not depend upon Python being installed on the host system) and a Python-fu programmer might be able to write a plug-in which limits itself to using only the GIMP-provided functionality, it is not uncommon that Python scripts "import" functions from external libraries which may not be available on the user's system; or worse, are not available for the user's platform. This creates a mini version of "dependency hell" and in practice distributing such plug-ins can be more problematic than distributing C-based plug-ins (which can statically link the necessary libraries). I say this not to criticize Python-fu (or any of the other more capable plug-in languages), but to highlight that the "module" functionality provided by R6RS does not particularly resolve any issues for current TinyScheme. I currently have an "sflib" file that contains several dozen convenience functions which I often employ within scripts I'm writing; however, I include the functions by copying the "library" code to my script, defining it within a local scope. Yes, this results in duplication of code and all the negative aspects that entails, but the alternative is that my script should fail unless the users have my library file installed on their system. This issue is not one of modularization, encapsulation, environment scopes, or any number of "advanced features" in modern high-level programming languages; it is a matter of distribution of dependencies not included in GIMP by default. The only way to properly resolve the issue would be institution of a repository/packaging system with automatic dependency resolution a la Debian's apt-get (while providing cross-platform support). This is certainly doable -- in fact the G'Mic project does a pretty fair job of implementing this in their third-party offering -- but in my opinion this challenge should be met before any script or plug-in language can expect to supplant Script-fu in GIMP. I don't mean to sound negative, in fact I would personally encourage your project to pursue adding Racket support to GIMP. However, you should initially approach it from the standpoint of producing a self-contained, third-party extension which provides its own infrastructure for distribution and maintenance of Racket-based GIMP add-ons. I would even be interested in participating in such a project. If successful, then later on the GIMP project might see its way clear to incorporating your offering within the official GIMP distribution. =============================== ------------------------------- Quoting Andreas_P: > I hope that this email was not being posted several times here > Hey all, > > I think I did loose the previously designed letter which I thought, > having sent to Kevin Cozens. > Now I have to write the whole letter again, hoping for him, that he is > on this list, from time to time. > > It sounded like that: > > Dear Mr. Cozens, > > Thank you for contributing to GIMP! > > [For the sake of clarity I have to introduce myself: My name is Andreas > Posur and I am a student on a big technical university inside Germany, > enrolled in BSc. EECS] > > I got the feeling that Script-Fu / Tiny-Fu (SIOD) isn't well recepted > because of "old & unsexy"... > quote: from the internet research. > I personally can support this statement. And I had some "REALLY" > difficult problems to get a proper "unit testing" within R5RS > (tinyscheme). > > Now my proposal: Just look at the upcoming (brand) new version of > "racket" which is nothing else than the newly renamed and rebranded > "PLT-Scheme". PLT is (in case you don't know) the bunch of hackers who > are refining the elements of R6RS-Scheme to a mixture which can sb. > call "impressive"... > > [quote > > Lazy - Functional - Reactive - OO - Macros (powerful, hygenic) - > Delimited continuations - Module system (dynamic) > > Not too mention the basics, eye opening approaches to XML and Web, an > IDE, debugger, contracts, typed/dynamic language, jit, Android > development, ... and on and on. > > The talent of the core PLT group is outstanding. Matthias Felleisen for > example was awarded an ACM Fellowship in 2006 for contributions to > programming languages and development environments. His academic > publications are right up there with the best out there, yet he spends > as much time focused on the foundational aspects of teaching kids, and > students as high brow papers, and the real world demands of > programming. And the rest the core are not too shabby either. > > > /quote] taken from: http://news.ycombinator.com/user?id=boskone > > The Programming Languages Teaching Website: http://www.plt-scheme.org > will be transferred to plt-racket.org > > DrScheme [IDE] will be DrRacket, MrED will be gracket, and mzscheme > will come out as racket. > > My main problem is that only Kevin probably will have the insights, > what has to change and what not in terms of tiny-fu and tinyscheme, he > developed the interpreter connector. > > So if anybody is able to help me (and perhaps later others with this) I > would really appreciate that. > My target is finally to get a powerful, ease of use, sexy Scheme > derivate running and implementing GEGL Operations/Services/Actions that > PhotoShop would have to fear... > > Greetings from Germany, yours sincerely: Andreas Posur > > (And when I have the time then I would do some basic bughunting (my c > skillz aren't that good yet)...) _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
