liblo-devel Mailing List for LibLO

On Mon, Aug 22, 2005 at 06:48:26 +0100, Martin Habets wrote:
> On Sat, Aug 20, 2005 at 11:20:33AM +0100, Steve Harris wrote:
> > The arguments that are used to pick the method to remove are the path and
> > typespec, which seems reasonable, but it is (currently) possible to have
> > more than one method bound to a particular path and typespec. I dont know
> > if anyone does that though.
> 
> I did not know this was possible (and don't use it). Can't think of a proper
> way (as in functional strength) to use multiple methods for one path.

I modelled it after the apache module API, you return a 0, indicating that
you've handled it, or a 1 indicating that it should fall through to other
methods that match the incoming message.

Its not a requirement that you fully specify the path and typespec.
OTOH I was just speculating about what features would be useful.

> > lo_server_thread_add_method() returns a lo_method, which I intended to be
> > used to remote it later, though I can see that might be inconvienient to
> > hold on to just so you can remove it later.
> > 
> > Thoughts?
> 
> It all depends on the reason for removing methods. Is there a scenario
> where someone would want to remove just one method bound to a path+typespec,
> and not all of them?
> In my mind one path maps to one method, cause I like to keep things simple.

Sure, that certianly seems to be the most common usage pattern. I was
curious to see what peoples programming models are.

- Steve

On Sat, Aug 20, 2005 at 11:20:33AM +0100, Steve Harris wrote:
> The arguments that are used to pick the method to remove are the path and
> typespec, which seems reasonable, but it is (currently) possible to have
> more than one method bound to a particular path and typespec. I dont know
> if anyone does that though.

I did not know this was possible (and don't use it). Can't think of a proper
way (as in functional strength) to use multiple methods for one path.

> lo_server_thread_add_method() returns a lo_method, which I intended to be
> used to remote it later, though I can see that might be inconvienient to
> hold on to just so you can remove it later.
> 
> Thoughts?

It all depends on the reason for removing methods. Is there a scenario
where someone would want to remove just one method bound to a path+typespec,
and not all of them?
In my mind one path maps to one method, cause I like to keep things simple.

-- 
Martin

I'm about to make a new release, and I've only just read the docs for
this, should have been paying attention before :)

The arguments that are used to pick the method to remove are the path and
typespec, which seems reasonable, but it is (currently) possible to have
more than one method bound to a particular path and typespec. I dont know
if anyone does that though.

lo_server_thread_add_method() returns a lo_method, which I intended to be
used to remote it later, though I can see that might be inconvienient to
hold on to just so you can remove it later.

Thoughts?

- Steve

ChangeLog:

2005-08-19  Steve Harris  <st...@pl...>

        * address.c, testlo.c: Added patch from Dave Robillard to fix parsing
          of IPV6 addresses in URLs.

and and old one I forgot:

2005-07-26  Steve Harris  <st...@pl...>

        * bundle.c, server.c: Endianess fixed from Topher Cyll for bundle
          timestamps.

  # Bundle delivery timing is still not right, theres an arithmetic error
  # somewhere, but I cant see it.

Theres quite a lot outstanding now, so I'l probably make a new release
ofter the weekend, so now would be a good time for developers to try CVS
head.

- Steve

The previous 2 patches I mailed are now in CVS, along with a minor
build-from-CVS fix to configure.in.
Subject line for those patches were:
- Re: [PATCH]  Add lo_server_thread_del_method()
- [PATCH] Fix char type sending for big endian machines

Enjoy,
-- 
Martin

Steve, sorry for for finding another issue so soon! It never rains,
and then it floods...

testlo fails on big endian machines with:
FAILED types[9] == 'c' && argv[9]->c == 'X' at testlo.c:578

Some debugging showed that:
argv[9]->c = ''
argv[9]->i = 88
Root cause of this lo_message_add_char(), which does an implicit
cast to an int.
The patch below removes this cast. With it testlo runs without errors
on machines of any endianness.

I have not tried sending messages between machines with different
endian types yet, but will probably get round to that soon.

-- 
Martin
---------------------------------------------------------------------------
Index: liblo-0.18/src/message.c
===================================================================
--- liblo-0.18.orig/src/message.c	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/src/message.c	2005-08-06 17:25:46.132357793 +0100
@@ -158,7 +158,7 @@
     lo_pcast32 b;
     int32_t *nptr = lo_message_add_data(m, sizeof(int32_t));
 
-    b.i = a;
+    b.c = a;
 
     lo_message_add_typechar(m, LO_CHAR);
     *nptr = lo_htoo32(b.nl);
@@ -420,7 +420,7 @@
 	break;
 
     case LO_CHAR:
-	printf("'%c'", (char)val32.i);
+	printf("'%c'", (char)val32.c);
 	break;
 
     case LO_MIDI:
Index: liblo-0.18/src/lo_types_internal.h
===================================================================
--- liblo-0.18.orig/src/lo_types_internal.h	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/src/lo_types_internal.h	2005-08-06 17:24:12.235506802 +0100
@@ -84,6 +84,7 @@
 typedef union {
     int32_t  i;
     float    f;
+    char     c;
     uint32_t nl;
 } lo_pcast32;
     

This started off as a private email exchange with Steve, but
is better discussed on this list as he recommended.

On Thu, Aug 04, 2005 at 01:54:30PM +0100, Steve Harris wrote:
> On Thu, Aug 04, 2005 at 01:37:08 +0100, Martin Habets wrote:
> > Hi Steve,
> > 
> > Decided to scratch that itch from a while back, so here's a patch
> > that adds lo_server_thread_del_method() and lo_server_del_method().
> 
> Great.

I've appended the patch again for benefit of those on the list.

> > There is some other functionality I'd like to see in liblo:
> > 
> > 1) I'd like lo_coerce() to also convert any other type from/to a string.
> > Converting to a string would be very similar to lo_arg_pp().
> > Converting from a string is especially usefull when converting
> > command line arguments.
> 
> That one is a bit contraversial. I'm not sure how I feel about it, but if
> you get the OK from some other liblo users I'd be happy for it to go in.

