liblo-devel Mailing List for LibLO

On Wed, Jun 9, 2010 at 5:18 AM, nico <sl1...@gm...> wrote:
> hi,
> i'm using liblo for a lighting project called D::Light
> (www.nicole-banana.com)
> recently while coding my prog crashed... nothing dramatic ;-)
> but the osc server previoulsy created was still running, and when i try
> to launch it again, it freeze to this step:
>     if(NULL != (s->st = lo_server_thread_new( port, error )))

Usually when a program crashes, doesn't it take down the entire
process?  Why would there still be a thread present?


> this function never return.... (on osX.6.3)
> did you ever heard about that?
> is it possible to install a timeout that return null if the server
> creation failed ?

I have no idea, sorry..


Steve

hi,
i'm using liblo for a lighting project called D::Light 
(www.nicole-banana.com)
recently while coding my prog crashed... nothing dramatic ;-)
but the osc server previoulsy created was still running, and when i try 
to launch it again, it freeze to this step:
     if(NULL != (s->st = lo_server_thread_new( port, error )))

this function never return.... (on osX.6.3)
did you ever heard about that?
is it possible to install a timeout that return null if the server 
creation failed ?

best regards,
nicolas

On Tue, Jun 1, 2010 at 5:53 AM,  <nen...@ma...> wrote:
> Dear Steve,
>
> you rock! :)

Glad it worked for you :)


>> It looks like the problem is caused by the "-ansi" argument to gcc.
>
> It seems that this was _exactly_ the problem: After fiddling with
> Matlab's mex's ("compiler" and linker) preferences and the command
> line switches passed to gcc, the compilation runs faultlessly!
>
> And so far everything seems to run fine, too (creating a server,
> creating a address, sending, receiving, all from inside Matlab).

Great!


> I was wondering though...
>
>>  although perhaps we can find a way to make it
>> ANSI C compliant in the case where it's necessary.
>
> ...does the problematic inline code maybe just not concern my machine
> (I'm _not_ on 64bits here) and will the process of breaking ANSI-C
> compliance possibly affect only other machines (which this here
> programm will quite possibly run on in the future)? (Or did I just get
> something all wrong and the inlined uint64_t lo_swap64 is used by my
> 32bit Linux just as well, and thus there's nothing to worry about?)

I think being ANSI-C compliant is not too dramatic a requirement.
Yes, it would help with wide cross-platform compatibility, but
realistically most C compilers support more than just the ANSI
standard, and inline is pretty common.  In some extreme cases it may
be useful to be backward compatible with ANSI, while still having the
inline functions if we can detect that it is supported in the
configure script for example.

Historically the liblo code had a few other GCC-isms in it (in
particular variadic macros) that I had to conditionally remove to get
things working with Visual Studio for example.


Steve

Dear Steve,

you rock! :)

> It looks like the problem is caused by the "-ansi" argument to gcc.

It seems that this was _exactly_ the problem: After fiddling with  
Matlab's mex's ("compiler" and linker) preferences and the command  
line switches passed to gcc, the compilation runs faultlessly!

And so far everything seems to run fine, too (creating a server,  
creating a address, sending, receiving, all from inside Matlab).

I was wondering though...

>  although perhaps we can find a way to make it
> ANSI C compliant in the case where it's necessary.

...does the problematic inline code maybe just not concern my machine  
(I'm _not_ on 64bits here) and will the process of breaking ANSI-C  
compliance possibly affect only other machines (which this here  
programm will quite possibly run on in the future)? (Or did I just get  
something all wrong and the inlined uint64_t lo_swap64 is used by my  
32bit Linux just as well, and thus there's nothing to worry about?)

Anyway, thanks really really very much,
this has been of tremendous help to me!

Matthias