search for: cortinas

Dear all, I'm using R-2.5.0. If I type: > load("C:\\Data1\\.RData") I get: Error in load("C:\\Data1\\.RData") : ReadItem: unknown type 63, perhaps written by later version of R Any idea why? Many thanks, Mario Dr Mario Cortina Borja; Senior Lecturer in Statistics MRC Centre of Epidemiology for Child Health, Institute of Child Health,

Please, how to fill the area under the curve? x <- c(1:10) y <- c(rnorm(10)) plot(x,y) lines(x,y) Thanks, Mauricio Cardeal

Hello, this is quite a minor issue but as summary() is in all likelihood one of the most widely used functions in R I decided to email this list. When producing a count of missing values, summary() in English generates an unnecessary and grammatically incorrect apostrophe (NA's rather than NAs) in its table header. For example: > summary(c(1,2,NA,3,4,NA)) Min. 1st Qu. Median Mean

Dear List, In documents (Therneau, 2003 : On mixed-effect cox models, ...), as far as I came to know, coxme penalize the partial likelihood (Ripatti, Palmgren, 2000) where as frailtyPenal (in frailtypack package) uses the penalized the full likelihood approach (Rondeau et al, 2003). How, then, coxme and coxph(...frailty(id, dist='gauss')) differs? Just the coding algorithm, or in

Hello everybody, I use the sweetpotato database included in R package: data(sweetpotato) This dataset contains two variables: yield(continous variable) and virus(factor variable). Due to Levene test is significant I cannot assume homogeneity of variances and I apply Welch test in R instead of one-way ANOVA followed by Tukey posthoc. Nevertheless, the problems come from when I apply posthoc

On Mon, 02 June 2014 Bruno Pr?mont <bonbons at linux-vserver.org> wrote: > With commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") > Matthew Garrett introduced a efifb vga_default_device() so that EFI > systems that do not load shadow VBIOS or setup VGA get proper value for > boot_vga PCI sysfs attribute on the corresponding PCI device. > > Xorg

This series add two important features. One of them changes the .ndo_tx_timeout to include an extra parameter to identify the stuck queue. Many drivers are using a nester loop to identify which queue is stooped/stucked. This is a redundant work since dev_watchdog is doing exactly the same thing. This is so interesting for other drivers to in terms of code optimization. The second part (second

This series add two important features. One of them changes the .ndo_tx_timeout to include an extra parameter to identify the stuck queue. Many drivers are using a nester loop to identify which queue is stooped/stucked. This is a redundant work since dev_watchdog is doing exactly the same thing. This is so interesting for other drivers to in terms of code optimization. The second part (second

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

Sorry about the churn, v10 was based on net - not on net-next by mistake. A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

Sorry about the churn, v10 was based on net - not on net-next by mistake. A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

Yet another forward declaration I missed. Hopfully the last one ... A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only.

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

A bunch of drivers want to know which tx queue triggered a timeout, and virtio wants to do the same. We actually have the info to hand, let's just pass it on to drivers. Note: tested with an experimental virtio patch by Julio. That patch itself isn't ready yet though, so not included. Other drivers compiled only. Michael S. Tsirkin (3): netdev: pass the stuck queue to the timeout

Em qua., 27 de nov. de 2019 ?s 12:12, Martin Habets <mhabets at solarflare.com> escreveu: > > Your @work correctly identifies that the drivers/net/ethernet/sfc drivers need patching, but the actual patches for them are missing. > Please add those. Makes me wonder if any other files are missing patches. Since, I'm adding new stuffs to virtion_net (2/2), I will split this into a

On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > Hi Michael, > > Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin > <mst at redhat.com> escreveu: > > > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco wrote: > > > Driver virtio_net is not handling error events for TX provided by > > > dev_watchdog. This event is

Em sex., 22 de nov. de 2019 ?s 11:53, Michael S. Tsirkin <mst at redhat.com> escreveu: > > On Fri, Nov 22, 2019 at 09:59:58AM -0300, Julio Faracco wrote: > > Hi Michael, > > > > Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin > > <mst at redhat.com> escreveu: > > > > > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco

Hi Michael, Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin <mst at redhat.com> escreveu: > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco wrote: > > Driver virtio_net is not handling error events for TX provided by > > dev_watchdog. This event is reached when transmission queue is having > > problems to transmit packets. This could happen for any

Hi Michael, Em sex., 22 de nov. de 2019 ?s 07:31, Michael S. Tsirkin <mst at redhat.com> escreveu: > > On Thu, Nov 21, 2019 at 10:36:36PM -0300, Julio Faracco wrote: > > Driver virtio_net is not handling error events for TX provided by > > dev_watchdog. This event is reached when transmission queue is having > > problems to transmit packets. This could happen for any

This allows incrementing the correct timeout statistic without any mess. Down the road, devices can learn to reset just the specific queue. The patch was generated with the following script: use strict; use warnings; our $^I = '.bak'; my @work = ( ["arch/m68k/emu/nfeth.c", "nfeth_tx_timeout"], ["arch/um/drivers/net_kern.c", "uml_net_tx_timeout"],