liblo-devel Mailing List for LibLO

Sounds dangerous. :)

I mean, maybe.. but I wouldn't be completely against just having a new
function to install an "enhanced" error handler for a server.
lo_server_add_error_handler() or something.

I guess it depends how badly this is needed.  I can see why it would
be useful, now I'm kicking myself for not thinking of this when we
bumped the soname version.

I suppose it could always be added in a future version if we decide to
increase soname again.  I'm not totally scared of breaking an API as
long as it actually causes compiler errors and isn't a silent failure.
 However I don't have an impression of how much existing code depends
on liblo's error handling.

Steve


On Tue, Mar 23, 2010 at 9:42 AM, Steve Harris
<S.W...@ec...> wrote:
> There may be some hack using variadic functions which would be back
> compatible, but it would be a bit hairy.
>
> You'd still need two versions of lo_err_handler (I think), but the
> handler function pointers would be back compatible.
>
> - Steve
>
> On 22 Mar 2010, at 17:24, Philippe Mougin wrote:
>
>> Hi Stephen,
>>
>> As a maintainer of some code myself I completely sympathize with
>> your answer. Breaking current client code is clearly out of
>> question, I believe. And I can live with the current way of handling
>> errors (I communicate them to the other parts of my app with a
>> static/global variable, which is still manageable and can be made
>> thread safe if needed).
>> Thanks
>>
>> Philippe
>>
>> Le 22 mars 2010 à 13:58, Stephen Sinclair a écrit :
>>
>>> I can see why it would be useful to pass the lo_server pointer to the
>>> lo_err_handler.  Associating a user_data field to lo_server might
>>> then
>>> solve your problem.  Unfortunately this wouldn't be simple to fix
>>> in a
>>> backward-compatible way without adding a whole extra handler type and
>>> maintain two different error handlers for each server.  Or we could
>>> break ABI/API compatibility and introduce this argument to
>>> lo_err_handler.  However I'm not really willing to do that right now
>>> seeing how long it took to get 0.46 accepted into distros due to very
>>> minor API changes.
>>>
>>> If anyone has a better suggestion I'm all ears.
>>>
>>> Steve
>>>
>>>
>>> On Wed, Mar 17, 2010 at 2:24 PM, Philippe Mougin <pm...@ac...>
>>> wrote:
>>>> Hi,
>>>>
>>>> In my application, which makes use of liblo, I'd very much like to
>>>> see error handling callbacks (i.e., lo_err_handler type functions)
>>>> be provided a "user data" information when called, much like
>>>> method handlers (i.e., lo_method_handler) callbacks are passed in
>>>> a void *user_data argument. Such "user data" would be provided by
>>>> application code to liblo along references to the error handler
>>>> functions (e.g., a new lo_server creation function similar
>>>> lo_server_new would be added to liblo and take an addtional void *
>>>> argument representing the user data).
>>>>
>>>> Or maybe there already is a nice way to achieve something similar
>>>> (i.e., being able to create error handler functions that interact
>>>> with other elements of my application without using thread-safe
>>>> adverse things like global variables) ?
>>>>
>>>> Thanks.
>>>>
>>>> Philippe Mougin
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel&#174; Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> liblo-devel mailing list
>>>> lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

There may be some hack using variadic functions which would be back  
compatible, but it would be a bit hairy.

You'd still need two versions of lo_err_handler (I think), but the  
handler function pointers would be back compatible.

- Steve

On 22 Mar 2010, at 17:24, Philippe Mougin wrote:

