>> 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