[PD-dev] 0.48-1 release plans

[Miller Puckette]

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 at 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 at 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 at lists.iem.at
> > https://lists.puredata.info/listinfo/pd-dev
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev