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
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
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
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
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
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
e: 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...@c
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
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
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
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
>
ressi.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>>
> Conten
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
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
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
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
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
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
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
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]
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
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.
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
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
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
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
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
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
28 matches
Mail list logo
