liblo-devel Mailing List for LibLO

On Tue, Mar 26, 2013 at 6:47 AM, Camille Troillard
<ca...@os...> wrote:
> Talking about lo_address_set_flags, I have a couple of questions ...
>
> It seems lo_address_set_flags is not public, is it intentional?

Nope, thanks for pointing that out.

> Also, the flags type for lo_address_set_flags is named lo_proto_flags, shouldn't we rather name it lo_address_flags?

Yes, perhaps.  I had only used it for details about the protocol (i.e.
which stream type to use) so I was calling them "protocol flags", but
you're right, perhaps they are "address flags".

> Finally, it would be nice to provide a name for the uninitialized flag, for example LO_NOFLAG=0x00.

Sure, I don't mind either way.

cheers,
Steve

Talking about lo_address_set_flags, I have a couple of questions ...

It seems lo_address_set_flags is not public, is it intentional?

Also, the flags type for lo_address_set_flags is named lo_proto_flags, shouldn't we rather name it lo_address_flags?

Finally, it would be nice to provide a name for the uninitialized flag, for example LO_NOFLAG=0x00.

Steve, let me know your thoughts and I will add similar option flags for lo_server.

Cam


On 25 mars 2013, at 21:55, Stephen Sinclair <rad...@gm...> wrote:

> I'm not really against an API addition to turn off coercion.  I've
> already added a set of option flags for lo_address, something similar
> for lo_server might make sense.

On 25 mars 2013, at 21:55, Stephen Sinclair <rad...@gm...> wrote:

> I'm not really against an API addition to turn off coercion.  I've
> already added a set of option flags for lo_address, something similar
> for lo_server might make sense.

I will implement a solution and submit a patch via Github.

Cam

On Mon, Mar 25, 2013 at 4:44 PM, Camille Troillard
<ca...@os...> wrote:
> Hi Steve,
>
>
> On 25 mars 2013, at 21:15, Stephen Sinclair <rad...@gm...> wrote:
>
>> On the other hand automatically truncating floats to int doesn't
>> necessarily make sense in most cases.  More problematically, I would
>> guess that registering an 'i' and then an 'f' handler would cause the
>> 'i' handler to always be called, instead of matching on 'i' or 'f' as
>> you might expect.
>>
>> Personally I would consider it a bit dangerous to have very different
>> semantics associated with a message depending on the type of its
>> arguments, but on the other hand I do find the automatic coercion a
>> bit of a hazard to be aware of.
>
> Yes. In the case I had in mind, I want to define OSC API that uses integers only.  Floats would not make sense, so I understand I should discard any message that has different types than those that were defined with the handler.  It seems it can be done easily by testing strcmp on the typespec argument of the handler callback.

