liblo-devel Mailing List for LibLO

Sure, I'm just getting used to the whole "pull request" thing too,
sorry it took me a while to acknowledge.

Steve

On Fri, Oct 19, 2012 at 4:18 AM, Camille Troillard
<ca...@os...> wrote:
> Hi,
>
> I just created a pull request on GitHub.
> This is the first I do this with the new liblo git account, so I hope it will work.
>
> It fixes a simple problem I noticed when receiving TCP messages.
>
>
> Cam
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi all,

Recently while working on integrating timetags and message bundling into
libmapper (www.libmapper.org) I started thinking about the order in which
the various methods matching bundle contents are called. Conceptually, all
the messages in a bundle should take effect at the same time, but in any
given program certain handlers may cause program output while others might
not. Some programs will be written to output at their own rate regardless
of input, so the order in which handlers are called will not matter, but
for users writing method handers that take immediate effect, it seems it
would be nice to be able to specify method priorities.

Currently liblo queues the bundle data, then deserializes each message in
order and dispatches it, meaning methods are called in the same order as
the messages in the bundle. This order was defined by the sending program
and may not make sense in terms of the structure of the receiving program.

I have pushed a branch showing a working version of what I am suggesting:
https://github.com/malloch/liblo/tree/method-priorities

In this branch, the "priority" of a lo_method can be set, so that if
several messages are received in a bundle or are scheduled for the same
time in the future the priority will determine the order in which the
methods will be called.

I added one function to the public API:
void lo_method_set_priority(lo_method m, int priority)

Otherwise there are no API changes. Behind the scenes I made some changes
to server.c, since I needed to check the priority of each method matching a
message before knowing where to place it in the queue. Instead of queueing
the unparsed bundles, I match the bundle contents to methods first and
queue the results ordered by both timestamp and priority.

some disadvantages of this change:
1) if an incoming message matches multiple methods and needs to be queued,
more queue memory will be required since each match will be queued
individually
2) if a bundle arrives with timestamp LO_TT_IMMEDIATE or a timestamp in the
past, more queue memory will be used since the bundle will be queued (and
ordered) before any handlers are called

...and an advantage:
if an incoming message has a future timestamp but does not match any
methods, less queue memory will be required since it will not be queued at
all

Any thoughts?
thanks,
Joe

Joseph Malloch
Input Devices and Music Interaction Laboratory
CIRMMT/BRAMS - McGill University
http://www.josephmalloch.com/
http://www.idmil.org/

Hi Steve,

On 2 oct. 2012, at 20:44, Stephen Sinclair <rad...@gm...> wrote:

> I'm actually still working on this somewhat.  Not for lo_send(), but
> for receiving, I started actually completely reworking the
> lo_server_recv_raw_stream() function to behave in an more asynchronous
> manner.

Cool!


> I was trying to figure out whether I could avoid reserving a big
> buffer for each open socket, but it seems like it may be impossible.
> Instead I'll just reserve a buffer only in cases where the full
> message doesn't arrive in one shot.

OK.
Isn't there a maximum size for a OSC message?
Also, wouldn't it be possible to grow the input buffer is a receive size is too large?


> Basically I'm trying to rewrite it to loop around back to select()
> after each recv(), instead of looping around recv(), and save the
> context if a full message couldn't be retrieved.  It's a bit
> challenging though, so after a couple of hacking sessions I was still
> trying to figure out the right way to organize it..

I see, yes this is not tricky at all.

My 0,02 €:

Have you has the chance to look at this example project:
https://github.com/tuscland/osc-echo-example

This is not C, but conceptually I am sure this can give you a good idea on how to work with asynchronous TCP calls.  Generally the approach is to use the reactor pattern, I don't know how easy it is to implement in C within liblo.


> I don't feel comfortable doing a release with the loop around recv()
> the way it is currently.  Once this is fixed though, I think it's the
> last blocker for 0.27.

I agree.
The SLIP encoding support you just added is great, and it makes the feature set more consistent wrt TCP support I think.


Best,
Cam

Hi,

I just created a pull request on GitHub.
This is the first I do this with the new liblo git account, so I hope it will work.

It fixes a simple problem I noticed when receiving TCP messages.


Cam

Hm, this is worth testing more thoroughly, I hadn't thought about
notifying on connection/disconnection.  Personally I prefer to treat
OSC as connectionless on the application layer, even if it's over TCP
for reliability, but I can see how it would make some sense to allow
per-connection notification in some cases.

Usually if I remember correctly I think the send() or recv() returns 0
if the socket is correctly disconnected, or an error if it is suddenly
disconnected, so Camille is right that you should be able to use this
to detect disconnection while sending.  However since liblo tends to
provide quite some insulation from raw POSIX, it wouldn't be a bad
thing to trigger events.

I'm only a little worried about "callback creep" which has been
happening as features get added...
Maybe it's no big deal though.

Please do try to remember however that OSC is really envisioned as a
stateless, connectionless protocol, meant to carry signal-oriented
data, not really for being a "remote procedure call" mechanism, even
though, of course, it could be used that way.

On the other hand, I could imagine e.g. some kind of synthesizer that
allocates new voices for each connection, among other things.

Steve


On Thu, Oct 4, 2012 at 10:15 AM, Camille Troillard
<ca...@os...> wrote:
> Hi William,
>
> As far as I know, TCP will not notify you on disconnection, unless you read or write the socket in which case you know it is disconnected by the result returned from recv() or send().
>
> In the case of liblo, lo_send_message returns the same value as send() would do, that is:
>
>      Upon successful completion, the number of bytes which were sent is
>      returned.  Otherwise, -1 is returned and the global variable errno is set
>      to indicate the error.
>
>
>
> Best,
> Cam
>
>
>
> On 4 oct. 2012, at 15:51, William Light <li...@wr...> wrote:
>
>> Hey all,
>> Quite stoked about the recent work on OSC over TCP. I'm hoping it's
>> going to make some features I've been mulling over for my application
>> possible.
>>
>> One of the things I need to get, though, is a notification whenever a
>> client disconnects. I need to allocate state for each client, and having
>> disconnection messages *only* at the application layer makes me nervous,
>> especially since TCP takes care of this at the transport layer.
>>
>> Is there any way I could get a notification of a client disconnecting?
>>
>> Regards,
>> -w
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

It's actually more twisted than I initially thought.
I tried again on a clean liblo repository and it failed as initially described.
After uninstalling and reinstalling autoconf, automake and libtool, autogen.sh and configure worked again…  So it was not a version problem but something else.  At least I know how to run the autogen.sh script, but something is definitely broken with the tools.


On 2 oct. 2012, at 20:47, Stephen Sinclair <rad...@gm...> wrote:

