On Wed, 2008-04-16 at 22:54 -0400, marius schebella wrote:
Roman Haefeli wrote:
how important is the portability between pd-extended and pd-vanilla/externals considered? any solution, that involves the [mylib/myclass] scheme creates patches, that are broken on a pd installation with multiclass externals.
seriously??? I did not know that. that actually changes a lot. it basically means "back to start"...
pd-extended: extra/zexy/abs~.pd_linux: 'abs~' can be called by [zexy/abs~] pd-vanilla: extra/zexy.pd_linux: [zexy/abs~] doesn't work
not only this, but also for a patch dev it can be quite a pain to make a patch work on both using [declare], because in one case you need -stdpath and in the other -stdlib. in the end you are forced to use always both for no good reason.
i think it is not up to me to ask such questions, but wouldn't it be generally better, if the multiple-class-per-external format would be simply dropped? this would also have the nice side effect, that noone would ever use aliasses anymore, which currently (and in the future?) aren't fully supported.
what are aliases? and what are multiple-class-per-externals? do you mean the bundled libraries or the split-into-separate-files libraries
[mux] is an alias od [multiplex]. currently [mux] can only be instantiated when a [multiplex] has been instantiated before. which means that aliases are not fully supported by the libdir format.
sorry for causing confusion with new terms. when saying 'multiple-class-per-external format' i was referring to the bundled libraries. let's stick with the latter.
from what i can tell, making a patch work exactly the same on extended and vanilla adds quite some overhead. or is it only me, who would like to create portable (between vanilla and extended) patches?
it should be 100% compatible and should add no or only the very minimum necessary overhead. I am willing to put a lot of effort into this being realized.
cool to hear.
here a list of a few issues regarding portability between extended and vanilla, that i encountered while using netpd:
objects, that use the alias name ([mux], [l2s], [s2l] etc.) cannot often not be created, when a patch is loaded on pd-extended. possible work-arounds: - avoid alias-names when making a netpd-patch(my recommended solution) - loading a patch which calls all objects with aliases by their original name, so that the aliasses work afterwards
certain classes cause troubles because they contain characters, that aren't supported by the filesystem (is the filesystem the real reason?) however, certain classes, such as [<~] and [<~] cannot be used at all in pd-extended. my recommended workaround: - avoid such classes in netpd-patches
since it cannot be expected, that every pd-user uses the same configuration (i.e. pd-settings file/registry), it seemed reasonable to me, that netpd loads dependencies by itself. the introduction of [declare] looked very promising at first glance, because it should make it possible, that each patch can load its own dependencies independently from a specific configuration file. currently there are still some culprits with that approach:
- [declare] is partially broken (undecided behaviour inside abstractions)
- i have to use a different [declare] for pd-extended than for pd- vanilla: [declare -stdlib zexy] vs. [declare -stdpath zexy]
- some libraries are called differently on both: iemlib vs. iemlib1, iemlib2, iem_t3_lib, iemabs
workarounds: none if a netpd-patch developer wants to make her patch work on all pd distros, she needs to be aware of the different layouts, which is an unnecessary overhead, i believe.
replace 'netpd' by any project, that focusses on portability.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de