search for: 19.38

Ping... with the updated code size impact data, any more comments? Any more data that would be interesting to collect? Thanks, Dehao On Thu, Feb 2, 2017 at 2:07 PM, Dehao Chen <dehao at google.com> wrote: > Here is the code size impact for clang, chrome and 24 google internal > benchmarks (name omited, 14 15 16 are encoding/decoding benchmarks similar > as h264). There are 2

Hello all! I have a problem to draw a polygon with R. My data is like this> Year Nb.series Perc.pos Perc.neg Nature RGV_mean RGV_sd neg poz 1 1901 1 0.00 0.00 0 4.29 NA 0.00 0.00 2 1902 1 100.00 0.00 1 16.47 NA 0.00 100.00 3 1903 1 100.00 0.00 1 31.31 NA 0.00 100.00 4 1904 1 0.00 0.00 0 -9.62 NA 0.00 0.00 5 1905 1 0.00 100.00 -1 -22.55 NA -100.00 0.00 6 1906 1 0.00 100.00 -1 -12.09 NA

On 02/10/2017 05:21 PM, Dehao Chen wrote: > Thanks every for the comments. > > Do we have a decision here? You're good to go as far as I'm concerned. -Hal > > Dehao > > On Tue, Feb 7, 2017 at 10:24 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote:

1 4 499492 150392 4496 4763380 0 0 192 552 1227 1094 2 0 75 24 0 0 5 499492 150656 4500 4763528 0 0 0 160 465 263 1 0 68 30 0 0 5 499492 150468 4500 4763532 0 0 0 0 177 93 1 0 69 31 0 1 5 499492 151020 4500 4763540 0 0 0 0 160 132 0 0 69 31 0 1 5 499492 151268 4500 4763540 0 0 0 0 304 143 1 0 69

On 02/07/2017 05:29 PM, Sanjay Patel via llvm-dev wrote: > Sorry if I missed it, but what machine/CPU are you using to collect > the perf numbers? > > I am concerned that what may be a win on a CPU that keeps a couple of > hundred instructions in-flight and has many MB of caches will not hold > for a small core. In my experience, unrolling tends to help weaker cores even more

> On Feb 1, 2017, at 4:57 PM, Xinliang David Li via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > clang, chrome, and some internal large apps are good candidates for size metrics. I'd also add the standard LLVM testsuite just because it's the suite everyone in the community can use. Michael > > David > > On Wed, Feb 1, 2017 at 4:47 PM, Chandler Carruth via

FWIW, I'm good with the updated data, but I'd really like at least someone from Apple and someone from ARM to chime in here... CC-ing random people in the hope it helps... On Mon, Feb 13, 2017 at 8:30 AM Dehao Chen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for the comment. The performance experiments were performed on > Intel Sandybridge. Updated this info to

Hello, I am tying to compile Dovecot 2.2.27 on Solaris 10, and I get this error: test-ioloop.c: In function `test_ioloop_pending_io': test-ioloop.c:188: error: size of array `type name' is negative My configuration is like this: Install prefix . : /usr/local File offsets ... : 64bit I/O polling .... : poll I/O notifys .... : none SSL ............ : yes (OpenSSL) GSSAPI ......... : no

On 2 Feb 2017, at 19.38, Mantas Gegu?is <mantas.geguzis at ittc.vu.lt> wrote: > > Hello, > > I am tying to compile Dovecot 2.2.27 on Solaris 10, and I get this error: > test-ioloop.c: In function `test_ioloop_pending_io': > test-ioloop.c:188: error: size of array `type name' is negative Change NULL to (void *)NULL in that line.

Hello, thank You, this solution worked too. But had to do same thing for those files: test-http-client-errors.c:388 test-http-client-errors.c:484 test-http-client-errors.c:556 test-http-client-errors.c:636 test-http-server-errors.c:594 main.c:63 director.c:1445 director.c:1448 imap-client.c:253 director.c:1445 director.c:1448 mail-stats.c:56 Is this an old compiler issue or something else?

The following zlib files need patches in order to compile using Compaq C on OpenVMS. These patches should also be needed on a Tru64 or LINUX on ALPHA using Compaq C. These should work on any ANSI compliant compiler. Operating System: OpenVMS ALPHA V7.3 Compiler: Compaq C T6.5 Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE) The module adler32.c is testing the unsigned value len to see if

Hi Michael, Geronimo JavaMail hard defaults to / separator. If the separator is manually set to undefined it automatically calculates the separator correctly. However neither through JavaMail or by command line does LIST "." "*" or LIST . "*" produce any root listing of default folder on my Dovecot installation. Only LIST "" "*" produces a

Thanks for running these Kristof! I'd still like to hear from Apple, and if we can get a few more x86 micro-architectures covered that'd be great, but it looks like -O3 is uncontroversial, and the question is whether this makes sense at O2... To me, it would help a lot to know the actual breakdown of benchmarks such as yours Kristof (as they seem to have more codesize impact than others

?Hola, A mí me funciona la importación directa. Previamente he guardado la hoja de Excel en .csv (separado por ";"). Y hago sin problemas la correlación entre dos variables (las dos primeras). > datIn <- read.csv("Variables.csv", header=T, as.is=T, sep=";", dec=",") > head(datIn) EMPRESAS AA AB AC AD AE AF AG AH AI

Has probado con cor(datos,use="pairwise.complete.obs") ??? > From: valeagui en outlook.es > To: cof en qualityexcellence.es; r-help-es en r-project.org > Date: Wed, 11 Nov 2015 15:13:55 +0000 > Subject: Re: [R-es] Problema con la lectura de datos > > Hola Carlos, muchas gracias....pero hago exactamente lo mismo que tu..y al intentar de hacer la matriz de

Hi there We have a pair of servers running FreeBSD 9.1-RC3 that act as transparent layer 7 loadbalancer (relayd) and pop/imap proxy (dovecot). Only one of them is active at a given time, it's a failover setup. From time to time the active one gets in a state in which the 'thread taskq' thread uses up 100% of one cpu on its own, like here: ---- PID USERNAME PRI NICE SIZE

Si lo has guardado como csv separado por comas: Abre con cualquier editor el fichero: mira separador de listas y separador de decimal, supongamos que sea "; " para las listas (esto depende de tu configuración regional) y "." para los decimales (es como lo tienes en tu fichero) entonces dat<-read.csv("Variables.csv", header=T, sep=";",

Hi, LLVM 2.1-pre1 test results: Linux (SUSE) on x86 (P4) Release mode, but with assertions enabled LLVM srcdir == objdir # of expected passes 2250 # of expected failures 5 I ran the llvm-test suite on my desktop while I was also working on that PC, so don't put too much trust in the timing info. Especially during the "spiff" test the machine was swapping

Hola. He estado viendo los datos que adjuntas en el correo. Al ser un fichero Excel xlsx ¿por qué no lo abres directamente? Te aconsejaría la librería openxlsx (si no la has usado nunca , instálala con install.packages(?openxlsx?)) Este es el código que he ejecutado y los resultados que obtengo: library(openxlsx) dat <- read.xlsx("Variables.xlsx") str(dat) Que produce:

LLVMers, The 2.1 pre-release (version 1) is available for testing: http://llvm.org/prereleases/2.1/version1/ I'm looking for members of the LLVM community to test the 2.1 release. There are 2 ways you can help: 1) Download llvm-2.1, llvm-test-2.1, and the appropriate llvm-gcc4.0 binary. Run "make check" and the full llvm-test suite (make TEST=nightly report). 2) Download