search for: unintrus

Dear fellow CentOS users, for my few hobby projects (web games + forums) I have been using CentOS 5 (then 6) with Drupal and PostgreSQL plus few custom PHP and Perl scripts written by mysef. Since PostgreSQL version delivered with CentOS package has been a bit dated, I always used the PGDG packages: # rpm -qa | grep -i pgdg pgdg-centos93-9.3-1.noarch

Hello, I just subscribed to the list to join the discussion after being blindsided by the change and reading Dirk Eddelbuettel's reply to my bug report at https://bugs.debian.org/866768 . As far as I can tell the advantages of site library are: 1. Saves disk space and a little bit of user time spent installing and upgrading. 2. Other Debian package manages, like pip, default?to

...raries are not version specific, even though in the case of R 3.0.0 and 3.4.0 compatibility was interrupted. > So maybe the change was too abrupt, and I think I may revert it. I > generally prefer for packagers like myself to not divert from upstream > unless they have good reasom or are unintrusive (and eg the added > tab-completion we have here is both). But leaving newbies without > installable directories is bad, as is possibly hiding existing > installations. I also like the idea of multiuser libraries, and in general the idea is that the most current package versions play...

...ss than ideal as well. But it ensures > writeability. Which I cannot do easily from the package. > > > So maybe the change was too abrupt, and I think I may revert it. I > generally prefer for packagers like myself to not divert from upstream > unless they have good reasom or are unintrusive (and eg the added > tab-completion we have here is both). But leaving newbies without > installable directories is bad, as is possibly hiding existing > installations. There are several entangled issues: 1. What should be the default places where packages are installed? 2. What should...

Hello, This patch implements cross-block dead store elimination for a simple scenario -- which was somehow important in my case --, i.e. when a store has only one memory dependence in a function. This patch is a bit narrow-minded (e..g, only store instructions are checked for memory dependencies), but I can always make it more generic, if you give me pointers *and* my code is correct. Cheers,

Hi Gianluca, did you look at Jakub Staszak's "Non-local DSE" patch he posted to the mailing list a while ago? Ciao, Duncan.

...d in a versioned directory less than ideal as well. But it ensures writeability. Which I cannot do easily from the package. So maybe the change was too abrupt, and I think I may revert it. I generally prefer for packagers like myself to not divert from upstream unless they have good reasom or are unintrusive (and eg the added tab-completion we have here is both). But leaving newbies without installable directories is bad, as is possibly hiding existing installations. I am a little pressed for time (at useR!) and system (main server is ill, as is backup machine) but I should get a 3.4.1-2 out. I...

...ensures > > writeability. Which I cannot do easily from the package. > > > > > > So maybe the change was too abrupt, and I think I may revert it. I > > generally prefer for packagers like myself to not divert from upstream > > unless they have good reasom or are unintrusive (and eg the added > > tab-completion we have here is both). But leaving newbies without > > installable directories is bad, as is possibly hiding existing > > installations. > > There are several entangled issues: > 1. What should be the default places where packages...

...;m under the impression most people use gold or lld > to link LLVM these days, so it isn't clear to me how big of a problem > this is. > For the record, the problem reproduces under 2.24, which is shipped by Ubuntu 14.04 LTS, which isn't that old. My view is that if we can find an unintrusive enough workaround, we should deploy it (with a comment to remove it after N years). Peter > > Peter > > > > > > > >> > >> > >> > >> > >> > >>> > >>> Peter > >>> > >>> > >...

...;> to link LLVM these days, so it isn't clear to me how big of a problem >>> this is. >>> >> >> For the record, the problem reproduces under 2.24, which is shipped by >> Ubuntu 14.04 LTS, which isn't that old. My view is that if we can find an >> unintrusive enough workaround, we should deploy it (with a comment to >> remove it after N years). >> >> Peter >> >> >>> > Peter >>> > >>> > >>> > >>> >> >>> >> >>> >> >>> >...

...bility. Which I cannot do easily from the package. > > > > > > > > > So maybe the change was too abrupt, and I think I may revert it. I > > > generally prefer for packagers like myself to not divert from upstream > > > unless they have good reasom or are unintrusive (and eg the added > > > tab-completion we have here is both). But leaving newbies without > > > installable directories is bad, as is possibly hiding existing > > > installations. > > > > There are several entangled issues: > > 1. What should be the...

Hi all, >> In other words, the dhcp server has to start the client on the >> correct binary for it's arch and by virtue of running different bins, >> we can determine the most appropriate config file for the client? > > That is definitely one way to deal with it. > > There is no way around the fact that you have to have different binaries > for different

On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Thu, Aug 24, 2017 at 3:20

Any idea why this calculates the integer the way it does? irb> ("291.15".to_f * 100.0).to_i => 29114 Thanks, Tom -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to

...n be used by custom VM implementation to make GPU objects allocated via TTM appear contiguous in the IOMMU space, allowing us to maximize the use of large pages and improve performance, but that part will come once the basic support is agreed on and merged. All in all this series should be largely unintrusive for non-Tegra GPUs, with only patch 1 changing common code parts, in a way that looks safe. Alexandre Courbot (6): make RAM device optional instmem/gk20a: move memory allocation to instmem gk20a: remove RAM device instmem/gk20a: use DMA attributes platform: probe IOMMU if present in...

...n be used by custom VM implementation to make GPU objects allocated via TTM appear contiguous in the IOMMU space, allowing us to maximize the use of large pages and improve performance, but that part will come once the basic support is agreed on and merged. All in all this series should be largely unintrusive for non-Tegra GPUs, with only patch 1 changing common code parts, in a way that looks safe. Alexandre Courbot (6): make RAM device optional instmem/gk20a: move memory allocation to instmem gk20a: remove RAM device instmem/gk20a: use DMA attributes platform: probe IOMMU if present in...

...n be used by custom VM implementation to make GPU objects allocated via TTM appear contiguous in the IOMMU space, allowing us to maximize the use of large pages and improve performance, but that part will come once the basic support is agreed on and merged. All in all this series should be largely unintrusive for non-Tegra GPUs, with only patch 1 changing common code parts, in a way that looks safe. Alexandre Courbot (6): make RAM device optional instmem/gk20a: move memory allocation to instmem gk20a: remove RAM device instmem/gk20a: use DMA attributes platform: probe IOMMU if present in...

...n be used by custom VM implementation to make GPU objects allocated via TTM appear contiguous in the IOMMU space, allowing us to maximize the use of large pages and improve performance, but that part will come once the basic support is agreed on and merged. All in all this series should be largely unintrusive for non-Tegra GPUs, with only patch 1 changing common code parts, in a way that looks safe. Alexandre Courbot (6): make RAM device optional instmem/gk20a: move memory allocation to instmem gk20a: remove RAM device instmem/gk20a: use DMA attributes platform: probe IOMMU if present in...