liblo-devel Mailing List for LibLO

On Wed, Oct 29, 2008 at 1:06 AM, Kentaro Fukuchi <fu...@me...> wrote:
> A memory leak fix of lo_url_get_path() follows.
>
> I was going to add a new test to detect this leak (with a memory leak checker)
> and found another issue of the URI form of OSC addressing for UNIX pipe. I'll
> report it in another mail.
>
> diff --git a/src/address.c b/src/address.c
> index 44a801e..d1a5287 100644
> --- a/src/address.c
> +++ b/src/address.c
> @@ -319,6 +319,8 @@ char *lo_url_get_path(const char *url)
>     }
>
>     /* doesnt look like an OSC URL with port number and path*/
> +    free(path);
> +
>     return NULL;
>  }

Applied.  Good stuff!
I'll try to take the time to explicitly hunt down more of these kinds
of things...
Seems like you're finding a lot of dangling mallocs.

Steve

A memory leak fix of lo_url_get_path() follows.

I was going to add a new test to detect this leak (with a memory leak checker)
and found another issue of the URI form of OSC addressing for UNIX pipe. I'll
report it in another mail.

diff --git a/src/address.c b/src/address.c
index 44a801e..d1a5287 100644
--- a/src/address.c
+++ b/src/address.c
@@ -319,6 +319,8 @@ char *lo_url_get_path(const char *url)
     }
 
     /* doesnt look like an OSC URL with port number and path*/
+    free(path);
+
     return NULL;
 }

--
Kentaro Fukuchi

On Thu, Oct 16, 2008 at 6:49 AM, Kentaro Fukuchi <fu...@me...> wrote:
> Hi Stephen,
>
> I divided my contribution into three patches attached to this mail.
> There patches are for the latest mainline in the git tree. Please apply
> them in the following order.
>
> 1. lo_url_get_protocol_id.patch    - adds lo_url_get_protocol_id().
> 2. lo_address_new_with_proto.patch - adds lo_address_new_with_proto().
> 3. code_cleaning.patch             - improves lo_address_new_from_url().

Committed, thanks!

I integrated parts of the testlo patch into 1 and 2 as appropriate and
made sure it's successful.
Thanks for the extra effort, this had slipped my mind in the last week.


Steve

Hi,

I forgot to attach the 4th patch that adds some tests to testlo.c.

Kentaro

Hi Stephen,

I divided my contribution into three patches attached to this mail.
There patches are for the latest mainline in the git tree. Please apply
them in the following order.

1. lo_url_get_protocol_id.patch    - adds lo_url_get_protocol_id().
2. lo_address_new_with_proto.patch - adds lo_address_new_with_proto().
3. code_cleaning.patch             - improves lo_address_new_from_url().

regards,

Kentaro Fukuchi

Hi,

I was rushing into the solution. I have found that this problem was already
covered by the latest release of autoconf (version 2.63).

http://lists.gnu.org/archive/html/autoconf/2008-09/msg00065.html

> ** AC_C_BIGENDIAN does not mistakenly report "universal" for some
>    bigendian hosts, a regression introduced with universal binary
>    support in 2.62.

I have not tested liblo with autoconf 2.63 yet, but probably this
problem can be solved with it.

Sorry for confusion.

Kentaro Fukuchi

On Thu, Oct 9, 2008 at 3:16 PM, Stephen Sinclair <rad...@gm...>wrote:

>
> No that's not what I said.  The autoconf configuration should take
> care of the endianness without problems.  Kentaro is talking about
> some breakage in how autoconf is handling endianness, which adversely
> seems to affect the liblo build.
> This is the first I've heard of it and I haven't had a chance to test,
> so I can't say how serious a problem it is, but as long as
> LO_BIGENDIAN is set correctly you should be fine.


ok, sorry for the confusion.



> > This is a bummer, as I always trusted liblo on this side, however my
> users
> > do not seems to have problems anyhow …  very strange.
>
> That's good news. :)  But if you're deploying on ppc without testing
> it yourself, that might be something you should consider doing, just
> as a general rule of thumb.


I did test on a ppc machine :^)
but endianness problems can be nasty, so I prefer to know your opinion as
well.


