search for: murky

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...

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

...f Kernighan & Ritchie. It explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and 'long' is 32 bit; and (in sec 2.3) introduces the I, U, and L labels for constants. So "back then when" 32 bit was indeed long. And as R uses 32 bit integers ... (It is all murky because the size is an implementation detail and later "essentially everybody" moved to 32 bit integers and 64 bit longs as the 64 bit architectures became prevalent. Which is why when it matters one should really use more explicit types like int32_t or int64_t.) Dirk -- http://dirk.e...

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 how I configure my channels much like IAX.conf or SIP.conf....

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/

...icitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and 'long' is >> 32 bit; and (in sec 2.3) introduces the I, U, and L labels for constants. So >> "back then when" 32 bit was indeed long. And as R uses 32 bit integers ... >> >> (It is all murky because the size is an implementation detail and later >> "essentially everybody" moved to 32 bit integers and 64 bit longs as the 64 >> bit architectures became prevalent. Which is why when it matters one should >> really use more explicit types like int32_t or int64_t...

...ires that the symbol being aliased has been defined before the '.alias' directive; but I can't get LLVM to do this, and it aggregates all file-scoped (or module-scoped) inline assembly before the code generated for the functions and data. Since the semantics of inline-assembly are very murky, I don't know if this is a bug or by-design. Is there anyway of writing C code that will preserve the relative ordering of file-scoped function, data and inline-assembly definitions? Thanks, MartinO -------------------------------------------------------------- Intel Research a...

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 as RPM from CentOS samba.x86_64 3.6.23-43.el6_9 @updates samba-common.x86_64 3.6.23-43.el6_9...

...reat, 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 to be atomically accessed? How about pointers? Bitfields? Actually I think the interaction of volatile and bitfields is murky so maybe we don't want to go there. Also, right now we don't check that the order in which volatiles are accessed is the same across all optimization levels. Fixing this is on my list. As long as we generate code with at most one volatile access between any given pair of sequence poi...

...ue is that you let userspace poke at the device which is also allowed by the IOMMU to poke at kernel memory (needed for kernel driver to work). Yes, maybe if device is not buggy it's all fine, but it's better if we do not have to trust the device otherwise the security picture becomes more murky. I suggested attaching a PASID to (some) queues - see my old post "using PASIDs to enable a safe variant of direct ring access". Then using IOMMU with VFIO to limit access through queue to corrent ranges of memory. -- MST

...ue is that you let userspace poke at the device which is also allowed by the IOMMU to poke at kernel memory (needed for kernel driver to work). Yes, maybe if device is not buggy it's all fine, but it's better if we do not have to trust the device otherwise the security picture becomes more murky. I suggested attaching a PASID to (some) queues - see my old post "using PASIDs to enable a safe variant of direct ring access". Then using IOMMU with VFIO to limit access through queue to corrent ranges of memory. -- MST

...9;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 I've got basically no clue about. It still could have been the best option (I started poking at Mips), but for one particularly nasty facet: you can select ATOMIC_CMP_SWAP in TableGen, but not ATOMIC_CMP_SWAP_WITH_SUCCESS (multiple results and all that). That means...

...t; %2 = load i32* %1 ; <i32> [#uses=1] > ret i32 %2 > } > > This is very strange - what is 0x400928F5C0000000 ??? > the 32 bit hex representation of 3.145 is 0x404947ae, and, > the 64 bit hex representation of 3.145 is 0x400928f5c28f5c29 For murky historical reasons, float literals are represented as if they were doubles, but with the precision of a float. It does not change their semantics. As for your other question, I don't know that there's a good reason that the parser isn't more accommodating. John.

...heta) a22 = scale * cos(theta) a31 = 0 a31 = 0 a33 = 1 w' = 1 w = 1 Can anyone give me a pointer on how to go about solving for the transformation matrix given a set of points, where x,y and x',y' are available? I sense the presence a solution lingering in the murky mists, (some kind of least squares?) but I am not sure what it is or how to go about it exactly. Thanks for your help! -- Russell Senior ``I have nine fingers; you have ten.'' seniorr at aracnet.com

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

...t; explicitly mentions (sec 2.2) that 'int' may be 16 or 32 bits, and 'long' is | > 32 bit; and (in sec 2.3) introduces the I, U, and L labels for constants. So | > "back then when" 32 bit was indeed long. And as R uses 32 bit integers ... | > | > (It is all murky because the size is an implementation detail and later | > "essentially everybody" moved to 32 bit integers and 64 bit longs as the 64 | > bit architectures became prevalent. Which is why when it matters one should | > really use more explicit types like int32_t or int64_t.) | &...

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 =

...                    ; <i32> [#uses=1] >>  ret i32 %2 >> } >> >> This is very strange - what is 0x400928F5C0000000 ??? >> the 32 bit hex representation of 3.145 is 0x404947ae, and, >> the 64 bit hex representation of 3.145 is 0x400928f5c28f5c29 > > For murky historical reasons, float literals are represented as > if they were doubles, but with the precision of a float.  It does > not change their semantics. But what is 0x400928F5C0000000? it is NOT the 64 bit representation with the low order 32 bits zeroed - it is the 62 bit representation with...