search for: l174

It does give a warning, but then it overwrites the files, anyway. Reproducible example below. This is R 3.4.3, but it does not seem to be fixed in R-devel: https://github.com/wch/r-source/blob/4a9ca3e5ac6b19d7faa7c9290374f7604bf0ef64/src/main/dounzip.c#L171-L174 FYI, G?bor dir.create(tmp <- tempfile()) setwd(tmp) cat("old1\n", file = "file1") cat("old2\n", file = "file2") utils::zip("files.zip", c("file1", "file2")) #> adding: file1 (stored 0%) #> adding: file2 (stored 0...

...stomLowering(Function &F) { + // You can use LowerIntrinsics::InsertRootInitializers as a template. + } }; LowerIntrinsics::InsertRootInitializers is only 26 lines of code. You can find it here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/GCStrategy.cpp?annotate=123170#l174 More invasively, you could consider adding a hook to GCStrategy which replaces the indicated call to ConstantPointerNull::get in LowerIntrinsics::InsertRootInitializers: // Add root initializers. bool MadeChange = false; for (AllocaInst **I = Roots, **E = Roots + Count; I != E; ++I)...

...sers\mtoews\Documents\R\win-library\3.3\file382064842da2\mypackage? to ?C:\Users\mtoews\Documents\R\win-library\3.3\mypackage? Debugging, I found the issue around here: https://github.com/wch/r-source/blob/980c15af89d99c04e09a40708512a57c49d1c6ee/src/library/utils/R/windows/install.packages.R#L173-L174 > ## To avoid anti-virus interference, wait a little > Sys.sleep(0.5) As indicated by an answer (https://stackoverflow.com/a/44256437/327026), debugging slows down the function to allow the package to be installed. A simple fix is to increase the sleep time to a time that is longer than 0.5...

Hello all, I set: InitRoots = true; in my gc plugin as i want the roots to be initialized to the "null" value. Is there a way to define which value should be the initial one? For example, i would like to initialize my roots to -5 (tagged, null value for the GC in my runtime system) instead of 0. Ofcourse, i could do it in the frontend (storing -5 to all GC roots), but i was wondering

On Thu, Nov 23, 2017 at 10:57 AM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Tue, Nov 21, 2017 at 11:43:54PM +0200, Yaniv Kaul wrote: > > Since I upgrading to FC27, I *sometimes* fail to virt-sysprep. > > The debug messages: > > libguestfs: trace: set_verbose true > > libguestfs: trace: set_verbose = 0 > > libguestfs: create: flags = 0, handle =

...at this a bit closer, I think this may be a bug in qemu. > > /dev/fd/7 is supposed to be the file descriptor of the image which we > have opened in libguestfs, see this code: > > https://github.com/libguestfs/libguestfs/blob/ > 06df910491c49360c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191 > > I wonder if qemu gets confused by this and thinks that the image is > open in two places? > > I can't reproduce this here however. Having a nice short reproducer > might help. > It's not reliably reproduced on my setup either. I run Lago (http://lago.readthed...

...ing at this a bit closer, I think this may be a bug in qemu. > > /dev/fd/7 is supposed to be the file descriptor of the image which we > have opened in libguestfs, see this code: > > https://github.com/libguestfs/libguestfs/blob/06df910491c49360c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191 > > I wonder if qemu gets confused by this and thinks that the image is > open in two places? > > I can't reproduce this here however. Having a nice short reproducer > might help. This bug has now been reported by a Debian user: https://bugs.debian.org/cgi-bin/bugr...

...0c (c) Copyright 1994-97, NCR Corporation (c) Copyright 1987-97, MetaWare Incorporated cc -I. -I. -g -DHAVE_CONFIG_H -I./popt -c util.c -o util.o NCR High Performance C Compiler R3.0c (c) Copyright 1994-97, NCR Corporation (c) Copyright 1987-97, MetaWare Incorporated w "util.c",L174/C10(#257): '=' encountered where '==' may have been intended. w "util.c",L516/C10(#257): '=' encountered where '==' may have been intended. w "util.c",L559/C8(#257): '=' encountered where '==' may have been inten...

...ss using the image? Looking at this a bit closer, I think this may be a bug in qemu. /dev/fd/7 is supposed to be the file descriptor of the image which we have opened in libguestfs, see this code: https://github.com/libguestfs/libguestfs/blob/06df910491c49360c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191 I wonder if qemu gets confused by this and thinks that the image is open in two places? I can't reproduce this here however. Having a nice short reproducer might help. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtu...

...closer, I think this may be a bug in qemu. >> >> /dev/fd/7 is supposed to be the file descriptor of the image which we >> have opened in libguestfs, see this code: >> >> https://github.com/libguestfs/libguestfs/blob/06df910491c49360c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191 >> >> I wonder if qemu gets confused by this and thinks that the image is >> open in two places? >> >> I can't reproduce this here however. Having a nice short reproducer >> might help. > > This bug has now been reported by a Debian user: > &...

...ecure? You might want to check that sshd allows port forwarding ('AllowTcpForwarding yes' in /etc/ssh/sshd_config). It would be useful to know what the actual sshd failure is. This is how ssh is invoked on the virt-p2v side: https://github.com/libguestfs/libguestfs/blob/master/p2v/ssh.c#L174 plus https://github.com/libguestfs/libguestfs/blob/master/p2v/ssh.c#L595 > Another point : as I wrote it before, I have no way to get a shell > prompt on the source machine, because alt-F1 leads to a blinking > screen trying to run virt-p2v and failing and respawning. > I nmap'd th...

...hink this may be a bug in qemu. > > > > /dev/fd/7 is supposed to be the file descriptor of the image which we > > have opened in libguestfs, see this code: > > > > https://github.com/libguestfs/libguestfs/blob/ > 06df910491c49360c0292c7153ba5e5cd09a4735/lib/info.c#L174-L191 > > > > I wonder if qemu gets confused by this and thinks that the image is > > open in two places? > > > > I can't reproduce this here however. Having a nice short reproducer > > might help. > > This bug has now been reported by a Debian user: &g...

Le 19/11/2014 18:12, Richard W.M. Jones a écrit : > On Wed, Nov 19, 2014 at 04:42:23PM +0100, Nicolas Ecarnot wrote: >> disks: >> nbd:localhost:33363 (raw) [sda] >> nbd:localhost:49584 (raw) [sdb] >> nbd:localhost:41988 (raw) [sdc] >> removable media: >> >> NICs: >> >> [ 0.0] Creating an overlay to protect the source from being modified