search for: segs

Hi All.., I need to do the following repetitive jobs: seg71 <- read.csv("C:/Awork/geneAssociation/removed8samples/neuhausen71/seg.pr3.csv", head=T) seg71$id <-"sn71" seg72 <- read.csv("C:/Awork/geneAssociation/removed8samples/neuhausen72/seg.pr3.csv", head=T) seg72$id <-"sn72" seg73 <-

From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> This patch handle additional cases for IVRS bugs where special->handle is not correctly initialized for IOAPIC and HPETS due to firmware bugs. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Provide logic in "is_ioapic_overidden()" Signed-off-by: Jan Beulich <JBeulich@suse.com> ---

Dear, I am trying to visualise a time-progressing line (it's supposed to represent spread patterns) using brew package and Google Earth. The idea is to have a function which takes start and end point geographic coordinates, as well as number of intervals to chop the path up, and returns the collection of points segmenting this line. Unfortunately my calculations fail for large distances,

Data and code as promised: #Creating a test dataset Year<- c(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014) Lake1<- c(2, 4, 5, 2, 1, 1, 2, 3, 4, 5, 6, 2, 3, 1, 2) Lake2<- c(1, 3, -1, 4, -2, 1, 2, 3, 4, 5, 6, 2, 3, 1, 2) Lake3<- c(1, 2, 5, -3, 1, 1, 2, 3, 4, 5, 6, 2, 3, 1, 2) Lake4<- c(1, 1, 1, 1, 1, 1, 1, 250, 240, 240, 240, 240, 240, 239,

On 5/22/2018 11:32 AM, Bailey Hewitt wrote: > Hi Bert, > > Thank you for the quick response! > > In its current?state?the code?prints three lines that say "warning". What I was expecting is that I would?get?a matrix with 4 columns, 1. column names (from the original data, ex. Lake1) 2. breakpoint year 3. slope 4. slope difference from the first to the?second segment of

Hello, The following might do it. Without data it's untested. wd <- function(i){ paste0("C:/Awork/geneAssociation/removed8samples/neuhausen7", i, "/seg.pr3.csv") } seg <- lapply(1:5, function(i) { DF <-read.csv(wd(i)) DF$id <- paste0("sn7", i) DF }) seg <- do.call(rbind, seg) row.names(seg) <- NULL Hope this helps,

Hi Bert, Thank you for the quick response!? In its current?state?the code?prints three lines that say "warning". What I was expecting is that I would?get?a matrix with 4 columns, 1. column names (from the original data, ex. Lake1) 2. breakpoint year 3. slope 4. slope difference from the first to the?second segment of the segmented regression. Each row in the matrix would be the results

Hello Ding, try this: seg <- list() for ( d in 71:75) { s <- paste0("seg",d) sn <- paste0("sn",d) Dir<-paste("C:/Awork/geneAssociation/removed8samples/neuhausen", i, sep="") setwd(Dir) seg[[s]] <- read.csv("seg.pr3.csv", head=T) seg[[s]]$id <- sn } Greetings, Albrecht -- Albrecht Kauffmann alkauffm at

...00921 *** SEGP2C.MI -9.869e-01 3.286e-01 -3.004 0.002669 ** SEGP2C.AI -1.306e+00 3.585e-01 -3.644 0.000269 *** SEGP2C.AA -1.743e+00 4.123e-01 -4.227 2.37e-05 *** [shortened] SEGP4C.ML -5.657e-01 2.990e-01 -1.892 0.058485 . SEGP4C.BL -2.908e-16 2.734e-01 -1.06e-15 1.000000 SEGSAX.MS 1.092e-01 2.700e-01 0.405 0.685772 SEGSAX.MAS -5.441e-16 2.734e-01 -1.99e-15 1.000000 SEGSAX.MA 7.130e-01 2.582e-01 2.761 0.005758 ** SEGSAX.ML 1.199e+00 2.565e-01 4.674 2.96e-06 *** SEGSAX.MP 1.313e+00 2.570e-01 5.108 3.26e-07 *** SEGSAX.MI 8.865e-01 2.56...

No. If your ouput is a numeric "matrix", it cannot include alpha. Columns in a data frame can be of different classes, but each column must be single class. and finally, of course, see ?cat -- I think you are misusing it. If you simply want to return "somestuff", your function should be: function(w) {"somestuff"} not function(w) {cat("somestuff")} As

IA-32 linear address translation is loads of fun. While cleaning up the LDT code, I noticed that kprobes code was very bogus with respect to segment handling. Many, many bugs are fixed here. I chose to combine the three separate functions that try to do linear address conversion into one, nice and working functions. All of the versions had bugs. 1) Taking an int3 from v8086 mode could cause

