liblo-devel Mailing List for LibLO

On Thu, Jun 5, 2008 at 5:19 AM, Camille Troillard <ca...@os...> wrote:
>> Strange, the 3rd argument is just int*, and the line is:
>> lo_message msg = lo_message_deserialise(data, size, &result);
>>
>> where result is an int.  Do you also get this warning on line 666,
>> which is almost exactly the same?
>
> No, only on line 649, perhaps the message is not repeated.
> It seems that the function definition of lo_message_deserialise uses a
> ssize_t * as third argument, whereas an int * is given here.
> Do you think it could be the problem?

Ah, no it was the opposite.  lo_message_deserialize() uses int* as
third argument, but the result variable was re-defined inside the
scope as ssize_t.  Fixed now by renaming it.  Thanks.


>> > 3.  The autogen.sh script doesn't work on Mac OS X.  It seems like it
>> > tries
>> > to use a utility named libtoolize that is not present on the platform.
>>
>> Not sure off the top of my head how best to deal with that but I'll
>> think about it.  It would be good to add it to the bug tracker.
>
> libtool is available on Mac OS X though.
> I'm wondering why libtoolize is not present …
> after some search here is what I found :
> http://trac.lighttpd.net/trac/ticket/973
>
> The following is necessary on Mac OS X (10.4.8):
>
> LIBTOOLIZE=glibtoolize sh ./autogen.sh

How strange.  Anyways, I fixed it.
Didn't notice it previously because in my OS X account I had installed
an up-to-date version of autotools for another project.


thanks, let me know if you notice more things.

Steve

On Thu, Jun 5, 2008 at 3:03 AM, Stephen Sinclair <rad...@gm...>
wrote:

>
> > I had the same problem with sending a value to SuperCollider.  The sent
> > value was a float (4000.0) and SuperCollider was unable to coerce it to
> an
> > int of value 4000, instead it coerced it to the value 4001.
> > I'd like to show more precise examples, perhaps someone else has
> something
> > to share about this?
>
>
> This is a new one to me.  The code uses "htonl" quite a lot to try and
> normalize endianness, but it's possible it could be missing somewhere.
>  I think, though, without more information, it might be very difficult
> to track it down.
> Some experimentation with Max will be needed I guess.
>
> However, if it's a problem with converting between float and integers,
> this doesn't sound like endianness.  (If the endian is wrong in a
> float, the int value would be waaay off.
>

Yes, I realize that this should not be an endianess problem after all.



> I don't know whether there are differences in how ppc and intel handle
> float conversions.  There shouldn't be, I think.  It would be nice to
> look at the network bytes in more detail.
>
> If you want to share some logs of byte-level transmissions, you could
> use the following command:
>
> nc -l -u -p <port> | hexdump -C  >logfile.txt


Thanks for the command line, I'll take a look and try to reproduce the
problem with SuperCollider to give a precise example.



> 2.  There is a compilation warning on Mac OS X (from svn trunk code): at
> > line 649 of server.c "warning: passing argument 3 of
> > 'lo_message_deserialise' from incompatible pointer type"
> > Not very serious, but I thought you should know.
>
> Strange, the 3rd argument is just int*, and the line is:
> lo_message msg = lo_message_deserialise(data, size, &result);
>
> where result is an int.  Do you also get this warning on line 666,
> which is almost exactly the same?


No, only on line 649, perhaps the message is not repeated.
It seems that the function definition of lo_message_deserialise uses a
ssize_t * as third argument, whereas an int * is given here.
Do you think it could be the problem?



> > 3.  The autogen.sh script doesn't work on Mac OS X.  It seems like it
> tries
> > to use a utility named libtoolize that is not present on the platform.
>
> Not sure off the top of my head how best to deal with that but I'll
> think about it.  It would be good to add it to the bug tracker.


libtool is available on Mac OS X though.
I'm wondering why libtoolize is not present …

after some search here is what I found :

http://trac.lighttpd.net/trac/ticket/973

The following is necessary on Mac OS X (10.4.8):

LIBTOOLIZE=glibtoolize sh ./autogen.sh

Best,
Cam

Hi Camille,

On Wed, Jun 4, 2008 at 7:15 PM, Camille Troillard <ca...@os...> wrote:
> Hi everyone,
> Hi Stephan,
> There are three things I have noticed I'd like to share with you all:
> 1.  On Mac OS X, it seems like the seralisation/deserialisation it not
> exactly the same when you compare PPC and Intel platforms.  There is maybe a
> bug of endianness, it is just a feeling.  I have some users that complained
> that the value they sent from Max/MSP to my application had different
> behaviours when performed on a PPC and an Intel machine.  There may be some
> rouding error as the sent argument was a float (1.0) and the received value
> was something more than 1 (like 1.000001).
> I had the same problem with sending a value to SuperCollider.  The sent
> value was a float (4000.0) and SuperCollider was unable to coerce it to an
> int of value 4000, instead it coerced it to the value 4001.
> I'd like to show more precise examples, perhaps someone else has something
> to share about this?


This is a new one to me.  The code uses "htonl" quite a lot to try and
normalize endianness, but it's possible it could be missing somewhere.
 I think, though, without more information, it might be very difficult
to track it down.
Some experimentation with Max will be needed I guess.

However, if it's a problem with converting between float and integers,
this doesn't sound like endianness.  (If the endian is wrong in a
float, the int value would be waaay off.

I don't know whether there are differences in how ppc and intel handle
float conversions.  There shouldn't be, I think.  It would be nice to
look at the network bytes in more detail.

If you want to share some logs of byte-level transmissions, you could
use the following command:

nc -l -u -p <port> | hexdump -C  >logfile.txt



> 2.  There is a compilation warning on Mac OS X (from svn trunk code): at
> line 649 of server.c "warning: passing argument 3 of
> 'lo_message_deserialise' from incompatible pointer type"
> Not very serious, but I thought you should know.

Strange, the 3rd argument is just int*, and the line is:
lo_message msg = lo_message_deserialise(data, size, &result);

where result is an int.  Do you also get this warning on line 666,
which is almost exactly the same?


> 3.  The autogen.sh script doesn't work on Mac OS X.  It seems like it tries
> to use a utility named libtoolize that is not present on the platform.

Not sure off the top of my head how best to deal with that but I'll
think about it.  It would be good to add it to the bug tracker.


thanks,
Steve

Hi everyone,Hi Stephan,

There are three things I have noticed I'd like to share with you all:

1.  On Mac OS X, it seems like the seralisation/deserialisation it not
exactly the same when you compare PPC and Intel platforms.  There is maybe a
bug of endianness, it is just a feeling.  I have some users that complained
that the value they sent from Max/MSP to my application had different
behaviours when performed on a PPC and an Intel machine.  There may be some
rouding error as the sent argument was a float (1.0) and the received value
was something more than 1 (like 1.000001).

I had the same problem with sending a value to SuperCollider.  The sent
value was a float (4000.0) and SuperCollider was unable to coerce it to an
int of value 4000, instead it coerced it to the value 4001.

I'd like to show more precise examples, perhaps someone else has something
to share about this?


2.  There is a compilation warning on Mac OS X (from svn trunk code): at
line 649 of server.c "warning: passing argument 3 of
'lo_message_deserialise' from incompatible pointer type"
Not very serious, but I thought you should know.


3.  The autogen.sh script doesn't work on Mac OS X.  It seems like it tries
to use a utility named libtoolize that is not present on the platform.


Best,
Camille