liblo-devel Mailing List for LibLO

Hi,

On Sun, Sep 14, 2008 at 4:56 PM, Dave Griffiths <da...@pa...> wrote:
> Hi Steve,
>
>>> In version 0.25 of liblo, lo_arg_size() has gone. I can't find mention
>>> of it in the docs, any pointers?
>>
>> When adding the validation code, some of the internal functions were
>> moved to src/lo_internal.h.
>> This is mainly used for liblo to determine arguments for memcpy and
>> memory allocation.
>> Perhaps it shouldn't have been moved, though I'd be curious to know
>> how you're using it.
>
> It seems I'm using it in order to get the total size of a message's
> arguments in order to copy them from a message into a ring buffer - see
> DefaultHandler() here:
> http://cvs.savannah.gnu.org/viewvc/fluxus/fluxa/src/OSCServer.cpp?root=fluxus&view=markup
>
> It's ages since I wrote this, so there might be a better approach without
> using it...

Okay, after some thought it was probably a mistake to consider
lo_arg_size() as an internal function.  I can see it might be useful
in some cases to get the argument size, though admittedly it's a bit
weird since there are few cases where you'd need the argument size in
a type-generic way.  Even in your example you loop through the
arguments and do type-specific things, but for reserving memory in
advance it's clearly a useful function.

More useful for your situation though, I think it would be great to
have functions to help defer OSC messages or pass them around to other
threads for manual dispatch, storing them in a ringbuffer and then
removing them, for example.  Some thought on that subject would pay
off well I think.  I've personally had to modify liblo in the past to
allow me to pass off OSC messages for handling in another thread.  In
other words, an API layer treating OSC messages as raw memory that can
be passed around might be very handy.

I don't know how I managed to move this function without thinking
clearly about it, but there are a few other functions that got moved
into lo_internal.h that maybe shouldn't have:

lo_get_path()
lo_arg_host_endian()
lo_arg_network_endian()

They are all arguably internal: lo_get_path() isn't necessary in
message handlers since it is provided as a parameter, and the
endianness converters are used before messages are dispatched and thus
a bit unnecessary.

But I will probably move them back as well, just on the idea that it
breaks the published API.


Steve

Hi Steve,

>> In version 0.25 of liblo, lo_arg_size() has gone. I can't find mention
>> of it in the docs, any pointers?
>
> When adding the validation code, some of the internal functions were
> moved to src/lo_internal.h.
> This is mainly used for liblo to determine arguments for memcpy and
> memory allocation.
> Perhaps it shouldn't have been moved, though I'd be curious to know
> how you're using it.

It seems I'm using it in order to get the total size of a message's
arguments in order to copy them from a message into a ring buffer - see
DefaultHandler() here:
http://cvs.savannah.gnu.org/viewvc/fluxus/fluxa/src/OSCServer.cpp?root=fluxus&view=markup

It's ages since I wrote this, so there might be a better approach without
using it...

cheers,

dave

On Sun, Sep 14, 2008 at 6:03 AM, Dave Griffiths <da...@pa...> wrote:
> Hi all,
>
> In version 0.25 of liblo, lo_arg_size() has gone. I can't find mention
> of it in the docs, any pointers?

When adding the validation code, some of the internal functions were
moved to src/lo_internal.h.
This is mainly used for liblo to determine arguments for memcpy and
memory allocation.
Perhaps it shouldn't have been moved, though I'd be curious to know
how you're using it.

Steve

Hi all,

In version 0.25 of liblo, lo_arg_size() has gone. I can't find mention
of it in the docs, any pointers? 

cheers,

dave

Hi folks,

Since I'm using git to sync with the subversion repository for LibLo,
I figured it couldn't hurt to make it available for anyone who wants
to work with it instead of using subversion.  I'll be regularly
syncing the master branch of the git repository with the subversion
repository.  Using git makes experimental work easier without
requiring svn access or public branching.

After a bit of consideration I decided (for now) on gitorious.org to
host it.  It's available here:

git clone git://gitorious.org/liblo/mainline.git

Please feel free to stick with svn if you'd like, since that will
still be considered the official trunk.


Steve

On Mon, 8 Sep 2008 18:09:53 -0400
"Stephen Sinclair" <rad...@gm...> wrote:
 
> Okay, at first look I can see that it is useful.  I see that a null
> check was missing in lo_address_new.  Also, I guess the memory leak
> you are referring to is the change you made in server.c?  It would be
> nice if you had split up these into different commits so that I can
> see clearly what is what.

Right. I had accidentally committed all patches at once.

Brief summary was written in ChangeLog, and here I wrote detailed docs
about the patches:
Memory leaks were found in server.c and address.c. The leak in dispatch_method()
is that exiting the function without freeing the list of strings. The other leak
in lo_address_new_from_url() is the missing free(a) when an error is occurred.

> I think the name lo_url_get_protocol2 is not very descriptive.
> Perhaps we could call it lo_url_get_protocol_id.
Thanks, I changed.

> Otherwise, I think the patch is quite good, thanks.
> Shall I split it up and apply it with the changed function name?  You
> can then base your changes to oscsend/dump off the new trunk.

Okay, I'm preparing patches.

thanks,

Kentaro

Hello!

On Sun, Sep 7, 2008 at 8:27 AM, Kentaro Fukuchi <fu...@me...> wrote:
> Hi,
>
> I just created a new branch named 'kentaro' in the SVN tree to test the
> implementation of lo_address_new_with_proto(). If you have a spare time,
> please check it out and your comments are welcome.
>
> During the tests of above, I found some possible memory leak bugs in the
> main trunk. I have already committed the fixes, but your check is needed
> to make the official release robust. In order to achieve the diff, type
> svn diff -r123:124
> in trunk/.


Okay, at first look I can see that it is useful.  I see that a null
check was missing in lo_address_new.  Also, I guess the memory leak
you are referring to is the change you made in server.c?  It would be
nice if you had split up these into different commits so that I can
see clearly what is what.

I think the name lo_url_get_protocol2 is not very descriptive.
Perhaps we could call it lo_url_get_protocol_id.

Otherwise, I think the patch is quite good, thanks.
Shall I split it up and apply it with the changed function name?  You
can then base your changes to oscsend/dump off the new trunk.

Steve

Hi,

I just created a new branch named 'kentaro' in the SVN tree to test the
implementation of lo_address_new_with_proto(). If you have a spare time,
please check it out and your comments are welcome.

During the tests of above, I found some possible memory leak bugs in the
main trunk. I have already committed the fixes, but your check is needed
to make the official release robust. In order to achieve the diff, type
svn diff -r123:124
in trunk/.

On Sat, 6 Sep 2008 19:42:25 +0900
Kentaro Fukuchi <fu...@me...> wrote:

> Hi all,
> 
> Current liblo does not provide a function to set protocol of lo_address.
> Only one method to set protocol to TCP or UNIX, you have to call
> lo_address_new_from_url(). How about to add new function like
> lo_address_new_with_proto()?

best regards,

Kentaro

Hi all,

Current liblo does not provide a function to set protocol of lo_address.
Only one method to set protocol to TCP or UNIX, you have to call
lo_address_new_from_url(). How about to add new function like
lo_address_new_with_proto()?

For example in pseudo code, 

lo_address lo_address_new_with_proto(int protocol, const char *host, const char *port)
{
  if(protocol = LO_UDP) {
    simply call lo_address_new()
  } else if(protocol == LO_TCP) {
    set a->protocol to LO_TCP
  } else if(protocol == LO_UNIX) {
    set a->protocol to LO_UNIX. Just ignore the host
  }
}

Request your comment.

Kentaro Fukuchi