[PD-dev] sysloader problem

[Hans-Christoph Steiner]

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 at 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