similar to: [PATCH nbdkit] golang: Pass Plugin and Connection by reference not value.

On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > Thanks: Dan Berrangé > > > > XXX UNFINISHED: > > > > - Is using uintptr for the handle a good idea? Plugins must return > > something != 0. In other languages we would allow plugins to > > return an

Thanks: Dan Berrangé XXX UNFINISHED: - Is using uintptr for the handle a good idea? Plugins must return something != 0. In other languages we would allow plugins to return an arbitrary object here, but this is not possible in golang because of lack of GC roots. - Default can_* methods are hard to implement. Ideally we would be able to test if a user plugin implements a

On Fri, Apr 10, 2020 at 02:51:52PM +0100, Richard W.M. Jones wrote: > Similar to C, OCaml and Rust, this is not a plugin per se. Instead > it's more of a method and set of tests around writing plugins in > golang. They are standalone programs that compile into shared objects > that nbdkit can then load (so there is no "go plugin" between nbdkit > and the user plugin,

Hi Folks, I''d love for everyone to grab the 0.3.12 pre-release gems from http://mongrel.rubyforge.org/releases/ and tell me if their stuff breaks. You can get it with a simple: gem install mongrel --source=http://mongrel.rubyforge.org/releases/ This release features the following goodies: * The -n and -t options to mongrel_rails start have changed in meaning to be the maximum number

On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > Thanks: Dan Berrangé > > XXX UNFINISHED: > > - Is using uintptr for the handle a good idea? Plugins must return > something != 0. In other languages we would allow plugins to > return an arbitrary object here, but this is not possible in golang > because of lack of GC roots. Yeah, this is

Thought I'd try and start a discussion. Feel free to jump in. I guess R needs to strike the right balance between opening up the internals to package writers and not allowing them to do bad things. My first attempt at cracking this nut is to just memcpy() the Rconnection and not allow access to the private stuff: /* Alternative to allowing C code access to connection API. */ Rconnection

On 4/23/20 2:13 PM, Richard W.M. Jones wrote: > Compiling nbdkit from source when an older nbdkit is installed would > fail because certain symbols such as .get_ready are not defined in the > (installed) <nbdkit-plugin.h>: > > ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) >

While using the file functions have found a few more issues (on both Unix and Windows) ie R documentation: In the "close" description (base package) we see that the possible values for the mode 'open' the "r+" and "r+b" values are repeated, and are incorrect the second time. The second set actually corresponds to the "w+" / "w+b", see

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

Compiling nbdkit from source when an older nbdkit is installed would fail because certain symbols such as .get_ready are not defined in the (installed) <nbdkit-plugin.h>: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) Of course we should be compiling against the local include/nbdkit-plugin.h

Hello, We've recently started using ifuncs in the x86(_64) FreeBSD kernel. Currently lld will emit a PLT entry for each ifunc, so ifunc calls are more expensive that those of regular functions. In our kernel, this overhead isn't really necessary: if lld instead emits PC-relative relocations for each ifunc call site, where each relocation references a symbol of type GNU_IFUNC, then during

On Thu, Apr 23, 2020 at 10:03:45AM +0100, Richard W.M. Jones wrote: > On Tue, Apr 21, 2020 at 05:07:43PM +0100, Daniel P. Berrangé wrote: > > On Tue, Apr 21, 2020 at 11:44:59AM +0100, Richard W.M. Jones wrote: > > > Thanks: Dan Berrangé > > > > > > XXX UNFINISHED: > > > > > > - Is using uintptr for the handle a good idea? Plugins must

G'Day, Following Daniels comments about semantics of the sys::Path API, he has convinced me otherwise as the driver doesn't make or remove directories, so his semantics do indeed make more sense in this context. Fixes applied here; LLVM: http://llvm.org/viewvc/llvm-project?view=rev&revision=89848 Clang: http://llvm.org/viewvc/llvm-project?view=rev&revision=89849 Thanks everyone

When compiling when an older nbdkit is installed, the build would fail because certain symbols such as .get_ready were not defined: ../../src/libguestfs.org/nbdkit/nbdkit.go:541:8: plugin.get_ready undefined (type _Ctype_struct_nbdkit_plugin has no field or method get_ready) This happens because we were using the installed <nbdkit-plugin.h> rather than the local copy. We don't want

The R-1.2.1 builds have gone fairly smoothly on most of my UNIX architectures, but there were many warnings reported by the picky SGI compiler that could be eliminated in future releases. Generally, I have found the SGI compilers very helpful in ferreting out portability problems, unused and/or obsolete variables, unexpected datatype coercions, etc., and they compile faster than any other

Sorry Dan, but I really do dislike golang with a passion :-) Here is a patch that allows you to write nbdkit plugins in golang. As with C, OCaml and Rust, you can write a plugin in Go which compiles directly to a .so file that can be loaded into golang, so in that sense it works completely differently from scripting language plugins like Perl and Python where there's an

I've just implemented a generalization of R's text connections, to also support reading/writing raw binary data. There is very little new code to speak of. For input connections, I wrote code to populate the old text connection buffer from a raw vector, and provided a new raw_read() method. For output connections, I wrote a raw_write() to append to a raw vector. On input, the mode

Here's an update of my rawConnection() implementation. In addition to providing a raw version of textConnection(), this fixes two existing issues with textConnection(): one is that the current textConnection() implementation carries around unprotected SEXP pointers, the other is a performance problem due to prolific copying of the output buffer as output is accumulated line by line. This new

Version 2: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00166 Version 3 contains all changes discussed in the previous review. Rich.

Version 1 was here: https://www.redhat.com/archives/libguestfs/2020-April/thread.html#00160 Version 2 side-steps the objections to the first patch by using a well-formed alternate nbdkit.pc file and running ordinary pkg-config against it, so any parsing of --cflags etc will be done by pkg-config. The first patch is essentially the same idea as: