search for: innocu

On Tue, Feb 17, 2009 at 2:35 PM, Mike Stump <mrs at apple.com> wrote: > On Feb 17, 2009, at 2:21 PM, Scott Michel wrote: > > - remove trailing whitespace, > > - expand tabs to spaces, > > I'd argue for not changing anything, just fail it. > Trimming whitespace is innocuous, at best. Expanding tabs to spaces, I might be inclined to agree is a 'fail' since weird formatting can result. 80-col violations are absolutely a 'fail'. -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermai...

I just noticed that on centso 4.5 I have an executable with the +s (chmod +s myexe) doing a chmod root myexe and chown root myexe does NOT affect the +s setting. However, on centos 5 this is not the case. chmod +s myexe chown root myexe or chgrp root myexe will DROP the +s status. How can I get around this? I want to keep the owner, group, world settings. Thanks, Jerry

I noticed, what seened to me, to be odd. These produce a boxplot in the first case and a spineplot in the second case in R .2.2.0: plot(Sepal.Length ~ Species, iris) plot(Species ~ Sepal.Length, iris) What if one wants to exchange axes? Does the fact that this seemingly innocuous change result in completely different graphics make sense? Is it desirable?

Hi all, Not sure if I''m the only one with this problem... We''re on edge for both rails and rspec, and i just did an update... Some apparently innocuous rails stuff was updated, and then half my specs broke due to an error in rspec_on_rails: ArgumentError in ''UserController without logged in user should show the index page'' wrong number of arguments (2 for 1) ..../vendor/plugins/rspec_on_rails/lib/spec/rails/example/behavio...

...owever, if there's been > standardization efforts for range, we should be sure that we're doing > something compatible there. There are a couple of proposals [1][2] that I can find. It sounds like the exact set of methods to provide is somewhat contentious [3]. empty() seems pretty innocuous though. Note that the standard proposals use std::range instead of std::iterator_range. In my opinion, other methods (e.g., front(), back(), and (for random access iterators) operator[]) would also be useful. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html [2]: http://...

...something that would be easy > >> to fix. > > > > I have a fix (yes, it was trivial). I'll have to see about a > > testcase as it's > > proprietary code. > > Usually, proprietary testcases can be reduced and simplified to the > point where they are innocuous, Yep, that's what I'm trying to do. -Dave

Hi, I am working with the package nlme, and I tried creating a new correlation class (which, according to the help pages, is possible if you write a few new method functions). Anyways, I think I am 99% of the way there, but I have a recurring problem with R crashing on seemingly innocuous statements (I have set debug() on nearly every function, so I can see where it is failing). For instance, sometime the code fails on the simple statement: object[[i]] Two things are odd about this: 1. It's not the first time I call object[[i]] 2. If I run save() on the object just before th...

Question: I am trying to impliment a function in R that we use quite regularly in Splus, and it fails due to a lack of the "terms.inner" function in R. The substitute is? Part question and part soapbox: Why remove terms.inner from R? It's little used, but rather innocuous. Mostly soapbox: I figured it was no big deal, as I originally discovered the use of terms.inner from reading the plot.gam function. So I'd just see what plot.gam does in R. > plot.gam Error: object "plot.gam" not found Ok, I know this function has to exist. I even rem...

...all the time: >> >> auth-worker(11160): Info: passwd(sales at bordo.com.au <mailto:sales at bordo.com.au>,10.0.0.54,<YSFoAYHAGoLAqAEo>): unknown user - trying the next userdb >> > > That is not an error. As the "Info: " prefix indicates, this is an innocuous informational message. > > Regards, > > Stephan. > Thanks Stephan. I know it?s not a major thing, it?s just that it is every third line of my log. Ie I get the auth-worker unknown user, then successful imap-login, then the imap logout. So I?m just trying to figure out what...

Hi, Can anyone suggest any reasons why this seemingly-innocuous (though stupid-looking) excerpt from gnu fileutils 4.1 would make llvm-gcc go so incredibly slowly? It doesn't seem to be a question of the size of the output. Here's what I do: % time llvm-gcc -c sha24.c 56.840u 0.050s 1:07.05 84.8% 0+0k 0+0io 1050pf+0w % ls -l sha24.o -rw-r--r--...

