[PD] hex loader

Hans-Christoph Steiner hans at eds.org
Thu Nov 29 05:44:39 CET 2007

By the way, I just read thru the whole hexloader README.  Looks like  
nice work, I think you covered every possibility that I could think  
of :)


On Nov 28, 2007, at 10:05 PM, Mathieu Bouchard wrote:

> On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
>> i don't like matju's suggestion to provide an API,
> Ideally, hexloader should be merged into the core and the API would  
> be a single function shared by the loader and the parts of the  
> internals that do the same thing as the hexloader does (the symbol  
> mangler).
> I'm not really advocating that an external exposes an API otherwise  
> than as pd objects and methods... but then, this is also what Gem  
> need to do if some externals are not linked directly into Gem... so  
> it must not be that ugly. GridFlow will also have to do it  
> eventually. I just think that doing it for one function is a waste.
> Anyway, because virtually the same code is already in the core, it  
> makes sense to have that shared function in the core, so the issue  
> of linking to an external should be moot.
>> as this would require to have hexloader be loaded before all other  
>> externals that rely on that API.
> Not if the linker knows about it. (The problem is how to tell the  
> linker about it)
>> what might be a better solution is to tell Pd to try to load a  
>> different class instead (kind of recursively calling the loading  
>> stuff).
> I don't understand.
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada


"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White

More information about the Pd-list mailing list