> Okay, glad to know there is a solution.  I didn't know about removal
> of autotools from OS X.  Not relying on Apple for this stuff is either
> a good thing or a bad thing, I can't decide.  :)
> 
> Anyways, hopefully after 0.27 we can put together a nice brew formula for liblo!
> 
> Steve
> 
> On Mon, Oct 1, 2012 at 9:18 AM, Camille Troillard <ca...@os...> wrote:
>> OK, I found the solution, and its not a problem with liblo:
>> 
>> One thing not totally obvious with brew is that you need to "update" its definitions from time to time.  In fact this is a feature I like, but this time the autotools that were initially installed had the wrong versions.
>> 
>> So, running `brew update' and then `brew upgrade autoconf automake lib tool' fixed the problem and I can build liblo as before.
>> 
>> The page containing the information that led me to the solution was here:
>> https://github.com/mxcl/homebrew/issues/15077
>> 
>> 
>> Cam
>> 
>> 
>> 
>> 
>> On 1 oct. 2012, at 14:30, Camille Troillard <ca...@os...> wrote:
>> 
>>> Hi,
>>> 
>>> For some obscure reason, I can't get autogen.sh to properly run on my new work environment based on OS X 10.8.  It is awfully frustrating knowing that I am very bad at dealing with automake and autoconf issues.
>>> 
>>> Here's the problem: Xcode does not ship autotools anymore so you have to install them by hand.  Best approach is to install them using brew:
>>> $ brew install automake autoconf
>>> 
>>> Then in liblo source directory:
>>> $ ./autogen.sh
>>> 
>>> **Warning**: I am going to run `configure' with no arguments.
>>> If you wish to pass any to it, please specify them on the
>>> `./autogen.sh' command line.
>>> 
>>> processing .
>>> Running libtoolize...
>>> glibtoolize: putting auxiliary files in `.'.
>>> glibtoolize: copying file `./ltmain.sh'
>>> glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
>>> glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
>>> glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>>> Running aclocal  ...
>>> Running autoheader...
>>> Running automake --gnu  ...
>>> configure.ac:41: error: required file './compile' not found
>>> configure.ac:39: error: required file './config.guess' not found
>>> configure.ac:39: error: required file './config.sub' not found
>>> configure.ac:23: error: required file './install-sh' not found
>>> configure.ac:23: error: required file './missing' not found
>>> examples/Makefile.am: error: required file './depcomp' not found
>>> Running autoconf ...
>>> Running ./configure --enable-maintainer-mode --enable-debug --disable-silent-rules ...
>>> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
>>> 
>>> 
>>> I don't understand why the compile symbolic link and the other files (config.guess, etc.) are not created.  I would tend to suspect a conflict the m4 files shipped with the autotools I installed and this version of OS X.
>>> 
>>> I would really appreciate any kind of help on that matter.
>>> 
>>> 
>>> Thanks!
>>> Cam

Hi William,

As far as I know, TCP will not notify you on disconnection, unless you read or write the socket in which case you know it is disconnected by the result returned from recv() or send().

In the case of liblo, lo_send_message returns the same value as send() would do, that is:

     Upon successful completion, the number of bytes which were sent is
     returned.  Otherwise, -1 is returned and the global variable errno is set
     to indicate the error.



Best,
Cam



On 4 oct. 2012, at 15:51, William Light <li...@wr...> wrote:

> Hey all,
> Quite stoked about the recent work on OSC over TCP. I'm hoping it's
> going to make some features I've been mulling over for my application
> possible.
> 
> One of the things I need to get, though, is a notification whenever a
> client disconnects. I need to allocate state for each client, and having
> disconnection messages *only* at the application layer makes me nervous,
> especially since TCP takes care of this at the transport layer.
> 
> Is there any way I could get a notification of a client disconnecting?
> 
> Regards,
> -w
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hey all,
Quite stoked about the recent work on OSC over TCP. I'm hoping it's
going to make some features I've been mulling over for my application
possible.

One of the things I need to get, though, is a notification whenever a
client disconnects. I need to allocate state for each client, and having
disconnection messages *only* at the application layer makes me nervous,
especially since TCP takes care of this at the transport layer.

Is there any way I could get a notification of a client disconnecting?

Regards,
-w

Okay, glad to know there is a solution.  I didn't know about removal
of autotools from OS X.  Not relying on Apple for this stuff is either
a good thing or a bad thing, I can't decide.  :)

Anyways, hopefully after 0.27 we can put together a nice brew formula for liblo!

Steve

On Mon, Oct 1, 2012 at 9:18 AM, Camille Troillard <ca...@os...> wrote:
> OK, I found the solution, and its not a problem with liblo:
>
> One thing not totally obvious with brew is that you need to "update" its definitions from time to time.  In fact this is a feature I like, but this time the autotools that were initially installed had the wrong versions.
>
> So, running `brew update' and then `brew upgrade autoconf automake lib tool' fixed the problem and I can build liblo as before.
>
> The page containing the information that led me to the solution was here:
> https://github.com/mxcl/homebrew/issues/15077
>
>
> Cam
>
>
>
>
> On 1 oct. 2012, at 14:30, Camille Troillard <ca...@os...> wrote:
>
>> Hi,
>>
>> For some obscure reason, I can't get autogen.sh to properly run on my new work environment based on OS X 10.8.  It is awfully frustrating knowing that I am very bad at dealing with automake and autoconf issues.
>>
>> Here's the problem: Xcode does not ship autotools anymore so you have to install them by hand.  Best approach is to install them using brew:
>> $ brew install automake autoconf
>>
>> Then in liblo source directory:
>> $ ./autogen.sh
>>
>> **Warning**: I am going to run `configure' with no arguments.
>> If you wish to pass any to it, please specify them on the
>> `./autogen.sh' command line.
>>
>> processing .
>> Running libtoolize...
>> glibtoolize: putting auxiliary files in `.'.
>> glibtoolize: copying file `./ltmain.sh'
>> glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
>> glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
>> glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>> Running aclocal  ...
>> Running autoheader...
>> Running automake --gnu  ...
>> configure.ac:41: error: required file './compile' not found
>> configure.ac:39: error: required file './config.guess' not found
>> configure.ac:39: error: required file './config.sub' not found
>> configure.ac:23: error: required file './install-sh' not found
>> configure.ac:23: error: required file './missing' not found
>> examples/Makefile.am: error: required file './depcomp' not found
>> Running autoconf ...
>> Running ./configure --enable-maintainer-mode --enable-debug --disable-silent-rules ...
>> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
>>
>>
>> I don't understand why the compile symbolic link and the other files (config.guess, etc.) are not created.  I would tend to suspect a conflict the m4 files shipped with the autotools I installed and this version of OS X.
>>
>> I would really appreciate any kind of help on that matter.
>>
>>
>> Thanks!
>> Cam
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Camille,

I'm actually still working on this somewhat.  Not for lo_send(), but
for receiving, I started actually completely reworking the
lo_server_recv_raw_stream() function to behave in an more asynchronous
manner.

I was trying to figure out whether I could avoid reserving a big
buffer for each open socket, but it seems like it may be impossible.
Instead I'll just reserve a buffer only in cases where the full
message doesn't arrive in one shot.

Basically I'm trying to rewrite it to loop around back to select()
after each recv(), instead of looping around recv(), and save the
context if a full message couldn't be retrieved.  It's a bit
challenging though, so after a couple of hacking sessions I was still
trying to figure out the right way to organize it..

I don't feel comfortable doing a release with the loop around recv()
the way it is currently.  Once this is fixed though, I think it's the
last blocker for 0.27.

Steve

On Mon, Oct 1, 2012 at 8:22 AM, Camille Troillard <ca...@os...> wrote:
> Hi Steve,
>
> On 28 août 2012, at 21:59, Stephen Sinclair <rad...@gm...> wrote:
>
>>> I am not sure if I understood correctly: so, this version of lo_send_async would call "send" and then return even if the call fails, am I right?
>>> If so, it seems that this is a blocking approach, not asynchronous, because send does not necessarily return right away.
>>
>> No no, I'm suggesting that lo_send_async() would return right away if
>> it's not ready to send.  Using select() to check.  If it _is_ ready to
>> send, it _still_ may not be able to send the whole message, and must
>> call select() again and return if it's not ready.  In that case it
>> still needs to be able to access previously unsent bytes.
>
> Alright then, sounds good to me!
>
>
>>> I believe one way to properly send messages asynchronously would be to use a message queue on which messages would be copied.
>>
>> Yeah, either copied or just maintain pointers.  It might be nice to do
>> it at the byte level and just queue things up in a big byte buffer,
>> like you are suggesting, although I guess that means an error message
>> if the buffer fills up.
>
> Yes, samewise for a queue of messages I guess.
>
>
>>> In fact, this queue does not even need to be implemented into liblo as long as lo_send is designed to loop over "send" until there is no more bytes to send or an error occurred.  A user could implement its own queue and run loop.  So I think lo_send_async is sugar for the future, we don't need it right now.
>>
>> Right, except that means changing the semantics of lo_send(), which is
>> why I was suggesting a new function.  Because currently lo_send() can
>> only return 0 for success or -1 for error.  I suppose we could change
>> it to use a positive number to indicate that some number of bytes
>> still need to be sent -- this would be sort of backwards compatible
>> since old code would error out if the whole message wasn't sent,
>> assuming old code checked "!=0" rather than "<0" or "==-1".  However
>> I'm not sure we have that guarantee.
>
> Now I get it, sorry for the confusion.  I agree the new API lo_send_async would be necessary, and that we can't make the guarantee that users of lo_send switching to lo_send_async can expect the same function results, since the semantics are not the same.
>
>
>>>> It's a bit more than I have time for at the moment however.  A loop
>>>> around send() should do the trick for the synchronous API.  If we're
>>>> tricky about it, in the bidirectional case we could use select() to
>>>> read any incoming data while waiting to write.
>>>
>>> I haven't though about this, thanks for pointing that out.
>>> It's becoming quite complex.
>>
>> Unfortunately.  I don't see a problem introducing new functions to get
>> around current limitations however, we can always consider an API
>> overhaul in the future for a major version update.
>
> Yes, and thank you Steve for the great work on liblo!
>
>
> Best,
> Cam
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

OK, I found the solution, and its not a problem with liblo:

One thing not totally obvious with brew is that you need to "update" its definitions from time to time.  In fact this is a feature I like, but this time the autotools that were initially installed had the wrong versions.

So, running `brew update' and then `brew upgrade autoconf automake lib tool' fixed the problem and I can build liblo as before.

The page containing the information that led me to the solution was here:
https://github.com/mxcl/homebrew/issues/15077


Cam




On 1 oct. 2012, at 14:30, Camille Troillard <ca...@os...> wrote:

> Hi,
> 
> For some obscure reason, I can't get autogen.sh to properly run on my new work environment based on OS X 10.8.  It is awfully frustrating knowing that I am very bad at dealing with automake and autoconf issues.
> 
> Here's the problem: Xcode does not ship autotools anymore so you have to install them by hand.  Best approach is to install them using brew:
> $ brew install automake autoconf
> 
> Then in liblo source directory:
> $ ./autogen.sh
> 
> **Warning**: I am going to run `configure' with no arguments.
> If you wish to pass any to it, please specify them on the
> `./autogen.sh' command line.
> 
> processing .
> Running libtoolize...
> glibtoolize: putting auxiliary files in `.'.
> glibtoolize: copying file `./ltmain.sh'
> glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
> glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
> glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> Running aclocal  ...
> Running autoheader...
> Running automake --gnu  ...
> configure.ac:41: error: required file './compile' not found
> configure.ac:39: error: required file './config.guess' not found
> configure.ac:39: error: required file './config.sub' not found
> configure.ac:23: error: required file './install-sh' not found
> configure.ac:23: error: required file './missing' not found
> examples/Makefile.am: error: required file './depcomp' not found
> Running autoconf ...
> Running ./configure --enable-maintainer-mode --enable-debug --disable-silent-rules ...
> configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
> 
> 
> I don't understand why the compile symbolic link and the other files (config.guess, etc.) are not created.  I would tend to suspect a conflict the m4 files shipped with the autotools I installed and this version of OS X.
> 
> I would really appreciate any kind of help on that matter.
> 
> 
> Thanks!
> Cam
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Steve,

Thank you for digging into this problem.


On 5 sept. 2012, at 20:10, Stephen Sinclair <rad...@gm...> wrote:

> I think this is the best replacement for the current code, without
> changing semantics.  However, finally, I actually think the above may
> still be somewhat wrong.  Although, locally, the hostname is valid,
> there is no reason to think that it is actually the way remotes can
> identify this host.  Rather, there can actually be several IP
> addresses and hostnames associated with a server, namely at minimum
> both the hostname and "localhost".  It makes me wonder if it would be
> appropriate in fact to return a list of URLs, one for each individual
> hostname associated with the computer's interfaces, by calling
> getnameinfo() on each result of getifaddrs().  In practice I'm not
> sure what the user would do with this list, and I think it would get
> confusing, so simply gethostname() seems to be the best approach for
> now.

I agree that gethostname is the best approach.


> It also occurred to me that there's no reason we couldn't upgrade the
> lo_server implementation to simultaneously handle waiting on multiple
> ports and even multiple protocols, since after all it already
> maintains a list of sockets for TCP.  It could be useful to be able to
> make a single server to simultaneously handle UDP and TCP.  But maybe
> that's for another day.

