search for: ycm

...this piece of code, I was able to extract "xy.1" as name for a data frame containing the coordinates for animal 1: nam_xy <- paste("xy.", 1, sep="") # creates "xy.1" coord.x <- paste("XCM", 1, sep="") coord.y <- paste("YCM", 1, sep="") for (i in 2:20) { nam_xy[i] <- paste("xy.", i, sep="") coord.x[i] <- paste("XCM", i, sep="") coord.y[i] <- paste("YCM", i, sep="") # creates "xy.2", "xy.3", etc....

Hi! I see the `__syncthreads_{and|or|count}()` CUDA intrinsics listed in https://github.com/llvm/llvm-project/blob/master/clang/lib/Headers/__clang_cuda_device_functions.h but the vanilla `__syncthreads()` intrinsic seems to be missing. Is this an oversight, or is it omitted for a specific reason? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL:

...r a few days now. The intent is to commit via the script I put together [2], although I haven't committed anything other than a testing commit [3]. All I can say is, *wow* is it nice. I hid everything I don't care about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] [6], ycm [7]) suddenly work better now that there isn't an artificial boundary between my clang and llvm repositories. I can have patch queues that include LLVM commits and clang commits arbitrarily interspersed with one another -- something I didn't realize I wanted until I made the switch and not...

Dave pointed out that I didn't complete one aspect of my argument on the push_back vs. emplace_back: On Thu, Dec 29, 2016 at 2:04 PM Chandler Carruth <chandlerc at gmail.com> wrote: > Still another way to see the consequence of this is to look at the nature > of compiler errors when a programmer makes a mistake. > > With emplace_back, if you fail to call the constructor

...contributor to run clang-tidy instead of listing things that contributor should change. We are a little far from having mandatory running of clang-format and clang-tidy on every patch automatically. - About workflow (Dave) If I remember correctly there is some integration for clang-tidy for vim (YCM?). There is also clang-tidy-diff, but maybe we should have git-clang-tidy to make it even simpler. 2016-12-29 23:19 GMT+01:00 Chandler Carruth via cfe-dev < cfe-dev at lists.llvm.org>: > Dave pointed out that I didn't complete one aspect of my argument on the > push_back vs. empl...

...ipt I put together >> [2], although I haven't committed anything other than a testing commit >> [3]. >> >> All I can say is, *wow* is it nice. I hid everything I don't care >> about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] >> [6], ycm [7]) suddenly work better now that there isn't an artificial >> boundary between my clang and llvm repositories. I can have patch >> queues that include LLVM commits and clang commits arbitrarily >> interspersed with one another -- something I didn't realize I wanted >...

...gt;> [2], although I haven't committed anything other than a testing commit >>> [3]. >>> >>> All I can say is, *wow* is it nice. I hid everything I don't care >>> about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5] >>> [6], ycm [7]) suddenly work better now that there isn't an artificial >>> boundary between my clang and llvm repositories. I can have patch >>> queues that include LLVM commits and clang commits arbitrarily >>> interspersed with one another -- something I didn't realize I...

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately end up in SVN. Our SVN is a effectively a

> The only thing a monorepo gets you that strictly isn’t possible without > it is the ability to commit to multiple projects in a single commit. > Personally I don’t think that is a big enough justification, but that is > my opinion, not a fact. Okay, I just bumped into r277008, in which commits to llvm, clang, and clang-tools-extra all have the same SVN revision number. I don't

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some