hi miller, all.
i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname<->filename mapping, which should eventually work for abstractions too)
the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the "abstract class" vs "instance" separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some "context".
ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader())
a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders.
mfasd.r IOhannes
Hi, it's true that the current loader hook has designed for libs only. I've also thought about introducing an additional object loader, which should then also be able to draw its patcher text from an external source (like from the web, or from a database), but that's hard because of the way how pd currently loads and creates the objects.
oops, wanted to write more, but no time.... all the best, Thomas
IOhannes m zmoelnig schrieb:
hi miller, all.
i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname<->filename mapping, which should eventually work for abstractions too)
the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the "abstract class" vs "instance" separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some "context".
ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader())
a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders.
mfasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I like the idea of having everything implemented as a loader. Then there could be something like /etc/init.d for the loaders, with the file order being the order that the loaders are run.
But I don't think I can offer much insight on this problem.
.hc
On Apr 19, 2007, at 8:00 AM, IOhannes m zmoelnig wrote:
hi miller, all.
i am currently having troubles implementing the hexloader as a system-loader. while things work rather straightforward in external/library land, it stops being trivial when it comes to loading abstractions via a system-loader. (this is needed since the hexloader mainly applies a different objectname<->filename mapping, which should eventually work for abstractions too)
the problem is, that in the context of the loader, i have no idea about the arguments for the object instance. unfortunately abstractions do not have the "abstract class" vs "instance" separation like binary objects, so the only way to instantiate them seems to be to directly evaluate them with the arguments available in some "context".
ultimately it would be good if patches would be loaded with the same mechanism as other externals within the pd core (this is: with a separate patch_loader() that is registered just like the lib_loader())
a temporary workaround would be some way to access the arguments passed to a yet-unknown object from within the loaders.
mfasd.r IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Thomas Grill