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/569__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijQjqUh9qQ$
. (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__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijSwulmy7g$
>
- 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__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijTfVhnB5Q$
>
fmasr
IOhannes
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/YDHOU42AQ423AOWGGDL52A4RQDUYB3RX/__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijQnWMxfSw$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/OSXQHND3K7OYCHXQBT5TK3JWBOQLI7VP/__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijT2lPxYcg$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/2RFT3GXJVRV6PMK6XU4J5KLVUM4W277W/__;!!Mih3wA!HxpV00_fcpH64N6Sl5zlOm4avJgIruAcNHHtqXtb2WtTylG_DHiVqnQxIuBDRWA3qnvWijSCndmEEQ$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/2PQOFHNPPLTDFZALD7ILMFNU6VOQZ52N/__;!!Mih3wA!Di3dJAn8VGytUrPhq23RBykxNBQXlXidDr-S-v3VKw5mtPnBaIkTqiNsl3vhmisUKujv2mai58COgQ$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/JC4EPDXHL43YNNHJQOSNLKTULLFYEP4N/__;!!Mih3wA!Di3dJAn8VGytUrPhq23RBykxNBQXlXidDr-S-v3VKw5mtPnBaIkTqiNsl3vhmisUKujv2mZQ3-mfqg$
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/K4HSA26BOVUG6UOOUT4WFFDRLZSSXSPC/
---
pd-dev@lists.iem.at - the Pd developers' mailinglist
https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WBVCWDB24ONQA2JVPSTE6XMOSK22TX3K/