Thanks for looking into this, y'all.
I also agree that this check is not really necessary. We already know the BundleID we are using, but it might have been put in place as Pd-extended had a different domain (and hence BundleID), so checking first would ensure the same plugin would work on multiple forks. We might want at least document this change and/or provide a better mechanism to check, although it seems macOS was the only platform to do this.
Following, I don't see a real reason why using the defaults command should be slow in and of itself (except for [1]).
This is perhaps a security mechanism where accessing the bundle's Info.plist directly is discouraged as it might be used by malware (my guess). Normally, you would query the defaults via the bundle ID or via the C/Obj-C/Swift APIs and *not* read Info.plist to get the bundle ID first. I don't see it as a Gatekeeper issue though, since the attributes were the same for the current stable release and this test3 release on my system:
% xattr /Applications/Pd-0.54-1.app com.apple.macl com.apple.provenance com.apple.quarantine
% xattr ~/Desktop/Pd-0.55-0test3a.app com.apple.macl com.apple.provenance com.apple.quarantine
[1] Saving Pd settings on macOS *used* to be slow (multiple seconds) as each setting was written individually using defaults from C. This was more an issue of making multiple system calls rather than an issue with defaults. I replaced that with using the Apple Foundation C API instead and it's very fast now. ;)
On Jun 2, 2024, at 12:00 PM, pd-list-request@lists.iem.at wrote:
Message: 1 Date: Sun, 2 Jun 2024 10:40:16 +0200 From: IOhannes m zm?lnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at Subject: Re: [PD] slow startup on macOS Message-ID: <76936eab-e81f-4b7c-a39d-37ff73c7d8dd@iem.at mailto:76936eab-e81f-4b7c-a39d-37ff73c7d8dd@iem.at> Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 6/2/24 09:34, Benjamin Wesch wrote:
On Sun, Jun 2, 2024 at 8:45?AM IOhannes m zm?lnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> wrote:
[...] replace the dynamic reading of ::pd_guiprefs::domain
without really understanding the whole mechanism: isn't this already defined here then? https://github.com/pure-data/pure-data/blob/master/tcl/pd_guiprefs.tcl#L21
yes. (as i said: there should be some fallback mechanisms in place).
or probably just remove the lines 72-76
both options work for me.
thanks for confirming. i've created a PR [2331] for the fix. CI-builds should be available soon.
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Am 2. Juni 2024 12:58:36 MESZ schrieb Dan Wilcox danomatika@gmail.com:
Thanks for looking into this, y'all.
I also agree that this check is not really necessary. We already know the BundleID we are using, but it might have been put in place as Pd-extended had a different domain (and hence BundleID), so checking first would ensure the same plugin would work on multiple forks. We might want at least document this change and/or provide a better mechanism to check,
There is no change.
I introduced querying the bundle id via defaults, because I prefer a single source of truth, rather than hardcoding the same value on multiple places.
As discussed earlier this year (or was it last year?) I would like to eventually change the id of pd to info.puredata.pd, as we do not really have control over puredata.org.
The commit to dynamically query the bundle id was a preparation for sich a switch.
however, my progress on changing the id stalled otherwise.
although it seems macOS was the only platform to do this.
macOS is the only platform that has a bundle id...
Following, I don't see a real reason why using the
defaultscommand should be slow in and of itself (except for [1]).This is perhaps a security mechanism where accessing the bundle's Info.plist directly is discouraged as it might be used by malware (my guess).
Either this, or because we are accessing our via it's absolute path. (So it looks like access to an arbitrary application - which is also what the popup warms about).
Maybe there's a more native way to access the bundle id within TclTk.
mfg.sfg.jfd IOhannes
On 6/2/24 18:53, IOhannes m zmölnig wrote:
Maybe there's a more native way to access the bundle id within TclTk.
ha! $::env(__CFBundleIdentifier) gives me that very information, without having to do anything!
i have pushed a change to develop that uses this (f990857d), but
probably will not create a PR just for this.
nevertheless, if somebody could try to the CI build [1] to confirm that it doesn't again introduce a regression, i would be thankful. (today i tried to reproduce on a macOS 14.3 "Sonoma" VM, but i couldn't. the VM is geared towards development, so has a couple of gatekeeper checks disabled, which most likely is the reasons why everything works)
gfmdasr IOhannes
[1] https://git.iem.at/pd/pure-data/-/jobs/73025/artifacts/file/Pd-0.55-0test3a-8-gf990857d.dmg
On Mon, Jun 3, 2024 at 8:56 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
[...] to confirm that it doesn't again introduce a regression [...]
confirmed with identical results as the hardcoded fix. what i obviously didn't test is whether this is returning a bundleID here.
cheers, ben
On 6/3/24 09:17, Benjamin Wesch wrote:
On Mon, Jun 3, 2024 at 8:56 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
[...] to confirm that it doesn't again introduce a regression [...]
confirmed with identical results as the hardcoded fix.
thanks.
what i obviously didn't test is whether this is returning a bundleID here.
well, if your (GUI) preferences still work, then it did :-)
mgdas IOhannes
On Mon, Jun 3, 2024 at 9:21 AM IOhannes m zmoelnig zmoelnig@iem.at wrote:
well, if your (GUI) preferences still work, then it did :-)
cool. preferences look familiar and get saved. my (false) assumption was that this might also be the fallback in action.
cheers, ben
-
Benjamin Wesch -
Dan Wilcox -
IOhannes m zmoelnig -
IOhannes m zmölnig