Sounds good. Let me know if I can help, ie. merge some of the various PRs into a single PR.
On Nov 30, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I put this right in 'head' on a clone of my own repo; it compiles OK for me here on linux/64 and widows-32 so I think it's provisionally working, but needs lots of testing.
If there's no reason not to I'll just throw that all in my own 'head' and push it all back to the git repo.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
OK, I ended up pushing to a new branch (just to stay on the safe side for now). Assuming all looks OK I can make this the main branch.
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Meanwhile, I think PRs are starting to appear on top of the existing PRs... and/or they're growing since I tried to merge them. I don't know how to get github to think of the PRs as against the 0.48-1 branch, so my thought for the moment is to wait until it looks save to merge 0.48-1 into master and then try merging whatever PRs might have changed.
In case some PR in fact hasn't been added to since I made all the merges, I think it will look like it has been merged once I merge the 0.48-1 branch into master. So at that point it should be easier to figure out which PRs need to be re-merged.
cheers Miller
On Thu, Nov 30, 2017 at 02:39:52PM +0100, Dan Wilcox wrote:
Sounds good. Let me know if I can help, ie. merge some of the various PRs into a single PR.
On Nov 30, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I put this right in 'head' on a clone of my own repo; it compiles OK for me here on linux/64 and widows-32 so I think it's provisionally working, but needs lots of testing.
If there's no reason not to I'll just throw that all in my own 'head' and push it all back to the git repo.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
hi, where can we check your new 0.48-1 branch?
cheers
2017-12-02 17:40 GMT-02:00 Miller Puckette msp@ucsd.edu:
OK, I ended up pushing to a new branch (just to stay on the safe side for now). Assuming all looks OK I can make this the main branch.
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Meanwhile, I think PRs are starting to appear on top of the existing PRs... and/or they're growing since I tried to merge them. I don't know how to get github to think of the PRs as against the 0.48-1 branch, so my thought for the moment is to wait until it looks save to merge 0.48-1 into master and then try merging whatever PRs might have changed.
In case some PR in fact hasn't been added to since I made all the merges, I think it will look like it has been merged once I merge the 0.48-1 branch into master. So at that point it should be easier to figure out which PRs need to be re-merged.
cheers Miller
On Thu, Nov 30, 2017 at 02:39:52PM +0100, Dan Wilcox wrote:
Sounds good. Let me know if I can help, ie. merge some of the various
PRs into a single PR.
On Nov 30, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I put this right in 'head' on a clone of my own repo; it compiles OK
for me
here on linux/64 and widows-32 so I think it's provisionally working,
but needs
lots of testing.
If there's no reason not to I'll just throw that all in my own 'head'
and push
it all back to the git repo.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
I believe it's up on github. I think you 'pull' it and then 'git checkout 0.48-1'.
cheers Miller
On Sat, Dec 02, 2017 at 06:52:52PM -0200, Alexandre Torres Porres wrote:
hi, where can we check your new 0.48-1 branch?
cheers
2017-12-02 17:40 GMT-02:00 Miller Puckette msp@ucsd.edu:
OK, I ended up pushing to a new branch (just to stay on the safe side for now). Assuming all looks OK I can make this the main branch.
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Meanwhile, I think PRs are starting to appear on top of the existing PRs... and/or they're growing since I tried to merge them. I don't know how to get github to think of the PRs as against the 0.48-1 branch, so my thought for the moment is to wait until it looks save to merge 0.48-1 into master and then try merging whatever PRs might have changed.
In case some PR in fact hasn't been added to since I made all the merges, I think it will look like it has been merged once I merge the 0.48-1 branch into master. So at that point it should be easier to figure out which PRs need to be re-merged.
cheers Miller
On Thu, Nov 30, 2017 at 02:39:52PM +0100, Dan Wilcox wrote:
Sounds good. Let me know if I can help, ie. merge some of the various
PRs into a single PR.
On Nov 30, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I put this right in 'head' on a clone of my own repo; it compiles OK
for me
here on linux/64 and widows-32 so I think it's provisionally working,
but needs
lots of testing.
If there's no reason not to I'll just throw that all in my own 'head'
and push
it all back to the git repo.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
2017-12-02 19:18 GMT-02:00 Miller Puckette msp@ucsd.edu:
I believe it's up on github. I think you 'pull' it and then 'git checkout 0.48-1'.
Ahá! Found it
https://github.com/pure-data/pure-data/tree/0.48-1
cheers Miller
On Sat, Dec 02, 2017 at 06:52:52PM -0200, Alexandre Torres Porres wrote:
hi, where can we check your new 0.48-1 branch?
cheers
2017-12-02 17:40 GMT-02:00 Miller Puckette msp@ucsd.edu:
OK, I ended up pushing to a new branch (just to stay on the safe side
for
now). Assuming all looks OK I can make this the main branch.
I had one small ouch: I don't think I can compatibly change t_int to
int
in m_pd.h (this is mentioned on another thread somewhere). I don't
know
how to make clang pipe down about this short of casting almost every call
to
atom_getint*() in the whole tree. Yuck... Maybe it's better just to
tell
clang to be more permissive (if that's possible)?
Meanwhile, I think PRs are starting to appear on top of the existing
PRs...
and/or they're growing since I tried to merge them. I don't know how
to
get github to think of the PRs as against the 0.48-1 branch, so my
thought
for the moment is to wait until it looks save to merge 0.48-1 into
master
and then try merging whatever PRs might have changed.
In case some PR in fact hasn't been added to since I made all the
merges, I
think it will look like it has been merged once I merge the 0.48-1
branch
into master. So at that point it should be easier to figure out which
PRs
need to be re-merged.
cheers Miller
On Thu, Nov 30, 2017 at 02:39:52PM +0100, Dan Wilcox wrote:
Sounds good. Let me know if I can help, ie. merge some of the various
PRs into a single PR.
On Nov 30, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
I put this right in 'head' on a clone of my own repo; it compiles
OK
for me
here on linux/64 and widows-32 so I think it's provisionally
working,
but needs
lots of testing.
If there's no reason not to I'll just throw that all in my own
'head'
and push
it all back to the git repo.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and I see that your PR changesit from "t_int" to "int" - and I believe it has to be "t_int" for back compatibility...
cheers M
On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote:
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I was following IOhannes' prompt about t_int: "rule of thumb: never use it for anything but passing data to perform-routines."
On Dec 2, 2017, at 10:22 PM, Miller Puckette msp@ucsd.edu wrote:
I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and I see that your PR changesit from "t_int" to "int" - and I believe it has to be "t_int" for back compatibility...
cheers M
On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote:
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I think the use of "t_int" in m_pd.h is incorrect - it should have been int. But it's a mistake I think is now ironed in and we're stuck with it.
M
On Sat, Dec 02, 2017 at 10:25:07PM +0100, Dan Wilcox wrote:
I was following IOhannes' prompt about t_int: "rule of thumb: never use it for anything but passing data to perform-routines."
On Dec 2, 2017, at 10:22 PM, Miller Puckette msp@ucsd.edu wrote:
I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and I see that your PR changesit from "t_int" to "int" - and I believe it has to be "t_int" for back compatibility...
cheers M
On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote:
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Or (aha) - I could make up new function names for the "int" versions and change the pd sources to use them, and declare the existing ones obsolete...?
In fact, is there any reason one can't just globally replace every call to atom_getint and atom_getintarg with the atom_getfloat equivalent - let externs blithely call atom_getint and get a t_int back all they want.
That would touch a lot of files so if I do it perhaps I should make sure to do all the PR-merging I possibly can beforehand.
AND: there's no reason I can't assign a float to an int without a cast, is there? As I understand it the only clang complaint is int-to-smaller-int conversions. So int x = atom_getfloat(&atom) is still kosher, correct?
thanks Miller On Sat, Dec 02, 2017 at 02:50:57PM -0800, Miller Puckette wrote:
I think the use of "t_int" in m_pd.h is incorrect - it should have been int. But it's a mistake I think is now ironed in and we're stuck with it.
M
On Sat, Dec 02, 2017 at 10:25:07PM +0100, Dan Wilcox wrote:
I was following IOhannes' prompt about t_int: "rule of thumb: never use it for anything but passing data to perform-routines."
On Dec 2, 2017, at 10:22 PM, Miller Puckette msp@ucsd.edu wrote:
I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and I see that your PR changesit from "t_int" to "int" - and I believe it has to be "t_int" for back compatibility...
cheers M
On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote:
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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, I think the complaint is mainly about possible loss of precision so (I may be wrong), the float to int cast might be fine.
On Dec 2, 2017, at 11:57 PM, Miller Puckette msp@ucsd.edu wrote:
Or (aha) - I could make up new function names for the "int" versions and change the pd sources to use them, and declare the existing ones obsolete...?
In fact, is there any reason one can't just globally replace every call to atom_getint and atom_getintarg with the atom_getfloat equivalent - let externs blithely call atom_getint and get a t_int back all they want.
That would touch a lot of files so if I do it perhaps I should make sure to do all the PR-merging I possibly can beforehand.
AND: there's no reason I can't assign a float to an int without a cast, is there? As I understand it the only clang complaint is int-to-smaller-int conversions. So int x = atom_getfloat(&atom) is still kosher, correct?
thanks Miller On Sat, Dec 02, 2017 at 02:50:57PM -0800, Miller Puckette wrote:
I think the use of "t_int" in m_pd.h is incorrect - it should have been int. But it's a mistake I think is now ironed in and we're stuck with it.
M
On Sat, Dec 02, 2017 at 10:25:07PM +0100, Dan Wilcox wrote:
I was following IOhannes' prompt about t_int: "rule of thumb: never use it for anything but passing data to perform-routines."
On Dec 2, 2017, at 10:22 PM, Miller Puckette msp@ucsd.edu wrote:
I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and I see that your PR changesit from "t_int" to "int" - and I believe it has to be "t_int" for back compatibility...
cheers M
On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote:
I think I had already fixed this: https://github.com/pure-data/pure-data/pull/223 https://github.com/pure-data/pure-data/pull/223 (?) Or am I missing something?
On Dec 2, 2017, at 8:40 PM, Miller Puckette msp@ucsd.edu wrote:
I had one small ouch: I don't think I can compatibly change t_int to int in m_pd.h (this is mentioned on another thread somewhere). I don't know how to make clang pipe down about this short of casting almost every call to atom_getint*() in the whole tree. Yuck... Maybe it's better just to tell clang to be more permissive (if that's possible)?
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 12/02/2017 11:57 PM, Miller Puckette wrote:
Or (aha) - I could make up new function names for the "int" versions and change the pd sources to use them, and declare the existing ones obsolete...?
In fact, is there any reason one can't just globally replace every call to atom_getint and atom_getintarg with the atom_getfloat equivalent - let externs blithely call atom_getint and get a t_int back all they want.
i guess atom_getint() is there mainly for Max compat (where an atom *can* hold integer values). In a Pd-only land there shouldn't be a difference.
That would touch a lot of files so if I do it perhaps I should make sure to do all the PR-merging I possibly can beforehand.
AND: there's no reason I can't assign a float to an int without a cast, is there? As I understand it the only clang complaint is int-to-smaller-int conversions. So int x = atom_getfloat(&atom) is still kosher, correct?
i think so.
gfds IOhannes