search for: barly

I''m trying to figure out how to design a view and controller to work with a simple collection. I have a Foo that has many Bars, so here''s what I did: $ ruby script/generate model Foo $ ruby script/generate model Bar (Uncomment t.column, :name: :string in foo and bar migrations) (Edit Foo.rb and Bar.rb, add has_many :bars to Foo, belongs_to :foo to Bar) $ rake db:migrate $ ruby

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

Dear R-helpers, I've got two functions; callTimes() calls times(), passing it an optional argument (bar) by name (bar=harry). times() then believes it has been passed a name, rather than a value ? but I want the value, not the name. Worse, if I evaluate the name, it is evaluated in the environment times() was defined, not where it is called. How can I call times(), defining its optional

Hi all, I expect I'm getting something wrong, but cat("foo bar baz foo bar baz foo bar baz", fill = 10) should be broken into lines of width 10, whereas I get: > cat("foo bar baz foo bar baz foo bar baz", fill = 10) foo bar baz foo bar baz foo bar baz This is on R 3.4.3, but I don't see mentions of it fixed in 3.4.4 or r-devel NEWS. Cheers, David

Just wondered about this curious behaviour. I'm trying to learn about classes. Basically setMethod works the first time, but does not seem to work the second time. Faheem. ************************************************************************* setClass("foo", representation(x="numeric")) bar <-

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

Greetings! I've ran into a couple difficulties for a particular rsync use-case I'm involved in implementing - hoping someone here might be able to clue me in! I've got an existing linux box, with a particular directory that needs to be mirrored onto another server, into a different base path on that server - i.e.: server1:/var/lib/bar/ to server2:/backupdir/var/lib/bar/ Now,

Dear R-users, I want to draw a barplot with beside=TRUE. One halve of the bars are drawn with a border, while the other halve are drawn without a border (i.e. filled bars vs. non-filled bars next to each other). Because borders are drawn around the bars, doing this leads to one halve of the bars being wider than the other halve, expanding across the 0-point of the y-axis. This problem emerges

I recommend instead of no border, that you use a border with the same color as the fill. I do this in the likert functions in the HH package. Rich On Mon, May 21, 2018 at 10:59 AM, Martin Batholdy via R-help <r-help at r-project.org> wrote: > Dear R-users, > > I want to draw a barplot with beside=TRUE. > One halve of the bars are drawn with a border, while the other halve are

Hi, I know S manuals used to warn against using the same names for a variable and a function, but I have never seen that cause problems in R, so I usually don't pay much attention to it. Which is why the following behaviour came as a surprise: > bar <- function() 1 > foo <- function(bar = bar()) { + bar + } > foo(9) [1] 9 > foo() Error in foo() : recursive default

Hello, R 2.3.0 Windows XP I have spent quite a bit of time trying to resolve my problem below, which included a R site search. The "vertical bars" syntax below produces a vertical bar chart with the values displayed above each bar. I want to cast this graphic horizontally, but I have not been able to arrive at a suitable outcome. The best I have been able to do, using the second block

[Was initially posted on cfe-users, sorry.] Hi, I'm sorry my message is quite long, the TL;DR version is "g++ and clang++ seem to have different opinions on how RTTI, templates, and ELF visibility should interact". I can't tell whether this is a bug or not: I have found no relevant documentation that could help me decide whether this behavior is meant, or not. All I can say

Some BARs (like GK20A's) do not support being ioremapped write-combined. Add a boolean property to the BAR structure and handle that case in the Nouveau BO implementation. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/include/subdev/bar.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_bo.c | 17 ++++++++++++----- 2 files changed, 15

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101

I have a seasonal time series. I want to calculate the annual mean value of the time series at its peak (say the mean of the three values before the peak, the peak, and the three values after the peak). The peak of the time series might change cycle slightly from year to year. # E.g., nPts <- 254 foo <- sin((2 * pi * 1/24) * 1:nPts) foo <- foo + rnorm(nPts, 0, 0.05) bar <- ts(foo,

Currently it is assumed PCI device BAR access < 4G memory. If there is such a device whose BAR size is larger than 4G, it must access > 4G memory address. This patch enable the 64bits big BAR support on hvmloader. v3 changes from v2: - Remain original print information v2 changes from v1 as comments by Jan. 1) Set Dynamic MMIO high memory address instead of a fixed number 640G 2) Mask

On Mon, 15 Dec 2014, Michael S. Tsirkin wrote: > From: Michael S Tsirkin <mst at redhat.com> > > Virtio drivers should map the part of the range they need, not > necessarily all of it. > To this end, support mapping ranges within BAR on s390. > Since multiple ranges can now be mapped within a BAR, we keep track of > the number of mappings created, and only clear out the

On Mon, 15 Dec 2014, Michael S. Tsirkin wrote: > From: Michael S Tsirkin <mst at redhat.com> > > Virtio drivers should map the part of the range they need, not > necessarily all of it. > To this end, support mapping ranges within BAR on s390. > Since multiple ranges can now be mapped within a BAR, we keep track of > the number of mappings created, and only clear out the

All, I have a question regarding colors in bar plots. I want to stack a total of 18 cost values in each bar. Basically, it is six cost types and each cost type has three components- direct, indirect, and induced costs. I would like to use both solid color bars and bars with the slanted lines (using the density parameter). The colors would distinguish cost types and the lines would

Hello, I wonder why there is a difference in how llvm-gcc compiles .c and .cpp files. Example: ---bar.cpp---- int bar() { return 42; } -------------- $ llvm-gcc -emit-llvm -c bar.cpp Now running bar.o through llvm-dis gives: -------------------------------- define i32 @_Z3barv() nounwind { < clip > } -------------------------------- Above, function 'bar' has been renamed