[PD] [PD-dev] [pdcontrol] reliance on Tcl

[Christof Ressi]

> If the idea is that gui sending provides a quick way to emulate a system() call, I can understand that however I think a more universal design would be based around system() itself
 
I don't think that's the intended purpose of the "gui" message, but you're right that running shell commands shouldn't be dependend on the GUI.
 
---
 
BTW, I have an idea for adding an asynchronous task API to Pd (similar to that of SuperCollider):

*** methods ***

typedef void (*t_task_method)(void *owner, void *data);
 
int async_task_add(void *owner, *data, t_task_method taskfn, t_task_method callbackfn, t_task_method freefn);
void async_task_cancel(int id);

*** explanation ***
 
"async_task_add" pushes a new task to a lockfree FIFO ("fromEngine") with "data" as the shared state and returns a unique task ID. A worker thread pops tasks from the FIFO, calls "taskfn" and when finished, pushes the task to a second FIFO ("toEngine"). Pd's scheduler pops the task from the "toEngine" FIFO and calls "callbackfn" to notify the owner that the task has finished.

"async_task_cancel" can be used to cancel a running task (by its ID), e.g. when the owning object is about to be destroyed.

The (optional) "freefn" is used for clean up and is called right after "callbackfn" or when the task has been cancelled; just set it to NULL if there's nothing to free (e.g. if "data" is managed by "owner").


This API can be used to execute non-realtime safe tasks which don't have to meet a certain deadline. [pdcontrol] could use it to spawn a process in the background and collect the result. It would also simplify https://github.com/pure-data/pure-data/pull/655. Of course, externals can use it too.
 
The big advantage would be that Pd itself manages the thread pool, so not every asynchronous object has to spawn its own worker thread!
 
I can work out a proof of concept, if people are interested.
 
Christof
 

Gesendet: Mittwoch, 07. August 2019 um 15:34 Uhr
Von: "Dan Wilcox" <danomatika at gmail.com>
An: pd-dev <pd-dev at lists.iem.at>
Betreff: [PD-dev] [pdcontrol] reliance on Tcl

I'm just now looking into the new [pdcontrol] object and I like what I see. I am concerned about the gui sending feature as it seems to rely directly on Tcl.
 
With my libpd hat on, I'm interested in moving the pd core towards less/no direct reliance on raw sending Tcl/Tk strings, basically making Pd more GUI agnostic. For the gui running Tcl/Tk, the plugin concept makes sense as it's focused on that domain and not with the pd core. However for a future libpd-based app that renders patches with a different framework on a specific platform (ie. PdParty) and focused on as much feature parity as possible, I may need to suddenly support people's edge-case usage of raw Tcl without a Tcl interpreter.
 
If the idea is that gui sending provides a quick way to emulate a system() call, I can understand that however I think a more universal design would be based around system() itself and an overridable function or interface as some platforms, namely iOS, do not allow the use of system().
 
I bring this up now as once this precedent is set, it's obviously *very* difficult to change it once people start using this feature. 

--------
Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 
_______________________________________________ Pd-dev mailing list Pd-dev at lists.iem.at https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev]