similar to: RFC: Deleting git-svn folder (git-llvm, git-svnrevert, git-svnup)

Giving at least one explicit: Sounds good to me. On Mon, May 4, 2020 at 12:01 PM Zola Bridges via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Here is a link to the patch: https://reviews.llvm.org/D79348 > > Zola Bridges > > > On Mon, May 4, 2020 at 11:50 AM Zola Bridges <zbrid at google.com> wrote: > >> Hi everyone, >> >> I would like to

I was actually using `git llvm` in my daily workflow. Could you explain why we want people to move away from that script? In addition to the convenience, it prevented me from accidentally creating a new branch (which I did before with push once). Cheers,   Johannes On 5/11/20 11:43 AM, Zola Bridges via llvm-dev wrote: > Deleted this morning. Thanks! > Zola Bridges > > > On

Just push :) On Tue, May 12, 2020, 8:46 AM Hiroshi Yamauchi <yamauchi at google.com> wrote: > I was also using "git llvm push" to commit, sort of out of habit. What's a > recommended, alternative way to push? > > On Mon, May 11, 2020 at 11:57 AM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I was actually using `git

@Zola, Eric, I really feel the communication and reasoning here is problematic. From my perspective, you removed stuff "we don't need", ignoring whether it is used, and then let people figure out how to deal with the result. What I most dislike about the process most is how questions and concerns are then ignored or played down. Thanks,   Johannes On 5/12/20 2:10 PM,

TBH, all I initially asked for, still ask for, is a reason why `git llvm` was being removed. Your email was the only one that hinted on a reason. (more below) On 5/12/20 4:00 PM, David Blaikie wrote: > On Tue, May 12, 2020 at 1:50 PM Johannes Doerfert via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> @Zola, Eric, >> >> >> I really feel the

FWIW, I'm not against people using the script if there's a good reason for it, but I'd be somewhat opposed to mandating it, as that could easily get confusing for people like me who work in both downstream and upstream repos who wouldn't want to use the scripts downstream - it would be fairly straightforward to forget to use it/use it incorrectly, and depending on what the script

Hi Zola, thanks for the response. People brought forth reasons why we should not have git scripts in the repo. I'm not sure about that but as long as we don't see other people coming forward, we don't need it in the repo. I can have a private copy after all. Thanks again,   Johannes On 5/15/20 2:16 PM, Zola Bridges via llvm-dev wrote: > Hey everyone, > > I missed

For some reason this thread seems to be gone in a wrong direction. I'm sorry for that. The discussion on the RFC asked for a reason to keep the script, I think we heard reasons to do so (due to branches). Now, I was unable to determine if the `git llvm` scripts was removed "just as part of the bunch" or if we expect a problem with the script. If it is the former, are there

Another thing to consider about your feature idea is that the output may be noisy depending on what you were hoping for. SLH tries to mitigate anything that could potentially be a problem and thus it instruments almost every branch, load, and function entry, for example. There isn't a lot of signal about what is really a gadget among the code instrumented by SLH. It really tries to be

I'm also a bit unclear on that point. I think one input here has to be: what are some example, existing codebases we want to mitigate, and what should the user experience be to mitigate them? I don't think we can make good engineering tradeoffs without having concrete use cases to evaluate. Another point: it seems some mitigation options have already been added to the GNU toolchain

Hi everyone, I followed up with some folks at Google about how we wanted to be involved in this group and we decided that Matthew Riley (mattdr at google.com) would be the right person to be involved here. Sorry about the confusion. I'd like to withdraw my request. Thanks again to everyone involved! I'm glad to see this becoming a part of how LLVM works. :) Zola Bridges On Wed, Jun

Hi everyone! I want to clarify the purpose and design of SESES. Thus far, I've characterized it as an LVI mitigation which is somewhat incorrect. SESES was built as a "big hammer." It is intended to protect against many side channel vulnerabilities (Spectre v1, Spectre v4, LVI, etc, etc) even though it was built in response to LVI. For folks protecting against LVI, this is an

Hi everyone, Some Intel processors have a newly disclosed vulnerability named Load Value Injection. One pager on Load Value Injection: https://software.intel.com/security-software-guidance/software-guidance/load-value-injection Deep dive on Load Value Injection: https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection I wrote this compiler pass that can

Thanks Zola, I’d rather have point-contact people, instead of having mailing lists. I have a few goals with this: Listing particular people makes it clear who’s on the hook from your organization These people can still communicate internally, but are responsible to ensure that the internal folks know what the LLVM process and disclosure restrictions are Listing a limited number of specific people

Hi I think llvm-dev list (CC'ed) have more visibility in this. On Wed, 22 Apr 2020 at 22:18, milsegv via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Hello everyone, > > It may not be the best place to ask this but I found nothing on the > internet about it. > I'm working on Spectre V1 detection and stumbled upon the mitigation > provided by clang, the

Great idea! Sign me up, please! On Fri, 12 Jun 2020 at 16:59, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Great! On the Apple side, we’ll propose Oliver Hunt (clang team) and Scotty Bolin (product security team), CC’ed to this email. > > > On Jun 12, 2020, at 6:50 AM, Kristof Beyls <Kristof.Beyls at arm.com> wrote: > > Thank you for progressing

Note though that this has been put on hold on stats.stackexchange.com as off-topic. On 23/06/2017 19:33, Bert Gunter wrote: > Probably the wrong list. R-help is concerned with R programming, not > statistics methodology questions, although the intersection can be > nonempty. > > I suggest you post on stats.stackexchange.com instead, which *is* > concerned with statistics

What is the best way to change my R code to be able to compare the pooled proportions(complication and reoperation rates) with the Chi square method? Verstuurd vanaf mijn iPhone > Op 24 jun. 2017 om 14:18 heeft Michael Dewey <lists at dewey.myzen.co.uk> het volgende geschreven: > > Note though that this has been put on hold on stats.stackexchange.com as off-topic. > >>

> On Jun 23, 2017, at 5:53 AM, Jay Zola <jayjay.1988 at hotmail.nl> wrote: > > Dear sir/madame, > > > I am currently writing a meta-analysis on the complication and reoperation rates of 5 different treatment modalities after a distal radius fracture. I was able to pool the rates of the 5 different rates using R. Now I have to compare the pooled rates of the 4 treatment

The code in your mail in a mangled mess, since you posted in HTML. Please configure your email client to send emails in plain text. Could you explain what exactly you mean by "Currently it is using a mixed effects model. Is it possible to change the code so a random effects model is used?" Best, Wolfgang >-----Original Message----- >From: R-help [mailto:r-help-bounces at