similar to: S4 accessors

Hi All, Sorry if this has been covered before, but I couldn''t find a previous thread on the list that answered my question. Basically I''m creating a new record in a table like so: def create @myInstance = MyModel.new(params[:formVars]) @myInstance.save! end My question is: How do I then get the id of the newly created record within this create method? It seems like

It seems that if an S4 class has no slots it can't be instantiated because it is assumed to be virtual. Is there a way around this other than adding a do-nothing slot? A singleton would be OK, though is not essential. Problem: EmptyFitResult <- setClass("EmptyFitResult", representation=representation()) # also tried it without the second argument. same result. > e <-

Hi there, I''d like to choose between an "static" and "dynamic" access of a reference class field, say ''a''. myObj <- getRefClass("Blabla")$new() Static: myObj$a Dynamic: myObj$a.get() where the function retrieves the data from a database (or some other location), stores it to a buffer and

Is there any good source of information on how S4 classes (and methods) work from C? E.g., for reading how to read a slot value how to invoke a method how to test if you have an s4 object For writing, how to make a new instance of an S4 object. I've found scattered hints in the archive, including a link to a talk on this subject "I am using C code to create an S4 object based on

setClass("B", representation=representation("B", extra="numeric)) setClass("B", representation=representation(extra="numeric"), contains="B") Are these the same? If not, how do they differ? What about setClass("B", representation=representation("B", extra="numeric"), contains="B") ? As far as I can

I haven't found much on S4 class redefinition; the little I've seen indicates the following is to be expected: 1. setClass("foo", ....) 2. create objects of class foo. 3. execute the same setClass("foo", ...) again (source the same file). 4. objects from step 2 are now NULL. Is that the expected behavior (I ran under R 2.7.1)? Assuming it is, it's kind of

I tried the following (relevant excerpt only) setMethod("likelihood", signature(spec="Specification", covs="vector", states="vector"), function(spec, covs, states) { #### setMethod("likelihood", signature(model="Model", path="matrix"), function(model, path) { This

Ticket 4052 (http://dev.rubyonrails.org/ticket/4052) just came through trac, which introduces the need for a better way to access fixtures. I believe the basic problem is the same as 3935 (http://dev.rubyonrails.org/ticket/3935) in that the accessor method which is constructed by the fixture call can''t infer the class name from the table name. The band-aid in 3935 was to allow you to

On Tue, Apr 07, 2015 at 02:15:52PM +0200, Greg Kurz wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument to some 3-value enum, this

On Tue, Apr 07, 2015 at 02:15:52PM +0200, Greg Kurz wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument to some 3-value enum, this

On Fri, Apr 10, 2015 at 12:16:20PM +0200, Greg Kurz wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument to some 3-value enum, this

On Fri, Apr 10, 2015 at 12:16:20PM +0200, Greg Kurz wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument to some 3-value enum, this

Virtio fs is modern-only. Use LE accessors for config space. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- fs/fuse/virtio_fs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c index 4c4ef5d69298..104f35de5270 100644 --- a/fs/fuse/virtio_fs.c +++ b/fs/fuse/virtio_fs.c @@ -606,8 +606,8 @@ static int

Virtgpu is modern-only. Use LE accessors for config space. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_kms.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c b/drivers/gpu/drm/virtio/virtgpu_kms.c index 0a5c8cf409fb..4d944a0dff3e 100644 ---

I'd like to have a class A that computes a likelihood, and a subclass B that computes the same likelihood by sometimes throws in an additional term (B includes measurement error). So B's likelihood needs to call A's, and then (sometimes) multiply by an additional term. It sounds as if, in the S3 scheme, NextMethod is supposed to do this: like.A <- function(stuff) compute value

Virtio input is modern-only. Use LE accessors for config space. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_input.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c index efaf65b0f42d..877b2ea3ed05 100644 --- a/drivers/virtio/virtio_input.c

Speed and duplex config fields depend on VIRTIO_NET_F_SPEED_DUPLEX which being 63>31 depends on VIRTIO_F_VERSION_1. Accordingly, use LE accessors for these fields. Reported-by: Cornelia Huck <cohuck at redhat.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 9 +++++---- include/uapi/linux/virtio_net.h | 2 +- 2 files changed, 6

http://libvirt.org/html/libvirt-libvirt.html#virDomainInfo http://libvirt.org/html/libvirt-libvirt.html#virVcpuInfo Both virDomainInfo and virVcpuInfo have a nanosecond cpuTime field. How do the two related to one another? With some experiementing, it appears the virDomainInfo::cpuTime is equal to the host CPU time used by the qemu-kvm process for the domain. It also appears that the

On Thu, 23 Apr 2015 17:29:06 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument

On Thu, 23 Apr 2015 17:29:06 +0200 Greg Kurz <gkurz at linux.vnet.ibm.com> wrote: > The current memory accessors logic is: > - little endian if little_endian > - native endian (i.e. no byteswap) if !little_endian > > If we want to fully support cross-endian vhost, we also need to be > able to convert to big endian. > > Instead of changing the little_endian argument