We have developed a feature which allows Scheme Scripting from a console inside of Inkscape.
We chose to implement a Scheme interpreter inside Inkscape because we felt higher-order programming and other functional paradigm ideas of Scheme would apply very nicely to a vector-based program such as Inkscape.
The tar file included at the directory below contains a README with directions to aid in the process of installing the patch contained in the tar file. The README also has instructions on running the console.
http://www.cs.grin.edu/~dangelod/scheme-patch.tar.gz
Please let us know what you think of it.
This patch was tested with revision 15458. If there is a better place to submit this patch since it is pretty large, let us know.
Thanks, David D'Angelo and Soren Berg glimmer07@...400...
On Thu, 2007-07-19 at 17:18 -0500, Glimmer Labs wrote:
Please let us know what you think of it.
It looks okay in principle -- my big concern is that it looks like it exposes a lot of the internal C++ API directly, which concerns me because it is due for some significant changes. I'd rather that we expose a more neutral API to scheme scripts which is can be more stable.
Have you talked with Bob Jamison at all? He's been working on a general framework for Inkscape scripting in Javascript (and other languages), you may want to combine efforts with him.
-mental
On Thu, 2007-07-19 at 17:18 -0500, Glimmer Labs wrote:
We have developed a feature which allows Scheme Scripting from a console inside of Inkscape.
Wow, lots of code. This e-mail is going to get long, sorry in advance.
I really thought that Python would be the first language implemented for internal scripting with all the Python folks around. But, I'd vote for Scheme personally :)
BTW, what is "Glimmer Labs"?
The tar file included at the directory below contains a README with directions to aid in the process of installing the patch contained in the tar file. The README also has instructions on running the console.
First off, some housekeeping things. The tarball that you posted has a lot of extra things like .a files and the Linux penguin as an SVG file. While fun, it would probably be easier for people to download the file if those were removed. If you've used Subversion (which it appears you have as there are subversion files included also) you can just do an "svn diff" which will give you a diff to the upstream repository. Then the whole thing, new files and all (if added through 'svn add') will be in one large patch file.
What problem were you trying to solve by adding the 'update' flag to the document object? I'm concerned that this is working around some synchronization issue that has broader implications in the codebase. Perhaps we have a different way of solving that problem.
I notice that you've included some source code called "tinyscheme". Is there are reason to use that over guile's bindings? I'm curious because it would be nice if we didn't have maintain code for a scheme interpreter in our codebase. Linking to one that is already maintained is a bonus.
I'm a little bit concerned over the interface between C++ and Scheme. I think it might be a little too high level as there is a lot of code duplicated between the Inkscape code base and the function implemented for the interface. I still think the functions are useful, but perhaps a better place to put them is in Scheme. For example (please excuse my rusty Scheme):
Add an interface function:
(define inkscape-call-verb (lambda (desktop verbname) () ))
And then a function like 'desktop_exit' can be implemented like:
(define desktop_exit (lambda (desktop) (inkscape-call-verb desktop 'FileQuit')))
But then it becomes really easy to implement:
(define desktop_close (lambda (desktop) (inkscape-call-verb desktop 'FileClose')))
or
(define selection_path_union (lambda (desktop) (inkscape-call-verb desktop 'SelectionUnion')))
Without editing any C code. It also allows script writers to quickly use any new functionality that is added to the main codebase without the scheme interface being updated.
This can also effect the XML side. Imagine this:
(define rectangle (lambda (desktop layer x y w h) ( let ((layerNode (getElementById (inkscape-desktop-document desktop) layer)) (node (createElementNS (inkscape-desktop-document desktop) "svg" "rect"))) (appendChild layerNode node) (setAttributeNS node "svg" "x" x) (setAttributeNS node "svg" "y" y) (setAttributeNS node "svg" "width" w) (setAttributeNS node "svg" "height" h) node) ))
This would give a script writer the flexibility to add their own function with another line:
(setAttributeNS node "tedSpace" "whoDoWeLove" "ted")
A very requested feature :)
Lastly, (if you've made it this far) while I think a scheme console is cool I'm not sure how useful it is to most users. (Though, AutoCAD people seem to really like it). I think it would be really cool if you'd implement a subclass of Inkscape::Extension::Implementation that would use scheme. I'm thinking someone could define an extension something like this: (the INX file)
<inkscape-extension> <name>Draw Rectangle</name> <effect/> <scheme> (define effect lambda (desktop) ( rectangle desktop (selected-layer desktop) 100 100 100 100 ) </scheme> </inkscape-extension>
I think this would work well for normal users to have ways to select and run the scheme scripts developed from the effects menu directly.
--Ted
Thank you for taking the time to give us feedback on this project.
On 7/19/07, Ted Gould <ted@...11...> wrote:
BTW, what is "Glimmer Labs"?
We're students at Grinnell College, and our advisor's mentor recommended naming his research lab. He is a bit of an acronym freak, so, after at least five minutes thought, came up with "The Grinnell Laboratory for Interactive Multi-Media Experimentation and Research", aka "Glimmer'.
What problem were you trying to solve by adding the 'update' flag to the document object? I'm concerned that this is working around some synchronization issue that has broader implications in the codebase. Perhaps we have a different way of solving that problem.
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
I notice that you've included some source code called "tinyscheme". Is there are reason to use that over guile's bindings? I'm curious because it would be nice if we didn't have maintain code for a scheme interpreter in our codebase. Linking to one that is already maintained is a bonus.
We considered multiple implementations of Scheme, including Guile. However it made sense to us to try to parallel the other big open-source graphics program (aka "The Gimp"), and The Gimp is using TinyScheme. We will consider Guile, however.
I'm a little bit concerned over the interface between C++ and Scheme. I think it might be a little too high level as there is a lot of code duplicated between the Inkscape code base and the function implemented for the interface. I still think the functions are useful, but perhaps a better place to put them is in Scheme.
We have implemented the inkscape-call-verb function which works extremely well, although verbs do not extend to node manipulation and creation. We also experimented with creating a rectangle in the manner you suggested.
(define (rectangle2 desktop layer x y w h) (let ((node (node-new desktop layer "svg:rect"))) (node-modify desktop node "style" (desktop-get-css 0)) (node-modify desktop node "x" x) (node-modify desktop node "y" y) (node-modify desktop node "width" w) (node-modify desktop node "height" h)))
(rectangle2 (get-desktop) "layer1" "10" "10" "100" "100")
This works with your idea to add new functionality without the scheme interface being updated, although along with mental's criticism, this implementation still exposes a lot of the internal C++ API directly concerning creating and modifying nodes. I guess this is an idea to explore more with Bob Jamison
A very requested feature :)
Lastly, (if you've made it this far) while I think a scheme console is cool I'm not sure how useful it is to most users. (Though, AutoCAD people seem to really like it). I think it would be really cool if you'd implement a subclass of Inkscape::Extension::Implementation that would use scheme.
We definitely would like to implement that feature, but we feel at the same time, that a interactive console can be useful to most users, and "every" user will find times in which it is faster or more natural to use a console. It also provides an easier entry into scripting than does "create a file, load it, test it."
Thanks again,
David D'Angelo and Soren Berg
On Fri, 2007-07-20 at 15:27 -0500, Glimmer Labs wrote:
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
It seems like there should be a better approach for addressing this -- generally speaking, screen updates shouldn't happen until the idle loop is entered.
although verbs do not extend to node manipulation and creation.
We would like to change that; we just need someone to work on it.
[Besides verb invocation, it would still be nice to have an object model which is not so "context-dependent", but is what Bob is working on.]
-mental
On Fri, 2007-07-20 at 15:27 -0500, Glimmer Labs wrote:
What problem were you trying to solve by adding the 'update' flag to the document object? I'm concerned that this is working around some synchronization issue that has broader implications in the codebase. Perhaps we have a different way of solving that problem.
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
Hmm, are you committing to the document each time? In theory the redraw should only be using idle cycles. My concern here is that we'd be be providing a pseudo-locking type mechanism that would really do everything most people would expect. I think we either need to provide real locking or find another way to work around it.
I notice that you've included some source code called "tinyscheme". Is there are reason to use that over guile's bindings? I'm curious because it would be nice if we didn't have maintain code for a scheme interpreter in our codebase. Linking to one that is already maintained is a bonus.
We considered multiple implementations of Scheme, including Guile. However it made sense to us to try to parallel the other big open-source graphics program (aka "The Gimp"), and The Gimp is using TinyScheme. We will consider Guile, however.
Ah, sorry, I thought that since you included it in the patch that this was something you had written. Can we link to TinyScheme? I'm unfamiliar with it. I don't see it in the libraries linked to The GIMP on my machine.
We have implemented the inkscape-call-verb function which works extremely well, although verbs do not extend to node manipulation and creation. We also experimented with creating a rectangle in the manner you suggested.
Cool. So would you guys be willing to implement some of the verbs for node manipulation as part of your project? I think that'd be more constructive than copying that code into the scheme interface.
This works with your idea to add new functionality without the scheme interface being updated, although along with mental's criticism, this implementation still exposes a lot of the internal C++ API directly concerning creating and modifying nodes. I guess this is an idea to explore more with Bob Jamison
I don't want to speak for Mental (okay, I do, but I'm trying to decrease my liability in doing it) but I think we agree that the interface that should be between Inkscape and scripting is the W3C DOM interface. The examples that I gave you were written with this interface. While I don't think that all of the DOM needs to be implemented for a binding to be useful, I do think this should be a goal. Bob is implementing the C++ side of DOM.
Lastly, (if you've made it this far) while I think a scheme console is cool I'm not sure how useful it is to most users. (Though, AutoCAD people seem to really like it). I think it would be really cool if you'd implement a subclass of Inkscape::Extension::Implementation that would use scheme.
We definitely would like to implement that feature, but we feel at the same time, that a interactive console can be useful to most users, and "every" user will find times in which it is faster or more natural to use a console. It also provides an easier entry into scripting than does "create a file, load it, test it."
Yes, I'm sorry if I wasn't clear. I think both target different users and are useful. I just think the majority of "art oriented" (vs. "math oriented") users are more comfortable selecting the scripts on the Effects menu. I wanted to provide a way for the math-folks to create things useful for the art folks.
In general, what is the goal of your project? Is it to provide scheme functionality in Inkscape or something larger? I'm not trying to be nosy as much as we can probably be more useful in our comments if we know where you're headed.
Thanks, Ted
Here is the new version of our Scheme Patch:
http://www.cs.grin.edu/~dangelod/scheme-patch-15638.tar.gz
When you run the console there should already be commented out lines in the scheme definitions window. If you run all those lines it should draw and morph a star. If that script does not work, something probably did not install correctly.
It now uses verb modification and eliminates almost all of the exposure to the internal C++ api. Once Bob's API is finished, we will reimplement the Scheme console to use it.
Some questions are answered below:
On 7/30/07, Ted Gould <ted@...11...> wrote:
On Fri, 2007-07-20 at 15:27 -0500, Glimmer Labs wrote:
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
Hmm, are you committing to the document each time? In theory the redraw should only be using idle cycles. My concern here is that we'd be be providing a pseudo-locking type mechanism that would really do everything most people would expect. I think we either need to provide real locking or find another way to work around it.
We agree that a real locking mechanism would be better or finding another way around it, but we aren't familiar enough with the Inkscape code to figure out where to put that locking mechanism.
Ah, sorry, I thought that since you included it in the patch that this was something you had written. Can we link to TinyScheme? I'm unfamiliar with it. I don't see it in the libraries linked to The GIMP on my machine.
We don't exactly know what you mean by linking to TinyScheme. Can you clarify that? Also, you may have been looking at an older version of The GIMP that didn't use TinyScheme. The current development of Script-fu is switching to using TinyScheme and its folder can be found in plug-ins/script-fu/tinyscheme.
Cool. So would you guys be willing to implement some of the verbs for node manipulation as part of your project? I think that'd be more constructive than copying that code into the scheme interface.
We've implemented some verbs for node manipulation that use void * pdata. We don't know your opinions on that, but we hope it's ok.
In general, what is the goal of your project? Is it to provide scheme functionality in Inkscape or something larger? I'm not trying to be nosy as much as we can probably be more useful in our comments if we know where you're headed.
In general, the goal of Glimmer Labs is to investigate the benefits of functional programming in media computation. Part of this goal is providing Scheme functionality to Inkscape to see the benefits particularly in a SVG vector graphics editor. We would love to eventually see the Scheme console adopted into Inkscape.
Thanks for everything,
David D'Angelo and Soren Berg
Could you go ahead and put this in the patch tracker? It's probably worth having an entry in there where we can track this.
(I haven't had a chance to look at the new code yet, but the improvements you describe sound good.)
-mental
On Fri, 2007-08-03 at 17:19 -0500, Glimmer Labs wrote:
Here is the new version of our Scheme Patch:
http://www.cs.grin.edu/~dangelod/scheme-patch-15638.tar.gz
When you run the console there should already be commented out lines in the scheme definitions window. If you run all those lines it should draw and morph a star. If that script does not work, something probably did not install correctly.
It now uses verb modification and eliminates almost all of the exposure to the internal C++ api. Once Bob's API is finished, we will reimplement the Scheme console to use it.
Some questions are answered below:
On 7/30/07, Ted Gould <ted@...11...> wrote:
On Fri, 2007-07-20 at 15:27 -0500, Glimmer Labs wrote:
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
Hmm, are you committing to the document each time? In theory the redraw should only be using idle cycles. My concern here is that we'd be be providing a pseudo-locking type mechanism that would really do everything most people would expect. I think we either need to provide real locking or find another way to work around it.
We agree that a real locking mechanism would be better or finding another way around it, but we aren't familiar enough with the Inkscape code to figure out where to put that locking mechanism.
Ah, sorry, I thought that since you included it in the patch that this was something you had written. Can we link to TinyScheme? I'm unfamiliar with it. I don't see it in the libraries linked to The GIMP on my machine.
We don't exactly know what you mean by linking to TinyScheme. Can you clarify that? Also, you may have been looking at an older version of The GIMP that didn't use TinyScheme. The current development of Script-fu is switching to using TinyScheme and its folder can be found in plug-ins/script-fu/tinyscheme.
Cool. So would you guys be willing to implement some of the verbs for node manipulation as part of your project? I think that'd be more constructive than copying that code into the scheme interface.
We've implemented some verbs for node manipulation that use void * pdata. We don't know your opinions on that, but we hope it's ok.
In general, what is the goal of your project? Is it to provide scheme functionality in Inkscape or something larger? I'm not trying to be nosy as much as we can probably be more useful in our comments if we know where you're headed.
In general, the goal of Glimmer Labs is to investigate the benefits of functional programming in media computation. Part of this goal is providing Scheme functionality to Inkscape to see the benefits particularly in a SVG vector graphics editor. We would love to eventually see the Scheme console adopted into Inkscape.
Thanks for everything,
David D'Angelo and Soren Berg
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 8/6/07, MenTaLguY <mental@...3...> wrote:
Could you go ahead and put this in the patch tracker? It's probably worth having an entry in there where we can track this.
I made an entry in the patch tracker. Is it possible to have the code (or some of the code) committed to the trunk? The patch process is becoming increasingly difficult, and having some or all of the code committed would help a large amount in creating patches. In particular, committing the code for the ui dialog would help. If not, what is the procedure for getting code committed to the trunk?
Thanks, David D'Angelo Glimmer Labs
On Fri, 2007-08-03 at 17:19 -0500, Glimmer Labs wrote:
Here is the new version of our Scheme Patch:
http://www.cs.grin.edu/~dangelod/scheme-patch-15638.tar.gz
When you run the console there should already be commented out lines in the scheme definitions window. If you run all those lines it should draw and morph a star. If that script does not work, something probably did not install correctly.
It now uses verb modification and eliminates almost all of the exposure to the internal C++ api. Once Bob's API is finished, we will reimplement the Scheme console to use it.
Some questions are answered below:
On 7/30/07, Ted Gould <ted@...11...> wrote:
On Fri, 2007-07-20 at 15:27 -0500, Glimmer Labs wrote:
The reason we added the update flag was for editing large numbers of objects (1000+) without updating the document each time, making it much faster. We found this to be useful because scripting allows one to do interesting things with large numbers of objects (such as morph) and updating the document every time something is drawn on the screen can slow down the function an immense amount.
Hmm, are you committing to the document each time? In theory the redraw should only be using idle cycles. My concern here is that we'd be be providing a pseudo-locking type mechanism that would really do everything most people would expect. I think we either need to provide real locking or find another way to work around it.
We agree that a real locking mechanism would be better or finding another way around it, but we aren't familiar enough with the Inkscape code to figure out where to put that locking mechanism.
Ah, sorry, I thought that since you included it in the patch that this was something you had written. Can we link to TinyScheme? I'm unfamiliar with it. I don't see it in the libraries linked to The GIMP on my machine.
We don't exactly know what you mean by linking to TinyScheme. Can you clarify that? Also, you may have been looking at an older version of The GIMP that didn't use TinyScheme. The current development of Script-fu is switching to using TinyScheme and its folder can be found in plug-ins/script-fu/tinyscheme.
Cool. So would you guys be willing to implement some of the verbs for node manipulation as part of your project? I think that'd be more constructive than copying that code into the scheme interface.
We've implemented some verbs for node manipulation that use void * pdata. We don't know your opinions on that, but we hope it's ok.
In general, what is the goal of your project? Is it to provide scheme functionality in Inkscape or something larger? I'm not trying to be nosy as much as we can probably be more useful in our comments if we know where you're headed.
In general, the goal of Glimmer Labs is to investigate the benefits of functional programming in media computation. Part of this goal is providing Scheme functionality to Inkscape to see the benefits particularly in a SVG vector graphics editor. We would love to eventually see the Scheme console adopted into Inkscape.
Thanks for everything,
David D'Angelo and Soren Berg
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2007-08-07 at 23:06 -0500, Glimmer Labs wrote:
On 8/6/07, MenTaLguY <mental@...3...> wrote:
Could you go ahead and put this in the patch tracker? It's probably worth having an entry in there where we can track this.
I made an entry in the patch tracker. Is it possible to have the code (or some of the code) committed to the trunk? The patch process is becoming increasingly difficult, and having some or all of the code committed would help a large amount in creating patches. In particular, committing the code for the ui dialog would help. If not, what is the procedure for getting code committed to the trunk?
Well, basically you need to convince someone who can to do it :)
Personally, I see two issues:
- The document locking (I'd like Mental to look at this)
- TinyScheme inclusion. I didn't get any response from the GIMP-devel list, I don't know if my e-mail made it. Do any of the packagers who read this list know what's going on with their various distros? Is there going to be a TinyScheme package?
--Ted
Glimmer Labs wrote:
We have developed a feature which allows Scheme Scripting from a console inside of Inkscape.
Unfortunately, I get a segfault with current SVN (the backtrace is attached, just in case). Pity, I would have loved to give this a try. Thanks for all the hard work! Although reading Ted's comments I think his concerns make sense (as far as I have a rough idea of the internals). Would you be willing to incorporate the changes he suggests? For what it's worth, I believe being able to use Scheme as a scripting language for Inkscape would be a really awesome thing. Thanks again!
/Max
==================
Backtrace:
#0 0xb6f95c7d in getc () from /lib/libc.so.6 #1 0x0846fd09 in basic_inchar (pt=0xa709794) at extension/script/tinyscheme/scheme.c:1463 #2 0x0846ff59 in inchar (sc=0xa709618) at extension/script/tinyscheme/scheme.c:1520 #3 0x08470017 in token (sc=0xa709618) at extension/script/tinyscheme/scheme.c:1771 #4 0x084753a0 in opexe_0 (sc=0xa709618, op=OP_READ_INTERNAL) at extension/script/tinyscheme/scheme.c:2462 #5 0x08471c23 in Eval_Cycle (sc=0xa709618, op=OP_LOAD) at extension/script/tinyscheme/scheme.c:4325 #6 0x08471faf in scheme_load_file (sc=0xa709618, fin=0x0) at extension/script/tinyscheme/scheme.c:4661 #7 0x08465a3d in Inkscape::Extension::Script::InkscapeScheme::tinyscheme_init (this=0xa055a78) at extension/script/InkscapeScheme.cpp:66 #8 0x081fd462 in SchemeDialogImpl (this=0xa055a18) at ui/dialog/schemedialog.cpp:263 #9 0x081fe952 in Inkscape::UI::Dialog::SchemeDialog::create () at ui/dialog/schemedialog.cpp:362 #10 0x08197805 in Inkscape::UI::Dialog::DialogManager::getDialog (this=0x8b6b598, name=1647) at ui/dialog/dialog-manager.cpp:144 #11 0x08197889 in Inkscape::UI::Dialog::DialogManager::showDialog (this=0x8b6b598, name=1647) at ui/dialog/dialog-manager.cpp:163 #12 0x08303c26 in sp_action_perform (action=0x876f150, data=0x0) at helper/action.cpp:181 #13 0xb74015c9 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #14 0xb73f41c2 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0xb7404cf3 in ?? () from /usr/lib/libgobject-2.0.so.0 #16 0x08c22730 in ?? () #17 0x00000000 in ?? ()
Maximilian Albert schrieb:
Glimmer Labs wrote:
We have developed a feature which allows Scheme Scripting from a console inside of Inkscape.
Unfortunately, I get a segfault with current SVN (the backtrace is attached, just in case).
Oops, sorry. I have several SVN versions on my computer and copied the share/scheme directory to the wrong location. It seems to work now, although I just managed to crash it again by running the example script in the README file - but maybe that's again related to some wrongly copied file. You should include some tests, though, whether the files you assume to exist really do.
Cheers, Max
participants (4)
-
Glimmer Labs -
Maximilian Albert -
MenTaLguY -
Ted Gould