[PD-dev] 0.48-1 release plans
Dan Wilcox
danomatika at gmail.com
Sat Dec 2 23:58:51 CET 2017
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 at 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 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
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20171202/ffad552a/attachment-0001.html>
More information about the Pd-dev
mailing list