search for: booming

Hi. We''re testing the most recent ZFS version from OpenSolaris ported to FreeBSD. Kris (CCed) observed strange situation. In function arc_read() he had a panic on assertion that we try to unlock a lock which is not beeing held: rw_enter(&pbuf->b_hdr->b_datalock, RW_READER); err = arc_read_nolock(pio, spa, bp, done, private, priority, flags, arc_flags, zb);

Hi, I''m trying to create a chatboard (I call it my BoomBox, each post is called a "boom") which appears on every page of a weblog I''m building. I have a scaffold-built controller called Boom, and the form to post to the BoomBox is written into my default layout. So, the form can be viewed from several of my other controllers, in most of their actions. The form

Hi all, I am having some problems in updating some packages from source. I start with : install.packages("Boom",lib="C:/RownLib",type="source") I get the following error message : * installing *source* package 'Boom' ... ** package 'Boom' successfully unpacked and MD5 sums checked ** libs *** arch - i386 c:/Rtools/mingw_32/bin/g++ -std=gnu++11

Hi, As far as I can see, no. On checking, I have confirmed that the only location of cygwin1.dll is : C:\Rtools\bin Thanks Vivek 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at gmail.com>: > On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > >> Hi all, >> I am having some problems in updating some packages from source. I start >> with : >>

On 03/06/2017 6:31 AM, Vivek Sutradhara wrote: > Hi all, > I am having some problems in updating some packages from source. I start > with : > install.packages("Boom",lib="C:/RownLib",type="source") > > I get the following error message : Do you have multiple copies of cygwin1.dll? Duncan Murdoch > > * installing *source* package

Hello, We are running Rails on www.montastic.com (free website monitoring service w/ ajax and RSS feeds) and we are trying to fork a process within a model e.g. and continue the query the model stored data e.g. in model server.rb... Server.count ==> 1111 fork { Server.count } ==> Boom. Mysql has gone away... Is there a way to fork in a way to keep the database connection? --

Tomas, I think you're not addressing the actual issue which is a clear regression in Sys.getenv() [because it used to work and still works for single env var, but not a list] and the cryptic error due to that regression (caused by changes in R-devel). So in either case, Sys.getenv needs fixing (i.e., this should really go to the bugzilla). Its behavior is currently inconsistent. The quoted

On 03/06/2017 7:00 AM, Vivek Sutradhara wrote: > Hi, > As far as I can see, no. > > On checking, I have confirmed that the only location of > cygwin1.dll is : > C:\Rtools\bin I would re-install Rtools, and make sure C:\Rtools\bin appears first in your PATH. Duncan Murdoch > > Thanks > Vivek > > 2017-06-03 12:57 GMT+02:00 Duncan Murdoch <murdoch.duncan at

On 7/12/17 7:19 PM, Mike Galbraith wrote: > On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: >> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: >>> On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >>>> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: >>>>> Some display stuff did change for 4.13 for

/Hello. SUMMARY: $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv()" Error in substring(x, m + 1L) : invalid multibyte string at '<ff>' $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv('BOOM')" [1] "\xff" BACKGROUND: I launch R through an Son of Grid Engine (SGE) scheduler, where the R

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >>

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efault at gmx.de> wrote: > On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote: >> Some details that may be useful in analysis of the bug: >> >> 1. lspci -nn -d 10de: > > 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 980] [10de:13c0] (rev a1) > 01:00.1 Audio device [0403]: NVIDIA

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: >> > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not >> > too much trouble, a bisect would be pretty useful. >> >> Bisection

On 7/14/17 3:41 PM, Mike Galbraith wrote: > On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >>  All DRM did was to slip a >> WARN_ON_ONCE() that nouveau triggers into a kernel module where such >> things no longer warn, they blow the box out of the water. > BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c > into a WARN_ONCE(), and all is

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith <efault at gmx.de> wrote: > On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: >> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE >> usage we could convert to WARN_ONCE? > > Shooting the messenger is generally considered uncool :) That's never stopped it from being a popular practice...

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> On 7/14/17 5:10 PM, Karol Herbst wrote: > Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE > usage we could convert to WARN_ONCE? > > Reviewed-By: Karol Herbst <karolherbst at

On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote: > > Ok, a network outage gave me time to go hunting.  Indeed it is a bad > > interaction with the tree DRM merged into.  All DRM did was to slip a > > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > > things no longer warn,

On Fri, 2017-07-14 at 14:42 -0500, Josh Poimboeuf wrote: > > Does this fix it? Yup, both READONLY __bug_table and "extra stern" warning are gone. > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h > index 39e702d..aa6b202 100644 > --- a/arch/x86/include/asm/bug.h > +++ b/arch/x86/include/asm/bug.h > @@ -35,7 +35,7 @@ > #define

+++ Peter Zijlstra [14/07/17 18:10 +0200]: >On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: >> On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > >> > Urgh, is for some mysterious reason the __bug_table section of modules >> > ending up in RO memory? >> > >> > I forever get lost in that link magic :/ >> >> +1

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > The conversion is a nice catch, but i'd like to have a bit more context, see > below! > > With a better description: > > Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> I don't think it was meant as a serious patch. WARN_ON_ONCE should work. The