hi
a couple of things:
- it seems that miller tagged a new release, but apparently some numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow https://github.com/pure-data/pure-data/pull/2721
- practically all translations have been touched as well (not that three were any significant change sto the actual translations though) https://github.com/pure-data/pure-data/pull/2722
fmasr IOhannes
On 07/08/2025 21:12, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
and it seems that my colleagues brought the macOS runner back to life, so we have macOS builds again \o/
*however*, after i tried to fix the issue with the DMG-format, it seems that the code-signing currently doesn't work as expected yet (probably i'll be able to fix this tonight)
dfmasr IOhannes
Am 7. August 2025 21:12:52 MESZ schrieb "IOhannes m zmölnig via Pd-dev" pd-dev@lists.iem.at:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1")
i can delete the tag, but i'd rather have miller do the correct tagging.
ah, there's actually an open issue for bad tags: https://github.com/pure-data/pure-data/issues/2417
mfg.sfg.jfd IOhannes
OK, I think they're gone now (I didn't know how to delete them before :)
On 8/8/25 9:23 AM, IOhannes m zmölnig via Pd-dev wrote:
Am 7. August 2025 21:12:52 MESZ schrieb "IOhannes m zmölnig via Pd-dev" pd-dev@lists.iem.at:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1")
i can delete the tag, but i'd rather have miller do the correct tagging.
ah, there's actually an open issue for bad tags: <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/24... >
mfg.sfg.jfd IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
I'm happy to merge this but just FWIW I think it's wrong to just take out 'EXTERN' since without it the code works differently on some platforms compared to others. Perhaps for a future release there could be a macro PRIVATE which becomes 'static' unless PD_INTERNAL is defined (which a foolish extern writer _could_ define but then they'd be creating their own problems :)
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow https://github.com/pure-data/pure-data/pull/2721
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) https://github.com/pure-data/pure-data/pull/2722
fmasr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YDHOU42AQ42...
On 08.08.2025 10:13, Miller Puckette via Pd-dev wrote:
I'm happy to merge this but just FWIW I think it's wrong to just take out 'EXTERN' since without it the code works differently on some platforms compared to others. Perhaps for a future release there could be a macro PRIVATE which becomes 'static' unless PD_INTERNAL is defined (which a foolish extern writer _could_ define but then they'd be creating their own problems :)
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://github.com/pure-data/pure-data/issues/569. (Linux and macOS really got the defaults wrong in this case.)
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow https://github.com/pure-data/pure-data/pull/2721
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) https://github.com/pure-data/pure-data/pull/2722
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YDHOU42AQ42...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/OSXQHND3K7O...
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
Because people are using the damn functions. I wish it weren't so :)
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
And that's bad because it's inconsistent.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/56... . (Linux and macOS really got the defaults wrong in this case.)
I think linux/MacOS have it right - but anyway that's a question of opinion for people who know about compilers to debate, not me.
I could imagine compiling Pd with -fvisiblity=hidden ... but then, different compiles of Pd would have different behaviors, which isn't great either. Anyway, I don't want to fool with this so late in the release cycle. If anyone is crazy enough to use functions out of s_stuff.h or g_canvas.h, then I say let them eat cake.
cheers M
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2721...
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2722...
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
On 08.08.2025 13:58, Miller Puckette via Pd-dev wrote:
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
Because people are using the damn functions. I wish it weren't so :)
But that's the point! If you don't want people to use a function, don't mark it as EXTERN. Just write an ordinary forward declaration.
Obviously, it's problematic to remove EXTERN from existing functions (even though they are really private) because it can break externals. But we should simply stop marking *new* functions as EXTERN, unless there is a very good reason to do so.
As a side note, there is another big problem with making private functions EXTERN: you can't change the function signature anymore without risking a crash in some external. But the very point of having a private API is that you can freely make changes.
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
And that's bad because it's inconsistent.
I don't think so. Functions marked as EXTERN might be potentially useful for externals (even though it might not be "officially" supported). Plain forward declarations are for internal helper/implementation functions.
Anyway, making things "consistent" by DLL-exporting private helper functions doesn't make sense to me. At this point we have to live with the inconsistency.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/56... . (Linux and macOS really got the defaults wrong in this case.)
I think linux/MacOS have it right - but anyway that's a question of opinion for people who know about compilers to debate, not me.
Hard disagree. If you export all symbols by default, you accidentally export your whole private API for the whole world to use. I don't see any upsides in this.
Christof
cheers M
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2721...
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2722...
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/2PQOFHNPPLT...
Well, this only affects folks who are abusing the API in teh first place, so I don't think it really matters at all. Since you feel more strongly than I do about it let's do it your way :)
M
On 8/8/25 2:33 PM, Christof Ressi wrote:
On 08.08.2025 13:58, Miller Puckette via Pd-dev wrote:
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
Because people are using the damn functions. I wish it weren't so :)
But that's the point! If you don't want people to use a function, don't mark it as EXTERN. Just write an ordinary forward declaration.
Obviously, it's problematic to remove EXTERN from existing functions (even though they are really private) because it can break externals. But we should simply stop marking *new* functions as EXTERN, unless there is a very good reason to do so.
As a side note, there is another big problem with making private functions EXTERN: you can't change the function signature anymore without risking a crash in some external. But the very point of having a private API is that you can freely make changes.
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
And that's bad because it's inconsistent.
I don't think so. Functions marked as EXTERN might be potentially useful for externals (even though it might not be "officially" supported). Plain forward declarations are for internal helper/implementation functions.
Anyway, making things "consistent" by DLL-exporting private helper functions doesn't make sense to me. At this point we have to live with the inconsistency.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/56... . (Linux and macOS really got the defaults wrong in this case.)
I think linux/MacOS have it right - but anyway that's a question of opinion for people who know about compilers to debate, not me.
Hard disagree. If you export all symbols by default, you accidentally export your whole private API for the whole world to use. I don't see any upsides in this.
Christof
cheers M
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2721...
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2722...
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
On 08.08.2025 15:22, Miller Puckette via Pd-dev wrote:
Well, this only affects folks who are abusing the API in teh first place, so I don't think it really matters at all.
It's easy to say "this is the private API, use on your own risk", until people start using these functions and we are afraid of making changes. I can remember situations where we couldn't change a private EXTERN function because we were afraid of breaking externals and instead had to add a new function... That's why I think it's better not to take the risk in the first place.
Since you feel more strongly than I do about it let's do it your way :)
That's usually not the best criteria for decision making :-D I hope that my technical arguments are more convincing than my feelings. Anyway, it was IOhannes who made the change and I just happen to (strongly) agree with him.
M
On 8/8/25 2:33 PM, Christof Ressi wrote:
On 08.08.2025 13:58, Miller Puckette via Pd-dev wrote:
Again, why would you tag a *private* function as EXTERN in the first place? EXTERN is a macro for *exporting* a function from the Pd binary so that Pd externals can use it. (I guess the better name would have been PD_EXPORT all along.)
Because people are using the damn functions. I wish it weren't so :)
But that's the point! If you don't want people to use a function, don't mark it as EXTERN. Just write an ordinary forward declaration.
Obviously, it's problematic to remove EXTERN from existing functions (even though they are really private) because it can break externals. But we should simply stop marking *new* functions as EXTERN, unless there is a very good reason to do so.
As a side note, there is another big problem with making private functions EXTERN: you can't change the function signature anymore without risking a crash in some external. But the very point of having a private API is that you can freely make changes.
If you just want to make a forward declaration, there is no need for EXTERN at all because functions have extern linkage by default. Just have a look at "s_stuff.h": some functions are marked EXTERN, but others are not.
And that's bad because it's inconsistent.
I don't think so. Functions marked as EXTERN might be potentially useful for externals (even though it might not be "officially" supported). Plain forward declarations are for internal helper/implementation functions.
Anyway, making things "consistent" by DLL-exporting private helper functions doesn't make sense to me. At this point we have to live with the inconsistency.
The issue is just that Linux and macOS export all functions by default, but this can be simply solved by compiling with "-fvisiblity=hidden". See https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/56... . (Linux and macOS really got the defaults wrong in this case.)
I think linux/MacOS have it right - but anyway that's a question of opinion for people who know about compilers to debate, not me.
Hard disagree. If you export all symbols by default, you accidentally export your whole private API for the whole world to use. I don't see any upsides in this.
Christof
cheers M
Cheers,
Christof
cheers M
On 8/7/25 9:12 PM, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2721... >
- practically all translations have been touched as well (not
that three were any significant change sto the actual translations though) <https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2722... >
fmasr IOhannes
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/K4HSA26BOVU...
Hi Miller,
there are at least two more bug reports we should consider for Pd 0.56-1:
https://github.com/pure-data/pure-data/issues/2724 (I will take care of that)
https://github.com/pure-data/pure-data/issues/2720
Christof
On 07.08.2025 21:12, IOhannes m zmölnig via Pd-dev wrote:
hi
a couple of things:
- it seems that miller tagged a new release, but apparently some
numbers were swapped (or i'm having this sleepy hollow moment) as the tag reads "0.65-1test1" (rather than "0.56-1test1") i can delete the tag, but i'd rather have miller do the correct tagging.
before tagging, please consider the following though:
- i've pushed a few small changes to the `develop` branch, that I
would like to see in the bugfix release: very minor things, like fixing the screenshot image URL (required for the flatpak packages), and making a new symbol private that shouldn't have been public anyhow https://github.com/pure-data/pure-data/pull/2721
- practically all translations have been touched as well (not that
three were any significant change sto the actual translations though) https://github.com/pure-data/pure-data/pull/2722
fmasr IOhannes
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YDHOU42AQ42...