[Fluxus] rubyk & fluxus

[Gaspard Bucher]

>
>
> Yes, this is the thing to probably try first, if you embed a racket
> interpreter and provide a gl context users can just import fluxus-engine
> and off they go... This is what happens if you use fluxus via DrRacket
> or emacs.
>

The gl context is provided by the GLWindow object so I just have to work out
the racket VM...


>
> I'm not sure what the implications are of running multiple instances of
> fluxus renderers in the same process however - there are some static
> things which may be showstoppers (e.g. texture caching). It would be
> worthwhile sorting these out though.
>

As a first step, I will need a global mutex on the VM and I can give a
warning about shared namespaces and such between racket scripts. But
clearly, the ideal solution is to avoid leakage between scripts (so that you
can easily reuse processing/rendering bits).


> From my point of view, good! We had planned to do some work to make a
> plugin architecture in the C++ code to simplify the extra bits we have
> already e.g. ATToolKit and make it easier to include more things like
> OpenCV and give them access to the scenegraph.
>
> It seems to me, thinking about it again, that it would make more sense
> if this connection was higher up the stack - for example via scheme
> where it (if I understand right) could come from Rubyk too.
>


I am taking a similar road in Rubyk: write bindings for scripting languages
instead of making tons of small Rubyk objects. I even wrote a tool to
automatically generate bindings by reading Doxygen output (
http://rubyk.org/en/project311.html).

I have some trouble fixing the Lua bindings to OpenCV 2.1 at the moment
(template resolution, typedefs). Once this is solved, the binder could also
spit Scheme bindings given the proper templates.


>
> cheers,
>
> dave
>
>
I'll keep you posted and start playing with (fluxus) !

Gaspard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20100916/9b0e6a40/attachment.html>