To Pd-announce:
Pd version 0.54-1 is available from http://msp.ucsd.edu/software.htm or (source only) via github: https://github.com/pure-data/pure-data
This updates Pd to work correctly on MacOS 14. There are various other bug fixes and documentation updates.
cheers
Miller
Pd-announce mailing list Pd-announce@lists.iem.at https://lists.puredata.info/listinfo/pd-announce
On 10/31/23 12:06, Miller Puckette wrote:
To Pd-announce:
Pd version 0.54-1 is available from http://msp.ucsd.edu/software.htm or (source only) via github: https://github.com/pure-data/pure-data
hooray.
the Debian for Pd-0.54-1 packages are currently building and should appear shortly in the Debian/unstable archives.¹
for Linux users who cannot use Debian (or derivatives), there's also a flatpak download available (both amd64 and arm64): https://flathub.org/apps/info.puredata.Pd
both the Debian packages and the flatpak binary have Pd64 enabled (in addition to the trusted single-precision processing).
for people who have to use macOS or Windows, Pd64 binaries can be obtained via https://puredata.info/downloads/pure-data/releases/0.54-1-pd64
happy patching.
gfmards IOhannes
¹ uploads to Debian/bookworm-backports resp the Ubuntu PPA Ubuntu PPA (https://launchpad.net/~pure-data/+archive/ubuntu/pure-data) will follow once the dust has settled
Em ter., 31 de out. de 2023 às 12:03, IOhannes m zmölnig zmoelnig@iem.at escreveu:
for people who have to use macOS or Windows, Pd64 binaries can be obtained via https://puredata.info/downloads/pure-data/releases/0.54-1-pd64
nice, what's still 'experimental' about this one?
Am 31. Oktober 2023 17:34:34 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Em ter., 31 de out. de 2023 às 12:03, IOhannes m zmölnig zmoelnig@iem.at escreveu:
for people who have to use macOS or Windows, Pd64 binaries can be obtained via https://puredata.info/downloads/pure-data/releases/0.54-1-pd64
nice, what's still 'experimental' about this one?
It's not an official release on miller's site.
mfg.sfg.jfd IOhannes
On 10/31/23 16:01, IOhannes m zmölnig wrote:
¹ uploads to Debian/bookworm-backports resp the Ubuntu PPA Ubuntu PPA (https://launchpad.net/~pure-data/+archive/ubuntu/pure-data) will follow once the dust has settled
Pd-0.54-1 is now also available on Debian/bookworm-backports https://backports.debian.org and Ubuntu (bionic, focal, jammy, lunar, mantic, noble) https://launchpad.net/~pure-data/+archive/ubuntu/pure-data
mfgar IOhannes
Thank you IOhannes.
Effectively it was proposed today by the Linux Mint 21 updates system:
- puredata 0.54.1+ds-1~ubuntu22.04~ppa1.
Q: Since LM 21.2 I have the following warning but with no negative impact on the Pd update result: " " " " " W: « nosnap.pref.old » dans le répertoire « /etc/apt/preferences.d/ » a été ignoré car il utilise une extension non valable. W: http://ppa.launchpad.net/pure-data/pure-data/ubuntu/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details. " " " " " Any idea on how to fix that, if it's really necessary.
Joseph Gastelais
Le 03/11/2023 à 11:34, IOhannes m zmölnig a écrit :
On 10/31/23 16:01, IOhannes m zmölnig wrote:
¹ uploads to Debian/bookworm-backports resp the Ubuntu PPA Ubuntu PPA (https://launchpad.net/~pure-data/+archive/ubuntu/pure-data) will follow once the dust has settled
Pd-0.54-1 is now also available on Debian/bookworm-backports https://backports.debian.org and Ubuntu (bionic, focal, jammy, lunar, mantic, noble) https://launchpad.net/~pure-data/+archive/ubuntu/pure-data
mfgar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Dear Linux ROUEN Normandie,
- Linux ROUEN Normandie linux.rouen@free.fr [2023-11-04 00:27]:
[...]
Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Type man apt-key and search for the DEPRECATION section?
amicalement, Peter
Thank you Peter, it's so simple ! 😉
Librement, Joseph
Le 04/11/2023 à 10:00, Peter P. a écrit :
Dear Linux ROUEN Normandie,
- Linux ROUEN Normandie linux.rouen@free.fr [2023-11-04 00:27]:
[...]
Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Type man apt-key and search for the DEPRECATION section?
amicalement, Peter _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
This might be obvious, but how is the 64-bit version launched? I installed Pd from Debian backports, but I can't see any pd64 or puredata64 executable on my system.
On 10/31/23 17:01, IOhannes m zmölnig wrote:
On 10/31/23 12:06, Miller Puckette wrote:
To Pd-announce:
Pd version 0.54-1 is available from http://msp.ucsd.edu/software.htm or (source only) via github: https://github.com/pure-data/pure-data
hooray.
the Debian for Pd-0.54-1 packages are currently building and should appear shortly in the Debian/unstable archives.¹
for Linux users who cannot use Debian (or derivatives), there's also a flatpak download available (both amd64 and arm64): https://flathub.org/apps/info.puredata.Pd
both the Debian packages and the flatpak binary have Pd64 enabled (in addition to the trusted single-precision processing).
for people who have to use macOS or Windows, Pd64 binaries can be obtained via https://puredata.info/downloads/pure-data/releases/0.54-1-pd64
happy patching.
gfmards IOhannes
¹ uploads to Debian/bookworm-backports resp the Ubuntu PPA Ubuntu PPA (https://launchpad.net/~pure-data/+archive/ubuntu/pure-data) will follow once the dust has settled
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2023-12-06 at 09:25 +0200, Alexandros Drymonitis wrote:
This might be obvious, but how is the 64-bit version launched? I installed Pd from Debian backports, but I can't see any pd64 or puredata64 executable on my system.
puredata64 is shipped with package puredata64:
apt-get install puredata64
Roman
Ahem, I should have guessed that...
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it). So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
On 12/6/23 09:33, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:25 +0200, Alexandros Drymonitis wrote:
This might be obvious, but how is the 64-bit version launched? I installed Pd from Debian backports, but I can't see any pd64 or puredata64 executable on my system.
puredata64 is shipped with package puredata64:
apt-get install puredata64
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
And here keeping an eye too for simple double-support I hope...
On 6 Dec 2023, at 07:43, Alexandros Drymonitis adrcki@gmail.com wrote:
Ahem, I should have guessed that...
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it). So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
On 12/6/23 09:33, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:25 +0200, Alexandros Drymonitis wrote:
This might be obvious, but how is the 64-bit version launched? I installed Pd from Debian backports, but I can't see any pd64 or puredata64 executable on my system.
puredata64 is shipped with package puredata64:
apt-get install puredata64
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote:
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it).
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away.
Roman
there is a name convention to support both float types in the same path.
https://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
If you are using lib-pd-builder see:
https://github.com/pure-data/pd-lib-builder/blob/master/tips-tricks.md#build...
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:12, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote:
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it).
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away.
Roman
But this states that the binaries have different names, depending on the architecture. When installing an external from deken, it doesn't seem to be the case. Also, will this be the case when compiling for 64-bit, the way Roman suggested?
On 12/6/23 10:21, Lucas Cordiviola wrote:
there is a name convention to support both float types in the same path.
https://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
If you are using lib-pd-builder see:
https://github.com/pure-data/pd-lib-builder/blob/master/tips-tricks.md#build...
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:12, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote:
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it).
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Sorry for the second question, now read the pd-lib-builder README. It states that 64-bit externals will indeed get a different name.
On 12/6/23 10:21, Lucas Cordiviola wrote:
there is a name convention to support both float types in the same path.
https://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
If you are using lib-pd-builder see:
https://github.com/pure-data/pd-lib-builder/blob/master/tips-tricks.md#build...
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:12, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote:
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it).
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
What worries me most, with FluCoMa in head, is what is the horizon to support this - in other words, when is 32 and 64 will be shipped as equal.
There is no more dev resources apart from some free time by yours truly for all the stuff so I need to plan carefully… in years! So if anyone on the dev team knows the horizon what would be appreciated
On 6 Dec 2023, at 08:27, Alexandros Drymonitis adrcki@gmail.com wrote:
Sorry for the second question, now read the pd-lib-builder README. It states that 64-bit externals will indeed get a different name.
On 12/6/23 10:21, Lucas Cordiviola wrote:
there is a name convention to support both float types in the same path.
https://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1If you are using lib-pd-builder see:
https://github.com/pure-data/pd-lib-builder/blob/master/tips-tricks.md#build...
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:12, Roman Haefeli wrote:
On Wed, 2023-12-06 at 09:43 +0200, Alexandros Drymonitis wrote:
The question now is how to have both versions run happily side by side? On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it).
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
Another question is, how to compile externals for 64-bit Pd? I would like to offer [neuralnet] for this version too.
Just compile it against the m_pd.h of the double-precision edition of Pd. That's not a very qualified statement, though. I haven't tried it myself yet. And from what I read about the topic, not all sources are compatible with Pd64 right away.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/12/2023 05:27, Alexandros Drymonitis wrote:
Sorry for the second question, now read the pd-lib-builder README. It states that 64-bit externals will indeed get a different name.
essentialy you need to do 2 compilations (no need to use different m_pd.h as they are the same)
then you have 2 files:
- my_lib.linux-amd64-32.so
- my_lib.linux-amd64-64.so
in the same path. Pd will load the the $-32.so and Pd64 the $-64.so. there are other combinations of file name that depends on the search order of the Pd(variant).
--
Mensaje telepatico asistido por maquinas.
Actually I just tried that with my [neuralnet] and it didn't work for Pd64. I do get a neuralnet.linux-arm64-64.so, but puredata64 can't load it.
On 12/6/23 10:44, Lucas Cordiviola wrote:
On 06/12/2023 05:27, Alexandros Drymonitis wrote:
Sorry for the second question, now read the pd-lib-builder README. It states that 64-bit externals will indeed get a different name.
essentialy you need to do 2 compilations (no need to use different m_pd.h as they are the same)
then you have 2 files:
- my_lib.linux-amd64-32.so
- my_lib.linux-amd64-64.so
in the same path. Pd will load the the $-32.so and Pd64 the $-64.so. there are other combinations of file name that depends on the search order of the Pd(variant).
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/12/2023 05:47, Alexandros Drymonitis wrote:
Actually I just tried that with my [neuralnet] and it didn't work for Pd64. I do get a neuralnet.linux-arm64-64.so, but puredata64 can't load it.
did you use "floatsize=64":
make floatsize=64 extension=linux-arm64-64.so
?
are you using the latest https://github.com/pure-data/pd-lib-builder ?
If i'm correct (and you are not using the latest plb) you can pass pre-processor flags
make CPPFLAGS=-DPD_FLOATSIZE=64 extension=linux-arm64-64.so
--
Mensaje telepatico asistido por maquinas.
Oh and also: your code should use t_float instead of float and t_sample for audio floats.
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:59, Lucas Cordiviola wrote:
On 06/12/2023 05:47, Alexandros Drymonitis wrote:
Actually I just tried that with my [neuralnet] and it didn't work for Pd64. I do get a neuralnet.linux-arm64-64.so, but puredata64 can't load it.
did you use "floatsize=64":
make floatsize=64 extension=linux-arm64-64.so
?
are you using the latest https://github.com/pure-data/pd-lib-builder ?
If i'm correct (and you are not using the latest plb) you can pass pre-processor flags
make CPPFLAGS=-DPD_FLOATSIZE=64 extension=linux-arm64-64.so
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yes, I'm using the latest pd-lib-builder (0.7.0), and compiled with floatsize=64 and extension=linux-amd64-64.so. I also use t_float instead of float in my code. I just checked the .c file to make sure.
On 12/6/23 11:06, Lucas Cordiviola wrote:
Oh and also: your code should use t_float instead of float and t_sample for audio floats.
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 05:59, Lucas Cordiviola wrote:
On 06/12/2023 05:47, Alexandros Drymonitis wrote:
Actually I just tried that with my [neuralnet] and it didn't work for Pd64. I do get a neuralnet.linux-arm64-64.so, but puredata64 can't load it.
did you use "floatsize=64":
make floatsize=64 extension=linux-arm64-64.so
?
are you using the latest https://github.com/pure-data/pd-lib-builder ?
If i'm correct (and you are not using the latest plb) you can pass pre-processor flags
make CPPFLAGS=-DPD_FLOATSIZE=64 extension=linux-arm64-64.so
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 06/12/2023 06:19, Alexandros Drymonitis wrote:
Yes, I'm using the latest pd-lib-builder (0.7.0), and compiled with floatsize=64 and extension=linux-amd64-64.so. I also use t_float instead of float in my code. I just checked the .c file to make sure.
what does the console says if you start pd64 -verbose from command line?
next: could you get a backtrace from GDB?
--
Mensaje telepatico asistido por maquinas.
Darn,
I think I made a typo when compiling. I tried another external of mine
and it worked, and then I copied the make command to the neuralnet
directory and now [neuralnet] loads fine. Sorry for the noise. Here's
the command, for anyone interested:
make floatsize=64 extension=linux-amd64-64.so
On 12/6/23 11:27, Lucas Cordiviola wrote:
On 06/12/2023 06:19, Alexandros Drymonitis wrote:
Yes, I'm using the latest pd-lib-builder (0.7.0), and compiled with floatsize=64 and extension=linux-amd64-64.so. I also use t_float instead of float in my code. I just checked the .c file to make sure.
what does the console says if you start
pd64 -verbosefrom command line?next: could you get a backtrace from GDB?
--
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/6/23 09:44, Lucas Cordiviola wrote:
On 06/12/2023 05:27, Alexandros Drymonitis wrote:
Sorry for the second question, now read the pd-lib-builder README. It states that 64-bit externals will indeed get a different name.
essentialy you need to do 2 compilations (no need to use different m_pd.h as they are the same)
then you have 2 files:
- my_lib.linux-amd64-32.so
- my_lib.linux-amd64-64.so
while this will work with Pd>=0.54, i would advice everybody to use the old-style extensions for the Pd32 externals:
- my_lib.l_amd64
- my_lib.linux-amd64-64.so
old-style extensions will not be used by Pd64 (so there's no danger in accidentally loading the wrong binary), but they *can* be loaded by older versions of Pd (which are Pd32 only).
of course, if you are using newer features that require Pd>=0.54 anyhow (e.g. multichannel), then by all means use the new-style extensions for Pd32 as well.
gdmasr IOhannes
You could configure different install and search paths for single- and double-precision versions of Pd. I don't know if they share the config file. If they do, you would have to adjust the config whenever you switch between them.
they do share the same config file on macOS at least. i solved this for me with this change here yesterday (it works - although I'm not sure if these changes are all correct and useful): https://github.com/ben-wes/pure-data/commit/18793a0192d41875af968cc6bd74ba58...
cheers, ben
On 12/6/23 09:12, Roman Haefeli wrote:
Just compile it against the m_pd.h of the double-precision edition of Pd.
this won't work, as the "m_pd.h" for Pd64 and Pd32 are exactly the same.
instead set the "PD_FLOATSIZE" macro to 64 when building the external.
reasoning:
- just building with "-DPD_FLOATSIZE=64" should be simple enough
- using two headers with different names ("m_pd.h", "m_pd64.h") just
moves the problem: the source code has to decide which header to include, and it most likely does this via some macro; so go back to square 1)
- shipping two different headers (with the only difference being the
PD_FLOATSIZE macro) with the same name is going to breed confusion: where do you find which header (this mostly matters with systems where header-files are not bundled with an application, but installed to a global place, like /usr/include)
- for systems where the headers are bundled with application, i think we
should bundle both Pd32 and Pd64 together (which we already can, its just that the downloadable packages don't do that yet). so back to square 3.
gfnsdrt IOhannes
On Wed, 2023-12-06 at 11:16 +0100, IOhannes m zmoelnig wrote:
On 12/6/23 09:12, Roman Haefeli wrote:
Just compile it against the m_pd.h of the double-precision edition of Pd.
this won't work, as the "m_pd.h" for Pd64 and Pd32 are exactly the same.
instead set the "PD_FLOATSIZE" macro to 64 when building the external.
reasoning:
Thanks for the clarifications. Makes all totally sense. I shouldn't have posted without knowing better.
Roman
@IOhannes in the HTML docs I filled the new "deken-scheme" naming for macOS with file extension ending with .dylib. is this incorrect?
I mean my_lib.darwin-amd64-64.dylib will load? or should be
my_lib.darwin-amd64-64.so
?
--
Mensaje telepatico asistido por maquinas.
Am 6. Dezember 2023 12:16:44 MEZ schrieb Lucas Cordiviola lucarda27@hotmail.com:
@IOhannes in the HTML docs I filled the new "deken-scheme" naming for macOS with file extension ending with .dylib. is this incorrect?
I mean
my_lib.darwin-amd64-64.dylibwill load? or should bemy_lib.darwin-amd64-64.so
my_lib.darwin-amd64-64.so
the .so extension is still common on macOS (being un*xy),so I/we went for a minimum number of (native) extensions.
mfg.sfg.jfd IOhannes
thanks.
fixed in PR https://github.com/pure-data/pure-data/pull/2156
--
Mensaje telepatico asistido por maquinas.
On 06/12/2023 12:45, IOhannes m zmölnig wrote:
my_lib.darwin-amd64-64.so
the .so extension is still common on macOS (being un*xy),so I/we went for a minimum number of (native) extensions.
On 12/6/23 08:43, Alexandros Drymonitis wrote:
Ahem, I should have guessed that...
The question now is how to have both versions run happily side by side?
for Pd on Debian the answer is:
- install both "puredata" and "puredata64"
- if you are a cmdline person, launch pd32 by typing "pd", and pd64 by
typing "pd64" in your favourite shell
- if you are a GUI person, just launch the Pd-GUI and select the falvour
via the preferences (you need to restart Pd for this to have an effect).
On the 64-bit version I did find zexy (but some other libraries I searched for, including my own, neuralnet, were not available - not a surprise for my own, I haven't compiled it for the 64-bit version), but installing it through deken, breaks compatibility with the 32-bit version (I guess it overrides it). So when I open the 32-bit version, zexy is no longer available. If I install it through deken from the 32-bit Pd, then it's not available for the 64-bit Pd.
the issue is, that when installing a library (e.g. "zexy") it will first attempt to uninstall older versions of it (by simply deleting the "zexy" folder in the target directory). so if you first installed a version that only contains the Linux-amd64-32 version of zexy, and then install a version that *only* contains the Linux-amd64-64 version of zexy, the first installation will be removed, and you now can no longer load zexy in a Pd32.
there are three options to solve this issue:
- user: disable the "Try to remove libraries before (re)installing
them" option in the deken preferences 2. user: follow roman's advice of using different search paths for Pd32 and Pd64 3. maintainer: ship both Pd32 and Pd64 binaries in your deken package
the 1st option is not really good, as you will accumulate cruft (e.g. outdated files that are no longer shipped in newer versions of the library will stay on the user's disk, leading to much confusion). that's the reason why we have this "uninstall" option in the first place
the 2nd option is probably okayish (and it's the best thing the user can do). one concern is that you need to install all libraries twice, even if they are just abstractions (and therefore could be shared between Pd32 and Pd64, and macOS and Windows; and ...).
my concern with both these options is, that each user has to fix their system themselves.
that's why i personally favour the 3rd option. it does require some work on the maintainer side, but for the users it is pretty transparent.
in theory i have setup my builders to produce packages that have both Pd32 and Pd64 binaries, but obviously zexy-2.4.2 was built and uploaded before i decided on implementing this.
as a sidenote, when shipping both Pd32 and Pd64 packages, it turned out that the deken filename scheme can get to its limits. i typically build my libraries for (macOS, Linux and Windows) for (amd64, i386, arm64 and armv7) and now for (Pd32 and Pd64) as well. i do not build all combinations (no Windows/armv7/Pd64 packages), but i currently do build for 16 different architectures. putting all these binaries into a single deken package will require a filename that has 264 characters solely for the architecture specifiers, which simply hits the maximum filename length on many OSs (practically *all* major filesystems only support up to 256 chars).
i do believe that it is beneficial to ship as little packages as possible, both for the user (who should only need to download once even if they use Win32/Pd32 and Win64/Pd64 and Win64/Pd32 on the same machine) and for our server infrastructure (there are some really big libraries like "ELSE": the size is mostly drowned in media files which are shared between all packages; creating 16 different packages will eat about 1GB of server space just for a single release candidate)
so that's why i've started to create per-OS packages (there's a Windows download, a macOS download and a Linux download; each comes with multiple CPU-architectures and both Pd32 and Pd64)
now that i've written this, i notice that I haven't actually uploaded any of my new packages to deken yet (that's mostly because i haven't done any new release yet).
gfmasdr IOhannes
On 12/6/23 11:07, IOhannes m zmoelnig wrote:
now that i've written this, i notice that I haven't actually uploaded any of my new packages to deken yet (that's mostly because i haven't done any new release yet).
at least i've fixed the upload for zexy for now.
others might follow.
-
Alexandre Torres Porres -
Alexandros Drymonitis -
Benjamin Wesch -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Linux ROUEN Normandie -
Lucas Cordiviola -
Miller Puckette -
Peter P. -
Pierre Alexandre Tremblay -
Roman Haefeli