[L2Ork-dev] Purr Data 2.3.0 Released

[Jonathan Wilkes]

Hi list,


Purr Data 2.3.0 is released.


https://github.com/jonwwilkes/purr-data/releases


Report issues here:


https://git.purrdata.net/jwilkes/purr-data/issues


We're no longer using the hexloader external. Instead 

the "hexmunge" code in s_loader.c is now leveraged to 

try to open hex-encoded filenames in the default loader. 


This greatly simplifies the loader mechanism. However, it 

does change the default behavior of Purr Data. That, the  

new [pdinfo] methods, and the sane defaults (see below) 

made me think the minor version number needed to be changed 

with this release.

All the externals shipped with Purr Data should load exactly 

as before, plus some that didn't load properly should now 

load. However, if you were depending on "hexloader" to load 

any hex-encoded external filenames that don't ship with 

Purr Data, you might need to add "hexloader" back to the 

startup lib list in "Preferences". (But hex-encoded files are 

so difficult to use and the hexloader sufficiently complex 

that I doubt anyone is actually doing that.)

Also, the "external-tests.pd" test is now used in all CI 

builds. Currently it's quite crude-- it just checks for a 

minimum number of external objects that get created. Anything 

below that threshold will cause the builds to fail. 

Nevertheless, it has revealed a plethora of bugs which got 

fixed in this release. The next step will be to create a test 

that checks for a certain number of objects in each libdir and 

fails if it doesn't find the correct number in each. (Then 

actually testing some methods, too.)


One thing the tests revealed is that there are probably lots 

of external libs that aren't properly declaring functions 

as static (including constructors). This can easily cause 

global namespace pollution that results in all kinds of 

undefined behavior. If anyone wants to run a script that at 

least searches for constructors (i.e., foo_new in foo.c) that 

don't have the "static" keyword before them, that would be 

a great help.

tof/imagebang was ported.

To make the tests work, every class that takes A_GIMME was 

changed so that the object will instantiate without any 

arguments. I initially did this because the A_GIMME interface 

is opaque-- since there's no way to figure out what args and 

arg types such a class requires, it's impossible to test unless 

such objects simply instantiate with no args with sane defaults.

However, what I found was that a significant percentage of 

such classes were hiding invalid reads and buffer overflows 

in their constructors. (All of which could be triggered _before_ 

I made it possible to isntantiate them without args, btw.) 

This was rather worrying-- it means just by trying to handle 

incoming arguments manually in C, developers have a well-documented 

risk of crashing Pd.

(And keep in mind I haven't even tested 

the external class methodspace yet. :)


Essentially what this revealed was that Pd's argument type 

checking mechanism is too crude for most developers to want to 

use it. They typically want a) non-zero defaults and b) a message 

to the console telling the correct types _plus_ annotation of 

what each argument actually specifies. But this is another topic 

altogether, outside the scope of these current tests.


Another topic-- we need to have some "best practices" for external 

authors. A subset of characters that are allowed on all Pd's 

supported platforms should be suggested for class names. Also, 

class_addcreator should only be used if the library is not allowed 

to be split into pieces. E.g., some kind of weird library called 

emojiflow where each object name is an emoji-- in that case you'd 

never split the library into one-class-per-file libraries, and the 

whole complication of weird filenames is avoided completely. For 

all "swiss army" libraries, authors should stick to alphanumeric 

class names with characters that can appear in a C function name.


Finally, this merge is a great example of how _not_ to do a 

merge request. I've got several reversions in there, plus little 

debugging commits I used to track down weirdness in the OSX 

tests. I tried rebasing a few times but that is simply too 

dangerous with a patchset this large. So I'll keep merges 

much smaller and more organized from now on.

Best,
Jonathan