liblo-devel Mailing List for LibLO

> Yes. Thank you for adding me.

It's done, you should be able to develop your project now under the
/tools directory.


> Please review and consider adding the following patch. The patch adds a new
> function "lo_bundle_free_messages()" that completly frees a bundle object.

Okay, thanks I'll try to have a look shortly.  It sounds useful.


Steve

On Sun, 27 Jan 2008 14:29:20 -0500
"Stephen Sinclair" <rad...@gm...> wrote:

> > It is very happy for me. If you could allow me to access the liblo's
> > svn tree, I would like to maintain and release them at there.
> 
> Okay, there are only a couple of things to consider:
> 
> First, I'll have to give you svn permission.  This isn't really a
> problem, I think.  Your SF username is "fukuchi", right?

Yes. Thank you for adding me.

> (I'll try to post a kind of 'roadmap' for 0.25 sometime soon..)

Please review and consider adding the following patch. The patch adds a new
function "lo_bundle_free_messages()" that completly frees a bundle object.

http://sourceforge.net/tracker/index.php?func=detail&aid=1878341&group_id=116064&atid=673871

Discussion of freeing messages in a bundle object can be found at:
http://sourceforge.net/mailarchive/forum.php?thread_name=20071118202552.f6f62279.fukuchi%40megaui.net&forum_name=liblo-devel

best,

Kentaro

On Sun, 27 Jan 2008 19:47:15 -0500
"Stephen Sinclair" <rad...@gm...> wrote:

> would you prefer to have your tools keep version 1.0.0, or would you
> mind keeping them with the same version number as liblo itself?
> 
> Personally I think the latter is the way to go.. if they are
> integrated as part of the liblo project, we may as well keep the
> version numbers in sync.  For now in my patch I added #include
> <config.h> to the oscsend.c and oscdump.c, so that they can use the
> VERSION macro from liblo.
> 
> What do you think?

I agree with you, the latter would be better. I'll soon update the
web page of oscsend/oscdump to avoid confusion with the degrade of
the version number.

best,

Kentaro

Answering myself here...

I've now got a patch which imports your released version of oscsend
and oscdump, ready to drop into the subversion.  The question is, in
reference to this....

> Second, if you make changes they will appear in the next version of
> liblo, but the timing of this release will be up to me.  If that's
> okay with you, we'll go ahead.

would you prefer to have your tools keep version 1.0.0, or would you
mind keeping them with the same version number as liblo itself?

Personally I think the latter is the way to go.. if they are
integrated as part of the liblo project, we may as well keep the
version numbers in sync.  For now in my patch I added #include
<config.h> to the oscsend.c and oscdump.c, so that they can use the
VERSION macro from liblo.

What do you think?

Steve

> It is very happy for me. If you could allow me to access the liblo's
> svn tree, I would like to maintain and release them at there.

Okay, there are only a couple of things to consider:

First, I'll have to give you svn permission.  This isn't really a
problem, I think.  Your SF username is "fukuchi", right?

Second, if you make changes they will appear in the next version of
liblo, but the timing of this release will be up to me.  If that's
okay with you, we'll go ahead.

(I'll try to post a kind of 'roadmap' for 0.25 sometime soon..)

Sigh, I've been using 'git' a lot lately, and it really makes these
things a non-issue.
Oh well, hopefully sourceforge will catch up to distributed version
control eventually.


Steve

On Jan 26, 2008 1:24 PM, Dave Robillard <da...@dr...> wrote:
> The parameter changes made to my varargs patch when committed broke
> things.  Mind those compiler warnings ;)

Thanks for catching this.

It would have been caught earlier if I'd properly added a test case
for lo_message_add(), so I've now done so.

Steve

The parameter changes made to my varargs patch when committed broke
things.  Mind those compiler warnings ;)

Patch attached.

Cheers,

-DR-

On Fri, 25 Jan 2008 14:27:43 -0500
"Stephen Sinclair" <rad...@gm...> wrote:

> > Wow, I didn't know that! I'll checkout the trunk tree soon.
> 
> I'll soon do a diff between your version and what's in the svn, to
> make sure things are up to date.
> What are you feelings on having your utilities included with liblo?

It is very happy for me. If you could allow me to access the liblo's
svn tree, I would like to maintain and release them at there.

> For the source distribution is sort of makes sense, but I guess for a
> distro package it would make more sense to have it split between
> "library" and "tools" packages.  I guess that would be up to whoever
> does the packaging.

I agree. They will add a new binary such as "liblo-bin".

Kentaro

