Glimmer Labs wrote:

Attempting to map a Scheme function in Script-Fu/Tiny-Fu to an entire image using the PDB functions gimp-drawable-get-pixel and gimp-drawable-set-pixel is painfully slow, so we've been trying to build a mk_foreign_func'ed function to attach to tinyscheme that updates images in a tile-aware way.

While using the foreign function interface of TinyScheme might work, for what you are trying to do it is not the best approach. You should really look at implementing it as a TinyScheme extension. Take a look at the re and tsx extensions for TinyScheme to see how extensions work.

Extensions can be loaded at run-time (although this feature is currently disabled). By putting your pixel operations you will make it possible for other users to make use of your routines without the need to compile a modified version of the Scheme interpreter.

I plan on enabling the loading of extensions at run-time at some point. The main reason it hasn't been turned on yet is that I do not know whether the code that loads extensions is portable to other operating systems.

Hi,

On Mon, 2007-07-02 at 11:38 -0500, Glimmer Labs wrote:

Attempting to map a Scheme function in Script-Fu/Tiny-Fu to an entire image using the PDB functions gimp-drawable-get-pixel and gimp-drawable-set-pixel is painfully slow, so we've been trying to build a mk_foreign_func'ed function to attach to tinyscheme that updates images in a tile-aware way.

Interesting attempt, but Script-Fu was never meant to be used for direct pixel manipulation. May I ask why you aren't using one of the GIMP bindings, like for example Python, that provides support for this level of pixel access?

Sven

Glimmer Labs wrote:

However, even if we were to build this in an extension, from looking at re and ftx, it seems like we'd still need mk_foreign_func'ed functions, at least one of which would still need to use scheme_call. Do you know of another way to assign arguments to and evaluate a closure passed to a foreign function from tinyscheme?

Have you also looked at init_procedures() and marshall_proc_db_call() in the scheme_wrapper.c file? You will find other examples of defining Scheme routines that will call C when invoked and which require parameters.

That is about all I can suggest for the moment without knowing the specifics of the situtation where you feel you have to use scheme_call.

Do you know if Jonathan Shapiro/Dimitrios Souflis are still actively maintaining tinyscheme?

AFAIK, they are still maintaining TinyScheme although I don't know how actively. Jonathan had also talked of doing a rewrite of TinyScheme but I haven't heard anything further on that issue.

Glimmer Labs wrote:

We're currently working on a function called from the Script-Fu/Tiny-Fu console like
(pixel-map drawable function)

You can take a look at init_procedures() to see how various Scheme functions are defined that all call one foreign function (FF) procedure (gimp-db-proc-call) to make the call to GIMP. The gimp-db-proc-call routine is passed a string which holds the name of the actual GIMP function to be executed.

Even if we were to find a way to get a string name for a procedure and build string calls like "(function r g b)" to pass to scheme_load_string, it seems like a step backward to do so having received the parameters in the first place in a format closer to tinyscheme's evaluation cycle.

I don't understand why you need to build a Scheme statement inside your FF that needs to be interpreted by TinyScheme. You should be trying to avoid the need to process Scheme statements from inside your FF. The idea of using an FF for pixel operations is to do lower level stuff and avoid the gawd awful slowness one would encounter processing a lot of pixels in Scheme code.

The way I see it, an FF is used to add a new function to Scheme along the lines of a library function. An FF shouldn't be trying to access any routines in the Scheme interpreter outside of those listed in the interface table. What you describe seems to be more of a higher level routine(s).

You might need to review your execution flow and what is getting done in the FF and what is getting done in Scheme. See if you can simplify the execution flow by moving some stuff to the Scheme code that runs before the FF is invoked.

> The problem with scheme_call is that it doesn't play well inside > foreign functions.

It is not too surprising that you have a problem with using scheme_call when you look at the routine. It calls dump_stack_reset() and Eval_Cycle(). These will very likely mess things up since your FF was called from inside an Eval_Cycle.

One possibility would be to create a new instance of a scheme struct before calling scheme_call(). The only problem would be if you need the environment that was in place when your FF was called but there may be a way to solve that.

I have made some progress with calling Scheme functions from C but do not really understand the details and am uncertain if I am doing things correctly.

I modified the 'scheme_call()' routine to the following:

void scheme_call(scheme *sc, pointer func, pointer args) { pointer stack = sc->dump; /* save dump_stack position */

dump_stack_reset(sc); sc->envir = sc->global_env;
sc->args = args;
sc->code = func;
sc->interactive_repl =0;
sc->retcode = 0;
Eval_Cycle(sc, OP_APPLY);
sc->dump = stack; /* restore dump_stack position */ }

This allowed me to define a C foreign function:

pointer foreign_test_call (scheme * sc, pointer args) { pointer func;

func = sc->vptr->pair_car(args); args = sc->vptr->pair_cdr(args);

scheme_call(sc, func, args); return sc->value;
}

which I could invoke with a command such as:

=> (test-call + 2 3) 5

or

=> (test-call list 1 2 3) (1 2 3)

I don't know if modifying 'scheme_call()' will cause other problems (it seems unreferenced elsewhere in TinyScheme, but the authors may have other intents); if so, one could provide a separate function which does not reset the "dump stack". I don't understand the theory or operation of the "dump stack", so maybe there is a better approach altogether.

Please understand that this information should be taken with a large grain of salt.

Quoting Glimmer Labs :

Attempting to map a Scheme function in Script-Fu/Tiny-Fu to an entire image using the PDB functions gimp-drawable-get-pixel and gimp-drawable-set-pixel is painfully slow, so we've been trying to build a mk_foreign_func'ed function to attach to tinyscheme that updates images in a tile-aware way.

As far as we can tell, the most straightforward methods tinyscheme provides for Scheme command evaluation from C are a) using the scheme_load_string function to parse a string of Scheme code, and b) passing Scheme function and argument pointers to scheme_call. mk_foreign_func'ed functions receive parameters in the latter format, so parsing them and building a command string to pass back seems clunky. scheme_call, on the other hand, quickly evaluates a closure passed with arguments and stores the result in sc->value, and we have had success mapping Scheme functions to large images.

However, mk_foreign_func'ed functions that call scheme_call don't return correctly, so Scheme code that contains calls to these functions breaks; we're having trouble figuring out why. scheme_call isn't included in scheme.h, so it's probably not even intended for external use. We haven't been able to find any documentation for scheme_call so we don't know whether we're using it correctly or not.

We've been using scheme_call like scheme_call(,
,
NIL))>)
Is this the correct way to call scheme_call? Including this call to scheme_call in any mk_foreign_func'ed function causes tinyscheme to fail to process the function's return, i.e., it causes (func-with-scheme_call foo), (+ 1 (func-with-scheme_call foo) ), etc. to not evaluate to anything. When we remove scheme_call calls, our functions do not have this problem.

We've been trying to learn how Eval_Cycle in scheme.c works to figure out why this is happening, but it's not going very well. We're hoping someone out there knows tinyscheme well enough to tell us what we're doing wrong. Below is a program we've been using for testing that shows how we're calling scheme_call, how calls with/without it behave, etc. This won't compile against the GIMP's tinyscheme without adding a scheme_call prototype to scheme.h, etc.; if you want specifics, we'll gladly provide them.

We're students, and we've tried to avoid making any egregious errors in tone/content or etiquette, but if any of this seems weird please attribute it to our inexperience and tell us why.

Thanks, Ted Cooper and Emily Jacobson

#include "scheme-private.h" #include "scheme.h"

pointer twomath(scheme *sc, pointer args);

pointer twomath(scheme *sc, pointer args){ long result;
pointer a, b;
pointer func;
a = sc->vptr->pair_car(args);
args = sc->vptr->pair_cdr(args);
b = sc->vptr->pair_car(args);
args = sc->vptr->pair_cdr(args);
func = sc->vptr->pair_car(args);
printf(" twomath: (pre-scheme_call) sc->vptr->ivalue(sc->value): %ld\n",sc->vptr->ivalue(sc-

value));

scheme_call(sc, func, cons(sc, a, cons(sc, b, sc->NIL))); result = sc->vptr->ivalue(sc->value); printf(" twomath: (post-scheme_call) sc->vptr->ivalue(sc->value): %ld\n", result);
printf(" twomath: scheme_call sets sc->value to the correct value, but when we try to return a copy..."); /*return sc->value;*/
return sc->vptr->mk_integer(sc,result);

}

int main(){ scheme *sc;
FILE *init_scm;
sc = scheme_init_new();;
init_scm = fopen("init.scm","r");
scheme_load_file(sc, init_scm);
fclose(init_scm);
scheme_set_output_port_file(sc, stdout); sc->print_flag=1; /* necessary? */ sc->print_output=1;
printf("regular functions return, produce output, and set sc->value to some crazy huge number:\n");
printf(" (pre-scheme_load_string), sc->vptr->ivalue(sc->value): %ld\n", sc->vptr->ivalue(sc->value)); printf(" (- 4 4)\n");
scheme_load_string(sc, "(- 4 4)"); printf("output above, and (post-scheme_load_string), sc->vptr->ivalue(sc->value): %ld vptr->ivalue(sc->value): %ld vptr->ivalue(sc->value): %ld = the value set in twomath (it hasn't been updated to some crazy huge number, since + couldn't evaluate without two parameters). Next, let's run a command that will evaluate to see what happens to sc->value\n",sc->vptr->ivalue(sc->value)); printf(" (+ 32 (- 4 5))\n");
scheme_load_string(sc, "(+ 32 (- 4 5))"); printf("output above, and (post-scheme_load_string), sc->vptr->ivalue(sc->value): %ld vptr->ivalue(sc->value));

return 0;

}

There is a flaw in my approach (I suspected there would be). Once my 'test-call' function is evaluated, a subsequent error (of any kind) will quit TinyScheme. I hope this doesn't mean it is necessary to replicate the environment -- that would seem a pretty heavy penalty just to call a function.

To summarize what I am seeing...

With scheme_call defined as:

void scheme_call(scheme *sc, pointer func, pointer args) { dump_stack_reset(sc);
sc->envir = sc->global_env;
sc->args = args;
sc->code = func;
sc->interactive_repl =0;
sc->retcode = 0;
Eval_Cycle(sc, OP_APPLY);
}

a function called from C will execute and then exit Scheme -- this can be shown with the code "(test-call write 1)".

If I save the dump stack before running 'Eval_Cycle' and restore it afterwards, TinyScheme will function properly, but will exit on encountering an error. My first thought was that this was owing to a loss of the 'nesting_stack' state (which, if I understand, maintains the input source) but I don't see any relationship in the code.

---------------------------- I guess I will keeping experimenting and perhaps try to contact the TinyScheme developers. The functionality of calling Scheme code from a foreign function (with return values) would provide a nice way to enhance Script-fu without having to alter the TinyScheme core (and avoiding the inherent maintenance problems).