[gephex-devel] Scheduling

[JS]

Georg Seidel wrote:

>-----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).
>
>  
>

Ok so you're using mzScheme. Why is that? In the end I thought about 
using Guile since I thought it would be more fit to what I needed, that 
is, a simple way to quickly build a simple scripting language on top of 
our C++ core.

>>   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)?
>  
>

Yes. However, I thought about a very modular architecture, where the 
core (what I've called "script engine" in the schema) merely offers a 
basic set of tools (factories, schedulers, etc), the real operations 
being implemented by the modules (what I've called "libraries").

>  
>
>>   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.
>  
>

Sorry, no, that's not what I meant. By bytecode I'm refering to your 
"homemade language" that is used by konsolenphex (e.g. "plus.phex" file).

>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...
>  
>

Ok, I agree with you on that. Actually, what I meant is that I don't 
think I'm going to add a "bytecode" language under the scheme layer 
(like the GePhex 0.5 approach with Scheme layer generating .phex 
scripts). Instead, the Scheme layer will run on top of a C++ core.

>  
>
>>   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.
>  
>

What I'm thinking about is a "control flow" dimension to the "data flow" 
interface. That interface would allow gears to listen and trigger 
events. Those events would just trigger the computation of the gear. 
When the gear has finished its execution, it would trigger an event that 
could be listened by other gears.

I have included an example in attachment (PDF file) of a simple 
operation that adds two random numbers and prints them when someone 
pushes a button in a GUI. An example of script for that operation is 
given here:
http://orangeseeds.net/wiki/drone/Core/Drone0.4/Scripting/Spike/Exemples/ValueAddScheduling

>>   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.
>  
>

Yes. That's why I'm thinking about that modular approach. That way, if 
someone is not satisfied with any of the proposed approaches for 
scheduling/event handling, he can code his own module with corresponding 
scripting functions. The responsibility of the core is then to ensure 
seamless integration of the modules.

Best,

++ js

>
>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-----
>_______________________________________________
>gephex-devel mailing list
>gephex-devel at lists.gephex.org
>http://lists.gephex.org/mailman/listinfo/gephex-devel
>
>  
>


-- 
Jean-Sébastien Senécal
Reseach Assistant, Hexagram / Assistant de recherche à Hexagram
M. A. Student in Interactive Media / Étudiant en Médias Interactifs, Université du Québec à Montréal
M. Sc. Computer Sciences / Informatique, Université de Montréal
Mail: js at drone.ws
Web: http://drone.ws

-------------- next part --------------
A non-text attachment was scrubbed...
Name: schema_drone_event1.pdf
Type: application/pdf
Size: 24520 bytes
Desc: not available
Url : http://lists.gephex.org/pipermail/gephex-devel/attachments/20060226/98e0a490/schema_drone_event1-0001.pdf