Here's how we do it in OpenFrameworks: https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrame...
On Jul 30, 2013, at 3:03 PM, pd-list-request@iem.at wrote:
From: Jonathan Wilkes jancsika@yahoo.com Subject: Re: [PD] get dir of current pd Date: July 30, 2013 2:43:24 PM EDT To: pd-list@iem.at
On 07/30/2013 07:48 AM, yvan volochine wrote:
On 30/07/13 08:41, Jonathan Wilkes wrote:
Ok, I figured out how to do this
and how do you do?
In GNU/Linux on some _distros_ you can check the symlink /proc/self/exe
If you do a readink from within C in Pd you'll get the absolute path and name of the executable.
However, if you use the command "readlink" to [shell] I imagine the readlink binary will look in the mirror and give you its own name back.
I don't think /proc/self/exe is a requirement of all Linux flavors, and I don't know what the BSD OSes do, or OSX. So I'm reluctant to add this to [pdinfo].
Windows has its own function accessible from C to return the full path and name of the executable.
-Jonathan
y
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On 07/30/2013 03:40 PM, Dan Wilcox wrote:
Here's how we do it in OpenFrameworks: https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrame...
Hm, looking here: http://stackoverflow.com/questions/7413445/accessing-proc
and here: http://stackoverflow.com/questions/1023306/finding-current-executables-path-...
It looks like a) proc/self/exe is going to be there for almost all (if not indeed all) modern Linux distros, and there are methods to get it for the BSDs and OSX. If someone knows a Linux setup where Pd can be used where "proc/self/exe" wouldn't work, let me know.
That's a lot of ifdefs, but we might as well fill out pd_getdirname and then it's easy to hook in through [pdinfo]. If nothing else, this would be useful for debugging/troubleshooting.
That said, launching another Pd from inside Pd this is the wrong solution to the OP's problem. That's kind of the point of [pd~]. Max- Are you experiencing dropouts from the subprocess stalling, or are you saying you're trying to avoid the possibility of dropouts. If it's the latter, then I'm having a hard time figuring out how two Pds connected through netsend would avoid dropouts. Also, what causes the freezes?
-Jonathan
On Jul 30, 2013, at 3:03 PM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> *Subject:**Re: [PD] get dir of current pd* *Date:*July 30, 2013 2:43:24 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at
On 07/30/2013 07:48 AM, yvan volochine wrote:
On 30/07/13 08:41, Jonathan Wilkes wrote:
Ok, I figured out how to do this
and how do you do?
In GNU/Linux on some _distros_ you can check the symlink /proc/self/exe
If you do a readink from within C in Pd you'll get the absolute path and name of the executable.
However, if you use the command "readlink" to [shell] I imagine the readlink binary will look in the mirror and give you its own name back.
I don't think /proc/self/exe is a requirement of all Linux flavors, and I don't know what the BSD OSes do, or OSX. So I'm reluctant to add this to [pdinfo].
Windows has its own function accessible from C to return the full path and name of the executable.
-Jonathan
y
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Am 30.07.2013 um 23:32 schrieb Jonathan Wilkes jancsika@yahoo.com:
Max- Are you experiencing dropouts from the subprocess stalling, or are you saying you're trying to avoid the possibility of dropouts. If it's the latter, then I'm having a hard time figuring out how two Pds connected through netsend would avoid dropouts. Also, what causes the freezes?
Cyrille has repeatedly said on this list that [pd~] is not the way to completely detach the two instances and that it one should use two instances instead. Never mind - I thought there was an elegant solution to launch another instance from a patch programmatically.
m.
On 07/30/2013 07:05 PM, Max wrote:
Am 30.07.2013 um 23:32 schrieb Jonathan Wilkes jancsika@yahoo.com:
Max- Are you experiencing dropouts from the subprocess stalling, or are you saying you're trying to avoid the possibility of dropouts. If it's the latter, then I'm having a hard time figuring out how two Pds connected through netsend would avoid dropouts. Also, what causes the freezes?
Cyrille has repeatedly said on this list that [pd~] is not the way to completely detach the two instances and that it one should use two instances instead. Never mind - I thought there was an elegant solution to launch another instance from a patch programmatically.
Yeah, I don't think I know of one. I've only read the paper on [pd~], never used it. (Nor the shared mem library external.)
-Jonathan
On 07/30/2013 07:05 PM, Max wrote:
Am 30.07.2013 um 23:32 schrieb Jonathan Wilkes jancsika@yahoo.com:
Max- Are you experiencing dropouts from the subprocess stalling, or are you saying you're trying to avoid the possibility of dropouts. If it's the latter, then I'm having a hard time figuring out how two Pds connected through netsend would avoid dropouts. Also, what causes the freezes?
Cyrille has repeatedly said on this list that [pd~] is not the way to completely detach the two instances and that it one should use two instances instead. Never mind - I thought there was an elegant solution to launch another instance from a patch programmatically.
m.
Attached is a patch to s_path.c that fleshes out a pd_getdirname function which should return the executable's path on OSX, Windows, Linux, and FreeBSD. I don't have FreeBSD running so I didn't test that one.
Question: should this function print an error, or should it send an empty symbol on error and let the caller do that? I'm currently doing the latter when using the function in [pdinfo]-- that let's me tailor the error message to the relevant object which should help with user error report. (I.e., generate a "findable" error.)
Anyway if this looks good I'll go ahead and update [pdinfo] and add a "dir" method, or maybe a "pddir" method. (Suggestions welcome on method name.)
-Jonathan
On 07/30/2013 03:40 PM, Dan Wilcox wrote:
Here's how we do it in OpenFrameworks: https://github.com/openframeworks/openFrameworks/blob/develop/libs/openFrame...
Btw-- In line 1414, is that supposed to be "!=" instead of "==" ?
-Jonathan
On Jul 30, 2013, at 3:03 PM, pd-list-request@iem.at mailto:pd-list-request@iem.at wrote:
*From:*Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> *Subject:**Re: [PD] get dir of current pd* *Date:*July 30, 2013 2:43:24 PM EDT *To:*pd-list@iem.at mailto:pd-list@iem.at
On 07/30/2013 07:48 AM, yvan volochine wrote:
On 30/07/13 08:41, Jonathan Wilkes wrote:
Ok, I figured out how to do this
and how do you do?
In GNU/Linux on some _distros_ you can check the symlink /proc/self/exe
If you do a readink from within C in Pd you'll get the absolute path and name of the executable.
However, if you use the command "readlink" to [shell] I imagine the readlink binary will look in the mirror and give you its own name back.
I don't think /proc/self/exe is a requirement of all Linux flavors, and I don't know what the BSD OSes do, or OSX. So I'm reluctant to add this to [pdinfo].
Windows has its own function accessible from C to return the full path and name of the executable.
-Jonathan
y
Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Dan Wilcox -
Jonathan Wilkes -
Max