search for: downstreams

Hello R list, This is a question for anyone who has used the by() command. I would like to perform a regression on a data frame by several factors. Using by() I think that I have able to perform this using the following: > lm.r <- by(master, list(Sectionf=Sectionf, startd=startd), function(x) lm (tot.c ~ starttime, data = x)) So that is, I would like to perform separate regressions for

Building on the great work that James Knight did on migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple tool to take migrated downstream fork branches and zip them into a single history given a history containing submodule updates of subprojects [2]. With migrate-downstream-fork.py, one is left with a set of unrelated histories, one per subproject: llvm

On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > We're going to be doing the same probing process in nouveau for > determining downstream DP port capabilities, so let's deduplicate the > work by moving i915's code for handling this into a shared helper: > drm_dp_downstream_read_info(). > > Note that when we do this, we also do make some functional

On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote: > (adding Ville and Imre to the cc here, they might be interested to know about > this, comments down below) > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > > We're going to be doing the same probing process in nouveau for > >

ei tuka imam edin pf conf obache pravi mnogo nomera, kato se pusne parvoto koeto e dropva paketi, timeoutva po serverite i t.n.. i speed-a e mnogo baven, vijte ako nqkoi moje da otkrie generalna greshka da reply :) vapreki che ne e freebsd-specific :P ne sym go pisal az a i ne sam mnogo mnogo zapoznat s pf zatova ako nqkoi moje da pomogne e dobre doshyl :) btw moje i neshto ot tia opcii kato set

Hi Philip, While it's true we don't I think Valentin is reasonable in saying "hey, when people do this let's try to combine them if it makes sense". It's just being polite to everyone, especially if it doesn't risk the patches or upstream stability. I don't think there's a policy change being proposed, just a "hey, let's see what we can do in the

I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. So for me the question is more, are renaming changes worth downstream projects not

Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody

(adding Ville and Imre to the cc here, they might be interested to know about this, comments down below) On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > We're going to be doing the same probing process in nouveau for > > determining downstream DP port capabilities, so let's deduplicate the > > work

During that variable renaming debate, there was a discussion about discussion about doing things all at once, piecemeal or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. All I'm asking as a kindness if we could

On Fri, 2020-08-21 at 01:37 +0300, Imre Deak wrote: > On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote: > > (adding Ville and Imre to the cc here, they might be interested to know > > about > > this, comments down below) > > > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote:

Hi Mehdi! I think the value to upstream (of doing mass reformatting in fewer commits) has to do with the intrusion of nonfunctional commits into `git blame` kinds of research. Every line that someone touches for a formatting reason necessarily obscures the history of functional changes in that block of code. The fewer of those that people have to work around, the better. I admit this is a

> On 29 Jul 2016, at 19:19, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream

On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer (for instance it is fairly easy to maintain a read-only view of the existing individual git repo currently on

Folks, There has been enough discussion about keeping development downstream and how painful that is. Even more so, I think we all agree, is having downstream releases while tracking upstream releases, trunk and other branches (ex. Android). I have proposed "en passant" a few times already, but now I'm going to do it to a wider audience: Shall we sync our upstream release with the

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_downstream_read_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read

Hi there, At the end of last week we saw a number of commits go in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit* functions. For example: - https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_read_downstream_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read

He all, I've updated the downstream fork zipping tool that I posted about last November [1]. It is much improved in every way. The most important enhancements are: - Does a better job of simplifying history - Handles nested submodules - Will put non-submodule-update content in a subdirectory of the monorepo - Updates tags In addition there are plenty of the requisite bug fixes. The

> On May 11, 2016, at 9:16 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This is a long email :-) I've made some comments inline, but I'll > summarize my thoughts here: > > - I like to think that the major releases have been shipped on a > pretty reliable six-month schedule lately. So we have that going for > us :-) > > - It