Issue with oscpack #50
Comments
|
@MyunginLee Have you seen this issue when compiling for M1s? Since it is an assertion, I am guessing that release builds don't catch this issue, as we have built on M1 devices. The issue is only for ints, so we have not seen issues as their use is less common. I am guessing the source of the problem is here external/oscpack/osc/OscTypes.h:64 : Can you try changing: to |
|
If the M1 for some reason passes this test:
can you try changing the contents of that branch? |
|
Hi, I didn't specifically experienced that issue maybe because I have Rosetta 2 installed. and didn't work since int32_t is undefined. Including this didn't work: so I tried: and it showed: |
|
Ah, yes, perhaps oscpack is note being compiled with C++11 support, so
perhaps
#include <cstdin>
will work.
…On Mon, Jun 6, 2022 at 2:56 PM Myungin Lee ***@***.***> wrote:
Hi, I didn't specifically experienced that issue maybe because I have
Rosetta 2 installed.
So I noticed my system goes to else instead of:
#if defined(__x86_64__) || defined(_M_X64)
and
typedef int32_t int32;
typedef uint32_t uint32;
didn't work since int32_t is undefined.
Including this didn't work:
#include <ctypes>
so I tried:
#include <ctype.h>
and it showed:
In file included from /Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:73:9: error: unknown type name 'int32_t'; did you mean '__int32_t'?
typedef int32_t int32;
^~~~~~~
__int32_t
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/arm/_types.h:20:33: note: '__int32_t' declared here
typedef int __int32_t;
^
In file included from /Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:74:9: error: unknown type name 'uint32_t'
typedef uint32_t uint32;
^
2 errors generated.
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADK3R2EOQZEXB27S5S7VKLVNZXYXANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
how about <cstdint>? (or stdint.h)---- On Mon, 06 Jun 2022 14:56:28 -0700 Myungin ***@***.***> wrote ----
Hi, I didn't specifically experienced that issue maybe because I have Rosetta 2 installed.
So I noticed my system goes to else instead of:
#if defined(__x86_64__) || defined(_M_X64)
and
typedef int32_t int32;
typedef uint32_t uint32;
didn't work since int32_t is undefined.
Including this didn't work:
#include <ctypes>
so I tried:
#include <ctype.h>
and it showed:
In file included from /Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:73:9: error: unknown type name 'int32_t'; did you mean '__int32_t'?
typedef int32_t int32;
^~~~~~~
__int32_t
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/arm/_types.h:20:33: note: '__int32_t' declared here
typedef int __int32_t;
^
In file included from /Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:74:9: error: unknown type name 'uint32_t'
typedef uint32_t uint32;
^
2 errors generated.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Yes, that's the correct one. Thanks!
…On Mon, Jun 6, 2022 at 2:59 PM Keehong Youn ***@***.***> wrote:
how about <cstdint>? (or stdint.h)---- On Mon, 06 Jun 2022 14:56:28 -0700
Myungin ***@***.***> wrote ----
Hi, I didn't specifically experienced that issue maybe because I have
Rosetta 2 installed.
So I noticed my system goes to else instead of:
#if defined(__x86_64__) || defined(_M_X64)
and
typedef int32_t int32;
typedef uint32_t uint32;
didn't work since int32_t is undefined.
Including this didn't work:
#include <ctypes>
so I tried:
#include <ctype.h>
and it showed:
In file included from
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:73:9:
error: unknown type name 'int32_t'; did you mean '__int32_t'?
typedef int32_t int32;
^~~~~~~
__int32_t
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/arm/_types.h:20:33:
note: '__int32_t' declared here
typedef int __int32_t;
^
In file included from
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.cpp:37:
/Users/ben/Desktop/projects/allolib_playground/allolib/external/oscpack/osc/OscTypes.h:74:9:
error: unknown type name 'uint32_t'
typedef uint32_t uint32;
^
2 errors generated.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you are subscribed to this thread.Message ID:
***@***.***>
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADK3R234BAAEJFROMZJ65LVNZYEXANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Including |
|
int == int32_t, one of the overloads should be disabled. It's our local copy so it should be fine. Maybe pick one that would be more frequently used? |
|
Something else to consider could be moving away from oscpack? I have wanted
to set up the OSC dependency as something that does parsing only on top of
raw cross platform sockets? (something that bothers me is that the buffer
size for messages in oscpack is pretty small... - we could change that too
in our local copy)
Perhaps something like:
https://github.com/mhroth/tinyosc
or:
https://github.com/ssilverman/LiteOSCParser
…On Mon, Jun 6, 2022 at 3:17 PM Keehong Youn ***@***.***> wrote:
int == int32_t, one of the overloads should be disabled. It's our local
copy so it should be fine. Maybe pick one that would be more frequently
used?
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADK3RZ5KJFK62NMWCOI6ULVNZ2HZANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Yes, using al_Socket for networking and using smaller one to only serialize/deserialize would be a good option. |
|
Yes..
http://gruntthepeon.free.fr/oscpkt/
But, but lot of examples would change.
…On Mon, Jun 6, 2022, 18:37 Keehong Youn ***@***.***> wrote:
Yes, using al_Socket for networking and using smaller one to only
serialize/deserialize would be a good option.
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMILJSX6EFJHCU25JTFMBDVN2RVXANCNFSM5X7OZWBQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Perhaps as we are wrapping the OSC library in al_Osc, it should be possible
to retain the API that uses the streaming operator.
…On Mon, Jun 6, 2022 at 9:07 PM karl yerkes ***@***.***> wrote:
Yes..
http://gruntthepeon.free.fr/oscpkt/
But, but lot of examples would change.
On Mon, Jun 6, 2022, 18:37 Keehong Youn ***@***.***> wrote:
> Yes, using al_Socket for networking and using smaller one to only
> serialize/deserialize would be a good option.
>
> —
> Reply to this email directly, view it on GitHub
> <
#50 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAMILJSX6EFJHCU25JTFMBDVN2RVXANCNFSM5X7OZWBQ
>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADK3R5SFSWVRC57MO3DWSLVN3DJVANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
oscpkt looks great. Perhaps the best of the three (at least on paper).
…On Mon, Jun 6, 2022 at 9:07 PM karl yerkes ***@***.***> wrote:
Yes..
http://gruntthepeon.free.fr/oscpkt/
But, but lot of examples would change.
On Mon, Jun 6, 2022, 18:37 Keehong Youn ***@***.***> wrote:
> Yes, using al_Socket for networking and using smaller one to only
> serialize/deserialize would be a good option.
>
> —
> Reply to this email directly, view it on GitHub
> <
#50 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAMILJSX6EFJHCU25JTFMBDVN2RVXANCNFSM5X7OZWBQ
>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADK3R5SFSWVRC57MO3DWSLVN3DJVANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Graham turned me on to it years ago. I use it frequently, but I have not
stress-tested it.
Retain the stream operator? Noooooooo... ;)
…On Mon, Jun 6, 2022, 22:10 Andres Cabrera ***@***.***> wrote:
oscpkt looks great. Perhaps the best of the three (at least on paper).
On Mon, Jun 6, 2022 at 9:07 PM karl yerkes ***@***.***> wrote:
> Yes..
>
> http://gruntthepeon.free.fr/oscpkt/
>
> But, but lot of examples would change.
>
> On Mon, Jun 6, 2022, 18:37 Keehong Youn ***@***.***> wrote:
>
> > Yes, using al_Socket for networking and using smaller one to only
> > serialize/deserialize would be a good option.
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <
>
#50 (comment)
> >,
> > or unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/AAMILJSX6EFJHCU25JTFMBDVN2RVXANCNFSM5X7OZWBQ
> >
> > .
> > You are receiving this because you are subscribed to this
thread.Message
> > ID: ***@***.***>
> >
>
> —
> Reply to this email directly, view it on GitHub
> <
#50 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AADK3R5SFSWVRC57MO3DWSLVN3DJVANCNFSM5X7OZWBQ
>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#50 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMILJQH7Z4EFULUE24Z6B3VN3KTRANCNFSM5X7OZWBQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thank you for the information, this directed us to a temporary solution, modifying the oscpack library. So it looks like the below conditional needs to return true on their machines: This meant making modifications to the conditionals in the following files |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Trying to install and run allolib. Examples that do not require graphics work fine (eg: example_math_random) but examples that require Parameter OSC Handshake server like all the graphics examples do not. This issue has been produced on two of the new macs with M1 chips, but could not be reproduced with a mac with an i9 processor.
Assertion failed: (sizeof(osc::int32) == 4), function OutboundPacketStream, file /[path]/C++/allolib/external/oscpack/osc/OscOutboundPacketStream.cpp, line 166.
Abort trap: 6
Heres the error message generated by the macOS system:
Process: example_graphics_cieColor [75498]
Path: /Users/USER/Desktop/*/example_graphics_cieColor
Identifier: example_graphics_cieColor
Version: 0
Code Type: ARM-64 (Native)
Parent Process: bash [75445]
Responsible: Terminal [75442]
User ID: 502
Date/Time: 2022-05-30 13:53:19.048 -0400
OS Version: macOS 11.3.1 (20E241)
Report Version: 12
The text was updated successfully, but these errors were encountered: