hi
my original subject was "pd-extended: <~ and matrix" but now i got confused so i renamed it. the newest pd-extended can't create [<~] nor [matrix] on default.
[<~] on the 20080523 could create (with an expr~ couldn't create error) now the [<~] can't create anymore. should i file a new bug report for hexloader or is it covered by https://sourceforge.net/tracker/index.php?func=detail&aid=1637460&gr...
matrix: so far netpd provides a [declare -stdlib iemmatrix] and a [declare -stdpath ../extra/iemmatrix] for pd-extended, but this seems to not work anymore. it is working with pd-ext-20080516 and _not_ working with 20080523. [matrix] creates when i first do a [iemmatrix/matrix] and then load my patches.
i also checked the matrix-help bugreport https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965876... eighthave says: "I added '#X declare -lib iemmatrix' to the help files, so this should work now. Please test tomorrow."
i checked it today and the help files is really working. the declare help file says: -lib load a library, relative to the patch maybe i must have missunderstand but the patch in this case would be netpd's _chat.pd wouldn't it?
relative to _chat.pd on my system would be something like: ../../../Applications/Pd-extended.app/Contents/Resources/extra or similar. why is -lib iemmatrix working?
is the declare-help file wrong?
also i am a bit disappointed that one can not write abstractions, that declares what it depends on. but probably that has some technical reason.
thanks eni
Pd-0.40.3-extended-20080602-macosx105-i386
matrix ... couldn't create
load_object: Symbol "0x3c0x7e_setup" not found error: BUG: no pd_objectmaker found <~ ... couldn't create load_object: Symbol "0x3c0x7e_setup" not found error: BUG: no pd_objectmaker found zexy/<~ ... couldn't create
On Mon, 2008-06-02 at 13:21 -0400, Enrique Erne wrote:
also i am a bit disappointed that one can not write abstractions, that declares what it depends on. but probably that has some technical reason.
this issue hasn't been solved yet, AFAIK. actually i am not even sure, what the problem might be. probably it is not clear how to expand search pathes for an abstractions without expanding the pathes of the parent patch. however (sorry to repeat myself), i think it is quite problematic, that since the introduction of [declare] there is an implicit difference between abstractions and patches, whereas before they were treated exactly the same, in the sense, that it didn't make any difference whether you opened a *.pd-file as patch or instantiated it as an abstraction.
is there already an agreement on how it should be implemented ideally? i am still confused, even if i tried to follow all the threads regarding that topic.
when writing a patch, i don't want to think about the dependencies of the abstractions i use. that is why i propose the following layout:
in my idea of an ideal [declare -std*] layout, it expands search pathes only locally to the patch and all its children (abstractions and abstractions of abstractions). the same goes for abstractions: search pathes are added for the instance itself and all children, but not for the parent patch nor other instances at the same level. search pathes added by the local [declare] should be checked _before_ the parent [declare] before the grandparent [declare] etc. 'relative' means always relative to the location of the file and not relative to file location of the most top parent patch (or anything else).
i think, this would be a clean and easy to understand layout, since it is quite similar to how [block~]/[switch~] are working.
does that make sense? am i overseeing problems, that aren't covered by this layout? frank, you probably made the most complex abstractions regarding nesting of depencencies (i am thinking of [nqpoly4]). would this layout work for projects using [nqoly4]?
in the name of the church of consistency, i truly hope, that we can come up with a layout, that everyone (miller included) agrees on. sorry, if that _did_ already happen and i missed it.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
when writing a patch, i don't want to think about the dependencies of the abstractions i use. that is why i propose the following layout:
in my idea of an ideal [declare -std*] layout, it expands search pathes only locally to the patch and all its children (abstractions and abstractions of abstractions). the same goes for abstractions: search pathes are added for the instance itself and all children, but not for the parent patch nor other instances at the same level. search pathes added by the local [declare] should be checked _before_ the parent [declare] before the grandparent [declare] etc. 'relative' means always relative to the location of the file and not relative to file location of the most top parent patch (or anything else).
hello roman, I totally agree with you. that should be the default behaviour. But iirc the current behaviour is the opposite way. objects loaded in an abstraction expand their paths to the parent patch. maybe this is because they are loaded first? maybe it is not possible to have local namespaces at all (everything global?)? marius.
On Tue, 2008-06-03 at 09:59 -0400, marius schebella wrote:
Roman Haefeli wrote:
when writing a patch, i don't want to think about the dependencies of the abstractions i use. that is why i propose the following layout:
in my idea of an ideal [declare -std*] layout, it expands search pathes only locally to the patch and all its children (abstractions and abstractions of abstractions). the same goes for abstractions: search pathes are added for the instance itself and all children, but not for the parent patch nor other instances at the same level. search pathes added by the local [declare] should be checked _before_ the parent [declare] before the grandparent [declare] etc. 'relative' means always relative to the location of the file and not relative to file location of the most top parent patch (or anything else).
hello roman, I totally agree with you. that should be the default behaviour. But iirc the current behaviour is the opposite way. objects loaded in an abstraction expand their paths to the parent patch. maybe this is because they are loaded first? maybe it is not possible to have local namespaces at all (everything global?)?
ok. got that. is this the reason, why miller wants to disable [declare -lib/path] inside abstractions in order to not pollute the parent patch's search path space? so, at this moment, it's a purely technical problem? it would be good to know, if it's only a technical problem, because i had the impression, that it is even unclear, how [declare] is supposed to work (besides the problem how to make it work how it is supposed to work). it would be good know, that there is no need for discussions about the ideal behaviour of [declare] anymore.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
it would be good to know, if it's only a technical problem, because i had the impression, that it is even unclear, how [declare] is supposed to work (besides the problem how to make it work how it is supposed to work). it would be good know, that there is no need for discussions about the ideal behaviour of [declare] anymore.
the discussion goes back to at least 2001 "This is going to be a never-ending problem...!" (Miller P.) http://lists.puredata.info/pipermail/pd-list/2001-07/002662.html
but then, "That it's adding stuff to the parent patch is a serious bug; there's no reason to believe that putting declare in abstractions is doing a useful thing at all at present!" (Miller P.) http://lists.puredata.info/pipermail/pd-list/2008-01/059038.html from which I read that (beginning with 0.41) patch-local namespaces are/will be working and the intended behaviour for inheritance is that abstractions should NOT extend their namespace to the parent patch. otoh, this still does not say that patches will extend their namespace to abstractions used inside them (which - hopefully - will be supported in the future.) now, does this mean that an abstraction can override an object declaration of a parent patch (avoiding nameclashes by forcing own declarations of objects). marius.
On Tue, 2008-06-03 at 14:54 +0200, Roman Haefeli wrote:
in my idea of an ideal [declare -std*] layout [..]
oops, i did a bad mistake here. of course i mean [declare -lib] and (more important) [declare -path] and _not_ [declare -std*].
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Enrique Erne -
marius schebella -
Roman Haefeli