[PD] mapping: path setting hell

Hans-Christoph Steiner hans at eds.org
Wed Apr 8 22:58:48 CEST 2009

On Apr 8, 2009, at 3:23 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> On Apr 8, 2009, at 5:35 AM, cyrille henry wrote:
>>> i think for this specific lib, any dependency of object outside it's
>>> directory can be seen as a bug.
>> I don't understand this at all.  Why did every modern operating  
>> system
>> spend massive amounts of work to switch from static linking of  
>> libraries
>> (i.e. including the library with the program itself) to dynamic,  
>> shared
>> libraries (i.e. a single copy of a library shared by all programs  
>> that
>> use it)?
> I think, advantages and disadvantages have to be weighted, and IMO  
> mapping
> currently is leaning to a not very user friendly side. For example  
> its use of
> [float_argument], [symbol_argument] and [once] from purepd creates a  
> dependency
> on purepd that is completely unnecessary: [once] is only used once,
> [symbol_argument] also, and float_argument very often is used where  
> a simple [f
> $1]  would be enough (its second argument is empty). So I'd say, get  
> rid of it
> and be more friendly to users.

If there is good code out there, I want to use it, not reinvent it.   
If you use mapping in Pd-extended, you never need to know anything  
about what's happening inside, it just works.  With a little bit of  
effort, Pd-vanilla users can also acheive this.  That's why I am  
fixing up libdir.c and these libraries in SVN.

> Another case is the "standardization" to use abstraction names, that  
> require
> the (sometimes broken) hexloader: Life would be much easier for a  
> lot of people
> without the "->" convention.

Indeed, I fully agree. That's why I fixed it over a year ago :D   
mapping needs to hexloader tricks.

> Other cases may not be so easy to fix and some externals are hard to  
> replace,
> but as it currenly is, mapping looks like a collection that puts  
> some abstract
> design principles higher than actual user demands. Of course that's  
> just my
> humble opinion, which is leaning to a much more simplistic side.

These libraries were a place for me to experiment with ways of  
handling libraries in Pd easier.  Some of the experiments failed, but  
I think right now its in a pretty good place.  So try it out the way  
it is now and tell me what doesn't work.


> Ciao
> -- 
> Frank
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


All information should be free.  - the hacker ethic

More information about the Pd-list mailing list