Re: [PD] Ability to access error messages from patch
(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 OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Ability to access error messages from patch
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 OpenPGP_signature Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Ability to access error messages from patch
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 -- ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Click Tracker Library is online
Dear List, You can now get the click track of your favorite piece online! (or almost) The Click Trackerwebsite hosts now an open library with tracks sent by its users. The selection is small, but hopefully will grow with time. You can find pieces by Carola Bauckholt, Christian Winther Christensen, Bernhard Lang, Mesias Maiguashca, Enno Poppe, Niklas Seidl, Simon Steen-Andersen, Øyvind Torvundand a couple others. These can be downloaded as a Click Tracker file, or mp3. All the details in http://jmmmp.github.io/clicktracker/index-library If you have any click track to be posted, let me know. Best, João Pais -- Click Tracker Mobile -https://bit.ly/click-tracker-mob Click Tracker -http://j.mp/click-tracker Facebook -http://j.mp/clicktrackerfb ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Ability to access error messages from patch
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: or if in "verbose" mode, it would be: 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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Ability to access error messages from patch
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 -- https://mathr.co.uk ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