I do not understand why adding functionality to lo_coerce() is
contraversial. I'm not suggesting changing the existing behaviour, except
adding where it would fail to coerce before.

> > 2) I'd like to see a 
> > 	lo_message_add_arg(lo_message m, lo_type type, lo_arg *arg)
> > function that is similar to add_varargs(), except it does not use
> > varargs :). It makes it easier to handle all osc types in applications,
> > avoiding switch statements (and bugs) there.
> 
> That makes sense. It woukd probably have to be a wrapper round
> lo_message_add_<type>, but at least it would keep the logic out of
> applications.

Yes, definitely a wrapper around the existing ones. I'll see if I can
come up with something.

> > Let me know how you feel about these. If you'd like I can provide
> > patches.
> 
> Sure. Are you on the sf.net project and mailing list? The list isnt used
> much, but it would be a better place to discuss things likle changing the
> behaviour of the coercion. I'm happy for you to commit the patch to CVS
> too.

Wasn't on the list before, but am now :). Am a sf.net user, if that was
the question.

-- 
Martin
---------------------------------------------------------------------------
Index: liblo-0.18/lo/lo_lowlevel.h
===================================================================
--- liblo-0.18.orig/lo/lo_lowlevel.h	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/lo/lo_lowlevel.h	2005-08-04 11:36:14.222278174 +0100
@@ -396,6 +396,17 @@
                                void *user_data);
 
 /**
+ * \brief Delete an OSC method from the specifed server.
+ *
+ * \param s The server the method is to be removed from.
+ * \param path The OSC path of the method to delete. If NULL is passed the
+ * method will match the generic handler.
+ * \param typespec The typespec the method accepts.
+ */
+void lo_server_del_method(lo_server s, const char *path,
+                               const char *typespec);
+
+/**
  * \brief Return the file descriptor of the server socket.
  *
  * If the server protocol supports exposing the server's underlying
Index: liblo-0.18/src/server_thread.c
===================================================================
--- liblo-0.18.orig/src/server_thread.c	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/src/server_thread.c	2005-08-04 11:32:36.555166218 +0100
@@ -64,6 +64,12 @@
     return lo_server_add_method(st->s, path, typespec, h, user_data);
 }
 
+void lo_server_thread_del_method(lo_server_thread st, const char *path,
+			       const char *typespec)
+{
+    lo_server_del_method(st->s, path, typespec);
+}
+
 void lo_server_thread_start(lo_server_thread st)
 {
     if (!st->active) {
Index: liblo-0.18/lo/lo.h
===================================================================
--- liblo-0.18.orig/lo/lo.h	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/lo/lo.h	2005-08-04 12:01:49.017952870 +0100
@@ -158,6 +158,16 @@
 lo_method lo_server_thread_add_method(lo_server_thread st, const char *path,
                                const char *typespec, lo_method_handler h,
                                void *user_data);
+/**
+ * \brief Delete an OSC method from the specifed server thread.
+ *
+ * \param st The server thread the method is to be removed from.
+ * \param path The OSC path of the method to delete. If NULL is passed the
+ * method will match the generic handler.
+ * \param typespec The typespec the method accepts.
+ */
+void lo_server_thread_del_method(lo_server_thread st, const char *path,
+				 const char *typespec);
 
 /**
  * \brief Start the server thread
Index: liblo-0.18/src/server.c
===================================================================
--- liblo-0.18.orig/src/server.c	2005-03-26 11:33:41.000000000 +0000
+++ liblo-0.18/src/server.c	2005-08-04 13:06:44.959311285 +0100
@@ -777,6 +777,43 @@
     return m;
 }
 
+void lo_server_del_method(lo_server s, const char *path,
+			  const char *typespec)
+{
+    lo_method it, prev;
+    int pattern = 0;
+
+    if (!s->first) return;
+    if (path) pattern = strpbrk(path, " #*,?[]{}") != NULL;
+
+    it = s->first;
+    prev = it;
+    while (it) {
+	/* If paths match or handler is wildcard */
+	if ((it->path == path) ||
+	    (path && it->path && !strcmp(path, it->path)) ||
+	    (pattern && lo_pattern_match(it->path, path))) {
+	    /* If types match or handler is wildcard */
+	    if ((it->typespec == typespec) ||
+		(typespec && it->typespec && !strcmp(typespec, it->typespec))
+	        ) {
+		/* Take care when removing the head. */
+		if (it == s->first) {
+		    s->first = it->next;
+		} else {
+		    prev->next = it->next;
+		}
+		free((void *)it->path);
+		free((void *)it->typespec);
+		free(it);
+		it = prev;
+	    }
+	}
+	prev = it;
+	if (it) it = it->next;
+    }
+}
+
 int lo_server_get_socket_fd(lo_server s)
 {
     if (s->protocol != LO_UDP &&
Index: liblo-0.18/src/testlo.c
===================================================================
--- liblo-0.18.orig/src/testlo.c	2005-03-02 19:15:47.000000000 +0000
+++ liblo-0.18/src/testlo.c	2005-08-04 13:00:14.325673021 +0100
@@ -418,6 +418,10 @@
 	exit(1);
     }
 
+    /* Delete methods */
+    lo_server_thread_del_method(st, "/coerce", "dfhiSs");
+    lo_server_del_method(s, NULL, NULL);
+
     lo_address_free(a);
     lo_server_free(s);
     free(server_url);