Hi
I was just discussing a feature request to an external (aoo) for posting error messages to the outlet instead of the Pd console.
It reminded me that I often found error posts on the console limiting because they make the error condition inaccessible for the patch. Often there is no way to deal with a certain error condition on a patch level.
Many programming languages provide an infrastructure to deal with error conditions in flexible ways. Pd not so much. OTOH, Pd considered being a rather higher level language, many people might do not expect such flexibility and are happy with clear errors in the console without having to hook up [print]s to all kinds of status outlets.
Now, what if the (error) messages printed to the console could be made accessible to the patch? This wouldn't affect convenience of current error post practice, but could allow for dealing with error conditions within the patch. I do not have a clear picture of how exactly this could be designed, but then I wonder if people think whether this is an intelligent idea at all, before I open a feature request. Or maybe an existing external already does that?
Roman
- Roman Haefeli reduzent@gmail.com [2021-06-13 22:53]:
Hi
I was just discussing a feature request to an external (aoo) for posting error messages to the outlet instead of the Pd console.
Roman, I think this is an excellent ideat! I am wondering how one would parse these error messages if they came from one single object outlet to tell where the error originated from?
best, P
Peter P. wrote:
- Roman Haefeli reduzent@gmail.com [2021-06-13 22:53]:
Hi
I was just discussing a feature request to an external (aoo) for posting error messages to the outlet instead of the Pd console.
Roman, I think this is an excellent ideat!
me too !!!
I am wondering how one would
parse these error messages if they came from one single object outlet to tell where the error originated from?
in practice it probably wouldn't be that difficult, since you most likely know the kind of error message you are looking for. so it should be easy to route. or use timed spigots etc...
anyway a [console] object that ouputs every thing that is sent to the PD console would be really fantastic and a huge helper for handling objects like [soundfiler], the hcs-objects etcetc.
best
oliver
On Mon, 2021-06-14 at 10:02 +0200, Peter P. wrote:
I am wondering how one would parse these error messages if they came from one single object outlet to tell where the error originated from?
I am wondering about that, too. Maybe a [pderror] would be canvas-local and only report errors from objects belonging to the local canvas? And it would prepend the name of the object to the message?
For instance:
'netsend netsend: bad host or port? Name or service not known (-2)'
or
'netsend connecting stream socket: Interrupted system call (4)'
Obviously, those messages are not intended for parsing, but having them available to the patch would still be immensely useful.
Another one I so often wished I get proper feedback for:
'text /tmp/foo.txt: can't open' 'text /tmp/foo.txt: read failed'
Roman
- Roman Haefeli reduzent@gmail.com [2021-06-14 10:24]:
[...]
I am wondering about that, too. Maybe a [pderror] would be canvas-local and only report errors from objects belonging to the local canvas? And it would prepend the name of the object to the message?
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
'text /tmp/foo.txt: can't open' 'text /tmp/foo.txt: read failed'
I think this could be solved with an extra outlet to [textfile], [soundfiler], [readsf~] and similar objects without going through the hassle of inventing a completely parsable error-message object.
On Mon, 2021-06-14 at 10:37 +0200, Peter P. wrote:
- Roman Haefeli reduzent@gmail.com [2021-06-14 10:24]:
[...]
I am wondering about that, too. Maybe a [pderror] would be canvas- local and only report errors from objects belonging to the local canvas? And it would prepend the name of the object to the message?
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
'text /tmp/foo.txt: can't open' 'text /tmp/foo.txt: read failed'
I think this could be solved with an extra outlet to [textfile], [soundfiler], [readsf~] and similar objects without going through the hassle of inventing a completely parsable error-message object.
Totally. I even would much prefer extra info directly from the object itself. However, I assumed such a change to so many objects is not realistically going to happen. A console parser would work even for externals that do not implement messages through outlets.
Roman
On 6/14/21 10:23 AM, Roman Haefeli wrote:
On Mon, 2021-06-14 at 10:02 +0200, Peter P. wrote:
I am wondering how one would parse these error messages if they came from one single object outlet to tell where the error originated from?
I am wondering about that, too. Maybe a [pderror] would be canvas-local and only report errors from objects belonging to the local canvas? And it would prepend the name of the object to the message?
i quite like the idea of having a canvas-scope for such an object.
however, i think [pderror] is a bad name, as i would expect this object to be usable for *generating* errors (ala [print]), rather than outputting them.
anyhow, i think the proposal maps nicely to what other languages offer as "exception handling". from that pov, a good name would be [catch] (which would be *very* good, if, alas! that weren't already occupied by the similarly named but totally different [catch~]), or [except] (but i somehow have the feeling that this would need some explicit *connection* to the object that is bailing out).
with iemgut's in mind, i would go for [canvaserror] (or, for a more general case: [canvasconsole]).
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
e.g. cf the python code
try:
x=int("foo")
y=int("bar")
except:
print("one of the two conversions failed")
while thinking about the exception analogy, it might be interesting to be able to re-throw an error message: if you don't want to hande the error in your canvas, you can just pass it on to the parent canvas by sending it to an [error] object.
the same could apply to [print], which can be considered just as a "low-priority error".
fgmdsr IOhannes
- IOhannes m zmoelnig zmoelnig@iem.at [2021-06-14 13:32]:
[...]
with iemgut's in mind, i would go for [canvaserror] (or, for a more general case: [canvasconsole]).
For beginners, "canvas" is not a common concept as it currently is not explained anywhere as a "patch window" or similar. Hence the name might be difficult to relate to the object's function.
I would call it [patcherror] and explain that it is per canvas in the help-patch, possibly giving it a flag to report all errors. Or [pdebug], or ...
[...]
while thinking about the exception analogy, it might be interesting to be able to re-throw an error message: if you don't want to hande the error in your canvas, you can just pass it on to the parent canvas by sending it to an [error] object.
the same could apply to [print], which can be considered just as a "low-priority error".
Possibly just use print. Can one prefix a print color somehow btw?
best, P
I sent the message below to the wrong list... Here we go again.
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
If the user queries the errno immediately after the method call, Pd's determinism guarantees that the error really belongs to that method call. We would have to reserve a special value (e.g. "0") to mean "no error".
My main point is that errors should not be *sent* by global or canvas-local objects, but that they should be *queried*. This way the user doesn't have to deal with cross talk between different objects.
Christof
On 14.06.2021 13:29, IOhannes m zmoelnig wrote:
On 6/14/21 10:23 AM, Roman Haefeli wrote:
On Mon, 2021-06-14 at 10:02 +0200, Peter P. wrote:
I am wondering how one would parse these error messages if they came from one single object outlet to tell where the error originated from?
I am wondering about that, too. Maybe a [pderror] would be canvas-local and only report errors from objects belonging to the local canvas? And it would prepend the name of the object to the message?
i quite like the idea of having a canvas-scope for such an object.
however, i think [pderror] is a bad name, as i would expect this object to be usable for *generating* errors (ala [print]), rather than outputting them.
anyhow, i think the proposal maps nicely to what other languages offer as "exception handling". from that pov, a good name would be [catch] (which would be *very* good, if, alas! that weren't already occupied by the similarly named but totally different [catch~]), or [except] (but i somehow have the feeling that this would need some explicit *connection* to the object that is bailing out).
with iemgut's in mind, i would go for [canvaserror] (or, for a more general case: [canvasconsole]).
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
e.g. cf the python code
try: x=int("foo") y=int("bar") except: print("one of the two conversions failed")while thinking about the exception analogy, it might be interesting to be able to re-throw an error message: if you don't want to hande the error in your canvas, you can just pass it on to the parent canvas by sending it to an [error] object.
the same could apply to [print], which can be considered just as a "low-priority error".
fgmdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
On 6/14/21 3:33 PM, Christof Ressi wrote:
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
but which error-code? i mean, there currently is no such thing and if you want to use it you have to hope for the object author to implement it.
the nice thing about the [patcherror] object is that no changes would be required to whatever objects (apart from the patch that uses it, obviously; but that's true for all solutions).
i also like the possibility, to suppress error printout (e.g. when opening an *optional* configuration file).
and: it would allow us to catch *multiple* errors (e.g. if an object emitted two errors in a row, without stopping to send something to the outlet so we can query the errno). as well as being able to catch errors that are not triggered by a message directly (think: delayed opening of a file; either because this happens only when dsp is turned on, or even in a separate thread).
gamdrs IOhannes
Ok, I think we have to seperate two things:
posting error messages
obtaining error codes
I think Roman is primarly interested in 2), so that his patches can programmatically deal with certain error conditions.
Of course, 1) and 2) can be combined into a single object, basically errno + strerror.
I just shudder at the thought that users would start parsing error messages. After all, error messages are meant for display and can change at any moment. In the future, error messages might even get localized.
I find it extremely important to add proper error codes from the start to establish good practices.
i mean, there currently is no such thing and if you want to use it you have to hope for the object author to implement it.
Sure. But library authors could update their objects to introduce error codes. If well designed, error codes could be entirely optional, e.g. [errno] outputting -1 if no error code was set.
Christof
On 14.06.2021 15:55, IOhannes m zmoelnig wrote:
On 6/14/21 3:33 PM, Christof Ressi wrote:
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
but which error-code? i mean, there currently is no such thing and if you want to use it you have to hope for the object author to implement it.
the nice thing about the [patcherror] object is that no changes would be required to whatever objects (apart from the patch that uses it, obviously; but that's true for all solutions).
i also like the possibility, to suppress error printout (e.g. when opening an *optional* configuration file).
and: it would allow us to catch *multiple* errors (e.g. if an object emitted two errors in a row, without stopping to send something to the outlet so we can query the errno). as well as being able to catch errors that are not triggered by a message directly (think: delayed opening of a file; either because this happens only when dsp is turned on, or even in a separate thread).
gamdrs IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, 2021-06-14 at 16:11 +0200, Christof Ressi wrote:
Ok, I think we have to seperate two things:
posting error messages
obtaining error codes
I think Roman is primarly interested in 2),
and 1), I guess...
so that his patches can programmatically deal with certain error conditions.
Exactly.
While I fully follow your reasoning how 2) is the cleaner and more correct long-term solution (a real error handling facility), 1) is probably a more pragmatic approach that doesn't require any code to be changed and still covers all Pd objects _and_ externals that employ 'post'.
So, I'm not going to argue against 1). If iemguts or Pd would provide something like IOhannes' [canvaserror], I'd totally use it.
Roman
- is
probably a more pragmatic approach that doesn't require any code to be changed and still covers all Pd objects _and_ externals that employ 'post'.
I mean, it's probably fine for display purposes, but the help file should clearly state:
"do NOT parse the textual content of error message. EVER. SERIOUSLY"
Parsing error messages is like a house of cards that can collapse anytime.
Christof
On 14.06.2021 16:50, Roman Haefeli wrote:
On Mon, 2021-06-14 at 16:11 +0200, Christof Ressi wrote:
Ok, I think we have to seperate two things:
posting error messages
obtaining error codes
I think Roman is primarly interested in 2),
and 1), I guess...
so that his patches can programmatically deal with certain error conditions.
Exactly.
While I fully follow your reasoning how 2) is the cleaner and more correct long-term solution (a real error handling facility), 1) is probably a more pragmatic approach that doesn't require any code to be changed and still covers all Pd objects _and_ externals that employ 'post'.
So, I'm not going to argue against 1). If iemguts or Pd would provide something like IOhannes' [canvaserror], I'd totally use it.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, Jun 14, 2021 at 11:03 AM Christof Ressi info@christofressi.com wrote:
- is
probably a more pragmatic approach that doesn't require any code to be changed and still covers all Pd objects _and_ externals that employ 'post'.
I mean, it's probably fine for display purposes, but the help file should clearly state:
"do NOT parse the textual content of error message. EVER. SERIOUSLY"
Parsing error messages is like a house of cards that can collapse anytime.
Also they would tend to fill up the symbol table with junk. If an error is really an error, it's not fixable from within the patch anyway. An object that encounters a showstopper error can call pd_error() instead of post() to print to the console, The user can then "find last error' and the object will be highlighted. Then they can plug the cable back in or whatever.
Martin
On Mon, 2021-06-14 at 17:01 +0200, Christof Ressi wrote:
- is
probably a more pragmatic approach that doesn't require any code to be changed and still covers all Pd objects _and_ externals that employ 'post'.
I mean, it's probably fine for display purposes, but the help file should clearly state:
"do NOT parse the textual content of error message. EVER. SERIOUSLY"
Absolutely. However, when that is the only information available, I'm very likely going to use it - against all good practice rules.
Roman
On 6/14/21 4:11 PM, Christof Ressi wrote:
I just shudder at the thought that users would start parsing error messages. After all, error messages are meant for display and can change at any moment. In the future, error messages might even get localized.
i totally agree.
I find it extremely important to add proper error codes from the start to establish good practices.
yes!
pity that Wannabe is no longer in the charts though.
fmdsadr IOhannes
Christof Ressi wrote:
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
that can take a long time, even for vanilla objects ;-)
and there are so many 3rd party objects out there that would all need to be modified and re-released in order to fit these quite specific needs.
if it's not too big a project (IOhannes must decide), i think that such an object (like [canvaserror]) would do no harm to "everyday users" and would at least be very handy for those who have a need for it.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
since it would be part of IEMGUTS (which i think is where it belongs to), people usually know what they let themselves in for and would design their patches accordingly. for example, there's no real need for more than one [soundfiler] or [text define] objects in a canvas...
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
If the user queries the errno immediately after the method call, Pd's determinism guarantees that the error really belongs to that method call. We would have to reserve a special value (e.g. "0") to mean "no error".
sounds nice, too. but it wouldn't verbosely specify the type of error, like the console output, would it ?
just my 2c
best
oliver
Here's another idea: a "catch" object that passes messages from inlet to outlet, but then reports errors (somehow or other) only when those errors occur while forwarding the message.
cheers M
On Mon, Jun 14, 2021 at 04:01:15PM +0200, oliver wrote:
Christof Ressi wrote:
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
that can take a long time, even for vanilla objects ;-)
and there are so many 3rd party objects out there that would all need to be modified and re-released in order to fit these quite specific needs.
if it's not too big a project (IOhannes must decide), i think that such an object (like [canvaserror]) would do no harm to "everyday users" and would at least be very handy for those who have a need for it.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
since it would be part of IEMGUTS (which i think is where it belongs to), people usually know what they let themselves in for and would design their patches accordingly. for example, there's no real need for more than one [soundfiler] or [text define] objects in a canvas...
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
If the user queries the errno immediately after the method call, Pd's determinism guarantees that the error really belongs to that method call. We would have to reserve a special value (e.g. "0") to mean "no error".
sounds nice, too. but it wouldn't verbosely specify the type of error, like the console output, would it ?
just my 2c
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
that's an excellent idea!
I think it could work like this:
[catch] has one inlet and two outlets. If you send a message to the inlet, the object will
reset the global (per instance) error state to a reserved value
forward the message throught he right outlet. This message would call
a "throwing" method in another object, which would in turn set the error state.
- output the current error state
There could be a public API method, e.g. pd_setlasterror(), which would set the current error code.
I think it would make sense to *always* output an error code, even on success, so we wouldn't need special logic to distinguish between success and failure. For example, 0 could always mean "no error".
Also, it might be useful to distinguish between "no error" and "unknown" (used in step 1).
If [catch] outputs "unknown", we know that the object didn't call pd_setlasterror(). This way we can write code that also works with older versions of the object.
Christof
On 14.06.2021 18:10, Miller Puckette via Pd-list wrote:
Here's another idea: a "catch" object that passes messages from inlet to outlet, but then reports errors (somehow or other) only when those errors occur while forwarding the message.
cheers M
On Mon, Jun 14, 2021 at 04:01:15PM +0200, oliver wrote:
Christof Ressi wrote:
i quite like the idea of having a canvas-scope for such an object.
Personally, I would rather prefer that if the error code would be simply output by the same object that generated the error.
that can take a long time, even for vanilla objects ;-)
and there are so many 3rd party objects out there that would all need to be modified and re-released in order to fit these quite specific needs.
if it's not too big a project (IOhannes must decide), i think that such an object (like [canvaserror]) would do no harm to "everyday users" and would at least be very handy for those who have a need for it.
On 6/14/21 10:37 AM, Peter P. wrote:
Yes, that's a good idea, but what if there are two identical objects on the same canvas?
i think that would be *your* problem. if you want to catch error messages from two instances of the same objectclass, just put them into separate canvases. simple as that.
I think Peter's concern is valid and it's actually another reason why I wouldn't like such a design.
since it would be part of IEMGUTS (which i think is where it belongs to), people usually know what they let themselves in for and would design their patches accordingly. for example, there's no real need for more than one [soundfiler] or [text define] objects in a canvas...
Here's another idea, which I don't really love, but which I would prefer over your proposed [canvaserror]:
Method calls which can generate an error send the error code to a global [errno] object and the user can query the current error state with a bang. This would be similar to 'errno' in C.
If the user queries the errno immediately after the method call, Pd's determinism guarantees that the error really belongs to that method call. We would have to reserve a special value (e.g. "0") to mean "no error".
sounds nice, too. but it wouldn't verbosely specify the type of error, like the console output, would it ?
just my 2c
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
- Christof Ressi info@christofressi.com [2021-06-14 22:35]:
that's an excellent idea!
I think it could work like this:
[catch] has one inlet and two outlets. If you send a message to the inlet,
Sounds good, but please don't call it [catch] for the reasons given earlier (confusion with catch~).
Just 2 innocent ideas to add to brainstorm,
1.) what about a special subpatch? like pd-try, or just try, it could work as a normal subpatch, but with a mandatory outlet that would catch errors for the objects that live inside it
just like we can open a [pd] object or a [clone] object, [pd-try something] would be the same but with an added outlet for errors
2.) another idea would be that try just loads the object in its first argument (and passes the next arguments for that object creation) with an added outlet if this object throws an error
so you could use [try soundifiler], and this would be a normal soundfiler that gets one more outlet
i like the catch idea, just thinking about other options too
Em Ter, 15 de jun de 2021 05:34, Peter P. peterparker@fastmail.com escreveu:
- Christof Ressi info@christofressi.com [2021-06-14 22:35]:
that's an excellent idea!
I think it could work like this:
[catch] has one inlet and two outlets. If you send a message to the
inlet,
Sounds good, but please don't call it [catch] for the reasons given earlier (confusion with catch~).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
typos.. of course i meant [try soundfiler]...
but adding something
the second idea would be interesting because it would be fast to change a patch, if you highlight the object that is throwing errors from the pd console (or using find last error), if you want to catch these errors you can just rename the object prepending "try" to it, instead of repatching, what do you think?
Em Ter, 15 de jun de 2021 09:35, José de Abreu abreubacelar@gmail.com escreveu:
Just 2 innocent ideas to add to brainstorm,
1.) what about a special subpatch? like pd-try, or just try, it could work as a normal subpatch, but with a mandatory outlet that would catch errors for the objects that live inside it
just like we can open a [pd] object or a [clone] object, [pd-try something] would be the same but with an added outlet for errors
2.) another idea would be that try just loads the object in its first argument (and passes the next arguments for that object creation) with an added outlet if this object throws an error
so you could use [try soundifiler], and this would be a normal soundfiler that gets one more outlet
i like the catch idea, just thinking about other options too
Em Ter, 15 de jun de 2021 05:34, Peter P. peterparker@fastmail.com escreveu:
- Christof Ressi info@christofressi.com [2021-06-14 22:35]:
that's an excellent idea!
I think it could work like this:
[catch] has one inlet and two outlets. If you send a message to the
inlet,
Sounds good, but please don't call it [catch] for the reasons given earlier (confusion with catch~).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi all,
Here's another thought.
What about setting "log" to "6", which would enable sending anything that is posted on the pd console to the current "pd" symbol, so that you place a [r pd] in your patch and route the console messages and errors?
Best!
Fede
On Mon, 2021-06-14 at 09:10 -0700, Miller Puckette via Pd-list wrote:
Here's another idea: a "catch" object that passes messages from inlet to outlet, but then reports errors (somehow or other) only when those errors occur while forwarding the message.
I'm not sure I understand your proposal correctly, though it sure sounds very interesting. It would report errors that happen in a specific control message a chain as a way to more precisely tie the reporting to the source of the error?
[O] | [catch] | | | [pd do_something_on_error_condition] | [read /tmp/foo.txt( | [text define bar]
Like this?
Roman
On Mon, 2021-06-14 at 22:39 +0200, Roman Haefeli wrote:
[O] | [catch] | | | [pd do_something_on_error_condition] | [read /tmp/foo.txt(
After reading Christof's mail, I realize I got the order wrong. The other way around:
- pass original message through right outlet
- report error state on left outlet
would probably make much more sense.
Roman
The other way around
Exactly :-)
On 14.06.2021 22:47, Roman Haefeli wrote:
On Mon, 2021-06-14 at 22:39 +0200, Roman Haefeli wrote:
[O] | [catch] | | | [pd do_something_on_error_condition] | [read /tmp/foo.txt(
After reading Christof's mail, I realize I got the order wrong. The other way around:
- pass original message through right outlet
- report error state on left outlet
would probably make much more sense.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Fede Camara Halac -
IOhannes m zmoelnig -
José de Abreu -
Martin Peach -
Miller Puckette -
oliver -
Peter P. -
Roman Haefeli