> I would really appreciate to have pointers on how to create a universal
> > binary version of a static library version of liblo 0.25 on OS X (intel
> > machine) !!!
>
> Maybe you can tell me how it goes. :)  I usually develop on Linux.  I
> do have access to a few macs through my lab at school though, so I can
> compile, but I don't do it on a regular basis.  On the other hand, I'm
> interested in making sure liblo is usable on as many platforms as
> possible, so if you run into trouble building a universal, tell me if
> you had to make any changes and we can try to fix it.


I didn't but I actually made a Xcode project to compile a static version of
liblo.
I can send it to anyone who is interested in it.


Best,
Cam

On Thu, Oct 9, 2008 at 9:03 AM, Camille Troillard <ca...@os...> wrote:
> Hey Steve,
>
> On Thu, Oct 9, 2008 at 2:58 PM, Stephen Sinclair <rad...@gm...>
> wrote:
>>
>> Anyways I've always had more success on OS X just compiling things
>> twice.. once on a ppc machine, once on an Intel machine, and then
>> combining the binaries manually with lipo.  Not ideal, but at least
>> it's clearer what is going on.
>
> Uh, are you saying that the code in liblo doesn't take care of the endianess
> automatically?

No that's not what I said.  The autoconf configuration should take
care of the endianness without problems.  Kentaro is talking about
some breakage in how autoconf is handling endianness, which adversely
seems to affect the liblo build.
This is the first I've heard of it and I haven't had a chance to test,
so I can't say how serious a problem it is, but as long as
LO_BIGENDIAN is set correctly you should be fine.

> This is a bummer, as I always trusted liblo on this side, however my users
> do not seems to have problems anyhow …  very strange.

That's good news. :)  But if you're deploying on ppc without testing
it yourself, that might be something you should consider doing, just
as a general rule of thumb.

> I would really appreciate to have pointers on how to create a universal
> binary version of a static library version of liblo 0.25 on OS X (intel
> machine) !!!

Maybe you can tell me how it goes. :)  I usually develop on Linux.  I
do have access to a few macs through my lab at school though, so I can
compile, but I don't do it on a regular basis.  On the other hand, I'm
interested in making sure liblo is usable on as many platforms as
possible, so if you run into trouble building a universal, tell me if
you had to make any changes and we can try to fix it.

Steve

You're right, your answer sounds wise.And exposing the function publicly
opens doors to the possibility to implement such custom protocols.



On Thu, Oct 9, 2008 at 3:08 PM, Stephen Sinclair
<sin...@mu...>wrote:

>
> You mean built-in support for a ringbuffer as a protocol?
>
> Mmmmaybe.. I'm not sure.  I thought maybe a good approach would be to
> just expose these functions so it makes it possible for the
> application to use any special communication mechanism it wants to.
> Implementing extra, non-standard protocols might be outside the scope
> of what LibLo is intended for.
>
> The problem is then, how many different protocols would need
> implementing.. serial ports, ringbuffers, shared memory ringbuffers.
> What kind of ringbuffer? One-reader-one-writer,
> multiple-reader-one-writer, one-reader-multiple-writer.. the list goes
> on.  It might be opening a big can of worms to try and support these
> things.
>
> A better approach might be to build a seperate library on top of LibLo
> to do these things.   Or alternatively (or in addition), bring up the
> issue on the OSC-dev mailing list, and try to get some opinions on
> whether these things should be standardized.  The OSC developers
> unfortunately have been rather silent on standardizing transport
> mechanisms, but it's an important part of the protocol.  (See, for
> example, the uncertainty in how to do the TCP stuff.)
>
>
> Steve
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Thu, Oct 9, 2008 at 5:40 AM, Camille Troillard <ca...@os...> wrote:
> Hey Stephen,
> This looks very interesting.
> I was actually thinking that OSC over shared memory ipc would be great for
> my application.  Do you think that this could be something we'd add to
> liblo?

You mean built-in support for a ringbuffer as a protocol?

Mmmmaybe.. I'm not sure.  I thought maybe a good approach would be to
just expose these functions so it makes it possible for the
application to use any special communication mechanism it wants to.
Implementing extra, non-standard protocols might be outside the scope
of what LibLo is intended for.

The problem is then, how many different protocols would need
implementing.. serial ports, ringbuffers, shared memory ringbuffers.
What kind of ringbuffer? One-reader-one-writer,
multiple-reader-one-writer, one-reader-multiple-writer.. the list goes
on.  It might be opening a big can of worms to try and support these
things.

