On Wed, Jul 18, 2012, at 08:23 PM, andy pugh wrote: > On 18 July 2012 13:41, andy pugh <bodge...@gmail.com> wrote: > > Is there a good reason why halcmd show displays S32 and U32 pin / > > param values in Hex? It seems that such items will generally represent > > physical units so decimal might be more appropriate? > > > > I think halmeter shows both formats, and I can't remember what Halshow > > does, but I think that is decimal. > > Looking at the code now I am at home. > > data_value creates a space-formatted string with float and s32 in > decimal, but u32 in hex. > data_value2 creates a packed string with all three numeric types in > decimal format. > > That seems inconsistent.
I'm sure it made perfect sense to me when I did it. But that was about 6 years ago. It might not make sense now. One thing that was different back then was that we had 8 and 16 bit integer types in HAL as well as 32 bit. Those types, and the unsigned version in particular, smelled to me like things that you might actually want to view as a collection of bits, nibbles, or bytes, as opposed to a numerical value. A hex format number (with leading zeros) lets you do that, and also lets you see how much space you have and how close it is to overflow. It is darn near impossible to extract bits or bytes from a decimal number once it gets bigger than about 4 bits. At the time I thought that mattered. As you have pointed out, HAL variables are rarely if ever used to pack in a collection of bits - they are almost always used to store a number. And I agree that a number is easier to understand in decimal. I won't be offended if someone wants to change it, but there should probably be a brief discussion about what it might break. Is anyone feeding the output of "hal show" to a script or another program for parsing? They might be surprised by the change. (They might be pleasantly surprised, not having to deal with hex - but it is still a surprise.) As for data_value vs data_value2, I believe one of those is used for "hal show", and the other for "hal save". The output of "show" is intended for humans, and I thought I was doing them a favor by letting them look at the bits of a U32, and also by padding things so the numbers line up in neat columns. The output of "save" is intended to be read by halcmd (although it is also human readable). As such, it is simpler to make it always decimal, and not to bother with padding. That is the "logic" (such as it was) behind they way it was done. I have no problems with someone changing it, time has shown that the logic might have been flawed. Regards, John Kasunich -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
