Failed to load libseekcamera.so from default system paths

[emartin-216]

Hi,

I have struggled to run this code, and I believe I'm missing something from the installation instructions that is causing this but I am not sure what. When I try to run pip install -e ., I get permission errors. Could this be causing the code to not work?

Below is the following error message:

Traceback (most recent call last): File "/home/pi/Documents/libseek-thermal-master/examples/seekcamera-python/seekcamera/_clib.py", line 107, in configure_dll _cdll = ctypes.CDLL(lib) File "/usr/lib/python3.7/ctypes/init.py", line 356, in init self._handle = _dlopen(self._name, mode) OSError: libseekcamera.so: cannot open shared object file: No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "seekcamera-opencv.py", line 166, in main() File "seekcamera-opencv.py", line 131, in main with SeekCameraManager(SeekCameraIOType.USB) as manager: File "/home/pi/Documents/libseek-thermal-master/examples/seekcamera-python/seekcamera/camera.py", line 543, in init _clib.configure_dll() File "/home/pi/Documents/libseek-thermal-master/examples/seekcamera-python/seekcamera/_clib.py", line 109, in configure_dll raise RuntimeError("Failed to load %s from default system paths" % lib) RuntimeError: Failed to load libseekcamera.so from default system paths

[pickx]

from what I can see, this would first require adding serde support to arbitrary-int.

are we looking for Deserialize support here as well? I think we can just deserialize to a temporary struct and then use the Struct::new().

[hecatia-elegua]

@pizzart if you're up to it, you can try building this. We can skip over serde support in arbitrary-int by just saving as the underlying type, or you could add that support as well (should be easy).

[widberg]

I have a rough draft of this at https://github.com/widberg/bilge using https://github.com/danlehmann/arbitrary-int/pull/38. It doesn't play nice with padding and reserved fields yet. I think these fields should not be serialized so I will probably skip them like the generated new implementation. Some cleanup is also in order.

[hecatia-elegua]

@widberg nicely done, feel free to open a draft PR :)

[widberg]

I was waiting for the arbitrary-int pr to go through so I wouldn't have my git repo as a dependency but I'll open a draft pr so it's easier to find and update it later.

[dicta]

The arbitrary-int PR looks like it was merged and released as part of v1.2.7, is there more work that needs to be done to revive this feature? This would be very nice to have, specifically the serialize side of things.

[widberg]

I switched the Cargo.toml dependency from my arbitrary-int git repo to v1.2.7 on crates.io and switched the PR from draft to open. My tests are passing but please test my repo and let me know if there are any problems.

[hecatia-elegua]

@dicta you might know a bit more about serde than me, take a look at the code in #84. Or even try it with your usecase via git repo dependency. I will merge it soon.

[dicta]

I've been testing this today and it's working well so far for my usecase -- which is just using SerializeBits, not the deserialize side.

Features I'm currently exercising are:

• interop with csv and serde_json crates, ensuring that field names are handled
• bitfields containing a mix of arbitrary-int and standard u8/u16/etc types
• enums (the error path indicating to use Serialize instead of SerializeBits for enums is nice!)
• structs containing multiple bitfield members, some of which derive SerializeBits and others do not
• single reserved member

Important features I haven't yet looked at so can't comment on status:

• DeserializeBits (at all)
• #[bitsize(N)] where N is an arbitrary-int type, not a standard-width integer
• multiple reserved members in a single bitfield