> Hi Stephen,
>
> As a maintainer of some code myself I completely sympathize with  
> your answer. Breaking current client code is clearly out of  
> question, I believe. And I can live with the current way of handling  
> errors (I communicate them to the other parts of my app with a  
> static/global variable, which is still manageable and can be made  
> thread safe if needed).
> Thanks
>
> Philippe
>
> Le 22 mars 2010 à 13:58, Stephen Sinclair a écrit :
>
>> I can see why it would be useful to pass the lo_server pointer to the
>> lo_err_handler.  Associating a user_data field to lo_server might  
>> then
>> solve your problem.  Unfortunately this wouldn't be simple to fix  
>> in a
>> backward-compatible way without adding a whole extra handler type and
>> maintain two different error handlers for each server.  Or we could
>> break ABI/API compatibility and introduce this argument to
>> lo_err_handler.  However I'm not really willing to do that right now
>> seeing how long it took to get 0.46 accepted into distros due to very
>> minor API changes.
>>
>> If anyone has a better suggestion I'm all ears.
>>
>> Steve
>>
>>
>> On Wed, Mar 17, 2010 at 2:24 PM, Philippe Mougin <pm...@ac...>  
>> wrote:
>>> Hi,
>>>
>>> In my application, which makes use of liblo, I'd very much like to  
>>> see error handling callbacks (i.e., lo_err_handler type functions)  
>>> be provided a "user data" information when called, much like  
>>> method handlers (i.e., lo_method_handler) callbacks are passed in  
>>> a void *user_data argument. Such "user data" would be provided by  
>>> application code to liblo along references to the error handler  
>>> functions (e.g., a new lo_server creation function similar  
>>> lo_server_new would be added to liblo and take an addtional void *  
>>> argument representing the user data).
>>>
>>> Or maybe there already is a nice way to achieve something similar  
>>> (i.e., being able to create error handler functions that interact  
>>> with other elements of my application without using thread-safe  
>>> adverse things like global variables) ?
>>>
>>> Thanks.
>>>
>>> Philippe Mougin
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Stephen, 

As a maintainer of some code myself I completely sympathize with your answer. Breaking current client code is clearly out of question, I believe. And I can live with the current way of handling errors (I communicate them to the other parts of my app with a static/global variable, which is still manageable and can be made thread safe if needed).
Thanks

Philippe

Le 22 mars 2010 à 13:58, Stephen Sinclair a écrit :

> I can see why it would be useful to pass the lo_server pointer to the
> lo_err_handler.  Associating a user_data field to lo_server might then
> solve your problem.  Unfortunately this wouldn't be simple to fix in a
> backward-compatible way without adding a whole extra handler type and
> maintain two different error handlers for each server.  Or we could
> break ABI/API compatibility and introduce this argument to
> lo_err_handler.  However I'm not really willing to do that right now
> seeing how long it took to get 0.46 accepted into distros due to very
> minor API changes.
> 
> If anyone has a better suggestion I'm all ears.
> 
> Steve
> 
> 
> On Wed, Mar 17, 2010 at 2:24 PM, Philippe Mougin <pm...@ac...> wrote:
>> Hi,
>> 
>> In my application, which makes use of liblo, I'd very much like to see error handling callbacks (i.e., lo_err_handler type functions) be provided a "user data" information when called, much like method handlers (i.e., lo_method_handler) callbacks are passed in a void *user_data argument. Such "user data" would be provided by application code to liblo along references to the error handler functions (e.g., a new lo_server creation function similar lo_server_new would be added to liblo and take an addtional void * argument representing the user data).
>> 
>> Or maybe there already is a nice way to achieve something similar (i.e., being able to create error handler functions that interact with other elements of my application without using thread-safe adverse things like global variables) ?
>> 
>> Thanks.
>> 
>> Philippe Mougin
>> 
>> 
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 

I can see why it would be useful to pass the lo_server pointer to the
lo_err_handler.  Associating a user_data field to lo_server might then
solve your problem.  Unfortunately this wouldn't be simple to fix in a
backward-compatible way without adding a whole extra handler type and
maintain two different error handlers for each server.  Or we could
break ABI/API compatibility and introduce this argument to
lo_err_handler.  However I'm not really willing to do that right now
seeing how long it took to get 0.46 accepted into distros due to very
minor API changes.

If anyone has a better suggestion I'm all ears.

Steve


On Wed, Mar 17, 2010 at 2:24 PM, Philippe Mougin <pm...@ac...> wrote:
> Hi,
>
> In my application, which makes use of liblo, I'd very much like to see error handling callbacks (i.e., lo_err_handler type functions) be provided a "user data" information when called, much like method handlers (i.e., lo_method_handler) callbacks are passed in a void *user_data argument. Such "user data" would be provided by application code to liblo along references to the error handler functions (e.g., a new lo_server creation function similar lo_server_new would be added to liblo and take an addtional void * argument representing the user data).
>
> Or maybe there already is a nice way to achieve something similar (i.e., being able to create error handler functions that interact with other elements of my application without using thread-safe adverse things like global variables) ?
>
> Thanks.
>
> Philippe Mougin
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Hi,

In my application, which makes use of liblo, I'd very much like to see error handling callbacks (i.e., lo_err_handler type functions) be provided a "user data" information when called, much like method handlers (i.e., lo_method_handler) callbacks are passed in a void *user_data argument. Such "user data" would be provided by application code to liblo along references to the error handler functions (e.g., a new lo_server creation function similar lo_server_new would be added to liblo and take an addtional void * argument representing the user data).

Or maybe there already is a nice way to achieve something similar (i.e., being able to create error handler functions that interact with other elements of my application without using thread-safe adverse things like global variables) ?

Thanks.

Philippe Mougin

Sorry for jumping into this thread late.  I have some notes regarding bundle contexts, atomicity and scheduling for implementations.

What we mean by atomicity concerns the scheduling precision between events within a bundle.  Interestingly in many systems there are some provisions for getting extremely good inter-event timing precision, but implementing support for these may require a change to the way an implementation processes the packet stream.

To make this possible, bundles with timestamps should be dispatched well in advance of their scheduling deadline, to allow time for unpacking, processing, error checking and so on.  Later, as close as possible to the deadline, another process is responsible for activating the new set of values.  That process can use the highest possible priority on the system to ensure that the new values are committed at the correct moment.

For example this may be done by double-buffering and then doing an atomic pointer swap at the time of activation to commit the new data.  

Another example, for a block-based audio computation environment any bundle with a scheduling deadline in the next block of audio needs to be processed at the start of the block so that the sample offsets into the block can be computed.  One may want this data to be available even sooner for example if you are intending to construct an interpolating ramp to the new value where the ramp duration may be longer than one block.

Another common example is found in embedded hardware design, where the driving state of two pins on the same port can be updated with a single instruction.  The difference between applying the pin updates sequentially vs simultaneously is significant in some circuits, such as an H-bridge where sequential updates would lead to undesired intermediate states (e.g. braking or simultaneous conduction / shoot-through).


---

Andy W. Schmeder
andy [at] cnmat.berkeley.edu

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

On Mon, Mar 15, 2010 at 8:06 PM, David Robillard <da...@dr...> wrote:
> On Fri, 2010-03-12 at 14:55 +0000, Stephen Sinclair wrote:
>> On Fri, Mar 12, 2010 at 1:12 AM, David Robillard <da...@dr...> wrote:
>> > On Fri, 2010-02-26 at 01:37 -0500, David Robillard wrote:
>> > [...]
>> >> Attached is a revised bundle handlers patch which uses separate
>> >> callbacks and passes the timetag to the start handler.
>> >
>> > So? :)
>> >
>> > Any issues with this?  I would very much like to begin building on this
>> > functionality...
>>
>> Yup, it was applied in r180.  Sorry, I forgot to post that information
>> to this thread.
>
> Ah, excellent.  Didn't think to check :)
>
> Can you bump the version so configure scripts can check for this?

Didn't you actually bump it in your patch?  I left the change because
it seemed like a good idea anyways.

In any case, the version shouldn't really matter for the svn repo.  It
might be time for a new tarball release however.  I'd suggest in a
configure script checking for the presence of
lo_server_add_bundle_handlers().  Seems more robust to me than
checking the version number.

Steve

On Fri, 2010-03-12 at 14:55 +0000, Stephen Sinclair wrote:
> On Fri, Mar 12, 2010 at 1:12 AM, David Robillard <da...@dr...> wrote:
> > On Fri, 2010-02-26 at 01:37 -0500, David Robillard wrote:
> > [...]
> >> Attached is a revised bundle handlers patch which uses separate
> >> callbacks and passes the timetag to the start handler.
> >
> > So? :)
> >
> > Any issues with this?  I would very much like to begin building on this
> > functionality...
> 
> Yup, it was applied in r180.  Sorry, I forgot to post that information
> to this thread.

Ah, excellent.  Didn't think to check :)

Can you bump the version so configure scripts can check for this?

Thanks,

-dr

