search for: bumping

Hi everyone, Finally figured out how to use the X.Org automatic submission script after realizing that I had to change the script in order for OpenChrome DDX to build in the first place. OpenChrome DDX Version 0.6 has added the following new features. - First official support for CX700, VX700, and VX800 chipsets integrated TMDS transmitter (i.e., DVI support) - Initial support for Silicon

On 03/25/2020 06:20 AM, Louis Dionne wrote: > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com> wrote: >> >> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: >>> In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we

On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev < llvm-dev at lists.llvm.org wrote: > [ Consider all of this to be preferences, not anything close to an > objection. ] > > Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > There haven't been many more responses in the last few days, so can we > > try to come to some kind of

On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote: > In October, there was a discussion about updating CMake to 3.15: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html. No decision was made, but maybe we should revisit that proposal? If we're going to require a newer version of CMake for some subprojects, I'd prefer to bump the minimum CMake version for all of LLVM.

> On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com> wrote: > > On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 03/25/2020 06:20 AM, Louis Dionne wrote: > > > > > >> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com

...s at lists.llvm.org> On Behalf Of Louis Dionne via llvm-dev > Sent: Wednesday, March 25, 2020 10:14 AM > To: Nikita Popov <nikita.ppv at gmail.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Libc++ Dev <libcxx-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi > > > > > On Mar 25, 2020, at 13:07, Nikita Popov <nikita.ppv at gmail.com <mailto:nikita.ppv at gmail.com>> wrote: > > On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org &l...

Hi, The minimum CMake version currently advertised for libc++ and libc++abi is currently 3.4.3. I think the oldest version of CMake actually being tested on any builder is 3.7.0, so advertising 3.4.3 is somewhat of a lie (I'm pretty sure we're using features that require a more recent version already). However, we do need to bump it to 3.8.0 at least because CMake 3.7 doesn't know

...y (i.e. bitcode does not have a linear versioning that is regularly bumped) but instead make sure the encoding itself allows an easy upgrade. I.e. the encoding of the FMF should have been such that the reader can detect and upgrade to the new IR representation. Now this is too late here I guess, so bumping may be a possible trade-off. What about any bitcode shipped after r317488 but before the version bump? Not worth taking into account because of the short period of time? Best, -- Mehdi > > > * Feedback Needed * > > I believe this change is big enough that it would be worth bumpi...

...etreault <ctetreau at quicinc.com> Date: Thursday, March 26, 2020 at 2:06 PM To: "ldionne at apple.com" <ldionne at apple.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Libc++ Dev <libcxx-dev at lists.llvm.org> Subject: Re: [llvm-dev] Bumping the CMake requirement for libc++ and libc++abi Wanting to use new features is a good reason to upgrade. You say you need 3.8 in order to compile C++17 code, which is needed by your subproject. This is a good reason to upgrade the version. The proposed policy of bumping the CMake minimum version pe...

...sure that when we do break API, that we refuse to load a filter compiled against one version of nbdkit with another server running a different API. A single bump once per stable release is good enough (rather than once per API change). We did this correctly for commits b0ce4411/cb309687/df0cc21d (bumping to API version 2 for the combined changes between v1.2 and v1.4), but failed to do so for f184fdc3 (affecting v1.10), 4ca66f70 (affecting v1.12), or 5ee7bd29/ee61d232 (affecting the upcoming v1.14). So do it retroacively now, as well as backporting intermediate bumps to affected stable branches....

Hi there, I would like to make a 'bumps chart' like the ones described e.g. here: http://junkcharts.typepad.com/junk_charts/bumps_chart/ Purpose: I'd like to plot the proportion of people in select countries living for less then one USD pr day in 1994 and 2004 respectively. I have already constructed a barplot - but I think a bumps chart would be better # The barplot and data

