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.
I've not got my new PC opening a Gem window yet (Ubuntu 10.4 - see previous posts), but my old laptop with Ubuntu 9.10 runs the gemnotes patch I'm working on OK - before it overheats :-!
Here's the patch at it's previous working state - open Islands_Score_M1.pd and hit the "START" toggle on the left-hand side of the patch. I'm using Pd-extended-0.42 so I'll have to see whether later versions of Gem/Pd don't exhibit this behaviour!
It's a mystery - I've tested it on Win7 32 and 64 bit, and the same error occurs. Works fine on OS X 10.6.8 and Ubuntu Linux.
Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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).
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-04 05:38, Ed Kelly wrote:
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.
to be honest, this is not an "integrity-defeating sloppiness" in w32, but a deliberate design decision made by microsoft.
the problem comes from people who are used the *nix ways (like me) and who are surprised by their implicit assumptions. since most devs here are more into *nix, it took a while till somebody came up with an idea what the problem might be.
fgmasdr IOhannes
-
Ed Kelly -
IOhannes m zmoelnig