search for: camelback

...of LLVM and Clang code I've read does indeed stick to the current CamelCase convention. Unless there's a plan for conversion then the practical impact of the naming convention change is that the codebase will be a muddle of mixed conventions for years. That seems like a regression, even if camelBack is a better convention. On a more practical note, if the intent is to move to camelBack I think it would be worth adding an example to the coding standard for handling an acronym. e.g. is it the intent that TTI would become tti. Best, Alex

...19 4:15 AM, Michael Platings via llvm-dev wrote: > Taking my previous example [1]: > > InnerLoopVectorizer LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC, > &LVL, &CM); > > If we imagine that over time it evolves such that 50% of the variables have been renamed to camelBack versions of the type names, then it will look like this: > > InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI, > assumptionCache, ORE, vectorizationFactor.Width, IC, > &loopVectorizationLegality, &CM); Hold on... The change from UpperCamel to lower...

...: > Regarding a plan for conversion, I'm keen to avoid perfect being the enemy > of better. It seems a bit early to discuss conversion given there’s not consensus on a style. For example: If we imagine that over time it evolves such that 50% of the variables have > been renamed to camelBack versions of the type names, then it will look > like this: This comment seems to assume that camelBack is the agreed upon style and all we need to do now is move forward, and I do not believe that to be the case -------------- next part -------------- An HTML attachment was scrubbed... URL: &l...

Hi folks, Git is on its way to learning how to ignore commits, allowing us to do variable renaming and other small refactorings without breaking git blame. It's like git-hyper-blame [1] but significantly more powerful as it uses fuzzy matching to match lines, including lines that may have been split or joined. A preview release of Git with this new feature is at:

...onsensus to do that. What is a way to proceed? On Sat, May 25, 2019 at 3:00 PM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Michael, > > I’m still very interested in seeing a change here. If someone is > interested in seeing a codebase using the proposed camelBack convention for > variables names, the MLIR codebase is public > <https://github.com/tensorflow/mlir> and uses it. > > If you’re curious to see what this looks like in practice, there are lots > of examples in the codebase, here is an example .cpp file > <https://github.co...

Hi all, To get wider visibility, build a broader consensus and address concerns on this topic, I'm again raising this as an RFC. This is a proposal to change the rule for variable names from CamelCase to camelBack _really this time_. Background: This has been proposed several times on this mailing list in the past. Most recent one was by Michael Platings in February this year [1], and there seems to be a general consensus that the status quo is not ideal. In the previous RFC thread, I nominated lld [2] as...

...Philip Roman > On 9/3/2019 8:14 PM, Rui Ueyama via llvm-dev wrote: > > Hi all, > > To get wider visibility, build a broader consensus and address concerns on this topic, I'm again raising this as an RFC. This is a proposal to change the rule for variable names from CamelCase to camelBack _really this time_. > > Background: > > This has been proposed several times on this mailing list in the past. Most recent one was by Michael Platings in February this year [1], and there seems to be a general consensus that the status quo is not ideal. > > In the previous RFC thr...

...proceed? > > > > On Sat, May 25, 2019 at 3:00 PM Chris Lattner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi Michael, > > > > I’m still very interested in seeing a change here. If someone is > interested in seeing a codebase using the proposed camelBack convention for > variables names, the MLIR codebase is public > <https://github.com/tensorflow/mlir> and uses it. > > > > If you’re curious to see what this looks like in practice, there are lots > of examples in the codebase, here is an example .cpp file > <https:/...

...May 25, 2019 at 3:00 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Michael, > > > > I’m still very interested in seeing a change here. If someone is interested in seeing a codebase using the proposed camelBack convention for variables names, the MLIR codebase is public <https://github.com/tensorflow/mlir> and uses it. > > > > If you’re curious to see what this looks like in practice, there are lots of examples in the codebase, here is an example .cpp file <https://github.com/tens...

...erPC and x86) and software (Linux, Windows and Android) platform development. * Passionate, dedicated and committed engineer. Preferred Experience / Education: * Master's Degree in Computer Science or equivalent work experience. Kai Knowlton MGA Employee Services Inc. 3131 E. Camelback Road Suite 200 | Phoenix, AZ 85016 Office: 602.508.1883 Fax: 602.648.3760 Kai at mgasearch.com<mailto:Kai at mgasearch.com> www.mgasearch.com<http://www.mgasearch.com/> [link]<http://www.linkedin.com/profile/view?id=132731401&trk=hb_tab_pro_top> -------------- next part ---...

...;>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>> Hi Michael, >>>> >>>> >>>> >>>> I’m still very interested in seeing a change here. If someone is >>>> interested in seeing a codebase using the proposed camelBack convention for >>>> variables names, the MLIR codebase is public >>>> <https://github.com/tensorflow/mlir> and uses it. >>>> >>>> >>>> >>>> If you’re curious to see what this looks like in practice, there are >>>...

...> > On 9/3/2019 8:14 PM, Rui Ueyama via llvm-dev wrote: >> Hi all, >> >> To get wider visibility, build a broader consensus and address concerns on this topic, I'm again raising this as an RFC. This is a proposal to change the rule for variable names from CamelCase to camelBack _really this time_. >> >> Background: >> >> This has been proposed several times on this mailing list in the past. Most recent one was by Michael Platings in February this year [1], and there seems to be a general consensus that the status quo is not ideal. >> >&...

...t;llvm-dev at lists.llvm.org> wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> >>>>> >>>>> I’m still very interested in seeing a change here. If someone is interested in seeing a codebase using the proposed camelBack convention for variables names, the MLIR codebase is public and uses it. >>>>> >>>>> >>>>> >>>>> If you’re curious to see what this looks like in practice, there are lots of examples in the codebase, here is an example .cpp file, here...

...sts.llvm.org> wrote: >>>>> >>>>> Hi Michael, >>>>> >>>>> >>>>> >>>>> I’m still very interested in seeing a change here. If someone is >>>>> interested in seeing a codebase using the proposed camelBack convention for >>>>> variables names, the MLIR codebase is public >>>>> <https://github.com/tensorflow/mlir> and uses it. >>>>> >>>>> >>>>> >>>>> If you’re curious to see what this looks like in practice...

TL;DR: change the rule for variable names from UpperCamelCase to lowerCamelCase. Just to get wider visibility on this, I'm raising this again as an RFC, as suggested by Roman Lebedev. My original post from last week is here and gives a rationale: http://lists.llvm.org/pipermail/llvm-dev/2019-February/129854.html. There seemed to be general agreement that the status quo is not ideal.

...;>>>>>> Hi Michael, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I’m still very interested in seeing a change here. If someone is >>>>>>> interested in seeing a codebase using the proposed camelBack convention for >>>>>>> variables names, the MLIR codebase is public >>>>>>> <https://github.com/tensorflow/mlir> and uses it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> If you’re...

...gt; >> On Sat, May 25, 2019 at 3:00 PM Chris Lattner via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Hi Michael, >> >> I’m still very interested in seeing a change here. If someone is >> interested in seeing a codebase using the proposed camelBack >> convention for variables names, the MLIR codebase is public [4] and >> uses it. >> >> If you’re curious to see what this looks like in practice, there >> are lots of examples in the codebase, here is an example .cpp file >> [5], here is another [6], here is a...

...019, at 8:14 PM, Rui Ueyama via llvm-dev <mailto:llvm-dev at lists.llvm.org> wrote: Hi all, To get wider visibility, build a broader consensus and address concerns on this topic, I'm again raising this as an RFC. This is a proposal to change the rule for variable names from CamelCase to camelBack _really this time_. Background: This has been proposed several times on this mailing list in the past. Most recent one was by Michael Platings in February this year [1], and there seems to be a general consensus that the status quo is not ideal. In the previous RFC thread, I nominated lld [2] as...

Hi all, I have exchanged my Dell R610 in favor of a Sun Fire 4170 M2 which has 32 GB RAM installed. I am running Sol11Expr on this host and I use it to primarily serve Netatalk AFP shares. From day one, I have noticed that the amount of free RAM decereased and along with that decrease the overall performance of ZFS decreased as well. Now, since I am still quite a Solaris newbie, I seem to

..., 2019 at 3:00 PM Chris Lattner via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > >> Hi Michael, > >> > >> I’m still very interested in seeing a change here. If someone is > >> interested in seeing a codebase using the proposed camelBack > >> convention for variables names, the MLIR codebase is public [4] and > >> uses it. > >> > >> If you’re curious to see what this looks like in practice, there > >> are lots of examples in the codebase, here is an example .cpp file > >> [5], h...