On May 25, 2009, at 2:50 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:On May 25, 2009, at 2:24 PM, Zach Welch wrote:Further, you can argue with the following assertions -- only if youcan show me a patch that proves them wrong:Show me your patch, or let me commit mine. This debate is silly. Cheers, ZachIt's interesting that every time a discussion about preferences comesup, it typically ends with "Here's my patch. This is silly. My patchalready works, let's just commit it." It's not like discussion is painful or this issue is causing problems for anyone. We're betteroff coming up with an answer that everyone is OK with rather than justdefaulting to whatever patch shows up first.Actually, these kinds of issues are very frustrating to me personally, because they always end up being counterproductive. This is why I am maintaining the Style Guide. I desperately want to hereafter resolve this debate by shouting "RTFM and STFU"; anything else is time wasted. The burden of proof lies on the person that lacks a patch in-hand. Until these matters are fully resolved, the discussion does cause a problem because it prevents us from moving forward with genuinely productive work on the system.
It isn't counterproductive the first time the discussion happens. It's counterproductive when someone wants to go against the established convention. The burden is always on the person who is arguing for something different that the convention. In this case, it's both of us.
The opposing patch is attached. As I already mentioned, it is large, but the changes were done entirely with the following commands: find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/ g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/ g' {} \; find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/ g' {} \;The first set just do a bulk rename of the types, but it also changes function names. Since it looks odd to include the _t in a function name, the second set changes the pattern used for function names to not include the _t.I hate it. You seriously want to make all of the functions that referred to u16 or u32 to now refer to uint16 and uint32??? This was _exactly_ what I meant when I said a patch would be hard to create.
It wasn't hard to create at all. Eight find and replaces is all it took. Less than 10 minutes.
Also, you do realize that the scope of these changes is _much_ morelikely to be disruptive to anyone with out-of-tree changes in progress?
Yup. It is. Sadly until we decide on all these various conventions, things are always going to be disruptive to those with out-of-tree changes. At least in this case, syncing with ToT is relatively simple. Using minimal change as an argument for is dangerous. Consider the local minimum effect. To get to a better solution, you might need to stir things up a bit in the short term. The question we need to be asking is "Do we do a big change now, or do we live with a non-standard type system?"
Are you insane or merely sadistic? :)
Neither and the smiley doesn't really help your case either. You're taking this _way_ too personal for something that is a relatively mundane discussion. The two sides have chimed in, patches have been provided, and a fair number of developers have commented. It's up to the majority to decide which way to go.
Cheers, Zach
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
