search for: tomle

On Wed, Jun 17, 2020 at 5:23 AM Richard W.M. Jones <rjones@redhat.com> wrote: > I pushed 2 & 3, thanks. > > But ... > > > From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > > From: Alan Somers <asomers@gmail.com> > > Date: Mon, 15 Jun 2020 16:59:53 -0600 > > Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level

On Wed, Jun 17, 2020 at 08:42:19AM -0600, alan somers wrote: > On Wed, Jun 17, 2020 at 5:23 AM Richard W.M. Jones <rjones@redhat.com> > wrote: > > > I pushed 2 & 3, thanks. > > > > But ... > > > > > From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > > > From: Alan Somers <asomers@gmail.com> > > >

On Fri, Jul 05, 2019 at 08:37:20AM +0100, Richard W.M. Jones wrote: >On Fri, Jul 05, 2019 at 01:28:12PM +0900, Hiroyuki Katsura wrote: >> > Have you decided whether we need to commit the generated files >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files >> > are still included and not added to .gitignore. >> >> I'm sorry I forgot

> Have you decided whether we need to commit the generated files > (Cargo.toml, Cargo.lock)? It looks like in this series those files > are still included and not added to .gitignore. I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to .gitignore. However, I think Cargo.toml should be staged. This is because this is a file managed by hands. It contains

Still not working, but I took the latest patch and: - rebased it against libnbd 1.0 - fixed it so it handles new args and cbargs The generator now runs without warnings. This patch doesn't handle optargs at all. In C these are converted to non-optional parameter. Rust doesn't (AFAIK) have optional or labelled arguments unfortunately. Rich.

I originally meant to post only the "vector.h" patch, but then (independently) nbdkit wouldn't build. Hence the other (rust plugin) patch. Laszlo Laszlo Ersek (2): common/utils: document empty_vector compound literal assignment plugins/rust: restrict predicates-{tree,core} to {1.0.7,1.0.5} common/utils/vector.h | 8 +++++++- plugins/rust/Cargo.toml | 2 ++ 2 files changed,

I added - data required to publish this crate to `crates.io`. - README.md which contains the details of how to publish this crate. --- rust/Cargo.toml.in | 5 ++++- rust/README.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 46 insertions(+), 1 deletion(-) create mode 100644 rust/README.md diff --git a/rust/Cargo.toml.in b/rust/Cargo.toml.in index b61e3ec7f..d217a530e

I pushed 2 & 3, thanks. But ... > From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > From: Alan Somers <asomers@gmail.com> > Date: Mon, 15 Jun 2020 16:59:53 -0600 > Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level directory > > This is necessary for other Rust projects to depend on unrelesed > versions of the nbdkit crate. > ---

This is just a basic ugly support, not meant to be pushed (at least for now). There is quite a lot missing, but there is an example which shows that it really works. And valgrind reports that all allocations were freed. The way the code is generated is also not nice, I wish there was more code actually written in some files and not generated by the generator (as much hard-coded static strings as

The beautiful world of uncontained dependencies: - We restrict mockall to 0.11.0, which in practice currently expands to 0.11.4, - mockall depends on predicates-tree, - predicates-tree depends on predicates-core, - approx. two weeks ago, predicates-tree and predicates-core have seen *PATCHLEVEL* upgrades (1.0.7 -> 1.0.9, and 1.0.5 -> 1.0.6, respectively) that now require

On Thu, Jun 27, 2019 at 05:06:04PM +0900, Hiroyuki Katsura wrote: > From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > > --- > generator/rust.ml | 13 ++++++++--- > run.in | 9 ++++++++ > rust/Cargo.lock | 6 +++++ > rust/Cargo.toml | 4 +--- > rust/tests/010_load.rs

On Thu, Jun 27, 2019 at 06:27:05PM +0900, Hiroyuki Katsura wrote: > > I guess this is a stray debug message? > > Yes. I'm sorry... > > > we did *not* check them into git. > > Really? Does it mean that every time you build the library, Cargo.toml is > generated? That's how it has worked in nbdkit. Whether it's right or not I don't know. Normally

Hello! Installed packages from SIG on centos7 , at first start it works, but after restart- not: ?glusterd2 --config /etc/glusterd2/glusterd2.toml DEBU[2018-04-04 09:28:16.945267] Starting GlusterD???????????????????????????? pid=221581 source="[main.go:55:main.main]" version=v4.0.0-0 INFO[2018-04-04 09:28:16.945824] loaded configuration from file???????????????

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- generator/rust.ml | 84 ++++++++++++++++++++++++++++++++++++++++++++++- rust/Cargo.toml | 2 ++ 2 files changed, 85 insertions(+), 1 deletion(-) diff --git a/generator/rust.ml b/generator/rust.ml index 83afdfe73..dbe9db010 100644 --- a/generator/rust.ml +++ b/generator/rust.ml @@ -31,4 +31,86 @@ open Events let

I managed to get a build of the async Rust handle compiling on FreeBSD (although the cirrus CI appears to not actually run 'make check' on non-Linux machines, at least when run on my fork): https://gitlab.com/ebblake/libnbd/-/jobs/4985192286 However, I'd really like Tage's review on patch 2 to see if my Rust makes sense. Eric Blake (2): maint: Favor 4-space indent in .rs files

> I guess this is a stray debug message? Yes. I'm sorry... > we did *not* check them into git. Really? Does it mean that every time you build the library, Cargo.toml is generated? > The actual test parts of this patch are fine, but you need to spend a > bit of time with ‘git rebase -i’ to move parts of patch 3 into patch 2. Does this mean that the followings should be moved to

Hi Dmitry, How many nodes does the cluster have ? If the quorum is lost (majority of nodes are down), additional recovery steps are necessary to bring it back up: https://github.com/gluster/glusterd2/wiki/Recovery On Wed, Apr 4, 2018 at 11:08 AM, Dmitry Melekhov <dm at belkam.com> wrote: > Hello! > > Installed packages from SIG on centos7 , > > at first start it works,

There are few more things that could be cleaned up related to the coding style and other things, like explicitly specifying the abi style after "extern" (i.e. `extern "C" fn` instead of `extern fn`), but since those are configurable in rustfmt config, I'm not sure whether the config needs to be added or complying with the defaults should be the priority. But this was just

This adds very rough support for writing nbdkit plugins in Rust. This is not very idiomatic -- essentially we're handling the direct C calls from nbdkit in Rust. We have to use ‘unsafe’ in a few places because there's no way to tell the Rust code that nbdkit satisfies guarantees (eg. around thread safety, always returning leaked pointers back to the close function, always doing bounds