Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
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).
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
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 [EMAIL PROTECTED]:
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(pointer to scheme struct,
pointer to closure,
args list made using cons(sc, pointer arg_1, cons(sc,
arg_2, sc-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 =
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
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. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
On 7/10/07, Kevin Cozens [EMAIL PROTECTED] wrote: 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. Our current setup uses init_procedures to load our functions, and is based on what we found there. Many of the functions listed there do an excellent job of parsing arguments passed from Scheme, but the only Script-Fu/Tiny-Fu way we've been able to find to make calls back to the Scheme interpreter is using the ts_interpret_string function, which calls tinyscheme's scheme_load_string and requires that you know the string name of the procedure you're trying to call. 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. We're currently working on a function called from the Script-Fu/Tiny-Fu console like (pixel-map drawable function) that maps said function (which takes an argument for each channel in the drawable and returns a list of new values for each channel) to every pixel in a drawable. When writing a foreign function that parses a Scheme argument list, we haven't found a way to get back a string procedure name from an argument of type T_CLOSURE, which is a problem since all user-defined Scheme procedures have this type, so we can't use scheme_load_string. Also, tinyscheme already has scheme_call, a function that works well enough to return values we can parse and takes arguments in the same format Scheme passes them to foreign functions (i.e. pointers to Scheme functions of type T_CLOSURE and pointers to argument lists). 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. The problem with scheme_call is that it doesn't play well inside foreign functions. Any foreign function, as far as we can tell, that calls scheme_call will proceed normally and return. However, the function's return value isn't picked up by tinyscheme, so something like (+ 1 (foreign-func-with-scheme_call 2)) won't return anything. This behavior is specific to foreign functiosn that call scheme_call, so something like (+ 1 (foreign-func-without-scheme_call 2)) will generally work. We'll try to contact the tinyscheme people about this. Thanks, Ted and Emily ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Thanks for the reply, Kevin. 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. Thanks for mentioning this; we hadn't looked at it previously. Making an extension is definitely what we'd like to do once our code is in a state worth sharing. 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? Do you know if Jonathan Shapiro/Dimitrios Souflis are still actively maintaining tinyscheme? 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. Looking forward to it! Thanks! Ted Cooper and Emily Jacobson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
Thanks for the reply! 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? We're working for the Grinnell College Computer Science department; The professors here teach introductory CS in Scheme and have been trying to use Script-Fu as a lab environment. Because the PDB fuctions gimp-drawable-get/set-pixel are all they've had access to for building higher-order image manipulation procedures, any image larger than about 100x100 took several minutes to process. One of our tasks for the summer has been to make Script-Fu faster, so its use in the classroom won't be painful for students. Thanks, Ted and Emily ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu/tinyscheme: using scheme_call?
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. -- Cheers! Kevin. http://www.ve3syb.ca/ |What are we going to do today, Borg? Owner of Elecraft K2 #2172 |Same thing we always do, Pinkutus: | Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
