-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix liblo 0.32 header compatibility #1954
Conversation
@@ -150,7 +150,7 @@ int OSCDataHandler(const char *osc_address, const char *types, lo_arg **argv, | |||
|
|||
if (argc == 1) { | |||
if (type == "b") { | |||
lo_blob blob = argv[0]; | |||
lo_blob blob = (lo_blob)argv[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example code in liblo also uses a regular typecast:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, and thanks for the fix. I was looking for some VERSION symbol in liblo's headers so we could check which version we are building against. However, only a function is provided.
I can confirm that the fix works fine with liblo-0.31 and liblo-0.32, thus I approve the changes.
@peternewman and @nomis52 : Are any older versions of liblo known that we might need to support and that would not compile with these changes?
CI debian sid failure seems unrelated:
|
Yes, indeed, that python3.12-related failure is not new, so nothing you broke :) |
Yeah sadly nothing easy like that and they haven't bumped in such a way we could detect a breaking ABI change either.
I've got an old box with liblo-0.28 still kicking about and it built fine on there too, so I think we're probably fine from that perspective. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @cbix LGTM/still compiles for me on an older version.
It would be good to get this into 0.10 branch too, but one of us can cherry-pick/backport it if you don't want to rebase onto there.
Just to have a note of it, have you (or indeed @kripton ) tested the OSC functionality with this patch or just that it compiles?
not 100 % sure how to test it, I just started olad and ran a python-osc example against its port 7770, couldn't observe any issues or errors but also nothing happens inside |
So it depends which direction you're testing @cbix . There's more detail in the plugin's docs (available from olad or online here): So by default it should listen on: From memory the input side accepts any of the formats of the output side. I think I've used oscdump from liblo-tools to look at data being sent from OLAd in the past. Remember to patch the OSC port to an OLA universe before checking dmxconsole/dmxmonitor (but I suspect you're aware of that bit already). |
Got it, OSC sending and receiving works! Tested with oscdump for output ports and python-osc with random floats and 512 byte blobs for input ports: Screencast.from.2024-04-02.02-01-56.webm |
Perfect thanks @cbix ! Do you want to try and rebase this onto the 0.10 branch, otherwise we can merge what you've got and backport it ourselves? |
@peternewman done :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks @cbix 💯 !
Would it be possible to release an 0.10.10 with that fix? |
Closes: https://bugs.gentoo.org/927000 Upstream-PR: OpenLightingProject/ola#1954 Upstream-Commit: OpenLightingProject/ola@e083653 Signed-off-by: Jannis Achstetter <[email protected]>
Changes to the PR made by marecki at merge time: - run ola-0.10.9-liblo.patch through scrub-patch - revert the revision bump as not needed while fixing build failures Closes: https://bugs.gentoo.org/927000 Upstream-PR: OpenLightingProject/ola#1954 Upstream-Commit: OpenLightingProject/ola@e083653 Signed-off-by: Jannis Achstetter <[email protected]> Signed-off-by: Marek Szuba <[email protected]>
OSCNode
code even simpler (?)