search for: cbint

...| CBArrayAndLen (UInt32 n, len) -> + pr " PyObject *py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n + | CBBytesIn _ + | CBInt _ + | CBInt64 _ -> () + | CBMutable (Int n) -> + pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; + pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; + pr " PyObject *py_%s_mod = PyImport...

...no error possible *) +and closure = { + cbname : string; (* name of callback function *) + cbargs : cbarg list; (* all closures return int for now *) +} +and cbarg = +| CBArrayAndLen of arg * string (* array + number of entries *) +| CBBytesIn of string * string (* like BytesIn *) +| CBInt of string (* like Int *) +| CBInt64 of string (* like Int64 *) +| CBMutable of arg (* mutable argument, eg. int* *) +| CBString of string (* like String *) +| CBUInt of string (* like UInt *) +| CBUInt64 of string (* like UInt64 *) and permitted_state =...

Patches 1-4 are basically uncontroversial, straightforward refactoring and IMHO we should just push them. Possibly 1-3 should be squashed together, but I posted them separately so they are easier to review. Patches 5 and 6 together implement OClosure. Patch 5 adds the feature and is simple to understand. Patch 6 changes the Closure completion callbacks into OClosure, but because it doesn't

...------------------------- > 1 file changed, 186 insertions(+), 242 deletions(-) > Relatively large, but does look like a simplification. > +and cbarg = > +| CBArrayAndLen of arg * string (* array + number of entries *) > +| CBBytesIn of string * string (* like BytesIn *) > +| CBInt of string (* like Int *) > +| CBInt64 of string (* like Int64 *) > +| CBMutable of arg (* mutable argument, eg. int* *) Should we use 'of cbarg' instead of 'of arg' for CBArrayAndLen and CBMutable? Or, as you said above, we could make it a specific ty...

These are some simplifications to the generator. They don't probably make much sense on their own, but they are preparatory to better handling of enums, and or'd lists of flags. Rich.

...[i]));\n" n n + pr " PyObject *py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n | CBBytesIn _ | CBInt _ | CBInt64 _ -> () | CBMutable (Int n) -> - pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; - pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; - pr " PyObj...

This feature is roughly finished now, although it needs a few more tests and some examples. It's pretty much up to par with all the other bindings, but it lacks a completely safe AIO buffer. It won't stop you from freeing the buffer too early) because golang's GC inexplicably lacks a way to declare a root from C. I can probably do it with a global variable and ref counting on the

...Long_FromUnsignedLong (%s[i]));\n" n n + pr " PyObject *py_%s = PyList_New (%s);\n" n len; + pr " for (size_t i = 0; i < %s; ++i)\n" len; + pr " PyList_SET_ITEM (py_%s, i, PyLong_FromUnsignedLong (%s[i]));\n" n n | CBBytesIn _ | CBInt _ | CBInt64 _ -> () | CBMutable (Int n) -> - pr " PyObject *py_%s_modname = PyUnicode_FromString (\"ctypes\");\n" n; - pr " if (!py_%s_modname) { PyErr_PrintEx (0); return -1; }\n" n; - pr " PyObject *py_%s_mod = PyImport...

Now runs a complete set of tests, notably including the AIO test. File descriptors are passed in and out as plain ints (instead of *os.File) for a couple of reasons: (1) We have to pass the plain int to syscall.Select. (2) Turning an fd into an os.File causes golang to set the blocking flag which is deeply unhelpful. Rich.

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.

This doesn't yet work. However it does make me more convinced than ever that we really need to sort out persistent buffer lifetimes in the library (similar to what we did for closures). Rich.

As proposed here: https://www.redhat.com/archives/libguestfs/2019-August/msg00130.html I didn't actually read Eric's replies to that yet because I've been concentrating on writing these patches all day. Anyway here they are and I'll look at what Eric said about the proposal next. Rich.

...uot; -> " (cbargs @ ["int"]) and ocaml_cbarg_to_string = function | CBArrayAndLen (arg, _) -> - sprintf "%s array" (ocaml_arg_to_string (OCamlArg arg)) + sprintf "%s array" (ocaml_arg_to_string arg) | CBBytesIn _ -> "bytes" | CBInt _ -> "int" | CBInt64 _ -> "int64" | CBMutable arg -> - sprintf "%s ref" (ocaml_arg_to_string (OCamlArg arg)) + sprintf "%s ref" (ocaml_arg_to_string arg) | CBString _ -> "string" | CBUInt _ -> "int" |...

Patches 1 & 2 are rather complex, but the end result is that we pass closures + user_data + free function in single struct parameters as I described previously in this email: https://www.redhat.com/archives/libguestfs/2019-August/msg00210.html Patch 3 adds a convenient FREE_CALLBACK macro which seems a worthwhile simplification if you buy into 1 & 2. Patch 4 adds another macro which is