On 2012-10-03 15:06, Ed Kelly wrote:
Hi list,
I know you main devs have bigger fish to fry right now, but an answer to (some of) my wierdness with Gem (in case you're interested) -- the "unable to save file: too many objects" message, and related errors (files no longer loaded within the patch, Pd seems to lose its bearings/path) only seem to occur on Windows. Something gets corrupted in Pd but I don't know what.
the problem is, that on w32 file-handles can be incompatible between different c-runtime versions and each dll uses the c-runtime it has been linked too. this means that file handles opened by one dll (e.g.: Pd-core) might not be closeable by another dll (e.g. Gem).
Thanks IOhannes, So there is some sloppiness in Windows, which is hardly a surprise since it's not created with the integrity of a *nix system. Fortunately for me, this piece has to work only on Mac OS X for now - on the percussionist's MacBook. I can use my old laptop to develop the project for now until I fix my new machine's Ubuntu/Pd/Gem issues. It's good to know there is a solution on the way though. Ed
on the other side, Pd<0.43 would only provide a function to open files (using all those search paths), but none to close them. this means, that whenever a file is opened via the search-path feature (and Gem uses that a lot), it is impossible to close it - effectively leading to a file-handle leak. now with Pd-0.43 there finally is a sys_close() function that allows those file-handles to be closed in the proper context (that is: the pd dll). unfortunately this does not mean that the problem will magically go away by upgrading to Pd-0.43 - the caller (e.g. Gem) has to use the new function in order to have an effect. starting with Gem-0.94, Gem should be able to handle the problem (and even continue to work with older Pd's - at the expense of keeping the file-handle leak with Pd<0.43) fgamsdr IOhannes