Sure, I guess that could work.  A bit ugly :(
I'm not really against an API addition to turn off coercion.  I've
already added a set of option flags for lo_address, something similar
for lo_server might make sense.

> In another use-case, the float and int values have different but close semantics.  Float are considered as normalized values (0.0 to 1.0) and integers as absolute values (depending on the range, for example 0 to 127).

So yeah, there's a case where you should be aware of the Pd / Max
behaviour.. if that's an intended usage scenario anyways.

Steve

Hi Steve,


On 25 mars 2013, at 21:15, Stephen Sinclair <rad...@gm...> wrote:

> Yup, liblo has always had type coercion as far as I know.  Currently
> there's no way to turn it off.  There are some funny effects depending
> on how programs deal with numbers.. for instance, Pure Data (which
> only supports floating point numbers) sends 'i' messages if the number
> is a whole number, or 'f' otherwise.  So scrolling a number box e.g.
> from 0.9 to 1.1 in Pure Data can actually result in the following
> messages being sent,
> 
> /message ,f 0.9
> /message ,i 1
> /message ,f 1.1
> 
> In that case it sort of makes sense to handle 'i' and 'f' as equivalent.

I agree.  I think Max/MSP also behaves the same way.


> On the other hand automatically truncating floats to int doesn't
> necessarily make sense in most cases.  More problematically, I would
> guess that registering an 'i' and then an 'f' handler would cause the
> 'i' handler to always be called, instead of matching on 'i' or 'f' as
> you might expect.
> 
> Personally I would consider it a bit dangerous to have very different
> semantics associated with a message depending on the type of its
> arguments, but on the other hand I do find the automatic coercion a
> bit of a hazard to be aware of.

Yes. In the case I had in mind, I want to define OSC API that uses integers only.  Floats would not make sense, so I understand I should discard any message that has different types than those that were defined with the handler.  It seems it can be done easily by testing strcmp on the typespec argument of the handler callback.

In another use-case, the float and int values have different but close semantics.  Float are considered as normalized values (0.0 to 1.0) and integers as absolute values (depending on the range, for example 0 to 127).

Thank you Steve for the clarification, it makes better sense.  I think this is an interesting feature to be aware of, which can be handled on an application specific basis.


Best,
Cam

Hi,

Yup, liblo has always had type coercion as far as I know.  Currently
there's no way to turn it off.  There are some funny effects depending
on how programs deal with numbers.. for instance, Pure Data (which
only supports floating point numbers) sends 'i' messages if the number
is a whole number, or 'f' otherwise.  So scrolling a number box e.g.
from 0.9 to 1.1 in Pure Data can actually result in the following
messages being sent,

/message ,f 0.9
/message ,i 1
/message ,f 1.1

In that case it sort of makes sense to handle 'i' and 'f' as equivalent.

On the other hand automatically truncating floats to int doesn't
necessarily make sense in most cases.  More problematically, I would
guess that registering an 'i' and then an 'f' handler would cause the
'i' handler to always be called, instead of matching on 'i' or 'f' as
you might expect.

Personally I would consider it a bit dangerous to have very different
semantics associated with a message depending on the type of its
arguments, but on the other hand I do find the automatic coercion a
bit of a hazard to be aware of.

Steve


On Mon, Mar 25, 2013 at 5:53 AM, Camille Troillard
<ca...@os...> wrote:
> OK, I can see in server.c at line 1646 that liblo does implicit type coercion.
> In my application, integers and floats arguments have different semantic values, is there a way to turn that feature off?
>
> I'd like to discuss if this feature should be kept in liblo 1.0, or make it optional (at the expense of adding a new API for controlling that behavior).  In my experience this only serves a few cases where integers and floats can be freely interchanged, and I honestly did not find a lot of applications where this was the case.
>
>
> Cam
>
>
> On 25 mars 2013, at 10:44, Camille Troillard <ca...@os...> wrote:
>
>> Hello,
>>
>> Using the latest version on the Github repository.
>> If I register the following method handler:
>>
>>    lo_server_add_method(server, "/path", "i", MyHandler, user_info);
>>
>> And send the message:
>>
>>    /path ,f 0.42
>>
>> To the server on which the previous handler was registered.  Then I expect that the message is not handled, however liblo calls my handler with the defined "i" type.  I find it surprising, should I?
>>
>>
>> Best,
>> 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_d2d_mar
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hello,

Using the latest version on the Github repository.
If I register the following method handler:

    lo_server_add_method(server, "/path", "i", MyHandler, user_info);

And send the message:

    /path ,f 0.42

To the server on which the previous handler was registered.  Then I expect that the message is not handled, however liblo calls my handler with the defined "i" type.  I find it surprising, should I?


Best,
Cam

OK, I can see in server.c at line 1646 that liblo does implicit type coercion.
In my application, integers and floats arguments have different semantic values, is there a way to turn that feature off?

I'd like to discuss if this feature should be kept in liblo 1.0, or make it optional (at the expense of adding a new API for controlling that behavior).  In my experience this only serves a few cases where integers and floats can be freely interchanged, and I honestly did not find a lot of applications where this was the case.


Cam


On 25 mars 2013, at 10:44, Camille Troillard <ca...@os...> wrote:

> Hello,
> 
> Using the latest version on the Github repository.
> If I register the following method handler:
> 
>    lo_server_add_method(server, "/path", "i", MyHandler, user_info);
> 
> And send the message:
> 
>    /path ,f 0.42
> 
> To the server on which the previous handler was registered.  Then I expect that the message is not handled, however liblo calls my handler with the defined "i" type.  I find it surprising, should I?
> 
> 
> Best,
> Cam
> 

Hi,

On Thu, Feb 28, 2013 at 3:37 PM, Karl Svec <kar...@gm...> wrote:
> Hello,
>
> I'm using MinGW-w64 with GCC 4.7.1 from the mingw-builds project
> (http://mingw-builds.googlecode.com), and the linker complains of syntax
> errors when parsing the generated DEF file. I have binutils version
> 2.22.90.20120727.
>
> Microsoft's documentation states that a DEF file must begin with "LIBRARY
> *.dll", and this is missing from src/liblo.def.in. It's possible that
> earlier versions of binutils were a bit more lax and would handle
> "malformed" DEF files.
>
> See http://msdn.microsoft.com/en-us/library/d91k01sh%28v=vs.80%29.aspx
>
> By adding "LIBRARY liblo-7.dll" to the top of src/liblo.def.in, I was able
> to build a liblo DLL successfully.
>
> Perhaps liblo's libtool script needs some slight changes?

Hm, thanks for pointing this out.  In principle the LIBRARY line could
be added by autoconf, but I can't quite figure out how to
auto-generate the "liblo-7.dll" filename.  That is to say, I'm not
100% sure where the -7 comes from.  Clearly it is related to the
LO_SO_VERSION string, but I think libtool is doing some magic to get
that filename...

I suppose I will just hard-code it for now, but it would be great to
figure out how to do it properly.

Steve

Hi,

On Tue, Feb 26, 2013 at 5:34 PM, Alexandre Quessy <ale...@qu...> wrote:
> Hello Steve,
>
> 2013/2/14 Stephen Sinclair <rad...@gm...>:
>> What segfaults?  It shouldn't.  Isn't the liblo error handler getting
>> called?  It should just report an error saying that the port is
>> unavailable.
>> On Thu, Feb 14, 2013 at 11:26 AM, Alexandre Quessy <ale...@qu...> wrote:
>>> When I create a second liblo receiver on the same port, it segfaults.
>
> Oh! It's because I call lo_server_add_method on a NULL lo_server.
> So, the lo_err_handler callback doesn't accept a pointer as an
> user-defined argument. I cannot pass a pointer this. (I am using C++)
> I assume that with a non-threaded server, lo_server_new will return me
> a NULL pointer.
>
> What if was using a threaded server?

Yeah the lack of a context pointer is surely an unfortunate oversight.
 Actually in commit 8f2b954, I added a thread-safe API (uses pthread
mutex) to pass a context pointer to the error handler by a global
variable, somewhat side-stepping this issue without changing the API.
Hopefully we can eventually fix this in an API-breaking future version
of liblo.  (After 0.27, I'm thinking maybe we should make a breaking
1.0 fork to help fix several difficult issues like this..)

Anyways, the thread-safe API in commit 8f2b954 adds the following
function calls,

void lo_server_set_error_context(lo_server s, void *user_data);

and then in the error handler you can call, lo_error_get_context()
which will return the user_data pointer for the server that threw the
error.

Steve