Howdy all,
I had a friend who had some trouble loading a couple of objects (beat and borax from maxlib). We thought maybe the lib wasn't being loaded, but it was. In the end, it seems the object will create but only with a certain number of args. After it's created once, creating the same object without any args works fine.
I assume this behavior is due to some sort of initialization that needs to be done within maxlib ... but I thinks it's quite confusing.
Is there any sort of spec libs need to be written to? If so, I think it should be mandatory that objects should always be able to be created with empty arguments.
Also, are there any other objects that do this or just some in maxlib?
Dan Wilcox danomatika.com robotcowboy.com
There are other objects that do that, but its best to not hve it that
way, IMHO. IOhannes suggested fixing this on the internal side, but I
think its OK to handle it in the external itself. If you make a
patch, submit it to the patch tracker.
.hc
On Nov 15, 2009, at 8:24 PM, Dan Wilcox wrote:
Howdy all,
I had a friend who had some trouble loading a couple of objects
(beat and borax from maxlib). We thought maybe the lib wasn't being
loaded, but it was. In the end, it seems the object will create but
only with a certain number of args. After it's created once,
creating the same object without any args works fine.I assume this behavior is due to some sort of initialization that
needs to be done within maxlib ... but I thinks it's quite confusing.Is there any sort of spec libs need to be written to? If so, I
think it should be mandatory that objects should always be able to
be created with empty arguments.Also, are there any other objects that do this or just some in maxlib?
Dan Wilcox danomatika.com robotcowboy.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
There are other objects that do that, but its best to not hve it that way, IMHO. IOhannes suggested fixing this on the internal side, but I think its OK to handle it in the external itself. If you make a patch, submit it to the patch tracker.
i suggested adding user-feedback if the object couldn't be created because of missing arguments.
the problem here is that the object only creates without arguments once it has been created with arguments.
i think this is something different (and entirely confusing). either an object should create with a given set of arguments or not.
somewhat related is the question of system exclusive ressources (e.g. a port for [netreceive]). i find it highly frustrating that all of the network server objects will plainly refuse to instantiate if they cannot allocate the given port. i would very much appreciate, if i could get feedback on the success and retry another port.
just wanted to get rid of this.
mfgasdr IOhannes
IOhannes m zmölnig wrote:
somewhat related is the question of system exclusive ressources (e.g. a port for [netreceive]). i find it highly frustrating that all of the network server objects will plainly refuse to instantiate if they cannot allocate the given port. i would very much appreciate, if i could get feedback on the success and retry another port.
Do you mean the object should sit there semi-instantiated until you type in a usable port number, or just fail to instantiate but leave a message saying why it failed?
Martin
On Nov 18, 2009, at 9:08 AM, Martin Peach wrote:
IOhannes m zmölnig wrote:
somewhat related is the question of system exclusive ressources
(e.g. a port for [netreceive]). i find it highly frustrating that all of the network server objects
will plainly refuse to instantiate if they cannot allocate the given port. i would very much appreciate, if i could get feedback on the
success and retry another port.Do you mean the object should sit there semi-instantiated until you
type in a usable port number, or just fail to instantiate but leave
a message saying why it failed?
Personally, I think it should instantiate, and throw a pd_error()
saying that it can't function without a port number. Another option
for netreceive is to pick a default port number.
But in general, I think an object should instantiate regardless of the
args so you can get help and having it throw findable errors, i.e.
pd_error();
.hc
"Making boring techno music is really easy with modern tools," he
says, "but with live coding, boring techno is much harder." - Chris
McCormick
Personally, I think it should instantiate, and throw a pd_error()
saying that it can't function without a port number. Another option
for netreceive is to pick a default port number.
So maybe Pd needs a default port number that could be inscribed in /etc/services and /etc/inetd.conf, or at least m_pd.h.
Martin
On Nov 18, 2009, at 1:18 PM, martin.peach@sympatico.ca wrote:
Personally, I think it should instantiate, and throw a pd_error() saying that it can't function without a port number. Another option for netreceive is to pick a default port number.
So maybe Pd needs a default port number that could be inscribed in / etc/services and /etc/inetd.conf, or at least m_pd.h.
Martin
Yeah, sounds like a good idea. But there is already kind of 5800/5600
for the pd<->pdgui connection.
.hc
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
martin.peach@sympatico.ca wrote:
Personally, I think it should instantiate, and throw a pd_error()
saying that it can't function without a port number. Another option
for netreceive is to pick a default port number.
this is not something i care about. people wanting to use the network, should at least understand they need a port :-)
i am really talking about tyring to listen to a certain port which is already used by somebody else. the object will just fail to create in this case (though it won't fail to create in other circumstances, e.g. when no other app is listening to this port)
an other case: a dummy user sits behind a firewall which has port 8888 open, but unfortunately the patch uses port 7777. the dummy user has to either phone the network admin to open up port 7777, or find their way through the patch and change the [netreceive].
So maybe Pd needs a default port number that could be inscribed in /etc/services and /etc/inetd.conf, or at least m_pd.h.
i think this will make my problem (multiple servers listening on a single port) even worse! imagine all those innocent [netreceive]s (with no args) sitting around.
furthermore, a default port is useful, if two applications using this port can talk to each other without knowing more. ports are usually reserved for protocols rather than applications (port 80 is http, not apache; FUDI is not really a protocol in this sense)
fg asdr IOhannes
On Wed, 18 Nov 2009, Hans-Christoph Steiner wrote:
But in general, I think an object should instantiate regardless of the args so you can get help and having it throw findable errors, i.e. pd_error();
no. instead you should make instantiation errors findable:
------------------8<--------cut-here--------8<------------------ diff -ru pd-0.42-5-orig/src/s_print.c pd-0.42-5/src/s_print.c --- pd-0.42-5-orig/src/s_print.c 2009-11-18 13:49:46.000000000 -0500 +++ pd-0.42-5/src/s_print.c 2009-11-18 13:50:43.000000000 -0500 @@ -132,7 +132,7 @@ offending or offended object around so the user can search for it later. */
-static void *error_object; +void *error_object; static char error_string[256]; void canvas_finderror(void *object);
diff -ru pd-0.42-5-orig/src/g_text.c pd-0.42-5/src/g_text.c --- pd-0.42-5-orig/src/g_text.c 2009-02-04 13:50:13.000000000 -0500 +++ pd-0.42-5/src/g_text.c 2009-11-18 13:52:47.000000000 -0500 @@ -86,6 +86,7 @@ t_binbuf *b) { t_text *x;
- int error = 0; int argc; t_atom *argv; newest = 0;
@@ -97,7 +98,7 @@ if (!newest) { binbuf_print(b);
post("... couldn't create");
error = 1; x = 0; } else if (!(x = pd_checkobject(newest)))
@@ -111,6 +112,7 @@ { /* LATER make the color reflect this */ x = (t_text *)pd_new(text_class);
if (error) pd_error(x,"... couldn't create"); } x->te_binbuf = b; x->te_xpix = xpix;
------------------8<--------cut-here--------8<------------------
it's as simple as that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Nov 18, 2009, at 2:02 PM, Mathieu Bouchard wrote:
On Wed, 18 Nov 2009, Hans-Christoph Steiner wrote:
But in general, I think an object should instantiate regardless of
the args so you can get help and having it throw findable errors,
i.e. pd_error();no. instead you should make instantiation errors findable:
Sounds like a useful patch, is it in the patch tracker?
I think there is a reason to do both. So if the object doesn't
create, it should throw the error like in this patch. But like
IOhannes talked about, something like [netrecieve]. Currently, if
there is a port conflict, it just doesn't create. Instead it should
create, and throw a pd_error() that explains the port conflict. So
both are very useful.
.hc
------------------8<--------cut-here--------8<------------------ diff -ru pd-0.42-5-orig/src/s_print.c pd-0.42-5/src/s_print.c --- pd-0.42-5-orig/src/s_print.c 2009-11-18
13:49:46.000000000 -0500 +++ pd-0.42-5/src/s_print.c 2009-11-18 13:50:43.000000000 -0500 @@ -132,7 +132,7 @@ offending or offended object around so the user can search for it later. */-static void *error_object; +void *error_object; static char error_string[256]; void canvas_finderror(void *object);
diff -ru pd-0.42-5-orig/src/g_text.c pd-0.42-5/src/g_text.c --- pd-0.42-5-orig/src/g_text.c 2009-02-04 13:50:13.000000000 -0500 +++ pd-0.42-5/src/g_text.c 2009-11-18 13:52:47.000000000 -0500 @@ -86,6 +86,7 @@ t_binbuf *b) { t_text *x;
- int error = 0; int argc; t_atom *argv; newest = 0;
@@ -97,7 +98,7 @@ if (!newest) { binbuf_print(b);
post("... couldn't create");
error = 1; x = 0; } else if (!(x = pd_checkobject(newest)))@@ -111,6 +112,7 @@ { /* LATER make the color reflect this */ x = (t_text *)pd_new(text_class);
if (error) pd_error(x,"... couldn't create");------------------8<--------cut-here--------8<------------------
it's as simple as that.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
There is no way to peace, peace is the way. -A.J. Muste
On Wed, 18 Nov 2009, Hans-Christoph Steiner wrote:
On Nov 18, 2009, at 2:02 PM, Mathieu Bouchard wrote:
no. instead you should make instantiation errors findable:
Sounds like a useful patch, is it in the patch tracker?
no.
I think there is a reason to do both. So if the object doesn't create, it should throw the error like in this patch. But like IOhannes talked about, something like [netrecieve]. Currently, if there is a port conflict, it just doesn't create. Instead it should create, and throw a pd_error() that explains the port conflict. So both are very useful.
It is not useful to have this feature if the port number does not come out by an outlet, because then, the programme that does [netsend] cannot know where to connect to.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin Peach wrote:
IOhannes m zmölnig wrote:
somewhat related is the question of system exclusive ressources (e.g. a port for [netreceive]). i find it highly frustrating that all of the network server objects will plainly refuse to instantiate if they cannot allocate the given port. i would very much appreciate, if i could get feedback on the success and retry another port.
Do you mean the object should sit there semi-instantiated until you type in a usable port number, or just fail to instantiate but leave a message saying why it failed?
what i would love is:
- object instantiates even if resource is already used exclusively by
somebody else
- object has a method to query it's status (so user knows, that resource
could not have been allocated)
- resource can be specified by user via messages (so user can chose an
alternative resource)
with [netreceive] this means:
- [netreceive 22] will fail to grab resource (ssh is running) but
instantiates
- [status( message to netreceive gives "0" on status outlet
- [port 2222( to netreceive will (free current resource) and try to bind
to port 2222
- [status( now gives "1"
mfgasr IOhannes
-
Dan Wilcox -
Hans-Christoph Steiner -
IOhannes m zmölnig -
Martin Peach -
martin.peach＠sympatico.ca
-
Mathieu Bouchard