AFAICT, the main issue is that multi-instance Pd misses symbols for
certain global variables, most notably s_float, s_symbol, s_bang, etc.
The problem is that these are really exported global structs. If they
were *pointers*, we could simply make them point to the corresponding
field in the
mdras
> IOhannes
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.puredata.info/pip
On 3/30/22 17:45, Dan Wilcox wrote:
I lean much more on the side that PDINSTANCE is a low-level, per project
compile option and not general-purpose. If you are using libpd, then your
environment is a bit more custom anyway.
i wonder what the penalty would be to turn on PDINSTANCE on Pd?
I lean much more on the side that PDINSTANCE is a low-level, per project
compile option and not general-purpose. If you are using libpd, then your
environment is a bit more custom anyway.
> On Mar 30, 2022, at 5:40 PM, pd-dev-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Wed, 30 Mar 2022
On 30.03.2022 17:40, IOhannes m zmoelnig wrote:
On 3/30/22 17:21, Christof Ressi wrote:
but i don't really see how it would help with fat binaries.
Two solutions that come to my mind:
1) just use an ugly folder name:
foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib
the problem with this
On 3/30/22 17:21, Christof Ressi wrote:
but i don't really see how it would help with fat binaries.
Two solutions that come to my mind:
1) just use an ugly folder name:
foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib
the problem with this is, that it is not well-defined.
currently we
but i don't really see how it would help with fat binaries.
Two solutions that come to my mind:
1) just use an ugly folder name:
foo.pd/darwin-amd64-32.darwin-arm64-32/foo.dylib
Typically, the user won't see it :-)
2) use a special specifier for universal binaries:
On 3/30/22 16:16, Christof Ressi wrote:
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so
maybe a bundle structure (as described in
https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html) might
not be such a bad idea after all?
maybe.
it solves problems like
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so
maybe a bundle structure (as described in
https://lists.puredata.info/pipermail/pd-dev/2022-03/022997.html) might
not be such a bad idea after all?
___
Pd-dev mailing list
On 3/29/22 20:03, Lucas Cordiviola wrote:
Joining the discussion:
I think the "deken-specifier" is Ok.
here's something i just came up with:
what would the deken-specifier be for fat-binaries (on macOS).
i do not want to have zexy.darwin-amd64-32.darwin-arm64-32.so
(the reason is
On 3/29/22 20:26, Sebastian Shader via Pd-dev wrote:
I wonder if anything should be considered for multi-instance support as well
(externals compiled w/ PDINSTANCE)
good question.
afaict, there are no plans to ever ship binaries Pd with PDINSTANCE=1
(but i have no idea, really).
can we
11 matches
Mail list logo
