search for: mutability

Mutable (Int n) => int *n This can currently only be used for callback arguments of type int (not for other types, nor for any ordinary function arguments), but it could be implemented more generally in future. --- generator/generator | 75 +++++++++++++++++++++++++++++++++++++-------- 1 file changed, 63 insertions(+), 12 deletions(-) diff --git a/generator/generator b/generator/generator

[RFC because generated OCaml code needs the same treatment, but I ran out of time to play with that. At least 'make -C python check' passes, although coverage is not complete yet, as there is no python/t/5XX-pread-structured-callback.py...] [Also RFC because I'm not sure if the use of a record type for 'callback' is the best approach or most idiomatic OCaml - but hey, it

An upcoming patch to add callbacks for aio completion notification wants to expose Int64 as a callback parameter. It's time to wire that up. --- generator/generator | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/generator/generator b/generator/generator index 45a030f..c5988e2 100755 --- a/generator/generator +++ b/generator/generator @@ -3508,7

Posting now that I got something to compile (at the expense of breaking OCaml bindings), but I'm open to ideas on how to improve it. Eric Blake (2): generator: Tweak print_c_arg_list to take alternate first arg RFC: generator: Handle shared callbacks in Python generator/generator | 556 ++++++++++++++++++++++---------------------- 1 file changed, 280 insertions(+), 276 deletions(-) --

If we accept that callbacks will never handle the full range of parameters then we can simplify the generator quite a bit by using a special type for closure args vs normal method args. This removes many asserts and quite a bit of unreachable code (eg. Python code for handling ArrayAndLen in normal methods that was never used). The output of the generator after this commit should be identical.

In preparation for closure lifetimes, split up the Closure so it no longer describes a list of closures, but a single callback. This changes the API because functions which take 2 or more closures now pass a separate user_data for each one. --- docs/libnbd.pod | 3 +- examples/strict-structured-reads.c | 2 +- generator/generator | 760

This is a bitmask so using an unsigned type is slightly safer. This is not an ABI change since the types are compatible. Thanks: Eric Blake. --- examples/strict-structured-reads.c | 2 +- generator/generator | 67 ++++++++++++++++-------------- interop/structured-read.c | 2 +- lib/internal.h | 2 +- tests/oldstyle.c | 2 +- 5

A Closure is a list of (usually one, but can be more) closures. In C there is also a singe ‘void *user_data’ parameter which is passed by the caller into the function and through as the first parameter of each callback invocation. By grouping the previously separate Opaque and Callback* parameters together we can avoid the awkward situation where we have to scan through the argument list to try

** INCOMPLETE ** This is the generator change as discussed on the list already. The Python and OCaml bindings are not yet done. It passes all [C only] tests and valgrind. Note that nbd_add_close_callback is inconsistent with other closure types because it passes the user_data parameter after the function. (This is not caused by the current patch, it was already inconsistent). We decided that

Define the types which will be used to communicate between the different parts of the inspection code. The main types are: fs corresponds to ‘struct inspect_fs’ in C code root no direct correspondence with the C code, but in the C code, ‘inspect_fs’ was overloaded to store roots inspection_data the inspection data which is incrementally collected about

On 3/7/23 09:35, Richard W.M. Jones wrote: > On Tue, Mar 07, 2023 at 08:48:56AM +0100, Laszlo Ersek wrote: >> On 3/6/23 17:52, Richard W.M. Jones wrote: >> >>> diff --git a/convert/convert_windows.ml b/convert/convert_windows.ml >>> index 9d8d271d05..f36b486359 100644 >>> --- a/convert/convert_windows.ml >>> +++ b/convert/convert_windows.ml

As before, but this one has working Python bindings. OCaml still TBD. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-July/thread.html#00231 The changes address everything that Eric picked up in his review of the first two patches. I have also added two more patches (4 and 5) which respectively fix docs and change int status -> unsigned status, as discussed. Passes make, check, check-valgrind. Rich.

As discussed in this thread, the parameter is an invitation to write code with race conditions: https://www.redhat.com/archives/libguestfs/2019-July/thread.html#00309 --- docs/libnbd.pod | 6 +- examples/glib-main-loop.c | 10 ++-- examples/strict-structured-reads.c | 2 +- generator/generator | 57

Is there any way that a model can be based on a stored procedure or function that so that it can return a set of data based on a parameter provided in either the controller, or s a variable in the model? That way you could: 1) Set the variable 2) Call find_all 3) Get a mutable set of results that takes better advantage of some of the advanced database features available?

This implements most of what I wrote here: https://www.redhat.com/archives/libguestfs/2019-July/msg00213.html

There's a bit of an API glitch with Query objects at present. This code shows it off: Xapian::Database("/path/to/db"); Xapian::Enquire enquire(db); // make a simple query Xapian::Query myquery(Xapian::Query::OP_NEAR, phrase, phrase + 2); enquire.set_query(myquery); // Now change the query - this shouldn't affect the query enquire // will run, but it does.

On 6/25/19 12:11 PM, Richard W.M. Jones wrote: > Mutable (Int n) => int *n > > This can currently only be used for callback arguments of type int > (not for other types, nor for any ordinary function arguments), but it > could be implemented more generally in future. > --- > generator/generator | 75 +++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 63

Dear list, I am writing C code to interface with R, and I would like to know the level of mutability for the type of a SEXP. I see that there is a macro/function TYPEOF(), and that it can be used as an l-value, as well as a macro/function SET_TYPEOF(). My question is "should the type be considered immutable, or it can it change after the SEXP has been created and used for a while ?"....

Previously closures had a crude flag which tells if they are persistent or transient. Transient closures (flag = false) last for the lifetime of the currently called libnbd function. Persistent closures had an indefinite lifetime which could last for as long as the handle. In language bindings handling persistent closures was wasteful as we needed to register a "close callback" to