search for: 44.89

Building the current release 2.7 branch on x86_64-apple-darwin10 with r81455 reverted, I get the following Polyhedron 2005 benchmark results (with no test failures)... ================================================================================ Date & Time : 7 Apr 2010 22:24:16 Test Name : llvm_gfortran_lin_p4 Compile Command : llvm-gfortran -ffast-math -funroll-loops -msse3

On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > Building the current release 2.7 branch on x86_64-apple-darwin10 > with r81455 reverted, I get the following Polyhedron 2005 benchmark > results (with no test failures)... Very nice! A 14% speedup on a benchmark we don't tune for isn't bad. I imagine that there are several easy wins you could get on it if you were interested

On Wed, Apr 07, 2010 at 09:54:36PM -0700, Chris Lattner wrote: > > On Apr 7, 2010, at 8:41 PM, Jack Howarth wrote: > > > Building the current release 2.7 branch on x86_64-apple-darwin10 > > with r81455 reverted, I get the following Polyhedron 2005 benchmark > > results (with no test failures)... > > Very nice! A 14% speedup on a benchmark we don't tune for

[CCing Dale since this was his change, not mine] The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC. When you build for Fortran, darwin-c.o is not linked so the GC gets

On Thu, Apr 08, 2010 at 08:45:48AM -0700, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt

On Apr 8, 2010, at 8:45 AMPDT, Bob Wilson wrote: > [CCing Dale since this was his change, not mine] > > The change in 81455 fixes a compiler crash. It doesn't happen very often, but I can't imagine we would want to back that out. Fixing it would be a more reasonable solution. From a quick look at it, the problem is that gcc/config/darwin-c.c is registering va_opt for GC.

Hi, I need some help with running a recursive function. I like to run funlp2 recursively. When I try to run recursive function in another function named "calclp" I get this "Error: any(!dat2$norm_sd) >= 1 is not TRUE". I have never built a recursive function before so having trouble executing it in this case. I would appreciate any help or guidance to resolve this issue.

You seem to have a typo at this expression (and some others like it) Namely, you write any(!dat2$norm_sd) >= 1 when you possibly meant to write !( any(dat2$norm_sd) >= 1 ) i.e. I think your ! seems to be in the wrong place. HTH, Eric On Thu, Dec 14, 2017 at 3:26 PM, DIGHE, NILESH [AG/2362] < nilesh.dighe at monsanto.com> wrote: > Hi, I need some help with running a

My own typo ... whoops ... !( any(dat2$norm_sd >= 1 )) On Thu, Dec 14, 2017 at 3:43 PM, Eric Berger <ericjberger at gmail.com> wrote: > You seem to have a typo at this expression (and some others like it) > > Namely, you write > > any(!dat2$norm_sd) >= 1 > > when you possibly meant to write > > !( any(dat2$norm_sd) >= 1 ) > > i.e. I think your !

Hi, I accidently left out few lines of code from the calclp function. Updated function is pasted below. I am still getting the same error ?Error: !(any(data1$norm_sd >= 1)) is not TRUE? I would appreciate any help. Nilesh dput(calclp) function (dataset) { dat1 <- funlp1(dataset) recursive_funlp <- function(dataset = dat1, func = funlp2) { dat2 <- dataset %>%

Eric: Thanks for taking time to look into my problem. Despite of making the change you suggested, I am still getting the same error. I am wondering if the logic I am using in the stopifnot and if functions is a problem. I like the recursive function to stop whenever the norm_sd column has zero values that are above or equal to 1. Below is the calclp function after the changes you suggested.

The message is coming from your stopifnot() condition being met. On Thu, Dec 14, 2017 at 5:31 PM, DIGHE, NILESH [AG/2362] < nilesh.dighe at monsanto.com> wrote: > Hi, I accidently left out few lines of code from the calclp function. > Updated function is pasted below. > > I am still getting the same error ?Error: !(any(data1$norm_sd >= 1)) is > not TRUE? > > >

If you are trying to understand why the "stopifnot" condition is met you can replace it by something like: if ( any(dat2$norm_sd >= 1) ) browser() This will put you in a debugging session where you can examine your variables, e.g. > dat$norm_sd HTH, Eric On Thu, Dec 14, 2017 at 5:33 PM, Eric Berger <ericjberger at gmail.com> wrote: > The message is coming from

Eric: I will try and see if I can figure out the issue by debugging as you suggested. I don?t know why my code after stopifnot is not getting executed where I like the code to run the funlp2 function when the if statement is TRUE but when it is false, I like it to keep running until the stopifnot condition is met. When the stopifnot condition is met, I like to get the output from if statement

Does anyone know what happens if you try to have 5 concurrent outgoing channels with VoicePulse Connect? Does it give you an error message or a reorder or something? I'm worried about using them as my primary carrier if this is the case. I noticed that they supposedly only allow 4 channels for free and then you have to pay $20 a month extra per channel. I'm guessing this is for inbound

Your code contains the lines stopifnot(!(any(data1$norm_sd >= 1))) if (!(any(data1$norm_sd >= 1))) { df1 <- dat1 return(df1) } stop() "throws an error", causing the current function and all functions in the call stack to abort and return nothing. It does not mean to stop now and return a result. Does the function give

v2: - Change the OCaml code in the daemon to use PCRE instead of Str. - Call pcre_compile2 so we can capture the error code on failure. - Extend the test suite. - Some other cleanups, but very minor. Rich.

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on