...on “downgrade" situation. #1 means that any code that uses unsafeMath is going to get a performance hit. In other words, one scenario implies generating wrong code and the other, runtime performance regressions. * Feedback Needed * I believe this change is big enough that it would be worth bumping the bitcode version so that the upgrader can do the right thing *before* we release it to the public with LLVM-6.0. That being said, I don’t know what are the implications of such bump and if people really don’t care about the performance problem that might be okay. The silent downgrade path is ho...

...k API, that we refuse to load a filter compiled against one > version of nbdkit with another server running a different API. A > single bump once per stable release is good enough (rather than once > per API change). > > We did this correctly for commits b0ce4411/cb309687/df0cc21d (bumping > to API version 2 for the combined changes between v1.2 and v1.4), but > failed to do so for f184fdc3 (affecting v1.10), 4ca66f70 (affecting > v1.12), or 5ee7bd29/ee61d232 (affecting the upcoming v1.14). So do it > retroacively now, as well as backporting intermediate bumps to > af...

.... bitcode does not have a linear versioning that is regularly bumped) but instead make sure the encoding itself allows an easy upgrade. I.e. the encoding of the FMF should have been such that the reader can detect and upgrade to the new IR representation. > Now this is too late here I guess, so bumping may be a possible trade-off. Do you think we should do it, or live with the performance drop? I know this performance drop is not acceptable for our use cases, but I don’t want to impose our ruling on this. > What about any bitcode shipped after r317488 but before the version bump? Not worth...

Compiz 0.8.4 is released! This is the second stable release of Compiz 0.8 series. This release brings two new plugins, translation updates, many bug fixes, improved stability, and better screen resolution change handling. Also included is additional integration work for KDE 4. In particular, window thumbnails are now supported in Plasma window tooltips with the new KDE compatibility plugin, the

...hat any code that uses unsafeMath is going to get a performance > hit. > > In other words, one scenario implies generating wrong code and the other, > runtime performance regressions. > > > * Feedback Needed * > > I believe this change is big enough that it would be worth bumping the > bitcode version so that the upgrader can do the right thing *before* we > release it to the public with LLVM-6.0. > > That being said, I don’t know what are the implications of such bump and > if people really don’t care about the performance problem that might be > okay. Th...

...eans that any code that uses unsafeMath is going to get a performance hit. > > In other words, one scenario implies generating wrong code and the other, runtime performance regressions. > > > * Feedback Needed * > > I believe this change is big enough that it would be worth bumping the bitcode version so that the upgrader can do the right thing *before* we release it to the public with LLVM-6.0. > > That being said, I don’t know what are the implications of such bump and if people really don’t care about the performance problem that might be okay. The silent downgrade...

Op 2013-12-11 om 02:09 schreef syslinux-bot for Matt Fleming: > Commit-ID: 5e59ac11d6d105591d6da742750ea2f804534d43 > Gitweb: http://www.syslinux.org/commit/5e59ac11d6d105591d6da742750ea2f804534d43 > Author: Matt Fleming <matt.fleming at intel.com> > AuthorDate: Wed, 11 Dec 2013 10:03:13 +0000 > Committer: Matt Fleming <matt.fleming at intel.com> >

...unsafeMath is going to get a performance hit. >> >> In other words, one scenario implies generating wrong code and the other, runtime performance regressions. >> >> >> * Feedback Needed * >> >> I believe this change is big enough that it would be worth bumping the bitcode version so that the upgrader can do the right thing *before* we release it to the public with LLVM-6.0. >> >> That being said, I don’t know what are the implications of such bump and if people really don’t care about the performance problem that might be okay. The silent do...

Hello! I'm using NVIDIA GeForce GT 640M. And beginning with this commit: commit 142c21b8d493318551932eee2e9d98ff14b473da Author: Christoph Bumiller <e0425955 at student.tuwien.ac.at> Date: Wed Mar 27 22:25:52 2013 +0100 drm/nouveau/drm: bump the driver version to 1.1.1 to report new features till the latest kernel 3.15-rc5 OpenArena game looks like this: