[PD] objects with no alphanumerical names, how to build them?

[Roman Haefeli]

Ok. You were lucky to have chosen '==' as an object name, then.

The insanity begins, when the object names use characters that are
forbidden by some file systems. On Windows, for instance, you can't
have ? < > | : * \ " in filenames. This means, if you want to be able to
load such an object, you need some mechanism to substitute those
characters by something that is allowed.

This is where hexloader comes into play. It was necessary because
Pd-extended decided to split libraries into single-object-files, so that
each object has its own dll|pd_darwin|pd_linux file. However, it's not
possible to have >~.dll. The problem got worked-around by substituting
the forbidden characters by their hexadecimal representation.  I don't
know the exact details, but hexloader enabled Pd to search not only for
the name you entered into the object box, but also for its hex counter
part. This means you could create an object [>~] and Pd would load
0x3e0x7e.dll, if it was available.

All this caused some degree of confusion, since hexloader wasn't loaded
per default in Pd-extended. This means, after [import zexy] you were
able to create [symbol2list], but not [>~]. You had to [import
hexloader], too, to be able to use [>~]. This created troubles for quite
many users. (Then there was the issue with object name aliases, so that
you could load [s2l] only after having created [symbol2list], but this
is another story).

All this was never an issue with the canonical zexy library, because
everything is packed in zexy.dll|pd_darwin|pd_linux. Once you load zexy,
all its classes simply worked. 

I maybe was over-dramatizing the situation, since your example with [==]
seems to work fine. However, since Pd-extended has reached its end of
life, we should take the chance to learn from its mistakes and I
consider the forceful splitting of libraries a mistake and the proposed
solution with hexloader a kludge. It might would make things a bit more
straight forward, if hexloader was part of Pd, but that's not likely to
happen (I remember Miller having expressed hesitation). And the whole
hexloader thing is currently not necessary as long as external authors
put their classes with 'weird' names into multi-object libraries with
'sane' names or use only 'sane' names for their single-object
externals.  

I hope I could make things a bit more clear and my explanations stick to
the facts.

Roman


On Tue, 2016-04-05 at 11:43 -0300, Alexandre Torres Porres wrote:
> 
> 
> 2016-04-05 5:08 GMT-03:00 Roman Haefeli <reduzent at gmail.com>:
>          If you're simply interested in knowing how things work
>         technically, fine.
> 
> 
> I'd love to know, for sure, that's why I'm asking :)
>  
>         Now that we have a chance to get rid of all hexloader related
>         kludges,
>         now you come and bring it up again.
> 
> 
> You see, I don't really get what you mean by "hexloader" or its
> related kludges. All I know is some [hexloader] object that is in my
> pd extended 0.42-5, and all I know is that I need to use it in order
> to load the [==~] object from zexy. What you're talking about,
> somehow, relates to that? 
> 
> 
> Anyway, seems so to me... and if so, the thing is that what I'm asking
> and doing has nothing to do with "hexloader"... (I never even
> mentioned about "hexloader", btw) ... and I read about the "hex
> loader" discussion as suggested, and found stuff that I didn't really
> think was related to my questions. Yeah, like I said, I don't really
> know much and I'd like to know, so I might be missing something, and
> someone can help me with it...
> 
> 
> But the thing is, all I asked was how to compile an object like [==~]
> and make it load without being part of a library. I found on deken a
> zexy version that seemed to do that
> (specifically: zexy-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar). And it didn't need a [hexloader] object too, by the way.
> 
> 
> I didn't get an answer, but me and my colleague were checking the
> source code from zexy and found some cues. We tried it... and it
> works!
> 
> 
> Now I have an object that is compiled as [==~], it's not part of a
> library, and it loads and works on pd vanilla 0.46-7 64 bits, pd
> vanilla 0.46-7 32 bits and also Pd-Extended 0.42-5 (without the need
> of the [hexloader] object by the way). All you need is the
> ==~.pd_darwin object in a search path.
> 
> 
> 
> 
> Speaking and thinking as a user, I think it is easy and great to have
> a working and compiled object that just loads and works, so that is
> what I 'm after.
> 
> 
> But anyway, yeah, I wanna know what are the dangers and all...
> 
> 
> cheers
> 
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160405/f8d8b32f/attachment-0001.sig>