A better approach might be to build a seperate library on top of LibLo
to do these things.   Or alternatively (or in addition), bring up the
issue on the OSC-dev mailing list, and try to get some opinions on
whether these things should be standardized.  The OSC developers
unfortunately have been rather silent on standardizing transport
mechanisms, but it's an important part of the protocol.  (See, for
example, the uncertainty in how to do the TCP stuff.)


Steve

Hey Steve,

On Thu, Oct 9, 2008 at 2:58 PM, Stephen Sinclair <rad...@gm...>wrote:

>
> Anyways I've always had more success on OS X just compiling things
> twice.. once on a ppc machine, once on an Intel machine, and then
> combining the binaries manually with lipo.  Not ideal, but at least
> it's clearer what is going on.


Uh, are you saying that the code in liblo doesn't take care of the endianess
automatically?
This is a bummer, as I always trusted liblo on this side, however my users
do not seems to have problems anyhow …  very strange.

I would really appreciate to have pointers on how to create a universal
binary version of a static library version of liblo 0.25 on OS X (intel
machine) !!!


Best,
Cam

On Thu, Oct 9, 2008 at 8:32 AM, Kentaro Fukuchi <fu...@me...> wrote:
> Hi all,
>
> I have tried to compile the trunk of the liblo on OS X 10.5 with the latest
> macports. The macports provides autoconf-2.62 and it causes an endian problem.
>
> Now with the endian-checker of autoconf returns newly added value 'universal'
> on OS X instead of 'yes' or 'no'. In configure.ac, AC_C_BIGENDIAN is called
> with two arguments.
>
> AC_C_BIGENDIAN([LO_BIGENDIAN="1"], [LO_BIGENDIAN="0"])
>
> The first expression is for big endian, and the second for little endian.
> Now AC_C_BIGENDIAN of autoconf-2.62 is extended for 'universal' environment.
> It now requires four argumnets like this:
>
> # AC_C_BIGENDIAN ([ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-UNKNOWN],
> #                 [ACTION-IF-UNIVERSAL])
> (from share/autoconf/autoconf/c.m4)
>
> So now we have a question. LO_BIGENDIAN should be 1 or 0 for OS X?

Yuck, this is ugly.

As Camille said, the endianness depends on the CPU, not the operating system.
So a universal build would probably need more changes than just
deciding on LO_BIGENDIAN.  Perhaps, according to your link, the value
of LO_BIGENDIAN could be set to __BIG_ENDIAN__, and it would
automatically follow?

Anyways I've always had more success on OS X just compiling things
twice.. once on a ppc machine, once on an Intel machine, and then
combining the binaries manually with lipo.  Not ideal, but at least
it's clearer what is going on.


Steve

Hi Kentaro,
I am a poor autoconf developer, so I can't help you there.
But perhaps it might help you to know that the endianness of macs depend on
the cpu (ppc or i386).


Cheers,
Camille


On Thu, Oct 9, 2008 at 2:37 PM, Kentaro Fukuchi <fu...@me...> wrote:

> > So now we have a question. LO_BIGENDIAN should be 1 or 0 for OS X?
>
> This document from Apple shows the hint?
>
> "Universal Binary Programming Guidelines, Second Edition"
>
> http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_compiling/chapter_2_section_7.html
>
> Kentaro
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Thu, Oct 9, 2008 at 5:59 AM, Kentaro Fukuchi <fu...@me...> wrote:
> Hi all,
>
> Did anyone try to compile liblo on Windows, without the mingw or any kind of
> UNIXen support? I would like to use liblo from a C++ program developed on VC++.

Absolutely.  I used the attached patch on liblo 0.24 to compile it
with VS 2005 Express.  So this I know works well.  The other one is an
attempt to port this forward to the latest svn, but I can't be sure it
will work since I haven't tested it.

You can see some *rough* things in there.  I want to include support
for VS more "officially" but it requires some ugly changes.  In
particular VC++ doesn't support variable-argument macros, which are
used quite a lot in liblo.  (These are not really official C standard
I think.)

This means, in additional to including lots of #ifdefs to declare the
functions differently, having to disable the LO_MARKER_A and
LO_MARKER_B magic which is done to ensure that parameters match the
type string.

Anyways, I hope to clean this up somehow, sometime.  I was using VC++
a lot for doing work on Windows up until about a year ago, when I
discovered that mingw makes many Windows-related problems go away. :)

