Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 19:11 +0100, Christof Ressi wrote:
> Should we also provide a creation argument and float message for the 
> parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> 
> [file patchdir] would output the parent patch directory, etc. This
> would 
> make [pdcontrol]'s [dir( method entirely obsolete.

Nice idea. The ability to query upper level patches is quite a powerful
feature. 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

probably [file patchpath] then?
a "path" can be both a file and a directory, whereas a "dir" can only be the 
latter

+1



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 8. Jänner 2022 19:11:43 MEZ schrieb Christof Ressi :
>Then let's go with [file patchdir] for now. I don't care too much about 
>the name :-)
>
>A bang would unsurprisingly output the patch directory.
>
>You can also send a path name as a symbol. If the path is relative, 
>[file patchdir] will resolve it to the patch directory. Absolute paths 
>are passed unchanged.


probably [file patchpath] then?
a "path" can be both a file and a directory, whereas a "dir" can only be the 
latter


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

Then let's go with [file patchdir] for now. I don't care too much about 
the name :-)


A bang would unsurprisingly output the patch directory.

You can also send a path name as a symbol. If the path is relative, 
[file patchdir] will resolve it to the patch directory. Absolute paths 
are passed unchanged.


Should we also provide a creation argument and float message for the 
parent level? For example, [bang( -> [file patchdir 1] resp. [1( -> 
[file patchdir] would output the parent patch directory, etc. This would 
make [pdcontrol]'s [dir( method entirely obsolete.


Christof

On 08.01.2022 18:46, IOhannes m zmölnig wrote:

Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi :

Both would essentially provide the same things. IMO, [file resolve]
would be more intuitive because after all that's what people likely want
to do when they ask for the current patch directory.



I dunno.
iirc, [file which] was originally named [file resolve] but I started a hearty 
dislike for this name, as I think its rather confusing.


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 8. Jänner 2022 18:31:43 MEZ schrieb Christof Ressi :
>Both would essentially provide the same things. IMO, [file resolve] 
>would be more intuitive because after all that's what people likely want 
>to do when they ask for the current patch directory.
>


I dunno.
iirc, [file which] was originally named [file resolve] but I started a hearty 
dislike for this name, as I think its rather confusing.


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

I'll be travelling on Monday and can make a PR while sitting around.


  (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)

Yes, there is. [file isabsolute] should be trivial to implement.


add [file cwd]
   (and probably allow it to also *set* the cwd, not just query it)

Yes, why not. Should be easy to do with chdir() resp. _chdir()


add [file patchdir]
   (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))
+1. On GitHub I have already proposed [file resolve]: 
https://github.com/pure-data/pure-data/issues/1539. The difference is 
that it resolves any path onto the patch directory. Sending a bang would 
output the patch directory itself (= [file patchdir]).


[file patchdir] would be the other way round: it's main purpose is to 
get the patch directory, but as an extra feature it should probably also 
allow to resolve a file path (because such a common task shouldn't 
require several objects).


Both would essentially provide the same things. IMO, [file resolve] 
would be more intuitive because after all that's what people likely want 
to do when they ask for the current patch directory.


Christof


On 08.01.2022 17:58, IOhannes m zmölnig wrote:

Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi :

I think what we actually need is something like [file isabsolute] and
[file isrelative]! That would be a trivial but very useful addition.


yes.

the solution I like best so far is:
- add [file isabsolute]
   (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)
- add [file cwd]
   (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir]
   (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Miller Puckette via Pd-list]

The confusion is my fault... "." never really meant current working directory,
it just means "THIS directory here".  I.E., it could mean any #$^#$ thing at
all :)

M

On Sat, Jan 08, 2022 at 10:42:35AM +0100, Dan Wilcox wrote:
> I agree with Roman's point that "current working directory" as an idea is 
> different, depending on the user. For some, it will be relative to the patch, 
> for others it will be relative to the shell (and the resulting programs 
> launched by it). I agree it makes technical sense that [file] would be 
> relative to the Pd process, knowing the C api behind it, but for many it's a 
> bit of friction for sure since it's something that now works different from 
> other objects which handle paths implicitly. Additionally, I think it's 
> perhaps a stretch to assume most beginners are aware of how shells and paths 
> work.
> 
> If it were up to me, I would make [file] work like the other objects and 
> treat relative paths as relative to the canvas. OTOH I know this could 
> complicate the implementation. I think at the very least, this difference 
> needs to be well documented with the requisite canvas-oriented approaches 
> documented. Forgive me if they are already as I've not used [file] yet, but 
> Roman's question indicates to me perhaps not everything is covered yet. ;)
> 
> Another approach is to provide a very explicit option to get the patch canvas 
> location which fits into the api ala [file patchdir] or [file canvasdir]. I 
> know this is probably redundant to [pdcontrol] but perhaps helps with the 
> distinction..?
> 
> > On Jan 8, 2022, at 1:07 AM, pd-list-requ...@lists.iem.at wrote:
> > 
> > Message: 4
> > Date: Sat, 8 Jan 2022 01:07:48 +0100
> > From: Christof Ressi  > <mailto:i...@christofressi.com>>
> > To: Pd-List mailto:pd-list@lists.iem.at>>
> > Subject: Re: [PD] [file]: paths not relative to patch
> > Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com 
> > <mailto:0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com>>
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > 
> >> If I pass a relative path to such an utility, I want it to resolve to 
> >> the current working directy and *not* to the Pd patch itself. 
> > In practice, I almost wrap such utilities in a shell script anyway and 
> > there I would turn relative path arguments into absolute paths before 
> > passing them on to Pd. But I just wanted to show that the current 
> > directory is not completely useless.
> 
> 
> Dan Wilcox
> @danomatika 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danomatika&d=DwIFAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD&s=gH_npJrym_AUp6g2bC1Cy42FFNjsXv2JGArQ6pEwxoM&e=
>  >
> danomatika.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__danomatika.com_&d=DwIFAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD&s=5QkVbm0PrquWxtDou0wHEgQlij2_6GjNBrY2b5e5XMI&e=
>  >
> robotcowboy.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__robotcowboy.com_&d=DwIFAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD&s=H8fVMW2BC7JQXR0lgwqC8aVGjEXivsHhxcCet25Ib4Q&e=
>  >
> 
> 
> 

> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=si0E4sBrl6UO_wKfCrB67OJIEHVUTR1xFkggTXMywUTZjoXA_Zik5eRJKP7Q-LwD&s=Yk4lLERpW4lj0UBqxDacoYqSc91l7nXb2qIJgzQCYoM&e=
>  




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[IOhannes m zmölnig]

Am 7. Jänner 2022 23:32:24 MEZ schrieb Christof Ressi :
>> I think what we actually need is something like [file isabsolute] and 
>> [file isrelative]! That would be a trivial but very useful addition. 


yes.

the solution I like best so far is:
- add [file isabsolute]
  (I'm currently afk, but isn't there already something like this in the 
filename handling parts of [file]?)
- add [file cwd]
  (and probably allow it to also *set* the cwd, not just query it)
- add [file patchdir]
  (I would consider it a feature if that functionality was provided by [file] 
rather than [pdcontrol] (which could keep it for legacy reasons))


mfg.sfg.jfd
IOhannes


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

I, personally, find the documentation of [file] quite good.


Yes, but it doesn't mention at all that relative paths are resolved to 
the current working directory (or any other way the OS prefers). This is 
goes against an established pattern and would be surprising to most 
users (although it's not wrong).


I think file-help.pd should mention prominently that relative file paths 
are generally *not* resolved to the canvas environment and you have to 
use either [file which] or [dir( -> [pd control]. Hopefully, the latter 
can soon be replaced by something like [file resolve]: 
https://github.com/pure-data/pure-data/issues/1539





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 10:42 +0100, Dan Wilcox wrote:

> 
> If it were up to me, I would make [file] work like the other objects
> and treat relative paths as relative to the canvas.

I agree with Christof that this probably not a good idea after pd 0.52
has been released.

>  OTOH I know this could complicate the implementation.

Yeah, I see that now. I thought
'chdir(canvas_getdir(canvas_getcurrent))' would probably do, but since
[file] runs directly in Pd it would apply to the whole Pd instance,
which is probably not what anyone wants. My external [command] does
that, but after forking, so it doesn't apply to the parent thread. This
allows to call scripts lying near the patch containing [command]. 

>  I think at the very least, this difference needs to be well
> documented with the requisite canvas-oriented approaches documented.
> Forgive me if they are already as I've not used [file] yet, but
> Roman's question indicates to me perhaps not everything is covered
> yet. ;)

It came up because I noticed [file] breaks established patterns
regarding relative paths. Improving the documentation alone wouldn't
help with making write files near the patch easier. I, personally, find
the documentation of [file] quite good. 

> Another approach is to provide a very explicit option to get the
> patch canvas location which fits into the api ala [file patchdir] or
> [file canvasdir]. I know this is probably redundant to [pdcontrol]
> but perhaps helps with the distinction..?

The hard part is not getting the canvas directory, as that is already
covered, but simply writing a file near the patch involves quite a lot
of patching right now. What _would_ help is Christof's suggestion of
[file resolve] if it has the ability to resolve to relative to the
patch.

[symbol myblobs/newblob.dat(
|
[file resolve -canvas]
|
[open $1 c(
|
[file handle]


See:
https://github.com/pure-data/pure-data/issues/1536#issuecomment-1007849130



Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Sat, 2022-01-08 at 10:27 +0100, Dan Wilcox wrote:
> I assume you already have a relative & absolute path check
> implementation. 

Yes, but thanks anyway.

> If not, I have a simple set of vanilla path abstractions, pre-[file]:
> 
> p_absolute, p_makeabsolute, p_makerelative, etc

> https://github.com/danomatika/rc-patches/tree/master/rc

The latter two currently use [getdir] from ggee, but this could easily
be replaced now by [dir(->[pdcontrol].

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Dan Wilcox]

I agree with Roman's point that "current working directory" as an idea is 
different, depending on the user. For some, it will be relative to the patch, 
for others it will be relative to the shell (and the resulting programs 
launched by it). I agree it makes technical sense that [file] would be relative 
to the Pd process, knowing the C api behind it, but for many it's a bit of 
friction for sure since it's something that now works different from other 
objects which handle paths implicitly. Additionally, I think it's perhaps a 
stretch to assume most beginners are aware of how shells and paths work.

If it were up to me, I would make [file] work like the other objects and treat 
relative paths as relative to the canvas. OTOH I know this could complicate the 
implementation. I think at the very least, this difference needs to be well 
documented with the requisite canvas-oriented approaches documented. Forgive me 
if they are already as I've not used [file] yet, but Roman's question indicates 
to me perhaps not everything is covered yet. ;)

Another approach is to provide a very explicit option to get the patch canvas 
location which fits into the api ala [file patchdir] or [file canvasdir]. I 
know this is probably redundant to [pdcontrol] but perhaps helps with the 
distinction..?

> On Jan 8, 2022, at 1:07 AM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 4
> Date: Sat, 8 Jan 2022 01:07:48 +0100
> From: Christof Ressi mailto:i...@christofressi.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] [file]: paths not relative to patch
> Message-ID: <0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com 
> <mailto:0d33e805-37ff-4988-d50e-29eb3d86d...@christofressi.com>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
>> If I pass a relative path to such an utility, I want it to resolve to 
>> the current working directy and *not* to the Pd patch itself. 
> In practice, I almost wrap such utilities in a shell script anyway and 
> there I would turn relative path arguments into absolute paths before 
> passing them on to Pd. But I just wanted to show that the current 
> directory is not completely useless.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Dan Wilcox]

I assume you already have a relative & absolute path check implementation. If 
not, I have a simple set of vanilla path abstractions, pre-[file]:

p_absolute, p_makeabsolute, p_makerelative, etc

https://github.com/danomatika/rc-patches/tree/master/rc 


> On Jan 7, 2022, at 11:35 PM, pd-list-requ...@lists.iem.at wrote:
> 
>> If you want to resolve an 
>> existing file using Pd's canvas: use [file which]. If you want create
>> a 
>> new file relative to the patch, use [dir( -> [pdcontrol].
> 
> That's what I do now. That's the easy part. The less easy part is
> reliably detecting whether a given path is relative. But knowing that
> even Pd does it somewhat clumsily, I'll stick to the clumsy solution
> (checking for / and :).


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

If I pass a relative path to such an utility, I want it to resolve to 
the current working directy and *not* to the Pd patch itself. 
In practice, I almost wrap such utilities in a shell script anyway and 
there I would turn relative path arguments into absolute paths before 
passing them on to Pd. But I just wanted to show that the current 
directory is not completely useless.


On 08.01.2022 00:49, Christof Ressi wrote:



use the current working directory?

Ah, now I understand your question. But I don't think it is a valid
question. I see no point in using what currently is the working
directory of Pd. Depending on how Pd is started, it uses a different
working directory without the user necessarily intending to do so.


There are certainly scenarios where this is exactly what you want, 
e.g. when Pd is used as command line utily (I have personally written 
such utilities). If I pass a relative path to such an utility, I want 
it to resolve to the current working directy and *not* to the Pd patch 
itself.



Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.
I acknowledge that it's an established pattern. Actually, [file] could 
have added an object [file cwd] to get the currenty
working directy if someone needs it and use the Pd patch location as 
the default.


On the other hand, I understand that [file] wants to be a low-level 
filesystem API and not apply any magic. It's really design decision.



I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it.


Yes, this is a limitation. And actually an argument for a [file cwd] 
object.



How is the current working directory not a sane directy?

See above. It's just not useful for anything.

See above. It is.

even Pd does it somewhat clumsily, I'll stick to the clumsy
solution
(checking for / and :).

That's what I was going to recommend.

  It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an
absolute path while I was intending it as a relative path.

Ah yes, on the patch level you don't know if you're on Windows. On 
Windows, ':' is a reserved character and can only appear as part of a 
drive letter.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

use the current working directory?

Ah, now I understand your question. But I don't think it is a valid
question. I see no point in using what currently is the working
directory of Pd. Depending on how Pd is started, it uses a different
working directory without the user necessarily intending to do so.


There are certainly scenarios where this is exactly what you want, e.g. 
when Pd is used as command line utily (I have personally written such 
utilities). If I pass a relative path to such an utility, I want it to 
resolve to the current working directy and *not* to the Pd patch itself.



Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.

I acknowledge that it's an established pattern. Actually, [file] could have 
added an object [file cwd] to get the currenty
working directy if someone needs it and use the Pd patch location as the 
default.

On the other hand, I understand that [file] wants to be a low-level filesystem 
API and not apply any magic. It's really design decision.


I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it.


Yes, this is a limitation. And actually an argument for a [file cwd] object.


How is the current working directory not a sane directy?

See above. It's just not useful for anything.

See above. It is.

even Pd does it somewhat clumsily, I'll stick to the clumsy
solution
(checking for / and :).

That's what I was going to recommend.
  
It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an

absolute path while I was intending it as a relative path.

Ah yes, on the patch level you don't know if you're on Windows. On 
Windows, ':' is a reserved character and can only appear as part of a 
drive letter.






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 23:41 +0100, Christof Ressi wrote:
> > > > And what would you *do* want to use the current working
> > > > directory?
> > The patch's own directory, like all other file writing objects do.
> Sorry, made a typo there. I meant: what would you do if you *do* want
> to 
> use the current working directory?

Ah, now I understand your question. But I don't think it is a valid
question. I see no point in using what currently is the working
directory of Pd. Depending on how Pd is started, it uses a different
working directory without the user necessarily intending to do so. When
I double-click a Pd file, the working directory is set to my user home.
When I launch Pd from terminal or by script, anything might be the
resulting working directory. If I do use that in a patch, I must make
assumptions about how the user running my patch is starting Pd. I do
not think that makes any sense, therefor I don't see how Pd's start
location has any sensible meaning in everyday patching. 

I'm asking you back: What do you do if you want to write relative to
Pd's start location with [text], [textfile], [table], [soundfiler],
[array]? You currently cannot do that and apparently this is no
problem, otherwise people would have requested it. 

> > > Generally, [file] doesn't do any magic.
> > I don't consider starting from a sane working directory magic.
> How is the current working directory not a sane directy? 

See above. It's just not useful for anything.

> Again, [file] 
> doesn't do anything special. It treats relative file paths just like
> the 
> OS shell would do.

And? It's usually not part of the Pd workflow to switch to a specific
directory before starting Pd. More often, Pd is launched by double-
clicking a patch. This is very unlike shell, where switching
directories  is part of the experience and where there's an expectation
it has an impact on the outcome ('ls' without args). This does not
apply to Pd at all. Thus, all file writing objects are written so that
they write relative to the patch. That's an already established
pattern. I don't see why you are arguing against it.


> > >   If you want to resolve an
> > > existing file using Pd's canvas: use [file which]. If you want
> > > create
> > > a
> > > new file relative to the patch, use [dir( -> [pdcontrol].
> > That's what I do now. That's the easy part. The less easy part is
> > reliably detecting whether a given path is relative. But knowing
> > that
> > even Pd does it somewhat clumsily, I'll stick to the clumsy
> > solution
> > (checking for / and :).
> That's what I was going to recommend. 
 
It's clumsy and wrong. It'll detect my  sub-directory named 'C:' as an
absolute path while I was intending it as a relative path.





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

And what would you *do* want to use the current working directory?

The patch's own directory, like all other file writing objects do.
Sorry, made a typo there. I meant: what would you do if you *do* want to 
use the current working directory?

Generally, [file] doesn't do any magic.

I don't consider starting from a sane working directory magic.
How is the current working directory not a sane directy? Again, [file] 
doesn't do anything special. It treats relative file paths just like the 
OS shell would do.

  If you want to resolve an
existing file using Pd's canvas: use [file which]. If you want create
a
new file relative to the patch, use [dir( -> [pdcontrol].

That's what I do now. That's the easy part. The less easy part is
reliably detecting whether a given path is relative. But knowing that
even Pd does it somewhat clumsily, I'll stick to the clumsy solution
(checking for / and :).
That's what I was going to recommend. After all, [file isabsolute] would 
likely just use sys_isabsolutepath() under the hood :-)





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 23:20 +0100, Christof Ressi wrote:
> > 
> 
> And what would you *do* want to use the current working directory?

The patch's own directory, like all other file writing objects do.


> Generally, [file] doesn't do any magic.

I don't consider starting from a sane working directory magic.

>  If you want to resolve an 
> existing file using Pd's canvas: use [file which]. If you want create
> a 
> new file relative to the patch, use [dir( -> [pdcontrol].

That's what I do now. That's the easy part. The less easy part is
reliably detecting whether a given path is relative. But knowing that
even Pd does it somewhat clumsily, I'll stick to the clumsy solution
(checking for / and :).
> 
> > Yeah, this works fine for finding already existing files, but as
> > the
> > help-file says, you cannot resolve directories with. So, it cannot
> > be
> > used for
> 
> But that's a general limitation of Pd. At the moment, it can only 
> resolve files but not directories. This limitation can, of course,
> be 
> removed and then [file which] will work as expection.

Thinking about it some more, this isn't a severe limitation. As I
understand, it looks into all search paths. However, when I configure
'myblobs' as directory, I don't mean to write to any other 'myblobs'
directory that might be returned by [file which]. I think [file which]
shouldn't be for finding directories to write new files into. It should
only be used for finding existing files. 


> > I only need to append the
> > configured path to the patch's path if the configured path is a
> > relative path. But how can I reliably detect that?
> I think what we actually need is something like [file isabsolute]
> and 
> [file isrelative]! That would be a trivial but very useful addition.

I think those would be valuable additions.

Roman





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

I think what we actually need is something like [file isabsolute] and 
[file isrelative]! That would be a trivial but very useful addition. 


Just made a feature request: 
https://github.com/pure-data/pure-data/issues/1535





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

What I think should happen when instantiating any [file] objects is to
set the working directory to the patch's directory and not to Pd's
start directory. The latter is irrelevant in the cases I can think of.


And what would you *do* want to use the current working directory?

Generally, [file] doesn't do any magic. If you want to resolve an 
existing file using Pd's canvas: use [file which]. If you want create a 
new file relative to the patch, use [dir( -> [pdcontrol].



Yeah, this works fine for finding already existing files, but as the
help-file says, you cannot resolve directories with. So, it cannot be
used for


But that's a general limitation of Pd. At the moment, it can only 
resolve files but not directories. This limitation can, of course, be 
removed and then [file which] will work as expection.



I only need to append the
configured path to the patch's path if the configured path is a
relative path. But how can I reliably detect that?
I think what we actually need is something like [file isabsolute] and 
[file isrelative]! That would be a trivial but very useful addition.


Christof





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
> 
> Yeah, this works fine for finding already existing files, but as the
> help-file says, you cannot resolve directories with. So, it cannot be
> used for 

Sorry, I somehow hit 'send' in the middle of a sentence. I meant to
say: [file which] doesn't work for resolving relative directories.
Obviously, you also cannot use it for non-existing files, a.k.a files
you want to create. This means, using [file] for writing files near the
patch is a rather convoluted enterprise.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 22:58 +0100, Roman Haefeli wrote:
> 
> What I think should happen when instantiating any [file] objects is
> to
> set the working directory to the patch's directory and not to Pd's
> start directory. 

I was wondering how objects before [file] did select a path for
writing. If I am not mistaken, [text] uses canvas_makefilename() for
converting a given path or filename to an absolute path. It first
checks if the given path is absolute by checking for '/' (first byte)
or ':' (second byte) and prepends the canvas' own directory to it, if
is relative. It's basically a clumsy way to switch the working
directory to the patch's directory. And it's what I have to do now when
using [file]. 

I need to be enlightened: What is the benefit of using Pd's start
location as working directory in [file]?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 18:11 +0100, Antoine Rousseau wrote:
> Have you tried [file which] ?

Thanks for the hint. This helps for finding already existing files by
their relative path, but it doesn't help for creating new files
specified by relative path.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 19:57 +0100, Christof Ressi wrote:
> > When using a relative path with the new [file], it is resolved
> > relative
> > to Pd's start location and not relative to the patch.

> Actually, it's resolved to the current working directy. This is
> expected behavior.

Expected by whom? Not by a regular user, I suppose, since virtually all
other objects interfacing with IO interpret relative paths as relative
to the patch for _writing_. It's only [file] that stands out and
behaves differently and its the only one that cannot write a file
relative to its patch. If you say this behavior is intended, then I
fail to see the usefulness of this design choice.

Consider this case (a real problem I currently face, not something made
up):

I am writing a patch with a configurable path for writing binary blobs.
The default in the configuration is set 'myblobs' and myblobs is a
directory that exists near the patch. The idea is that new binblobs are
saved there. Since [file] won't find 'myblobs/newblob.dat' near the
patch, I can use [dir(-[pdcontrol] to find the patch's directory and
append the configured path to it: '/path/to/my/patch/myblobs'. Now, I
am able to write my new binblob to the configured path at
'/path/to/my/patch/myblobs/newblob.dat'. Now, the user configures a
custom absolute path for their binblobs: '/opt/myblobs'. My patch
appends this to the patch's path: '/path/to/my/patch/opt/myblobs' and
boom, that is not what the user has expected. I only need to append the
configured path to the patch's path if the configured path is a
relative path. But how can I reliably detect that? Not that easy as I
explained in the other mail. 

What I think should happen when instantiating any [file] objects is to
set the working directory to the patch's directory and not to Pd's
start directory. The latter is irrelevant in the cases I can think of.


>  The [file] interface itself is just a thin wrapper over the 
> POSIX file API and therefore agnostic of Pd's search paths.

Absolutely. I don't see how I am challenging that. I think the decision
of what the current working directory is is wrong. 

> As Antoine has already mentioned, use [file which] if you want to 
> resolve a relative path to the canvas environment.

Yeah, this works fine for finding already existing files, but as the
help-file says, you cannot resolve directories with. So, it cannot be
used for 


Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Christof Ressi]

When using a relative path with the new [file], it is resolved relative
to Pd's start location and not relative to the patch.
Actually, it's resolved to the current working directy. This is expected 
behavior. The [file] interface itself is just a thin wrapper over the 
POSIX file API and therefore agnostic of Pd's search paths.


As Antoine has already mentioned, use [file which] if you want to 
resolve a relative path to the canvas environment.


Christof

On 07.01.2022 17:34, Roman Haefeli wrote:

Dear list

When using a relative path with the new [file], it is resolved relative
to Pd's start location and not relative to the patch. This is unusual,
as [text], [array], [table], [soundfile], etc. resolve relative paths
relative to the patch. Also, I don't quite see the use case for
relative to Pd's start. At least, _I_ never cared about where Pd was
started from and when working on a patch meant to run on other people's
computer I don't make any assumptions about Pd's start location. To me,
relative to Pd's start location is pretty useless.

Now, it's really unlucky I spotted this only now after 0.52 has been
released. Fixing it would break backwards-compatibility. OTOH, the fact
this hasn't been reported yet makes me assume [file] with relative
paths wasn't used that much yet. If this is going to be fixed, it
should be fixed rather soon.

Best,
Roman

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Antoine Rousseau]

Have you tried [file which] ?


Le ven. 7 janv. 2022 à 17:58, Roman Haefeli  a écrit :

> On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
> > Dear list
> >
> > When using a relative path with the new [file], it is resolved
> > relative
> > to Pd's start location and not relative to the patch.
>
> I'd like to work-around this with [dir(-[pdcontrol] which returns the
> directory of the patch which can be used to construct an absolute path
> with a given relative path.
> However, the hard part is to reliably detect whether a given path is
> relative. I thought I could check for absolute paths by checking if the
> first byte is a '/' OR the second byte is a ':'. However, it turns out
> 'C:' is a perfectly valid name for a directory on ext4, for instance.
> Doing that detection reliably turns out to be quite hard and probably
> involves detecting the OS.
>
> Or am I overlooking a simpler vanilla way?
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [file]: paths not relative to patch

[Roman Haefeli]

On Fri, 2022-01-07 at 17:34 +0100, Roman Haefeli wrote:
> Dear list
> 
> When using a relative path with the new [file], it is resolved
> relative
> to Pd's start location and not relative to the patch.

I'd like to work-around this with [dir(-[pdcontrol] which returns the
directory of the patch which can be used to construct an absolute path
with a given relative path.
However, the hard part is to reliably detect whether a given path is
relative. I thought I could check for absolute paths by checking if the
first byte is a '/' OR the second byte is a ':'. However, it turns out
'C:' is a perfectly valid name for a directory on ext4, for instance.
Doing that detection reliably turns out to be quite hard and probably
involves detecting the OS.

Or am I overlooking a simpler vanilla way?
Roman 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [file]: paths not relative to patch

[Roman Haefeli]

Dear list

When using a relative path with the new [file], it is resolved relative
to Pd's start location and not relative to the patch. This is unusual,
as [text], [array], [table], [soundfile], etc. resolve relative paths
relative to the patch. Also, I don't quite see the use case for
relative to Pd's start. At least, _I_ never cared about where Pd was
started from and when working on a patch meant to run on other people's
computer I don't make any assumptions about Pd's start location. To me,
relative to Pd's start location is pretty useless. 

Now, it's really unlucky I spotted this only now after 0.52 has been
released. Fixing it would break backwards-compatibility. OTOH, the fact
this hasn't been reported yet makes me assume [file] with relative
paths wasn't used that much yet. If this is going to be fixed, it
should be fixed rather soon.

Best, 
Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list