similar to: [LLVMdev] draft rule for naming types/functions/variables

On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > +llvmdev > > Thanks for the comments, Chris. > > On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: >> >>> Hi guys, >>> >>> Based on our discussion

Zhanyong Wan (λx.x x) wrote: > If possible, I'd prefer that all variable names have the same style. > I'm afraid that we'll end up with the current inconsistent style if > we > leave it to people to interpret whether a name is metasyntactic and > thus should be lower-case. > > Also, having both types and variables in StrictCamelCase increases > the > chance

Hi, I enjoyed the new coding style in recent patches. Camel case makes it easy to pick a descriptive name. Starting functions and variables with lower cases reduces chances to conflict with a type name. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > >

Hi, I uploaded a patch for the "*Kind enum" rule to http://codereview.appspot.com/3402041 and attached it to this message too. Would you please take a look? Thanks, On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > Thanks, Chris and John.  Committed in r120689.  I'll try to add the > *Kind rule in a separate patch.  Cheers, > >

On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > Hi Chris, > > I've uploaded a new patch to http://codereview.appspot.com/3264041. > It's also attached to this message. This patch looks great to me, please apply, thanks! > I think I've addressed all your comments, except "when in doubt, an > enum should be a 'Kind'". I don't

On Dec 1, 2010, at 9:32 PM, Zhanyong Wan (λx.x x) wrote: > Hi, > > I uploaded a patch for the "*Kind enum" rule to > > http://codereview.appspot.com/3402041 > > and attached it to this message too. Would you please take a look? Thanks, Applied, thanks! After applying it, I went through and restructured the section for readability:

On Tue, Nov 30, 2010 at 5:07 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > >> Thanks for the comments, Chris!  Glad that we are making progress. >> >> I'll make most of the edits you suggested later today.  Before that, >> there are a couple of high-level points I'd like to go over

Thanks, Chris and John. Committed in r120689. I'll try to add the *Kind rule in a separate patch. Cheers, On Wed, Dec 1, 2010 at 5:18 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi Chris, >> >> I've uploaded a new patch to http://codereview.appspot.com/3264041. >> It's

Hi Chris, I've uploaded a new patch to http://codereview.appspot.com/3264041. It's also attached to this message. I think I've addressed all your comments, except "when in doubt, an enum should be a 'Kind'". I don't think I fully understand that point, and it strikes me as a bit ad hoc for the coding standards. Do we really want it? If you feel that's

On Sun, Nov 28, 2010 at 11:02 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I enjoyed the new coding style in recent patches. Camel case makes it easy >> to pick a descriptive name. Starting functions and variables with lower >> cases reduces chances to conflict with a type name. > Honestly speaking, I don't. Especially in the cases when varname is

Hi Doug, While refactoring clang::FileManager to use llvm::sys::path, I had a need for a function to test whether a char is a path separator. I think it would be generally useful. Would you be able to review it? You can see http://codereview.appspot.com/4186045 or the attachment. Thanks, -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi Chris, I was reading the LLVM coding standards and noticed some typos & formatting nits. Please see http://codereview.appspot.com/3127041 for my proposed fix. Most of changes are local and cosmetic. The only bigger change I made is to group the sections about iostream and raw_ostream together, as they are logically related. I had to edit the text a little bit after the move, in order

Thanks for the comments, Chris! Glad that we are making progress. I'll make most of the edits you suggested later today. Before that, there are a couple of high-level points I'd like to go over with you. 1. I totally agree that the biggest benefit of a naming convention is uniform APIs. On the other hand, an inconsistent local naming style hurts the productivity of contributors and

On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > Thanks for the comments, Chris! Glad that we are making progress. > > I'll make most of the edits you suggested later today. Before that, > there are a couple of high-level points I'd like to go over with you. > > 1. I totally agree that the biggest benefit of a naming convention is > uniform APIs. On

On Nov 29, 2010, at 11:07 AM, Zhanyong Wan (λx.x x) wrote: > C++ is such a complex language that no single naming convention will > be able to cover all cases. Therefore we aim at a reasonable default > that works for the majority of the cases. As Chris put at the > beginning of the coding standards, "no coding standards should be > regarded as absolute requirements to be

On Tue, Nov 23, 2010 at 10:15 AM, Bo Persson <bop at gmb.dk> wrote: >  > > > ----- Original Message ----- > From: Chandler Carruth > To: Zhanyong Wan (λx.x x) > Cc: Argyrios Kyrtzidis ; clang-dev Developers > Sent: Tuesday, November 23, 2010 6:40 AM > Subject: Re: [cfe-dev] draft rule for naming types/functions/variables > On Mon, Nov 22, 2010 at 9:36 PM,

Hi all, When I called arrayIndex(20:23, dim=c(4,3,3)), it says "Error: could not find function "arrayIndex"in R". So I called ls("package:utils") to see the functions inside: [1] "?" [2] "adist" [3] "alarm" [4] "apropos" [5] "aregexec" [6] "argsAnywhere" [7] "arrangeWindows" [8]

On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote: > Hi, > I enjoyed the new coding style in recent patches. Camel case makes it > easy to pick a descriptive name. Starting functions and variables with > lower cases reduces chances to conflict with a type name. On the other hand, having names that only differ in the case of a single character, is not

I have upgraded to version 3.0.27a on ubuntu 7.10 server and now the getent command wont display the active directory users, but wbinfo will. It worked fine with 3.0.26a and I have not changed my configuration. I do however have this in my winbind log: [2007/12/04 13:39:01, 0] nsswitch/winbindd.c:request_len_recv(544) request_len_recv: Invalid request size received: 2084 (expected

All, After upgrading to samba 3.0.30 on gentoo amd64 because of my recent best friend CVE-2008-1105 My winbind daemon is 'hanging up', and refusing to respond to pings after a few minutes of activity. Wbinfo -u, getent passwd all work successfully, then after a bit wbinfo -p just tells me winbind dies. I have 3.0.30/winbind on another machine, also amd64 that is working.... So