IA-32 linear address translation is loads of fun. While cleaning up the LDT code, I noticed that kprobes code was very bogus with respect to segment handling. Many, many bugs are fixed here. I chose to combine the three separate functions that try to do linear address conversion into one, nice and working functions. All of the versions had bugs. 1) Taking an int3 from v8086 mode could cause

Am I right in saying that first_sect & last_sect in blkif_request_segment are the relative sector numbers in the transfer? So if I wanted to transfer 9 sectors starting at 100, the resultant contents of the request would look like: req->sector_number = 100 req->seg[0].first_sect = 0 req->seg[0].last_sect = 3 req->seg[1].first_sect = 4 req->seg[1].last_sect = 7

Hey, Ferret is repeatedly seg-faulting my mongrel servers on the same line: /usr/local/lib/ruby/gems/1.8/gems/ferret-0.10.11/lib/ferret/index.rb:718: [BUG] Segmentation fault ruby 1.8.5 (2006-08-25) [i686-linux] I''m using ferret 0.10.11. I haven''t had the time to dig into yet, it''s on the backburner right now - I just keep several spare servers and restart them

...", + regs->errcode, regs->trapnum); + + lguest_dump_trace(vcpu, regs); +} + +struct guest_ksym_stuff { + unsigned long *addresses; + unsigned long num_syms; + u8 *names; + u8 *token_table; + u16 *token_index; + unsigned long *markers; +}; + +static struct lguest_text_ptr *get_text_segs(struct lguest_vcpu *vcpu) +{ + struct lguest_guest_info *linfo = vcpu->guest; + struct lguest_text_ptr *segs, **p; + struct lguest_text_ptr *g; + unsigned long addr; + int i; + + if (!linfo->lguest_data) + return NULL; + + addr = lhread_u64(vcpu, (u64)&linfo->lguest_data->text); +...

...", + regs->errcode, regs->trapnum); + + lguest_dump_trace(vcpu, regs); +} + +struct guest_ksym_stuff { + unsigned long *addresses; + unsigned long num_syms; + u8 *names; + u8 *token_table; + u16 *token_index; + unsigned long *markers; +}; + +static struct lguest_text_ptr *get_text_segs(struct lguest_vcpu *vcpu) +{ + struct lguest_guest_info *linfo = vcpu->guest; + struct lguest_text_ptr *segs, **p; + struct lguest_text_ptr *g; + unsigned long addr; + int i; + + if (!linfo->lguest_data) + return NULL; + + addr = lhread_u64(vcpu, (u64)&linfo->lguest_data->text); +...

Add some convenient segment macros to the kernel. This makes the rather obfuscated 'seg & 4' go away. Patch-keys: i386 segment cleanup Patch-base: 2.6.13-rc5-mm1 Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/segment.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/segment.h

Add some convenient segment macros to the kernel. This makes the rather obfuscated 'seg & 4' go away. Patch-keys: i386 segment cleanup Patch-base: 2.6.13-rc5-mm1 Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.13/include/asm-i386/segment.h =================================================================== --- linux-2.6.13.orig/include/asm-i386/segment.h

Hi All, Does anyone knows what doest this output means? [root@serverxen ~]# xm list Name                                      ID Mem(MiB) VCPUs State   Time(s) Domain-0                                   0     3202     8 r-----   5220.1 vm1                                  3     4095     2 -b----   3529.2 vm2                                  5     8191     4 -b----    399.0 [root@serverxen ~]# xm

...; > I am using libvirt (virt-manager) to configure and run the virtual > machine, but looking at the xml, I do not think it's passing > 'scsi=off' at all. > > Btw, that xfs file system is a root file system. > > > [ 3.667553] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.668692] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.669897] blk_recount_segments: 1-0-1 vcnt-0 segs-128 > [ 3.671083] blk_recount_segments: 1-0-1 vcnt-0 segs-128 Hamm, I should have used bi_phys_segments to decide if merge is needed, and attached patch should fix...