Products > Programming

Is a C struct flatten in memory (Python wrap for a C lib)?

<< < (4/4)


--- Quote from: RoGeorge ---- Can somebody explain to me in words please "void (*broadcast)(const char *address, const char *interface);"?

--- End quote ---

Have a look at cdecl utility:

--- Code: ---> cdecl explain "void (*broadcast)(const char *, const char *)"
declare broadcast as pointer to function (pointer to const char, pointer to const char) returning void

--- End code ---

It works the other way round as well:

--- Code: ---> cdecl declare "broadcast as pointer to function (pointer to const char, pointer to const char) returning void"
void (*broadcast)(const char *, const char *)

--- End code ---


--- Quote from: Nominal Animal on November 30, 2022, 04:39:23 am ---If you want, I can write you the Python lxi module based on ctypes and liblxi using the following logic:

Class hierarchy:
        HiSlipInstrument (later)

Discover function (module method) returns a list of Instrument objects,
    import lxi
    instruments = lxi.Discover('VXI-11', timeout=10.0, broadcast=None, found=None)
where timeout, broadcast and found are optional callables; found returning False if the instrument is not to be included in the list.

Constructions like
    instruments = []
    instruments +='VXI-11')
    instruments +='MDNS')
would be perfectly acceptable.

This can be extended to lxi_discover_if(), limiting the discovery to specific network interfaces, via additional optional keyword parameter interface later on.

A specific instrument can be chosen from the above list,
    instrument = instruments[0]
constructing an Instrument instance,
    instrument = Instrument('VXI-11', address=b'', port=111, timeout=10.0)
or directly an Instrument subclass instance,
    instrument = VXI11Instrument(address=b'', timeout=10.0)

Default timeout and maximum default response length can be set and queried via
    instrument.timeout = 5.0
    instrument.maxlength = 65536
or used as a named (optional) parameter in the method calls.

(instrument.type would be a read-only string. instrument.address would be bytes and instrument.port int, modifiable while not connected, and readonly when connected.)

The unconnected instance only describes a possible connection.
Communication is only possible after connecting,
and before disconnecting,
and disconnecting is done automatically when the instance is destroyed; setting instrument=None before exiting the Python code would suffice for clean disconnect.

In addition to the SCPI send and receive commands, i.e.
    data = instrument.recv()
it might make sense to do a combined query, ie.
    data = instrument.query(message)

A wrapper module can then be used to extend this to GUI toolkits, with all lxi code run in a separate thread, and queries and responses (both connected and discovery) communicated via Queues.  That part is toolkit-independent; but usually you also want to insert an event in the event loop notifying a response is available from the Queue.

This way, your Qt/Gtk/wxWidgets/FLTK GUI won't stall during any LXI-related event, and on multicore machines, LXI doesn't have to share a CPU core with the Python code, making for much more useful Python applications.

However, it would be nice to hear from the users, if the above interface seems any nicer than the existing one.
(I do not have any LXI/SCPI/VXI-11 instruments myself, but I do often create all sorts of Python and C interfaces to my experimental microcontroller projects.)

--- End quote ---

I welcome any contributions that improve the liblxi python bindings and if you would like to add further object abstraction on top of the cdll/ctypes mappings feel to do so via pull request. I only did the cdll grunt work to map the minimum python bindings directly because a friend requested it and that is why it is not a further polished solution. Actually, someone contributed the original python bindings using the boost library but that is a terrible dependency to introduce for the use of such a simple library so I was compelled to replace it with cdll/ctypes. As maintainer of liblxi I try hard to avoid maintaining language bindings because that is a maintenance burden I simply can't afford among my other open source efforts so any help on that point is appreciated. By the end of the day, such bindings are best made and maintained by those that use them.

Nominal Animal:

--- Quote from: lundmar on November 30, 2022, 12:09:21 pm ---By the end of the day, such bindings are best made and maintained by those that use them.
--- End quote ---
Exactly.  The 'you' in my last post was meant equally as much to you as RoGeorge.

I did not originally do this exactly because I don't have the equipment, so I cannot even test the code; and without seeing your full bindings first, I didn't even know how they were to be used.  The above model is what I came up with after looking at the bindings and the examples, and mapping to the closest Python bindings that I've found to work well.  Even so, it is a guess, and without enthusiastic users willing to test and perhaps even maintain it, it is unnecessary effort.

If one looks at e.g. PyQt5 bindings by RiverBankComputing – a British firm not directly related to Qt –, it is obvious why it is crucial that those who maintain it, themselves also use it.  For one, they need to document the interface and common use cases well, just to save repeating the same efforts in the long run. PySide was also independently developed, and PySide2 folded into the Qt Project only in 2015.  The PySide folks ended up developing API extractor (for Qt-based projects) and Shiboken, somewhat similarly to GObject Introspection to GObject/glib based projects.

In any case, if you get asked about something like this later on or somewhere else, do feel free to throw me or tell them to throw me an email.  The address is shown on my home page, which is linked to from my profile.  I cannot promise anything, but I do love to help just to see/hear others do useful stuff and create new tools, and I always do this stuff for free, only asking to pass the help forwards.


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod