> 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" <[email protected]>
An: pd-dev <[email protected]>
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
[email protected]
https://lists.puredata.info/listinfo/pd-dev[https://lists.puredata.info/listinfo/pd-dev]
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
