Hey all,
I am recently trying to dive into the C realm and revamped ggee's [shell] external. Because its API is different in many ways from the original, I decided to give it a new name.
Before I publish this to a wider audience through Deken, I would like to make sure I do not destroy the world by releasing this. Any comments or suggestions are welcome.
A first question I have is concerning the order of outlets. I kept the original order: STDOUT left, exit code right. However, since the exit code outlet fires always last, it probably would make sense the make it the left-most. Are there any similar precedent objects?
https://github.com/pd-externals/command/
Thanks, Roman
It's been some time since you posted this, and there's silence on this topic. I would just like to say that I'm very interested in a supported object similar to [shell] since ggee is not maintained any more (or is it?). If there is any way I can help, let me know, though I doubt I can help with the C programming for this object. Testing and anything else you need I'd be happy to help, if I can.
On 13/7/21 12:26 π.μ., Roman Haefeli wrote:
Hey all,
I am recently trying to dive into the C realm and revamped ggee's [shell] external. Because its API is different in many ways from the original, I decided to give it a new name.
Before I publish this to a wider audience through Deken, I would like to make sure I do not destroy the world by releasing this. Any comments or suggestions are welcome.
A first question I have is concerning the order of outlets. I kept the original order: STDOUT left, exit code right. However, since the exit code outlet fires always last, it probably would make sense the make it the left-most. Are there any similar precedent objects?
https://github.com/pd-externals/command/
Thanks, Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 13/7/21 12:26 π.μ., Roman Haefeli wrote:
However, since the exit code outlet fires always last, it probably would make
sense the make it the left-most. Are there any similar precedent objects?
Many objects do fire something not on the leftmost outlet for last to say something is done, take [cyclone/uzi] as an example.
cheers
On Tue, 2021-09-21 at 14:19 -0300, Alexandre Torres Porres wrote:
On 13/7/21 12:26 π.μ., Roman Haefeli wrote:
However, since the exit code outlet fires always last, it probably would make sense the make it the left-most. Are there any similar precedent objects?
Many objects do fire something not on the leftmost outlet for last to say something is done, take [cyclone/uzi] as an example.
Thanks for the example. I'm clear now that I should follow the rule and made the exit code outlet the left-most, since it is the only one that always fires after command execution (and because it makes sense for the left-most outlet to fire last, of course).
And yeah, [uzi] is confusing in that regard, but I guess it had to be done this way because the original was using this order.
Roman
Em qua., 22 de set. de 2021 às 11:38, Roman Haefeli reduzent@gmail.com escreveu:
[getdir] is now (soon) covered by Pd's [file]
it's already covered by [pdcontrol]'s 'dir' method.
I still have to better check the new [file] object, I'm assuming it overlaps with [else/dir].
And yeah, [uzi] is confusing in that regard, but I guess it had to be done this way because the original was using this order.
it is confusing and not the only example in cyclone, but maybe others make more sense, like a rightmost outlet that fires a bang when something is done with as in cyclone/seq, where a bang tells you the sequence is over - that's the same with [readsf~] by the way. If your object is more like [uzi], then it makes sense to have the leftmost outlet firing last.
cheers
On Tue, 2021-09-21 at 19:17 +0300, Alexandros wrote:
It's been some time since you posted this, and there's silence on this topic. I would just like to say that I'm very interested in a supported object similar to [shell] since ggee is not maintained any more (or is it?).
I had some interest in maintaining ggee because of [shell], but realized that I want a completely different object that would definitely break backwards compatibility with [shell]. [command] is based on [shell] code, though.
When I announced [command], it wasn't ready at all as I found out not much later. I discovered a few issues. Some of them are fixed now (IOhannes helped, too) and some are still open.
What I wanted and what [shell] did not support: - search executable relative to patch instead of Pd start location - output stdout and stderr through outlets - ways to interact with the running process: - send data to stdin - kill the running process
The list of open issues can be found here: https://github.com/pd-externals/command/issues
If there is any way I can help, let me know, though I doubt I can help with the C programming for this object. Testing and anything else you need I'd be happy to help, if I can.
If you don't need to send something to stdin, it's already working fine now. It should run on Linux and macOS and uses pd-lib-builder for building. Of course, I'm glad if you can test. I can provide binaries, if needed (I think it is not ready yet to be released through Deken). You're welcome to open any issues or feature requests.
Re ggee: [shell] and [getdir] were the two objects actually extended Pd's capabilities. I consider [shell] insufficient and [getdir] is now (soon) covered by Pd's [file] object, which is orders of magnitude more powerful. I wouldn't base any new projects on ggee. I would keep ggee alive purely for supporting old patches. I don't think that any new development efforts should go into ggee.
Roman
-
Alexandre Torres Porres -
Alexandros -
Roman Haefeli