Hi Everyone,
I'm trying to get my head around this problem, and I am not sure the subject describes it well…:
In an external, I'm writing into a file with:
FILE *fp1; fp1 = fopen(x->globalpath, "w");
I provide the external with x->globalpath through a message such as "open /home/user/filename.txt", but I am trying to find a path that would work on both os x and linux, so that it at least works in two platforms and my help file isn't platform specific.
In Linux, I call Pd from the console with "pd" and I send several relative paths like "filename.txt" , "~/filename.txt", or "./filename.txt" work.
In OS X, If I call Pd from the Terminal, I can also use these relative paths. By relative i mean relative to the Pd executable (bin).
However, in OS X, when I double click on the Pd Icon, these same paths are not valid. I am trying to figure how textfile's write message does it, but I cannot locate the point in source where this is done.
Anybody has any pointers?
best,
J
On Fri, Jun 27, 2014 at 8:57 PM, Jaime E Oliver via Pd-list pd-list@lists.iem.at wrote:
Hi Everyone,
I'm trying to get my head around this problem, and I am not sure the subject describes it well…:
In an external, I'm writing into a file with:
FILE *fp1; fp1 = fopen(x->globalpath, "w");
I provide the external with x->globalpath through a message such as "open /home/user/filename.txt", but I am trying to find a path that would work on both os x and linux, so that it at least works in two platforms and my help file isn't platform specific.
In Linux, I call Pd from the console with "pd" and I send several relative paths like "filename.txt" , "~/filename.txt", or "./filename.txt" work.
In OS X, If I call Pd from the Terminal, I can also use these relative paths. By relative i mean relative to the Pd executable (bin).
However, in OS X, when I double click on the Pd Icon, these same paths are not valid. I am trying to figure how textfile's write message does it, but I cannot locate the point in source where this is done.
Anybody has any pointers?
best,
J
What comes to mind is that you could write some "post()" calls in your external to print out x->globalpath to the console when the setup routine is called. Then, try it out on different platforms and with different launch methods (terminal vs menu item).
Aside from just trying it out, you need some insight into the code (the reason for your mail of course).
Hey, Jaime! It also occurs to me that there must be some easy C way to return the current path. cd does it, why can't you? A crude solution might be to put some platform specific #ifdef statements into the code, but that may not get to the heart of your problem. -David
On 06/29/2014 08:18 AM, Charles Z Henry via Pd-list wrote:
On Fri, Jun 27, 2014 at 8:57 PM, Jaime E Oliver via Pd-list pd-list@lists.iem.at wrote:
Hi Everyone,
I'm trying to get my head around this problem, and I am not sure the subject describes it well…:
In an external, I'm writing into a file with:
FILE *fp1; fp1 = fopen(x->globalpath, "w");
I provide the external with x->globalpath through a message such as "open /home/user/filename.txt", but I am trying to find a path that would work on both os x and linux, so that it at least works in two platforms and my help file isn't platform specific.
In Linux, I call Pd from the console with "pd" and I send several relative paths like "filename.txt" , "~/filename.txt", or "./filename.txt" work.
In OS X, If I call Pd from the Terminal, I can also use these relative paths. By relative i mean relative to the Pd executable (bin).
However, in OS X, when I double click on the Pd Icon, these same paths are not valid. I am trying to figure how textfile's write message does it, but I cannot locate the point in source where this is done.
Anybody has any pointers?
best,
J
What comes to mind is that you could write some "post()" calls in your external to print out x->globalpath to the console when the setup routine is called. Then, try it out on different platforms and with different launch methods (terminal vs menu item).
Aside from just trying it out, you need some insight into the code (the reason for your mail of course).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/29/2014 11:18 AM, Charles Z Henry via Pd-list wrote:
On Fri, Jun 27, 2014 at 8:57 PM, Jaime E Oliver via Pd-list pd-list@lists.iem.at wrote:
Hi Everyone,
I'm trying to get my head around this problem, and I am not sure the subject describes it well…:
In an external, I'm writing into a file with:
FILE *fp1; fp1 = fopen(x->globalpath, "w");
I provide the external with x->globalpath through a message such as "open /home/user/filename.txt", but I am trying to find a path that would work on both os x and linux, so that it at least works in two platforms and my help file isn't platform specific.
I think you might want to check out canvas_open inside g_canvas.c. It looks like it will hand you back a file descriptor.
If you use that same interface, then in your help file you can just tell the user it searches the path the same as the rest of Pd.
But I may be misunderstanding what it is you're trying to do.
-Jonathan
Thanks!
This is exactly what I was looking for...
J
On Jun 29, 2014, at 1:29 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
canvas_open inside g_canvas.c
Hi all,
Checking out canvas_open inside g_canvas.c, I realize that this is a function to open a file that already exists, while what I am trying to do is write a file with a path that is relative to the canvas. I couldn't find something similar, such as canvas_write or such.
thanks again!
J
You probably want to call canvas_makefilename(), supplying the owning canvas, not a new one. YOu can get the owning canvas using canvas_getcurrent(), but only when the object is being created (the information is not kept so your object needs to keep it itself). For a simple example, search pd/extra/bink~/bonk~.c for x->x_canvas - it gets intialized in the new() methnd and used both to create and read files.
cheers Miller
On Sun, Jun 29, 2014 at 05:49:23PM -0500, Jaime E Oliver via Pd-list wrote:
Hi all,
Checking out canvas_open inside g_canvas.c, I realize that this is a function to open a file that already exists, while what I am trying to do is write a file with a path that is relative to the canvas. I couldn't find something similar, such as canvas_write or such.
thanks again!
J
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, exactly, thanks for this! best, J
On Jun 30, 2014, at 12:40 AM, Miller Puckette msp@ucsd.edu wrote:
You probably want to call canvas_makefilename(), supplying the owning canvas, not a new one. YOu can get the owning canvas using canvas_getcurrent(), but only when the object is being created (the information is not kept so your object needs to keep it itself). For a simple example, search pd/extra/bink~/bonk~.c for x->x_canvas - it gets intialized in the new() methnd and used both to create and read files.
cheers Miller
On Sun, Jun 29, 2014 at 05:49:23PM -0500, Jaime E Oliver via Pd-list wrote:
Hi all,
Checking out canvas_open inside g_canvas.c, I realize that this is a function to open a file that already exists, while what I am trying to do is write a file with a path that is relative to the canvas. I couldn't find something similar, such as canvas_write or such.
thanks again!
J
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Charles Z Henry via Pd-list -
David Medine via Pd-list
-
Jaime E Oliver via Pd-list
-
Jonathan Wilkes via Pd-list
-
Miller Puckette via Pd-list