> (a more advanced form would actually load (and loadbang) the meta-patch,
so it can run some real code)
There's also the possibility to load the meta-patch, but _always_ suppress
loadbang.
Then you'd have a rough equivalent to a c header file-- the lib author could
basically declare things-- [s
i *think* that the best way to achieve this is to allow a
library/framework to run some code when being setup. for me the
obvious place would be the "-meta" file (Gem-meta.pd) which has become
the de-facto standard to add meta-information to a library.
It could be very nice and configurable
On 2016-05-08 23:21, Miller Puckette wrote:
> Meanwhile a "real" fix
> is needed...
i think the sensible way would be, if a library loaded via declare could
add paths (and load other libraries).
e.g. with Gem, there are abstractions and a single external:
~/pd-externals/Gem/Gem-meta.pd
~/pd-exte
OK... so as a fall-back I'll just fix it so that setting Pd compatibility to
0.46 makes declare fall back to the old behavior. Meanwhile a "real" fix
is needed...
cheers
M
On Sun, May 08, 2016 at 11:07:15PM +0200, Jérôme Abel wrote:
> > if [import] can indeed be used
>
> In fact, it seems that
> if [import] can indeed be used
In fact, it seems that [import] only deals with libraries ... not with
abstractions folders.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-lis
On 05/08/2016 05:31 PM, Jonathan Wilkes via Pd-list wrote:
> You write as if you aren't a time traveler.
> [declare] has had this behavior for at least a decade.
so you *are* a time traveler who is caught in a loop?
fgmar
IOhannes
signature.asc
Description: OpenPGP digital signature
__
> So basically [declare] only was "allowed" in a toplevel patch.
You write as if you aren't a time traveler.
[declare] has had this behavior for at least a decade. That's more than
enough time for the ninjas to test and package it up to use in the manner
described by the OP.
What is the cost of
On Sun, May 08, 2016 at 12:09:04AM +, Jonathan Wilkes via Pd-list wrote:
> Hi Jerome,If you're saying that your patches used to work and they now break,
> do file a bug about it. Others on the list have mentioned using
> [declare] for this purpose-- I never have but it's a reasonable use cas
I don't regard this as a patch-level incompatibility
Indeed.
But the old behavior was seriously broken and I don't see any good way to
provide it without causing trouble
and confusion. I'm open to ideas...
I understand.
# USE CASE
An abstraction [include] that you can put on all patche
The trouble with that is that the old behavior depended on what order you
created
objects and saved/restored patches in - in other words, it was defective by
design.
I know it was possible to work around that, but I can't see any way to make it
do
the buggey thing it did and not be buggy.
cheer
> But the old behavior was seriously broken and I don't see any good way to
> provide it without causing trouble and confusion.
Deprecate the old [declare] and name the new [declare] something else.
-Jonathan
On Saturday, May 7, 2016 8:40 PM, Miller Puckette wrote:
I don't regard this
I don't regard this as a patch-level incompatibility (I believe you can run all
the patches -- only now you'll have to add 6 directories to Pd's search path).
But it's a serious inconvenience for sure. But the old behavior was seriously
broken and I don't see any good way to provide it without cau
Hi Jerome,If you're saying that your patches used to work and they now break,
do file a bug about it. Others on the list have mentioned using
[declare] for this purpose-- I never have but it's a reasonable use case.
-Jonathan
On Saturday, May 7, 2016 7:30 PM, Jérôme Abel wrote:
Hi
Hi list,
With the new [declare] behavior, I am a little confused (Pd.0.47). I've
read that putting [declare] in abstractions was not the "right" way, but
that what I've done. Shame.
In La Malinette (malinette.info), it is very useful to have an
abstraction named [include] which contains all
14 matches
Mail list logo
