currently, we have to manually set PD_LONGINTTYPE to "long long" when compiling 64bit Pd for Windows (because on Windows "long" is always 32 bit, even in 64 bit programs). now my question:
should we fix this in the makefile or directly in m_pd.h?
I think m_pd.h should make a reasonable guess, in a way that makes it easy to override. Perhaps like this:
#if !defined(PD_LONGINTTYPE) #if (sizeof(void *) > sizeof(long)) #define PD_LONGINTTYPE long long #else #define PD_LONGINTTYPE long #endif #endif
There's a patch on github I haven't yet looked at closely - perhpas there's a better fix there.
cheers Miller
On Wed, Jun 20, 2018 at 02:36:04AM +0200, Christof Ressi wrote:
currently, we have to manually set PD_LONGINTTYPE to "long long" when compiling 64bit Pd for Windows (because on Windows "long" is always 32 bit, even in 64 bit programs). now my question:
should we fix this in the makefile or directly in m_pd.h?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
some more ideas:
<WinDef.h> defines INT_PTR (https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%...).
<stdint.h> defines intptr_t (the standard says it's optional, but is there actually a platform which doesn't provide it?)
Gesendet: Mittwoch, 20. Juni 2018 um 02:51 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: pd-dev pd-dev@lists.iem.at Betreff: Re: [PD-dev] PD_LONGINTTYPE
I think m_pd.h should make a reasonable guess, in a way that makes it easy to override. Perhaps like this:
#if !defined(PD_LONGINTTYPE) #if (sizeof(void *) > sizeof(long)) #define PD_LONGINTTYPE long long #else #define PD_LONGINTTYPE long #endif #endif
There's a patch on github I haven't yet looked at closely - perhpas there's a better fix there.
cheers Miller
On Wed, Jun 20, 2018 at 02:36:04AM +0200, Christof Ressi wrote:
currently, we have to manually set PD_LONGINTTYPE to "long long" when compiling 64bit Pd for Windows (because on Windows "long" is always 32 bit, even in 64 bit programs). now my question:
should we fix this in the makefile or directly in m_pd.h?
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2018-06-20 02:51, Miller Puckette wrote:
I think m_pd.h should make a reasonable guess, in a way that makes it easy to override. Perhaps like this:
#if !defined(PD_LONGINTTYPE) #if (sizeof(void *) > sizeof(long)) #define PD_LONGINTTYPE long long #else #define PD_LONGINTTYPE long #endif #endif
unfortunately, we cannot use sizeof() in pre-processor conditionals.
there might be some compiler-specific hacks to achieve something like that on C99-compliant compilers, but i don't really think it's worth it. (that is: i think being able to compile Pd with older microsoft compilers is more interesting, than adding quirks).
There's a patch on github I haven't yet looked at closely - perhpas there's a better fix there.
i've inluded the patch in my "more toward double-precision" PR, found at: https://github.com/pure-data/pure-data/pull/300 the original (single-patch) PR is https://github.com/pure-data/pure-data/pull/7
it is much simpler, as there the only known system with an LLP64 data model¹ (which mandates "long" to be 32bit on 64bit architectures) is... MSW. so it's simple enough to just special-case w64 and be done.
i've also included
fgmasdr IOhannes
PS: i've just seen that the patch only addresses the amd64 (aka x86_64) architecture, while w64 also uses LLP64 on ia-64 (aka itanium).
¹ https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
cheers M
On Wed, Jun 20, 2018 at 09:49:18AM +0200, IOhannes m zmoelnig wrote:
On 2018-06-20 02:51, Miller Puckette wrote:
I think m_pd.h should make a reasonable guess, in a way that makes it easy to override. Perhaps like this:
#if !defined(PD_LONGINTTYPE) #if (sizeof(void *) > sizeof(long)) #define PD_LONGINTTYPE long long #else #define PD_LONGINTTYPE long #endif #endif
unfortunately, we cannot use sizeof() in pre-processor conditionals.
there might be some compiler-specific hacks to achieve something like that on C99-compliant compilers, but i don't really think it's worth it. (that is: i think being able to compile Pd with older microsoft compilers is more interesting, than adding quirks).
There's a patch on github I haven't yet looked at closely - perhpas there's a better fix there.
i've inluded the patch in my "more toward double-precision" PR, found at: https://github.com/pure-data/pure-data/pull/300 the original (single-patch) PR is https://github.com/pure-data/pure-data/pull/7
it is much simpler, as there the only known system with an LLP64 data model¹ (which mandates "long" to be 32bit on 64bit architectures) is... MSW. so it's simple enough to just special-case w64 and be done.
i've also included
fgmasdr IOhannes
PS: i've just seen that the patch only addresses the amd64 (aka x86_64) architecture, while w64 also uses LLP64 on ia-64 (aka itanium).
¹ https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 06/23/2018 09:35 PM, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
great.
please note that the PR [336] "0.48-2 / 0.49 running branch" is a curated branch that only contains trivial bugfixes, translation updates and documentation updates.
(there's also an update of the deken plugin, so it plays nicely with some changes that happened on the deken-server).
i consider the changes there to be safe for a bugfix update. please consider merging it.
gfmards IOhannes
2018-06-24 3:59 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
On 06/23/2018 09:35 PM, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable
0.48-2 -
I'll pull teh original one for that and hold off on
more-toward-double-precision
for 0.49.
great.
please note that the PR [336] "0.48-2 / 0.49 running branch" is a curated branch that only contains trivial bugfixes, translation updates and documentation updates.
(there's also an update of the deken plugin, so it plays nicely with some changes that happened on the deken-server).
i consider the changes there to be safe for a bugfix update. please consider merging it.
hi, please consider these simple documentation updates as well, maybe just include them in this running branch
https://github.com/pure-data/pure-data/pull/292
https://github.com/pure-data/pure-data/pull/359
cheers
Cool.... that just saved me hours of work going through PRs one by one :)
M
On Sun, Jun 24, 2018 at 08:59:49AM +0200, IOhannes m zmölnig wrote:
On 06/23/2018 09:35 PM, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
great.
please note that the PR [336] "0.48-2 / 0.49 running branch" is a curated branch that only contains trivial bugfixes, translation updates and documentation updates.
(there's also an update of the deken plugin, so it plays nicely with some changes that happened on the deken-server).
i consider the changes there to be safe for a bugfix update. please consider merging it.
gfmards IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi Miller,
here are some random bugfix PR's you might consider for 0.48.2:
https://github.com/pure-data/pure-data/pull/389 https://github.com/pure-data/pure-data/pull/381 https://github.com/pure-data/pure-data/pull/366 https://github.com/pure-data/pure-data/pull/307
the following PR is still WIP but the first 6 commits could be already cherry picked: https://github.com/pure-data/pure-data/pull/349/commits
Christof
Gesendet: Sonntag, 24. Juni 2018 um 21:08 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "IOhannes m zmölnig" zmoelnig@iem.at Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] PD_LONGINTTYPE
Cool.... that just saved me hours of work going through PRs one by one :)
M
On Sun, Jun 24, 2018 at 08:59:49AM +0200, IOhannes m zmölnig wrote:
On 06/23/2018 09:35 PM, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
great.
please note that the PR [336] "0.48-2 / 0.49 running branch" is a curated branch that only contains trivial bugfixes, translation updates and documentation updates.
(there's also an update of the deken plugin, so it plays nicely with some changes that happened on the deken-server).
i consider the changes there to be safe for a bugfix update. please consider merging it.
gfmards IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
yeah, that was quick :) since this was before merging my requests into the running 0.48-2/49 branch, I reiterate to consider merging these simple documentation updates as well.
https://github.com/pure-data/pure-data/pull/292 https://github.com/pure-data/pure-data/pull/359
And if we're picking "random" fixes to consider, I'd also like to highlight this [declare] fix from Dan which I think is really important: https://github.com/pure-data/pure-data/pull/205 - actually, I was hoping that to be part of 0.48-1, as this is really needed since 0.48 came out
cheers
2018-06-24 16:37 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
Hi Miller,
here are some random bugfix PR's you might consider for 0.48.2:
https://github.com/pure-data/pure-data/pull/389 https://github.com/pure-data/pure-data/pull/381 https://github.com/pure-data/pure-data/pull/366 https://github.com/pure-data/pure-data/pull/307
the following PR is still WIP but the first 6 commits could be already cherry picked: https://github.com/pure-data/pure-data/pull/349/commits
Christof
Gesendet: Sonntag, 24. Juni 2018 um 21:08 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "IOhannes m zmölnig" zmoelnig@iem.at Cc: pd-dev@lists.iem.at Betreff: Re: [PD-dev] PD_LONGINTTYPE
Cool.... that just saved me hours of work going through PRs one by one :)
M
On Sun, Jun 24, 2018 at 08:59:49AM +0200, IOhannes m zmölnig wrote:
On 06/23/2018 09:35 PM, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable
0.48-2 -
I'll pull teh original one for that and hold off on
more-toward-double-precision
for 0.49.
great.
please note that the PR [336] "0.48-2 / 0.49 running branch" is a curated branch that only contains trivial bugfixes, translation updates and documentation updates.
(there's also an update of the deken plugin, so it plays nicely with some changes that happened on the deken-server).
i consider the changes there to be safe for a bugfix update. please consider merging it.
gfmards IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 2018-06-24 21:08, Miller Puckette wrote:
Cool.... that just saved me hours of work going through PRs one by one :)
great to be of help.
please note, that there are a number of PRs that are *not* included, (e.g. the PD_LONGINTTYPE patch [7]).
my rule of thumb for including patches in the PR is that they must be no-brainers: #1 only bugfixes #2 the patch is trivial #3 the patch is "unanimous" (no protests, "buts" or second thoughts have been (ever) voiced)
i haven't included the PD_LONGINTTYPE patch because of #3 (see †). i haven't included some of the help-patch updates because of #2 (as Pd-patches are really a pain to compare).
i try my best to live up to my own rules, but as a human this is not always easy.
gfmasdr IOhannes
[7] https://github.com/pure-data/pure-data/pull/7 † https://github.com/pure-data/pure-data/pull/7#issuecomment-216948587
On 2018-06-23 21:35, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
one more thing: it seems that you haven't really included the PD_LONGINTTYPE patch yet (which is really towards compiling (a single-precision Pd) for win64 rather than about double-precision).
this might be because i confused everybody with my "update/0.48-2" branch advertisment.
just for the record: i usually close the PRs that i include in the "update/0.xx" branch, so they don't show up on the list of active PRs any more. if i don't close them for whatever reason, then at least i leave a comment that the PR is included.
fgmasdr IOhannes
On Mon, Jun 25, 2018 at 10:06:09AM +0200, IOhannes m zmoelnig wrote:
On 2018-06-23 21:35, Miller Puckette wrote:
OK... I need to fix a few bugs and quirks and put out a nice stable 0.48-2 - I'll pull teh original one for that and hold off on more-toward-double-precision for 0.49.
one more thing: it seems that you haven't really included the PD_LONGINTTYPE patch yet (which is really towards compiling (a single-precision Pd) for win64 rather than about double-precision).
Sure enough... I had somehow pulled it but not merged it, shouhd be fixed now.
M
this might be because i confused everybody with my "update/0.48-2" branch advertisment.
just for the record: i usually close the PRs that i include in the "update/0.xx" branch, so they don't show up on the list of active PRs any more. if i don't close them for whatever reason, then at least i leave a comment that the PR is included.
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev