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

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

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

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 r

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

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://gith

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

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

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

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

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

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 is

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

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

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

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

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

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 original

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

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 un

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

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 re

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

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

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