On Fri, Mar 12, 2010 at 1:12 AM, David Robillard <da...@dr...> wrote:
> On Fri, 2010-02-26 at 01:37 -0500, David Robillard wrote:
> [...]
>> Attached is a revised bundle handlers patch which uses separate
>> callbacks and passes the timetag to the start handler.
>
> So? :)
>
> Any issues with this?  I would very much like to begin building on this
> functionality...

Yup, it was applied in r180.  Sorry, I forgot to post that information
to this thread.

Steve

On Fri, 2010-02-26 at 01:37 -0500, David Robillard wrote:
[...]
> Attached is a revised bundle handlers patch which uses separate
> callbacks and passes the timetag to the start handler.

So? :)

Any issues with this?  I would very much like to begin building on this
functionality...

-dr

2010/2/28 IOhannes m zmölnig <zmo...@ie...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stephen Sinclair wrote:
>> Mainly, a feature request in the past has been how to access liblo
>> message timetags, and how to get liblo to trigger handlers _before_
>> they are due.  Historically of course liblo intends to make things
>> easier for the user by handling timing automatically by dispatching at
>> the correct time.  However for some use cases (like message
>> forwarding), an application might want to handle messages ahead of
>> time and access the timetag information manually.
>>
>
> while we are there:
> it sometimes might also be useful to be able to modify the timestamps.
> that would basically just mean to get a hand on the OSC-bundle as it
> arrives, including the timestamp (this is what is discussed in this
> thread), and then reschedule the message to be dispatched by liblo
> (which, iirc, is currently possible anyhow).
>
> i guess it would just require a hook that overrides the automatic
> passing of a bundle to the scheduler.
>
> i would have needed that for my last project (which i have then
> implemented in Pd for various other reasons...)

I think perhaps a dedicated function, like
lo_server_reschedule_message() that could be called from a message
handler would be appropriate for that.  Not sure off the top of my
head how easy it would be to implement.

Steve

I agree, I think the current _del_method() is a little less useful
than this suggestion.

How about being able to specify the path, but default to removing all
methods with the provided handler if path=0?

Steve


On Sun, Feb 28, 2010 at 12:04 PM, Philippe Mougin <pm...@ac...> wrote:
> Hi Cam,
>
> I thought including path and typespec might be useful when the same handler has been registered for multiple methods and one want to unregister it for only a given method. But I don't know if this is a need in real-life use cases. In my case, the simpler API you describe would be ok.
>
> Thx
>
> Phil
>
> Le 28 févr. 2010 à 11:37, Camille Troillard a écrit :
>
>> Hi Philippe,
>>
>> It looks like a sensitive idea.
>> I actually didn't know that it was possible to register multiple handlers for one method.
>>
>> Why not making the API as simple as :
>>
>> lo_server_del_method_handler (lo_server s, lo_method_handler h)
>>
>> I guess we just need to walk through the chain of handlers, and remove every occurrences of the one that we want.  What do you think?
>> I am not sure why path and typespec would be needed, or maybe was it just a side effect of writing an email late a night? :-)
>>
>>
>> Best,
>> Cam
>>
>>
>>
>> On Sun, Feb 28, 2010 at 1:29 AM, Philippe Mougin <pm...@ac...> wrote:
>> Hi,
>>
>> Sometimes in my application I can have multiple different handlers registered for the same method. For example, I can be in a state similar by the one created by:
>>
>>  lo_server_add_method(localOSCServer, "/foo/bar", "f", foo_handler, NULL);
>>  lo_server_add_method(localOSCServer, "/foo/bar", "f", bar_handler, NULL);
>>
>> Now, I'd like to unregister bar_handler while keeping foo_handler registered. I don't see how to do that with the current API (seems that I can only remove the whole "/foo/bar" method with all associated handlers).
>>
>> I may well be overlooking something as I'm new to liblo (besides, it's 1 a.m.)
>>
>> If not, do you think it would be a good idea to extend the API with something like lo_server_del_method_handler (lo_server s, const char *path, const char *typespec, lo_method_handler h), which would remove h from the handlers associated with the given path/typespecs?
>>
>> Thanks,
>>
>> Philippe Mougin
>> http://www.fscript.org
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>