That's an interesting idea.  Currently OSCulator spanws two lo_servers on the same port but different protocols (TCP & UDP), it would be cool to have only one lo_server...


Best,
Cam

Hi,

For some obscure reason, I can't get autogen.sh to properly run on my new work environment based on OS X 10.8.  It is awfully frustrating knowing that I am very bad at dealing with automake and autoconf issues.

Here's the problem: Xcode does not ship autotools anymore so you have to install them by hand.  Best approach is to install them using brew:
$ brew install automake autoconf

Then in liblo source directory:
$ ./autogen.sh

**Warning**: I am going to run `configure' with no arguments.
If you wish to pass any to it, please specify them on the
`./autogen.sh' command line.

processing .
Running libtoolize...
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
Running aclocal  ...
Running autoheader...
Running automake --gnu  ...
configure.ac:41: error: required file './compile' not found
configure.ac:39: error: required file './config.guess' not found
configure.ac:39: error: required file './config.sub' not found
configure.ac:23: error: required file './install-sh' not found
configure.ac:23: error: required file './missing' not found
examples/Makefile.am: error: required file './depcomp' not found
Running autoconf ...
Running ./configure --enable-maintainer-mode --enable-debug --disable-silent-rules ...
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."


I don't understand why the compile symbolic link and the other files (config.guess, etc.) are not created.  I would tend to suspect a conflict the m4 files shipped with the autotools I installed and this version of OS X.

I would really appreciate any kind of help on that matter.


Thanks!
Cam

Hi Steve,

On 28 août 2012, at 21:59, Stephen Sinclair <rad...@gm...> wrote:

>> I am not sure if I understood correctly: so, this version of lo_send_async would call "send" and then return even if the call fails, am I right?
>> If so, it seems that this is a blocking approach, not asynchronous, because send does not necessarily return right away.
> 
> No no, I'm suggesting that lo_send_async() would return right away if
> it's not ready to send.  Using select() to check.  If it _is_ ready to
> send, it _still_ may not be able to send the whole message, and must
> call select() again and return if it's not ready.  In that case it
> still needs to be able to access previously unsent bytes.

Alright then, sounds good to me!


>> I believe one way to properly send messages asynchronously would be to use a message queue on which messages would be copied.
> 
> Yeah, either copied or just maintain pointers.  It might be nice to do
> it at the byte level and just queue things up in a big byte buffer,
> like you are suggesting, although I guess that means an error message
> if the buffer fills up.

Yes, samewise for a queue of messages I guess.


>> In fact, this queue does not even need to be implemented into liblo as long as lo_send is designed to loop over "send" until there is no more bytes to send or an error occurred.  A user could implement its own queue and run loop.  So I think lo_send_async is sugar for the future, we don't need it right now.
> 
> Right, except that means changing the semantics of lo_send(), which is
> why I was suggesting a new function.  Because currently lo_send() can
> only return 0 for success or -1 for error.  I suppose we could change
> it to use a positive number to indicate that some number of bytes
> still need to be sent -- this would be sort of backwards compatible
> since old code would error out if the whole message wasn't sent,
> assuming old code checked "!=0" rather than "<0" or "==-1".  However
> I'm not sure we have that guarantee.

Now I get it, sorry for the confusion.  I agree the new API lo_send_async would be necessary, and that we can't make the guarantee that users of lo_send switching to lo_send_async can expect the same function results, since the semantics are not the same.


>>> It's a bit more than I have time for at the moment however.  A loop
>>> around send() should do the trick for the synchronous API.  If we're
>>> tricky about it, in the bidirectional case we could use select() to
>>> read any incoming data while waiting to write.
>> 
>> I haven't though about this, thanks for pointing that out.
>> It's becoming quite complex.
> 
> Unfortunately.  I don't see a problem introducing new functions to get
> around current limitations however, we can always consider an API
> overhaul in the future for a major version update.

Yes, and thank you Steve for the great work on liblo!


Best,
Cam