similar to: Welcome Hiroyuki Katsura as Google Summer of Code 2019 student

Thanks. I'll summarize the project and issue an outline of the implementation to the mailing list soon. (I'm not familiar with mailing lists so I'm sorry if this message is passed to a wrong place.) Hiroyuki Katsura

Hi, I'm Hiroyuki Katsura. I will contribute to libguestfs as a Google Summer of Code project. I'll start to develop from next week. I'm going to work on the project "Create Rust bindings for libguestfs." Project summary is available here. https://summerofcode.withgoogle.com/projects/#6730007286644736 Now, I'll show you the detail of the project. This is the reprint of

This patch includes: - Event callback handlers - Tests related to events(410-430) --- generator/rust.ml | 38 ++++++- rust/src/base.rs | 24 +++-- rust/src/error.rs | 8 +- rust/src/event.rs | 158 ++++++++++++++++++++++++++++ rust/src/lib.rs | 2 + rust/tests/040_create_multiple.rs | 2 +-

I fixed based on comments. I'll send these two patches to this mailing list. - Fix Handle -> Handle<'a> - Add events Regards, Hiroyuki 2019年8月1日(木) 0:01 Pino Toscano <ptoscano@redhat.com>: > Hi Hiroyuki, > > On Tuesday, 30 July 2019 07:51:37 CEST Hiroyuki Katsura wrote: > > This patch includes: > > > > - Event callback handlers > > -

Hi! I'm currently a final year student of Informatics Institute of Technology Sri Lanka affiliated with the University of Westminster, a successful GSOC 2017 participant <https://summerofcode.withgoogle.com/projects/#6522320890888192>. Witnessing the usage of machine learning and information retrieval I'm keen to contribute to The Xapian project thus, enhancing my skills in machine

> Can you explain which errors did you get? I tried pod2markdown on a > couple of API longdesc's, and the result seemed OK. > Most probably we will need to write our own pod2markdown though, as > pod2markdown does not allow users to customize all the options that > the Pod::Markdown module has. Yes. Most of the results seemed OK. But, for example, translating

> 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

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

> 2019/08/13 1:01、Pino Toscano <ptoscano@redhat.com>のメール: > > On Sunday, 11 August 2019 06:42:21 CEST Hiroyuki Katsura wrote: >> `cargo doc` will generate docs with long descriptions. > > This is a nice start, although most probably it will not look that good > though (since the plain text output may be misrendered as markdown). > > I remember we talked about

Hi Hiroyuki, sorry for the late reply. Most of the work is definitely nice! There are few notes below, although they are not big issues. I will check this patch once more on monday, especially the rust parts. Otherwise, I'd say that we are close to merging this :) On Tuesday, 23 July 2019 10:37:17 CEST Hiroyuki Katsura wrote: > From: Hiroyuki_Katsura

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

Dear Richard, > We have tended to avoid this in other languages because the results > can be very poor quality (eg. swig bindings are usually terrible). > However if the resulting code from bindgen is high quality and > accurately covers all the features that libguestfs bindings need then > we can consider it. Thank you for your reply. Actually, I have not used bindgen and I

Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key

On Tue, Jul 02, 2019 at 10:14:19PM +0900, Hiroyuki Katsura wrote: >From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > >--- > Makefile.am | 4 ++++ > configure.ac | 3 +++ > generator/Makefile.am | 3 +++ > generator/bindtests.ml | 3 +++ > generator/bindtests.mli | 1 + > generator/main.ml | 5 +++++ > generator/rust.ml

Hi, I'm now implementing generators of Rust, and I faced a problem. In order for the wrapper to 'understand' the struct passed from C API, it is required to incorporate the definition of the struct in C into Rust code. I have two approaches. 1. Create raw struct(#[repr(C)]), which has the equivalent memory mapping to C struct and access through this struct in Rust 2. Use bindgen to

On Monday, 5 August 2019 08:59:31 CEST Hiroyuki Katsura wrote: > Without clarifying handle's lifetime, it is unable > to see how long the callbacks which the handle > owns will live. Then, Rust compiler will infer > that the callbacks have 'static lifetime. It is > not convenient for users. > --- My initial idea was to split the Handle -> Handle<'a> change

> So this has a lifetime same as the whole handle? Yes. > Why do you then need to keep > it in the list of callbacks then? Because I want to make sure that callbacks must exist while they are running. > Also you explicitly leak it here, so even > without a lifetime it will not get freed. If you do not explicly write lifetime here, the pointer will have static lifetime.

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

Dear Rich I waited for Pino’s response because I failed to divide this patch into two commits as Pino thought. Is it OK? Regards, Hiroyuki > On Aug 6, 2019, at 23:16, Richard W.M. Jones <rjones@redhat.com> wrote: > > > These look fine to me and they don't break the build so I have > pushed both. > > Thanks. > > Rich. > > -- > Richard Jones,

This patch includes: - Event callback handlers - Tests related to events(410-430) src/bin/event.rs and src/bin/event_leak.rs are the PoCs that Boxes related to callbacks are not leaked. --- rust/src/bin/.gitkeep | 0 rust/src/bin/event.rs | 29 ++++++ rust/src/bin/event_leak.rs | 30 ++++++ rust/src/error.rs | 6 ++ rust/src/event.rs