[gephex-devel] Scheduling
Georg Seidel
georg at gephex.org
Sat Feb 25 16:42:33 CET 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Jean-Sébastien,
Glad to hear you keep on experimenting with the scheme scripting ideas!
In gephex, development has become pretty slow the last month, but we
are making some progress wrt. the scheme integration (currently using
mzscheme).
> I'm currently working out to try to integrate one new programming
> paradigm in Drone (apart from dataflow): hierarchical finite-state
> machines. The point would be to facilitate the creation of event-based,
> complex behaviors that could change the way data is processed. This
> paradigm should in fact be a module that integrate seamlessly with the
> dataflow paradigm that is currently Drone's core (which would thus also
> become a module). Thinking about this had me consider the idea of using
> a scripting language as the "middleground" between those various
> modules. In the end, the structure I was thinking of looked like this:
>
> FSM-GUI dataflow-GUI
> | |
> script code (scheme)
> |
> script engine (guile) <--> FSM/dataflow libraries
Would the engine be responsible for loading units (or gears)?
> This is rather close to proposed GePhex 0.5 architecture, except
> there is no bytecode layer. The reason is
> 1) I didn't really find any reason to use a bytecode
> 2) GePhex 0.5 bytecode was useless because it has no event scheduling
I cannot follow you here. What exactly do you mean with bytecode in
gephex? You mean the gephex core written in C++? I will assume this
for the rest of my answer.
The reason to create a simple and fast core in C++ instead of doing
all in a scripting language was real-time behaviour.
If you use a garbage-collected language like scheme to schedule the
update, you will probably have difficulties to achieve real-time video
streams...
> However I recently read this comment about a scheduling unit in
> GePhex 0.5 bytecode:
> http://lists.gephex.org/pipermail/gephex-devel/2005-November/000795.html
>
> I guess that such a feature would add what is, in my mind, truly
> missing in gephex bytecode in order for it to support various paradigmas
> (though I'm thinking that I would still need some kind of event
> sender/listener facility).
Please explain about the sender/listener facility you have in mind.
> However, I still don't really see the point of creating such a
> bytecode language under the Scheme layer. Why not simply code it in
> Scheme with the help of Guile? I've reproduced the Kalkulon example in
> Scheme here and it's pretty neat:
> http://orangeseeds.net/wiki/drone/Core/Drone0.4/Scripting/Spike
>
> Plus, that would allow users to script their own way of
> handling/scheduling data.
I agree that we should make it possible for users to determine the way
scheduling is done - but if you want a real-time core, this has to be
done beyond the scripting layer IMO.
Best regards,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEAHrp/rP0cdKF/ToRAsnjAJwP+870IYiQCWXaNA2ZkBmBTiyVdgCg8KEE
9pkdAB1gGE0qt2uDeNW1Gi8=
=Xvfu
-----END PGP SIGNATURE-----
More information about the gephex-devel
mailing list