Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote: > https://jira.secondlife.com/browse/BUG-41029 > > .../... > > There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined > indirectly here: > > https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 > > that are used to count memory sizes/usage/difference etc. I think we can > convert them to their U64 equivalents for all viewers. > > Nat points out, rewriting this code using size_t as a return type would > make more sense but that seems like it would involve more invasive code > changes including changes in fundamental LL headers. > > What does the collective wisdom say? My *personal* wisdom says that this U32Bytes/U32Megabytes templatized thingy is just the expression of the lazyness of its coder (frankly, is it *that* difficult to use a constant multiplier to convert from bytes to megabytes ?) and just adds more complexity to the generated code without any benefit whatsoever. As a result, I did not backport this non-sense to the Cool VL Viewer and kept everything in normal variables (U32 for megabytes, U64 for bytes, etc), using constants to convert from one unit to the other when needed; my viewer is therefore unafffected by that bug... My advice would therefore be to revert the corresponding commit. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Fri, 16 Dec 2016 09:44:51 +0100, Henri Beauchamp wrote: > my viewer is therefore unafffected by that bug... In fact, I had a doubt and checked: it was affected, but the fix took me exactly 3 minutes to perform (4 static variables in LLImageGL and LLViewerTexture that were S32 integers and that I made into S64 ones): compared to what it will take you to edit the templatized names in all files, I'd say that the demonstration of how templates can actually harm the maintainability of the code is done... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > I'd say that the demonstration of how templates can actually > harm the maintainability of the code is done... Hahaha, that is a permanent on-going debate. m ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Fri, 16 Dec 2016 10:07:45 -0500, Monty Brandenberg wrote: > On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > > > I'd say that the demonstration of how templates can actually > > harm the maintainability of the code is done... > > Hahaha, that is a permanent on-going debate. I said *can harm*, not *always harm*... There are very appropriate and efficient uses of templates, but the one in question is not (it's more like using a hammer and an anvil to squash a bug). :-) Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
FWIW, those particular units types were introduced as part of the LLTrace metrics update and found several cases where the incorrect units were being recorded, resulting in skewed/invalid metrics. The point is not that it is hard to multiply by a constant to do unit conversion...it is that programmers sometimes forget to, so it is hard to know how much you can trust metrics that have not been thoroughly vetted in the code. On Fri, 16 Dec 2016 00:44:51 -0800, Henri Beauchamp wrote: > On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote: > >> https://jira.secondlife.com/browse/BUG-41029 >> >> .../... >> >> There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) >> defined >> indirectly here: >> >> https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default&fileviewer=file-view-default#llunittype.h-824 >> >> that are used to count memory sizes/usage/difference etc. I think we >> can >> convert them to their U64 equivalents for all viewers. >> >> Nat points out, rewriting this code using size_t as a return type would >> make more sense but that seems like it would involve more invasive code >> changes including changes in fundamental LL headers. >> >> What does the collective wisdom say? > > My *personal* wisdom says that this U32Bytes/U32Megabytes templatized > thingy is just the expression of the lazyness of its coder (frankly, > is it *that* difficult to use a constant multiplier to convert from > bytes to megabytes ?) and just adds more complexity to the generated > code without any benefit whatsoever. > > As a result, I did not backport this non-sense to the Cool VL Viewer > and kept everything in normal variables (U32 for megabytes, U64 for > bytes, etc), using constants to convert from one unit to the other > when needed; my viewer is therefore unafffected by that bug... > > My advice would therefore be to revert the corresponding commit. > > Henri. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges -- Festina Lente ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
