(Resending to pd-list after respond to wrong post.)
Some quick thoughts on my end.
# error outlets
Let's say.... if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really. I already added a general "info" outlet for [soundfiler] which could easily be extended by outputting an error list ala "error # msg symbols..." or simply "errno."
One negative is that this sort of approach becomes relatively arbitrary and supported by only a few objects, some which may have a dedicated error outlet and others which may have a generalized outlet with some sort of error list selector etc. OTOH the growth of Pd's objects over time has ensured this kind of "arbitrariness" is part and parcel, so maybe it is less so.
A positive point is that it's relatively easy to communicate and work with. For instance, we have this paradigm to a small degree where [netrecieve] will output a 0 if the connect message failed.
# errno object
As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers. At least there is something already to use, however the standard values are probably not enough to cover all cases but at least "can't open file" or "unsupported parameter" etc are there.
This would force a certain design paradigm where you need to do A then check error, then maybe do B and check error, etc. Sure, that's how you do it in C, for most things, but it's also a lot of boilerplate and boilerplate is much more annoying in a patcher.
# (sub)patch errors
I find a sub(patch) level error object enticing, ie. anything in this (sub)patch will throw an error to this object. I think IOhannes called them exceptions, but I would avoid that naming as I assume it will not halt or crash Pd if the error is not handled.
Like errno, this would force a certain design paradigm where you need to group object + error object all the time. In some cases it wouldn't bother me and in others I'd find it annoying. It would be simple to communicate however and relatively easy to integrate into Pd by, I assume, a new API call where objects can raise a "patch level" error as opposed to global stdout/stderr all console.
On Jun 14, 2021, at 11:25 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
# error outlets
Let's say.... if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really.
I agree. We should ask ourselves if it is really necessary to add some generic error reporting mechanism to Pd. Error outlets are certainly the most simple and most easy to understand solution from a user perspective.
# errno object
As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers
When proposing the [errno] object, I did not mean that it would output the C errno, but rather custom error codes as defined by each object.
# (sub)patch errors
Another disadvantage is that you need to have the object in a dedicated subpatch, otherwise you have to use complicated [spigot] logic to deal with crosstalk between several objects.
Christof
On 15.06.2021 00:11, Dan Wilcox wrote:
(Resending to pd-list after respond to wrong post.)
Some quick thoughts on my end.
# error outlets
Let's say.... if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really. I already added a general "info" outlet for [soundfiler] which could easily be extended by outputting an error list ala "error # msg symbols..." or simply "errno."
One negative is that this sort of approach becomes relatively arbitrary and supported by only a few objects, some which may have a dedicated error outlet and others which may have a generalized outlet with some sort of error list selector etc. OTOH the growth of Pd's objects over time has ensured this kind of "arbitrariness" is part and parcel, so maybe it is less so.
A positive point is that it's relatively easy to communicate and work with. For instance, we have this paradigm to a small degree where [netrecieve] will output a 0 if the connect message failed.
# errno object
As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers. At least there is something already to use, however the standard values are probably not enough to cover all cases but at least "can't open file" or "unsupported parameter" etc are there.
This would force a certain design paradigm where you need to do A then check error, then maybe do B and check error, etc. Sure, that's how you do it in C, for most things, but it's also a lot of boilerplate and boilerplate is much more annoying in a patcher.
# (sub)patch errors
I find a sub(patch) level error object enticing, ie. anything in this (sub)patch will throw an error to this object. I think IOhannes called them exceptions, but I would avoid that naming as I assume it will not halt or crash Pd if the error is not handled.
Like errno, this would force a certain design paradigm where you need to group object + error object all the time. In some cases it wouldn't bother me and in others I'd find it annoying. It would be simple to communicate however and relatively easy to integrate into Pd by, I assume, a new API call where objects can raise a "patch level" error as opposed to global stdout/stderr all console.
On Jun 14, 2021, at 11:25 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
(argh. one of those emails that are lingering opened on my desktop, and were never sent...here you go:)
On 6/15/21 12:32 AM, Christof Ressi wrote:
# error outlets
Let's say.... if we were to consider adding some sort of "standard outlet" for errors, how many objects are we talking about? I assume not every object but perhaps those which read/write files and the net objects? That's not so many, really.
I agree. We should ask ourselves if it is really necessary to add some generic error reporting mechanism to Pd. Error outlets are certainly the most simple and most easy to understand solution from a user perspective.
totally.
in any case: ith the error outlet i think we really want a possibility to both:
- get the error string as well
- suppress the internal error message (as it can now be handled on a
patch level)
# errno object
As Pd is more or less structured after C to some degree, I like the idea of formalizing something like errno and simply using the standard defined error numbers
When proposing the [errno] object, I did not mean that it would output the C errno, but rather custom error codes as defined by each object.
which of course could happen to be the same as the system error numbers
- as long as they are not system *specific*.
iirc POSIX defines error names, but not their values. so probably its better to come up with your own error numbers from the start.
# (sub)patch errors
Another disadvantage is that you need to have the object in a dedicated subpatch, otherwise you have to use complicated [spigot] logic to deal with crosstalk between several objects.
again, i think this is not necessarily a bad thing as it nicely groups the objects that one wants to monitor.
Pd is a data flow language and I thikn the per-canvas paradigm maps well to the idea of data "passing through a danger zone" - which it can also leave as well.
think IOhannes called them exceptions, but I would avoid that naming as I assume it will not halt or crash Pd if the error is not handled.
well, there are uncatchable exceptions.
anyhow, i used that naming here as an input for brainstorming and for the sake of an analogy.
anyhow, whatever the name, i think we also should not use [catch] as the proposed object name ;-)
however, I do like oliver's idea of hooking up such a [catch]-like object in the object-tree.
gmasdr IOhannes
Hi all,
On 17/06/2021 12:25, IOhannes m zmoelnig wrote: ...
Pd is a data flow language and I thikn the per-canvas paradigm maps well to the idea of data "passing through a danger zone" - which it can also leave as well.
...
however, I do like oliver's idea of hooking up such a [catch]-like object in the object-tree.
...
Both have their merits, I suppose the depth first flow version could benefit from another object to uninstall the error handler, making it able to emulate the per-canvas mechanism.
A feature like "(re-)throw error/exception to parent" could be useful in both cases; with top-level unhandled errors getting printed in the console. And a "throw error to current exception handler" would be useful too.
This proliferation of objects makes me think that it could be useful to have an [error foo] set of objects, like [list].
Something like this perhaps (swap outlet order if you like, doesn't bother me)
 | [error begin ]  |      | [foo]     recover from bar and baz errors (apart from error 42 from bar) as well as errors from foo  | [error begin    ]  |          | [bar]      [route 42               ]  |         |                | [error end] recover from bar error 42   [error throw]  | [baz]  |
Claude
On Thu, Jun 17, 2021 at 12:54:40PM +0100, Claude Heiland-Allen wrote:
Hi all,
On 17/06/2021 12:25, IOhannes m zmoelnig wrote: ...
Pd is a data flow language and I thikn the per-canvas paradigm maps well to the idea of data "passing through a danger zone" - which it can also leave as well.
...
however, I do like oliver's idea of hooking up such a [catch]-like object in the object-tree.
...
Both have their merits, I suppose the depth first flow version could benefit from another object to uninstall the error handler, making it able to emulate the per-canvas mechanism.
A feature like "(re-)throw error/exception to parent" could be useful in both cases; with top-level unhandled errors getting printed in the console.? And a "throw error to current exception handler" would be useful too.
This proliferation of objects makes me think that it could be useful to have an [error foo] set of objects, like [list].
Something like this perhaps (swap outlet order if you like, doesn't bother me)
?| [error begin? ] ?|?? ? ? ? ? | [foo]????? recover from bar and baz errors (apart from error 42 from bar) as well as errors from foo ?| [error begin ?? ? ] ?|???????? ?? | [bar] ?? ? ?? [route 42???????? ? ? ? ???? ] ?|?? ????? ?? |??? ? ? ? ? ? ? ? ?? ? ?? ? | [error end]? recover from bar error 42 ? ? [error throw] ?| [baz] ? |
Claude
Well, how about just adding capabilities to the pdcontrol object.
What I'm imagining is:
[pdcontrol catch-printout [mask]] - send this a bang, and a bang comes out the (left?) outlet. This would catches whatever post(), warn(), error(), etc, messages occur while handling the "bang" outlet and send it to the printout-outlet. The message coming out could be:
<type> <error-name>
or if in "verbose" mode, it would be:
<type> <error-name> <text of message parsed as a Pd list>
The error-name would be a symbol such as "open-failed". If any of the existing post(), warn(), error(), or pd_error() got called, this would just be "print", "warning", or "error". A new chocolate-flavored pd_erport_error() would allow the reporting object to specify the error symbol.
A creation flag to pdcontrol would simply allow all messages to be output, symbol table pollution notwithstanding, for those situations where you can't get a Pd window or stderr (patches inside Camomile for example).
cheers Miller
On 6/17/21 22:56, Miller Puckette via Pd-list wrote:
Well, how about just adding capabilities to the pdcontrol object.
i am wondering why you would put that into [pdcontrol] - and not, say, the [float] object.
gfdgn IOhannes
to scare people... more seriously, because I'd consider such a thing "meta" (such as message back-tracing, which I also want to add someday)
I don't have a precise idea what I mean by "meta" here.
M
On Thu, Jun 17, 2021 at 11:38:52PM +0200, IOhannes m zm??lnig wrote:
On 6/17/21 22:56, Miller Puckette via Pd-list wrote:
Well, how about just adding capabilities to the pdcontrol object.
i am wondering why you would put that into [pdcontrol] - and not, say, the [float] object.
gfdgn IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
"On 6/17/21 23:47, Miller Puckette via Pd-list wrote:
to scare people... more seriously, because I'd consider such a thing "meta" (such as message back-tracing, which I also want to add someday)
i see.
I don't have a precise idea what I mean by "meta" here.
:-)
afaict, there's a couple of different object-types:
- "normal", modular-synth like objects
this probably includes practically *all* signal-processing objects (e.g. [osc~]) and other, simple operator objects (e.g. [+])
- "language"-defining constructs.
this is the class of objects that define the "patcher language". i think there are at least two subgroups a. data-flow objects ([trigger], [spigot], [select], [route], [until],...) b. abstract concepts, such as subpatches ([pd]), abtractions, arguments ($1), declarative objects ([declare], [namecanvas], [block~]/[switch~],...), but also [clone] and [pd~]
- "introspection" thingies
objects that allow us to gather meta-information on the patch itself. iemguts is an external collection of mostly such objects. but there's also built-in support for introspection, e.g. the [dir( and [isvisible( messages to [pdcontrol].
for me, "meta"-objects would be of the 3rd kind (and probably 2b).
i think that error-reporting - as we know it from other languages like C++, java, python,... - is a typical "language" feature. otoh, getting a backtrace is more about introspection of the running patch.
i understand that you are reluctant to add new "language" (or even "instrospection") features, as it's practically a bottomless pit (and where would we end up, if we stared too long into that? ;-))
now what i really hate about [pdcontrol], is that it belongs to all three categories. of course the groups are not totally orthogonal, and there's certainly object that fit into more than one (e.g. [change]).
but with [pdcontrol] this is different, as it just bundles unrelated functionality into a single object, but the so-far implemented functionalities actually are rather easy to categorize:
- [browse(->[pdcontrol] just belongs to the "normal" group (it is
somehow non-standard as it is asynchronous and involves the Pd-GUI, but that is actually an implementation detail)
- [args( is really just an extension of the argument-system (and it was
always possible to get all arguments of a patch; it just involved a lot of idiosyncracies (which is ok, as we are on the "language"-level) and the only way to re-use the code was by copy-and-paste (instead of wrapping it into an abstraction)
- as mentioned above, [dir( and [isvisible( messages really give you
meta-information about the patch, so they belong the "introspection" group.
and of course the name "pdcontrol" does not suggest *any* of the functionality we have so far. leaving out the [browse( message (which could just be implemented in a dedicated object and no-one would be off any worse), all the other messages so far operate on either a canvas- or a patch-level. at least for me, "pdcontrol" always suggests an "interface to control/communicate with Pd" (very much related to what we can already do by sending things to "pd"; but - being an object - theoretically much more powerful, as it allows us to get data back). i definitely don't read that name as "interface to a [pd]". it also doesn't convey the meaning of "this is a perilous realm; go away and be scared".
and then there is [pdcontrol catch-printout] which is actually a totally different objectclass. hmm.
for practical reasons, i think it might help if we could just separate the various functionalities into separate objectclasses. at least like [pdcontrol args] and [pdcontrol dir]. i guess nobody actually has a need to query the selfsame object for both the visibility state of a window and to ask it where on the disk supplementary files are located. probably also rename the object to [canvascontrol] or [patchcontrol].
in order to scare people away from using experimental objects, we might use some prefix clearly marking them as such: [XXX.browsefile]
and finally: which object would I use to get the version of the running Pd?
mfgds IOhannes
On Fri, 2021-06-18 at 13:57 +0200, IOhannes m zmölnig wrote:
i guess nobody actually has a need to query the selfsame object for both the visibility state of a window and to ask it where on the disk supplementary files are located.
+1
Roman
-
Christof Ressi -
Claude Heiland-Allen -
Dan Wilcox -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Miller Puckette -
Roman Haefeli