Scheme Scripting Console

[Glimmer07]

This patch allows for scripting in the Scheme programming language using an
interactive window. The patch was created for revision 15638.

Here is the patch:
http://www.cs.grin.edu/~dangelod/scheme-patch-15638.tar.gz

Here is a README to help one get started:
http://www.cs.grin.edu/~dangelod/README

Here is a list of functions created for the Scheme console:
http://www.cs.grin.edu/~dangelod/functions.txt

Let us know what you think.

Thanks,
David D'Angelo and Soren Berg
<email address hidden>

[Ted Gould (ted)]

I would like to get this in for 0.46. Do you guys have an up-to-date patch for current SVN?

[Glimmer Labs (glimmer07-gmail)]

Here is an up-to-date patch created for svn revision 16980. I created it pretty quickly, so hopefully there are not any bugs caused by changes since the previous patch. Let me know if you have any questions/problems.

Here are some example scripts that can be used to test the console:
http://www.cs.grin.edu/~dangelod/example-scripts

Thanks,

David D'Angelo

<email address hidden>

[Maximilian Albert (cilix)]

Compiling inkscape with this new patch and trying to open the Scheme Console via View->Scheme results in a crash.
I'm on Debian unstable, SVN rev. #17018

Backtrace:

#0 0xb6e8513d in getc () from /lib/libc.so.6
#1 0x0854a2e9 in basic_inchar (pt=0xa53957c) at
extension/script/tinyscheme/scheme.c:1464
#2 0x0854a529 in inchar (sc=0xa539400) at
extension/script/tinyscheme/scheme.c:1521
#3 0x0854a5e7 in token (sc=0xa539400) at
extension/script/tinyscheme/scheme.c:1774
#4 0x0854f9c0 in opexe_0 (sc=0xa539400, op=OP_READ_INTERNAL) at
extension/script/tinyscheme/scheme.c:2465
#5 0x0854c1f3 in Eval_Cycle (sc=0xa539400, op=OP_LOAD) at
extension/script/tinyscheme/scheme.c:4333
#6 0x0854c57f in scheme_load_file (sc=0xa539400, fin=0x0) at
extension/script/tinyscheme/scheme.c:4669
#7 0x08547517 in
Inkscape::Extension::Script::InkscapeScheme::tinyscheme_init
(this=0xab6ddc0) at extension/script/InkscapeScheme.cpp:165
#8 0x0826e356 in SchemeDialogImpl (this=0xab6dc00) at
ui/dialog/schemedialog.cpp:252
#9 0x0826f892 in Inkscape::UI::Dialog::SchemeDialog::getInstance () at
ui/dialog/schemedialog.cpp:359
#10 0x081da454 in
Inkscape::UI::Dialog::PanelDialog<Inkscape::UI::Dialog::Behavior::DockBehavior>::create<Inkscape::UI::Dialog::SchemeDialog>
() at ./ui/dialog/panel-dialog.h:164
#11 0x081da4db in Inkscape::UI::Dialog::(anonymous
namespace)::create<Inkscape::UI::Dialog::SchemeDialog,
Inkscape::UI::Dialog::Behavior::DockBehavior> () at
ui/dialog/dialog-manager.cpp:59
#12 0x081d6b95 in Inkscape::UI::Dialog::DialogManager::getDialog
(this=0x8eb01d8, name=1857) at ui/dialog/dialog-manager.cpp:212
#13 0x081d6c18 in Inkscape::UI::Dialog::DialogManager::showDialog
(this=0x8eb01d8, name=1857) at ui/dialog/dialog-manager.cpp:231
#14 0x0838a030 in sp_action_perform (action=0x8edbfc0, data=0x0) at
helper/action.cpp:181
#15 0xb73df95f in g_cclosure_marshal_VOID__VOID () from
/usr/lib/libgobject-2.0.so.0
#16 0xb73d2619 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#17 0xb73e6dfb in ?? () from /usr/lib/libgobject-2.0.so.0
#18 0x08f67c10 in ?? ()
#19 0x00000000 in ?? ()

[Bryce Harrington (bryce)]

It's gotten to be too late in the process for inclusion of this new feature, so I'm dropping the milestone. Hopefully leaving it for 0.47 will also provide it with additional time for testing and polishing. Sorry we couldn't get it in for 0.46,

[Alexandre Prokoudine (alexandre-prokoudine)]

Any news on this?

[Ted Gould (ted)]

On Fri, 2008-06-20 at 14:37 +0000, Alexandre Prokoudine wrote:
> Any news on this?

Well, I was curious where Ishmal's work is going. If it goes to
somewhere interesting we'd have Scheme on top of the JVM, so it wouldn't
make sense to put the scheme engine in separately... Now, I'm not sure
about Ishmal's work and where it'll end up. I don't want to close this,
but I want to decide closer to when we're talking about 0.47 and can
make a good decision.

[MenTaLguY (mental-deactivatedaccount)]

In the long run, I'd prefer to have all of our scripting languages served by the same runtime -- things get too hairy if any one of them tries to do something clever (like conservative collection or threads or something) that ends up conflicting with the others. At the moment, it looks like the JVM is by far the strongest candidate for our common runtime.

On the downside, the JVM currently isn't well-suited to scheme, although I know the work being done by the Da Vinci Machine people will eventually change that.

[Alexandre Prokoudine (alexandre-prokoudine)]

Ted, are we closer enough to 0.47 now? :-)

[ScislaC (scislac)]

Ted: Is this still "in progress"? It would need a major update for trunk at this point is my guess.

[Ted Gould (ted)]

I think this is superseded by the SoC work on the dbus interface which can do all of this.