search for: murkiness

Delving into the murky world of dates and times I found this: dates <- c("02/27/92", "02/27/92", "01/14/92", "02/28/92", "02/01/92") > times <- c("23:03:20", "22:29:56", "01:03:30", "18:21:03", "16:56:26") > x <- paste(dates, times) > z <- strptime(x, "%m/%d/%y

Thank you very much, I will try these. There are only Centos 7 and Windows 10 machines on the network. On Sun, Jul 23, 2017 at 4:11 PM, Walter H. <Walter.H at mathemainzel.info> wrote: > On 23.07.2017 13:08, vychytraly . wrote: > >> Hello friends, >> >> I have a Gigabit network with few Windows and Centos 7 machines and I >> noticed that when copying files

Hi, I''m playing around with module instance variables. I can set one up and initialise it when the module is included in a class. What I can''t work out is how I initialise one when a class inherits another class that includes the module. See http://pastie.org/905720 This creates two classes, the first inherits a module that contains an instance variable. The second inherits the

On 25 August 2018 at 09:28, Carl Boettiger wrote: | I always thought it meant "Long" (I'm assuming R's integers are long | integers in C sense (iirrc one can declare 'long x', and it being common to | refer to integers as "longs" in the same way we use "doubles" to mean | double precision floating point). But pure speculation on my part, so I'm |

Can anyone explain to me the difference in zaptel.conf and zapata.conf? I'm trying to get a real clear understanding of them but its getting a little murky in places. I will be setting up a PBX running asterisk with 2 T100P cards. I will be bringing a 23 channel PRI into one card and connecting the other card to a Nortell 24 channel FXS channel bank. As I understand it zapata.conf is

Sometimes the absence of a name is maked by an NA: x <- 1:2 names(x)[[1]] <- "a" names(x) # [1] "a" NA Whereas other times its y <- c(a = 1, 2) names(y) # [1] "a" "" Is this deliberate? The help for names() is a bit murky, but an example shows the NA behaviour. Hadley -- http://had.co.nz/

On 25/08/2018 4:49 PM, Herv? Pag?s wrote: > The choice of the L suffix in R to mean "R integer type", which > is mapped to the "int" type at the C level, and NOT to the "long int" > type, is really unfortunate as it seems to be misleading and confusing > a lot of people. Can you provide any evidence of that (e.g. a link to a message from one of these

I am trying to support an experimental DSL that uses non-C identifiers, but I want to write the implementation of the runtime support libraries for this DSL in C. The compiler is built using the LLVM v5.0.0 release branch. To do this I thought I could simply write: int foo() { return 42; } // The C implementation asm(".alias nonCname foo"); // Make the non-C name be a synonym for

On 23.07.2017 19:56, mad.scientist.at.large at tutanota.com wrote: > Can I ask where people are downloading samba from? I followed the instructions in the centos wiki but it's hard to tell what to do next on the German site. It was easy before but totally murky now (at least to this wetware). a link or two or clearer/more complete instructions would be greatly appreciated. Samaba comes

Hi Duncan, We currently check that every byte of a volatile is accessed the same number of times, and that this number doesn't change across optimization levels. If LLVM wants to make stronger guarantees that's great, I suspect this is not hard to all to check. Can you provide a list of types that should be atomic for the x86 target? For example would we expect a struct of size 4

On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > One problem is that, different virtio ring compatible devices > > > > may have different device interfaces. That is to say, we will > > > > need different drivers in QEMU. It could be troublesome. And > > > > that's what this patch trying to fix. The idea behind this > >

On Tue, Apr 10, 2018 at 03:25:45PM +0800, Jason Wang wrote: > > > > One problem is that, different virtio ring compatible devices > > > > may have different device interfaces. That is to say, we will > > > > need different drivers in QEMU. It could be troublesome. And > > > > that's what this patch trying to fix. The idea behind this > >

Hi Chandler, > So, I see where you're going here, but I'm curious -- why not just switch > ATOMIC_CMP_SWAP to have a second i1 value, and still be strong? Is this > *just* to support expanding? I wonder if that's really useful rather than > just lowering it directly on the various targets.... I tried that originally, but quickly got into murky waters with all the targets

On Apr 26, 2011, at 2:07 AM, Joe Armstrong wrote: > Compiles (via clang) to: > > ; ModuleID = 'test101.c' > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" > target triple = "i386-pc-linux-gnu" > > define i32 @main() nounwind { > %1 =

We have recently digitized a set of points from some scanned engineering drawings (in the form of PDFs). The digitization resulted in x,y page coordinates for each point. The scans were not aligned perfectly so there is a small rotation, and furthermore each projection (e.g. the yz-plane) on the drawing has a different offset from the page origin to the projection origin. From the dimensions

Hi, I’ve stumbled across something curious with the Relase_40 I have built here: I tried to build for aarch64-apple-iphoneos, but ended up getting ELF objects $ clang -target aarch64-apple-iphoneos -c tmp.ll -o tmp.o warning: overriding the module target triple with aarch64-apple-iphoneos [-Woverride-module] 1 warning generated. bin $ file tmp.o tmp.o: ELF 64-bit LSB relocatable, ARM aarch64,

I have a data file read into a data frame. For example, V1 V2 V3 V4 1 1 1 3 4 2 2 3 5 10 . . . . . . . . . . n V1[n] V2[n] V3[n] V4[n] to n=many thousand I want to plot a graph with many line segments, where v1[i]=x1, v2[i]=y1, v3[i]=x2, v4[i]=y2 for i=1,n. This seems relatively simple in theory but I've spent quite a bit of time trying to make it happen with

On 25 August 2018 at 13:49, Herv? Pag?s wrote: | The choice of the L suffix in R to mean "R integer type", which | is mapped to the "int" type at the C level, and NOT to the "long int" | type, is really unfortunate as it seems to be misleading and confusing | a lot of people. The point I was trying to make in what you quote below is that the L may come from a time

I assumed that C floats are 32 bits and doubles 64 bits ... but This code int main(){ float f; double f1; f = 3.145; f1 = 3.145; return(0); } Compiles (via clang) to: ; ModuleID = 'test101.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple =

On Wed, Apr 27, 2011 at 12:51 AM, John McCall <rjmccall at apple.com> wrote: > On Apr 26, 2011, at 2:07 AM, Joe Armstrong wrote: >> Compiles (via clang) to: >> >>  ; ModuleID = 'test101.c' >>  target datalayout = >>