Re: Re: GePhex and scripting

Georg Seidel <[email protected]>
Newsgroups gmane.comp.video.gephex.devel
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just read through some articles and postings about
extending applications with scripting languages
(thanks to teemu for the links).

In http://twistedmatrix.com/users/glyph/rant/extendit.html,
the author strongly argues for extending an existing language
(python in this example), by loading your application as a
library, and doing all the high level stuff in the
scripting language.
He has some good points, but I can't follow his conclusion.
For example, he does not mention issues like debugging etc.

He also argues not to use application specific plugin mechanisms,
but instead to use only the library loading mechanism of the
respective scripting language.
I think that in our case (real-time image manipulation), our
separate plugin mechanism is rectified. Also, I somehow don't
like such an intimate tangling of the application with the
specifics of the scripting language...

The author also links to this article http://advogato.org/article/550.html,
which compares the scripting interface of vi, emacs and gimp, and comes to
the conclusion that it's best to support multiple scripting
languages, all on the same level.
The last comment is from the author of the first article, and argues
against supporting many scripting languages, but rather to support one
really well.


I think it's time to decide what kind of extension language we want to
support in gephex-0.5, and how.

Let me summarize my current understanding of our design:

~  1/ implement the core as a library, without any asynchronous operation
~     (update loop)

~  2/ somehow integrate a scripting language to use
~     this core and export *all* core functionality to that language

~  3/ current language candidate: scheme (guile)

~  4/ use that scripting language as an interface to the gui
~     (i.e. gui can be written in any language, but uses the scripting
~     language to communicate with the core)



Here are some thoughts:

~  * it would be really great if we could use that same extension
~    language from within the gui to automate stuff (for example I think
~    of writing a small script that toggles different effects or changes
~    parameter values of effects)

~  * as martin mentioned, it would be cool to be able to implement new
~    effects and link types in a scripting language.
~    but unlike his proposal to build a special plugin that imports
~    the "script effects", I propose to incorporate this functionality
~    directly into our scripting language:
~    To implement a new effect, you would have to write the relevant
~    functions (init, update, ..) in scheme (or python or whatever),
~    and then call a function
~     "(register-effect my-init my-update ...)"
~    to register it.
~    This should not be hard to implement, because the concept of a
~    library is well factored out inside the gephex core (see the
~    ILibrary interface).

~    Related to this: does anybody know the details of the script-fu
~    stuff in the gimp? I think it is a scheme dialect. It would be
~    *really* cool to be able to use some image filters from gimp in
~    gephex...


~  * what about python, or even another language?
~    I favor scheme, but it's largely a matter of my personal taste,
~    I think.
~    I can see the following advantage of python: it has a richer,
~    more mature (and standardized) set of functions to deal with stuff
~    like files, threads, regexps, ...
~    scheme lacks most of this, and every scheme dialect adds it's own
~    set of functions.
~    A second advantage of python is a larger user base.

~    The advantages of scheme I see is the extremely easy syntax
~    and it's success in wide-spread applications
~    (emacs (okay, it's a lisp dialect...), gimp, autocad).


I'm waiting for your comments!


georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAsJSJ/rP0cdKF/ToRAkyKAKC+aTKllEH+zKLQDHxINWwgcGYj/wCgpHOH
XWrDs783cg0UeATXmtYpXdE=
=Uecd
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.