On Divendres 25 Gener 2008, Stephen Sinclair wrote:
> On Jan 23, 2008 3:29 PM,  <dga...@iu...> wrote:
> > Just in case anyone is interested in this same task, I got liblo
> > crosscompiled in mingw, that is, windows binaries generated from Linux.
> >
> > Instructions are written in a wiki where we do the same with every
> > dependency our project has. That includes pthreads which is a liblo
> > dependency itself.
>
> Great, thanks for this!
> It might be useful for some other projects I'm involved with as well. :)
>
> > While the first two issues are not because liblo and can be easily fixed
> > using the proper autogen options, the third one requires editing src
> > files and it would be nice have it fixed. I don't know which problem
> > address such a redefinition but it would be nice if it can be inside so=
me
> > #ifdef that is not WIN32
>
> Okay, thanks.  I've heard that perhaps "WIN32" is not the best
> preprocessor define to use for Windows compiling.
> I've personally been using VS to compile liblo and I also had to make
> some changes to liblo to get it to work.
> So I think general support for windows compiling is something that needs
> work.
>
> > I would be nice too if the pkg-config file is generated with the ws2_32
> > library dependency when you are in such a context.
>
> Good idea.  If you have the time to submit a patch, please do so, or
> perhaps just file a bug in the tracker otherwise.
> I'm slowly getting through some of the backlog of "things to do", but
> it may take some time.  Using the tracker will help greatly.

Half a patch might be also of help. Just change this line in the liblo.pc.a=
c :

Libs: @LDFLAGS@ -L${libdir} @LIBS@ -llo

This line will propagate to the pc file those two linking vars, from the on=
es=20
specified on the command line and the ones added by autoconf (included=20
pthread previously hardcoded in this same line).

That works for me because i am passing the LIBS option on the commandline, =
but=20
the full patch would make 'configure' script detecting mingw or trying the=
=20
ws2_32 for a winsocket2 symbol and then adding such a library to the LIBS=20
environment by itself.

But I tried with some AC macros (AC_CHECK_LIB and AC_SEARCH_LIB) and i=20
couldn't get them to work. With AC_CHECK_LIB the program doesn't link becau=
se=20
the symbol is not found but if i modify the generated source to include=20
winsock2.h, then magically works. Maybe it is due because they use a=20
different ABI or something like that (PASCAL calling conventions? windows=20
demangling?)

Anyway I dont know the AC macro i should use to do the test compilation wit=
h=20
an include in the source.=20

The symbols on liblo that are missing when the library is not linked are:
htonl, ntohl, send, getaddrinfo, WSAGetLastError, WSAStartup, WSACleanup,=20
connect, sendto, freeaddrinfo, listen, gethostbyname, bind, select, recvfro=
m,=20
accept, getnameinfo, recv, socket.


=2D-=20
David Garc=EDa Garz=F3n
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia

> Wow, I didn't know that! I'll checkout the trunk tree soon.

I'll soon do a diff between your version and what's in the svn, to
make sure things are up to date.
What are you feelings on having your utilities included with liblo?
For the source distribution is sort of makes sense, but I guess for a
distro package it would make more sense to have it split between
"library" and "tools" packages.  I guess that would be up to whoever
does the packaging.

> That is the reason why I changed the name to oscsend/oscdump.

Ah, yes sorry i didn't notice the distinction.  :)


Steve

On Jan 23, 2008 3:29 PM,  <dga...@iu...> wrote:
> Just in case anyone is interested in this same task, I got liblo crosscompiled
> in mingw, that is, windows binaries generated from Linux.
>
> Instructions are written in a wiki where we do the same with every dependency
> our project has. That includes pthreads which is a liblo dependency itself.

Great, thanks for this!
It might be useful for some other projects I'm involved with as well. :)


> While the first two issues are not because liblo and can be easily fixed using
> the proper autogen options, the third one requires editing src files and it
> would be nice have it fixed. I don't know which problem address such a
> redefinition but it would be nice if it can be inside some #ifdef that is not
> WIN32

Okay, thanks.  I've heard that perhaps "WIN32" is not the best
preprocessor define to use for Windows compiling.
I've personally been using VS to compile liblo and I also had to make
some changes to liblo to get it to work.
So I think general support for windows compiling is something that needs work.


> I would be nice too if the pkg-config file is generated with the ws2_32
> library dependency when you are in such a context.

Good idea.  If you have the time to submit a patch, please do so, or
perhaps just file a bug in the tracker otherwise.
I'm slowly getting through some of the backlog of "things to do", but
it may take some time.  Using the tracker will help greatly.


Thanks,
Steve

On Thu, 24 Jan 2008 07:35:47 -0500
"Stephen Sinclair" <rad...@gm...> wrote:

> > Today I released OSC messaging utilities "oscsend/oscdump" using liblo.
> 
> Great!
> 
> I've been using these utilities myself for testing for some time,
> they're quite useful.
> Nicholas Humfrey had uploaded these to the liblo subversion a few
> weeks ago by the way, so they are included with liblo by default now!

Wow, I didn't know that! I'll checkout the trunk tree soon.

> By the way, Kentaro, take a look at rev92, I fixed a small error in
> sendosc.c related to sending strings and symbols.  I haven't checked
> whether this is also in the version posted on your site.

Yes, it is fixed in the latest release. At this momemnt there is no
significant changes between oscsend/oscdump-1.0.0 and sendosc.c/dumposc.c.

> I wonder if they shouldn't be named "losend" and "lodump" or
> something, to differentiate from Matt Wright's utilities..

That is the reason why I changed the name to oscsend/oscdump.

Kentaro

> Today I released OSC messaging utilities "oscsend/oscdump" using liblo.

Great!

I've been using these utilities myself for testing for some time,
they're quite useful.
Nicholas Humfrey had uploaded these to the liblo subversion a few
weeks ago by the way, so they are included with liblo by default now!

By the way, Kentaro, take a look at rev92, I fixed a small error in
sendosc.c related to sending strings and symbols.  I haven't checked
whether this is also in the version posted on your site.

I wonder if they shouldn't be named "losend" and "lodump" or
something, to differentiate from Matt Wright's utilities..

Steve

Hi,

Today I released OSC messaging utilities "oscsend/oscdump" using liblo.

http://megaui.net/fukuchi/works/oscsend/index.en.html

They are very similar to Matt Wright's sendOSC/dumpOSC, but incompatible with
them. If you are familiar with them, you will be disappointed by the differences
of the user interface or the format of OSC message. On the other hand, oscsend
and oscdump are designed to be familiar with liblo developers. For example,
you can specify the types of a OSC message just like what liblo employs.

Comments, suggestions, bug reports and questions are welcome.

Kentaro Fukuchi

Just in case anyone is interested in this same task, I got liblo crosscompi=
led=20
in mingw, that is, windows binaries generated from Linux.

Instructions are written in a wiki where we do the same with every dependen=
cy=20
our project has. That includes pthreads which is a liblo dependency itself.

http://clam.iua.upf.edu/wikis/clam/index.php/Devel/Windows_MinGW_cross_comp=
ile

That works for liblo 2.4 and svn.

The main problems i found were:
=2D pthreads for win uses a different naming conventions for the library=20
(libpthreadGE2.a instead liblo expected libpthread.a), i just did a symlink=
=20
as already explained in csound mailing list
=2D crosscompiling for linux suposes an old Windows version for compatibili=
ty=20
and winsocket2 headers doesn't define some sockets related symbols. I just=
=20
defined _WIN32_WINNT=3D0x0501 (>=3Dwinxp, i think)
=2D There was a function (WSAAPI gai_strerrorA) redefined in src/server.c t=
hat=20
it is already available on standard mingw headers. I commented it out.
=2D I had to explicitly add the ws2_32 (winsocket2) library to link it

While the first two issues are not because liblo and can be easily fixed us=
ing=20
the proper autogen options, the third one requires editing src files and it=
=20
would be nice have it fixed. I don't know which problem address such a=20
redefinition but it would be nice if it can be inside some #ifdef that is n=
ot=20
WIN32

I would be nice too if the pkg-config file is generated with the ws2_32=20
library dependency when you are in such a context.

Thanks.

=2D-=20
David Garc=C3=ADa Garz=C3=B3n
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia

Hi,

I've added a Patch Tracker to the sourceforge page for LibLo.
If you have any patches, please add them there, I think it will be
easier to track things and coordinate.

thanks,
Steve

Hi folks,

I've offerred to take over maintenance duties for the LibLo project
off of Nicholas' hands, as he's understandably been having trouble
finding time for it.  He's given me sourceforge access and forwarded
all your recent patches and bug reports.

I plan to start digging through them in the coming weeks.  Please feel
free to follow the subversion repository if you have any suggestions
or comments on applied patches.

I'll try to post to the list and to the author of any patch if I find
I have questions regarding any of the above.  My initial focus will be
on integrating bug fixes and important features that don't require
drastic code or API changes.  I plan on keeping as closely as possible
to the original intent of the library, which is to provide a very
simple (yet complete) interface to the Open Sound Control protocol.

cheers,
Steve