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  > >
> > 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 
> > >
> > 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 
>   >
> danomatika.com 
>   >
> robotcowboy.com 
>   >
> 
> 
> 

> ___
> 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 
> >
> 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 
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

[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