Oh yeah, if these patches don't work for you, you could also try Alex
Bouenard's CMake build:
http://www-valoria.univ-ubs.fr/Alexandre.Bouenard/index.php/Coding/Cross-Compiling#toc1

He's got it working on liblo 0.25, and I think he told me it works for VS too.

Steve

> So now we have a question. LO_BIGENDIAN should be 1 or 0 for OS X?

This document from Apple shows the hint?

"Universal Binary Programming Guidelines, Second Edition"
http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_compiling/chapter_2_section_7.html

Kentaro

Hi all,

I have tried to compile the trunk of the liblo on OS X 10.5 with the latest
macports. The macports provides autoconf-2.62 and it causes an endian problem.

Now with the endian-checker of autoconf returns newly added value 'universal'
on OS X instead of 'yes' or 'no'. In configure.ac, AC_C_BIGENDIAN is called
with two arguments.

AC_C_BIGENDIAN([LO_BIGENDIAN="1"], [LO_BIGENDIAN="0"])

The first expression is for big endian, and the second for little endian.
Now AC_C_BIGENDIAN of autoconf-2.62 is extended for 'universal' environment.
It now requires four argumnets like this:

# AC_C_BIGENDIAN ([ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-UNKNOWN],
#                 [ACTION-IF-UNIVERSAL])
(from share/autoconf/autoconf/c.m4)

So now we have a question. LO_BIGENDIAN should be 1 or 0 for OS X?



Kentaro Fukuchi

Hi all,

Did anyone try to compile liblo on Windows, without the mingw or any kind of
UNIXen support? I would like to use liblo from a C++ program developed on VC++.

Kentaro Fukuchi

Hey Stephen,
This looks very interesting.
I was actually thinking that OSC over shared memory ipc would be great for
my application.  Do you think that this could be something we'd add to
liblo?


Best,
Cam


On Tue, Oct 7, 2008 at 4:47 PM, Stephen Sinclair <rad...@gm...>wrote:

> Hi,
>
> I have made the lo_server_dispatch_data() function public in the svn
> This function is used internally to take a block of received OSC data
> and deserialise it into a lo_message, then check if we have a handler
> and subsequently either dispatch or queue the message.
>
> Now that we have a serialise() and deserialise() function, I realised
> it would be nice to actually be able to handle serialised data without
> having to go through the network recv() call.  This means now we can
> go between lo_message and raw OSC representations of OSC data
> directly, and actually *handle* the messages.  I'm using it currently
> in a program to transmit OSC messages in a circular buffer, for
> example.  lo_message_serialise() on the sender, copy it to the buffer,
> and lo_server_dispatch_data() on the receiving end.  For low-latency
> between threads, it seems much more efficient than making a system
> call to the network layer.
>
> I imagine this would also be useful for other means of transmitting
> OSC, for example if you had a serial port reader you might want to
> implement your own buffering code, then call lo_server_dispatch_data()
> on it.
>
> Eventually I hope to make the UDP networking code conditional with
> autoconf.  This might make liblo useful for embedded applications for
> example.  Also, it might make it possible to support
> OSC-over-shared-memory-IPC.
>
> Comments (and testing!) appreciated!
>
>
> Steve
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi,

I have made the lo_server_dispatch_data() function public in the svn
This function is used internally to take a block of received OSC data
and deserialise it into a lo_message, then check if we have a handler
and subsequently either dispatch or queue the message.

Now that we have a serialise() and deserialise() function, I realised
it would be nice to actually be able to handle serialised data without
having to go through the network recv() call.  This means now we can
go between lo_message and raw OSC representations of OSC data
directly, and actually *handle* the messages.  I'm using it currently
in a program to transmit OSC messages in a circular buffer, for
example.  lo_message_serialise() on the sender, copy it to the buffer,
and lo_server_dispatch_data() on the receiving end.  For low-latency
between threads, it seems much more efficient than making a system
call to the network layer.

I imagine this would also be useful for other means of transmitting
OSC, for example if you had a serial port reader you might want to
implement your own buffering code, then call lo_server_dispatch_data()
on it.

Eventually I hope to make the UDP networking code conditional with
autoconf.  This might make liblo useful for embedded applications for
example.  Also, it might make it possible to support
OSC-over-shared-memory-IPC.

Comments (and testing!) appreciated!


Steve