...after the fact, > and the patch isn't sent). > > This seems easy to fix by requiring llvm-commits on llvm patches > (and cfe-commits on clang patches). Is there a technical hurdle > to requiring this? +1. This is the situation I've seen most often, and while innocuous it can be pretty annoying. > 2. Reviewer (or commenter) has an invalid or un-subscribed email on > Phab. > > Is it technically feasible to disallow reviews (or comments on a > review) from logins that aren't subscribed to the appropriate list > and/or have...

On Thursday 25 September 2008 19:12, Chris Lattner wrote: > On Sep 24, 2008, at 5:11 PM, David Greene wrote: > > I just ran into this today with x86-64: > > > > Cannot yet select: 0x3cbc180: f64 = ConstantFP <1> > > > > As far as I can tell, DAGCombiner comes along and sees an sint_to_fp > > of the > > constant 1 and hapilly folds it into a

...u have a testcase? It sounds like something that would be easy >> to fix. > > I have a fix (yes, it was trivial). I'll have to see about a > testcase as it's > proprietary code. Usually, proprietary testcases can be reduced and simplified to the point where they are innocuous, -Chris

On Sep 29, 2008, at 9:21 AM, David Greene wrote: >> Usually, proprietary testcases can be reduced and simplified to the >> point where they are innocuous, > > Yep, that's what I'm trying to do. Have you run delta?

On Feb 17, 2009, at 2:46 PM, Scott Michel wrote: > Trimming whitespace is innocuous, at best. Unless you're doing a testcase that wants to verify a feature.

...a0 :[<ffffffff810a662e>] ? kthread+0x9e/0xc0 :[<ffffffff8100c28a>] ? child_rip+0xa/0x20 :[<ffffffff810a6590>] ? kthread+0x0/0xc0 :[<ffffffff8100c280>] ? child_rip+0x0/0x20 PID 31 is: root 31 0.9 0.0 0 0 ? S Jun03 12:44 [events/4] It seems to be innocuous (everything seems to still work) but things that seem to be innocuous have a habit of coming back and biting me. Anyone else experiencing this? Anyone know how to fix it? Both kernel and xorg-x11-drv-nouveau are current as is the rest of the system. Not finding anything with Google. Cheers,...

On Fri, Nov 17, 2006 at 08:32:02AM -0800, Josh Coalson wrote: > OK, I built on one of the sourceforge machines and made a bunch > more fixes. there are a couple innocuous warnings but the tests > all pass for me. I also checked in changes to the vendor string, > can you try one more time now? Yep, all 7 tests pass now. Yay! Attached is an autogen integration patch: (a) pass -I m4 to aclocal (b) set a minimum automake version of 1.7 Both are required to...

Has anyone put an eye to my patches*? AFAIK, they're simple and quite innocuous. Sorry to be a bother. (*) http://bugs.xiph.org/show_bug.cgi?id=208 http://bugs.xiph.org/show_bug.cgi?id=210 -- -:-:- David K. Gasaway -:-:- XNS : =David K Gasaway -:-:- Email: dave@gasaway.org -:-:- Web : dave.gasaway.org <p><p>--- >8 ---- List archives: http://www.xiph.o...

Hi all, I get a (usually) reproducible error for only one of my controllers. This doesn''t happen for any of the other 10+ controllers. I didn''t see anything weird about file permissions. The "offending" line 142 is quite innocuous and triggers the error even when that portion of the controller is not even being run. . . . 141 while logfile.readline 142 next unless /Average Redundancy Per Shell/ 143 break 144 end . . . The error looks like this in the logs/develop...

On 01/08/2014 22:07, Chandler Carruth wrote: > Note that I've fixed one bad compile time regression quite recently, and > we're bisecting to another one. We benchmarked the multithreading stuff > pretty carefully, so I doubt its that. Have you tried reverting locally and > reproducing? Not really. It just saw this passing by and was wondering if it raised some bells. The