Is there any way to prevent error messages from printing in the console? I know they're there for a reason, but there are some legitimate uses of certain objects that still generate error messages, and it would be nice to suppress them, at least while the patch is loading.
What are some of those legitimate uses? A legitimate use of an object should not be generating an error in the first place. So if that is the case it's a bug, and we should fix it. -Jonathan
On Tuesday, October 13, 2015 9:13 AM, Liam Goodacre <liamg_uw@hotmail.com> wrote:
<!--#yiv0947590529 .yiv0947590529hmmessage P{margin:0px;padding:0px;}#yiv0947590529 body.yiv0947590529hmmessage{font-size:12pt;font-family:Calibri;}-->Is there any way to prevent error messages from printing in the console? I know they're there for a reason, but there are some legitimate uses of certain objects that still generate error messages, and it would be nice to suppress them, at least while the patch is loading.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
as far as i know, there aren't any legitimate uses of vanilla objects that generate error messages. I have a pretty huge project, and the only thing i get in the console is:
expr, expr~, fexpr~ version 0.4 under GNU Lesser General Public License
...and even that is just for a gui thing that doesn't go into the final libpd release.
But when i used to use pd-extended and its objects, i often got unavoidable warnings - stuff like "xxxx is not compatible with Windows" or whatever...whether you would consider the warning a bug, or the incompatibility a bug, is not something i can answer.
what errors are you getting Liam? and with what objects? there very well could be a tidy way to avoid them.
On Tue, Oct 13, 2015 at 10:43 PM, Jonathan Wilkes via Pd-list < pd-list@lists.iem.at> wrote:
What are some of those legitimate uses?
A legitimate use of an object should not be generating an error in the first place. So if that is the case it's a bug, and we should fix it.
-Jonathan
On Tuesday, October 13, 2015 9:13 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Is there any way to prevent error messages from printing in the console? I know they're there for a reason, but there are some legitimate uses of certain objects that still generate error messages, and it would be nice to suppress them, at least while the patch is loading.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-10-13 15:43, Jonathan Wilkes via Pd-list wrote:
What are some of those legitimate uses? A legitimate use of an object should not be generating an error in the first place.
+1 well, more or less.
e.g. accessing a non-existing or locked ressource is a legitimate use of an object and should nevertheless be reported back. ideally, it would be reported back to the patch (so that (the author of) the patch can react appropriately, rather than the user , but tradition has it that Pd reports such situations by itself.
this makes it nigh impossible to e.g. check for the existence of a file in Pd (vanilla) without generating an error-message as a side-effect.
this might be annoying but i'm not sure whether i would like this behaviour to be "fixed".
anyhow, one way to suppress those messages is by setting the loglevel to "fatal" (0), then clearing the console and setting the loglevel back to normal. or ignore the loglevel fuddling, and just clear the console after you're done. afaik, there is no way to do this programmatically (in Pd vanilla) and it also deletes the entire content of the console so far.
fgm IOhannes
On Wed, 2015-10-14 at 09:09 +0200, IOhannes m zmoelnig wrote:
On 2015-10-13 15:43, Jonathan Wilkes via Pd-list wrote:
What are some of those legitimate uses? A legitimate use of an object should not be generating an error in the first place.
+1 well, more or less.
e.g. accessing a non-existing or locked ressource is a legitimate use of an object and should nevertheless be reported back. ideally, it would be reported back to the patch (so that (the author of) the patch can react appropriately, rather than the user , but tradition has it that Pd reports such situations by itself.
this makes it nigh impossible to e.g. check for the existence of a file in Pd (vanilla) without generating an error-message as a side-effect.
this might be annoying but i'm not sure whether i would like this behaviour to be "fixed".
Why not?
I desperately needed this functionality and I found a solution that does _not_ cause an error. However, it requires object classes from three different libraries (zexy, ggee, moocow): https://github.com/reduzent/netpd2/blob/master/includes/netpd-if-file.pd
I don't see why [textfile] shouldn't report that to the patch instead of the console.
Roman
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
matju already wrote a class to put console posts inside the patch for the user to handle: http://artengine.ca/desiredata/gallery/unpost.gif If people don't like that design, I'd love to see the code that shows a better way to handle errors from within the patch. However, I don't think you need (or should encourage) error-handling inside a patch just to check whether a file exists. There are already externals for that, too.
-Jonathan
On Wednesday, October 14, 2015 6:14 AM, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt.
As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR.
On Wed, Oct 14, 2015 at 6:12 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Matt,Looks like expr has '^'. What is [error]? Is it in Max? -Jonathan
On Wednesday, October 14, 2015 2:40 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt. As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR. On Wed, Oct 14, 2015 at 6:12 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think error is in the log library.
Did the license issue with expr ever get sorted? On Oct 14, 2015 4:40 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
Hi Matt, Looks like expr has '^'.
What is [error]? Is it in Max?
-Jonathan
On Wednesday, October 14, 2015 2:40 PM, Matt Barber brbrofsvl@gmail.com wrote:
A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt.
As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR.
On Wed, Oct 14, 2015 at 6:12 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ah, I see. Nice. The software I use is either copyleft or compatible with copyleft, so my brain never registered the problem. -Jonathan
On Wednesday, October 14, 2015 5:15 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
I think error is in the log library.Did the license issue with expr ever get sorted?On Oct 14, 2015 4:40 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
Hi Matt,Looks like expr has '^'. What is [error]? Is it in Max? -Jonathan
On Wednesday, October 14, 2015 2:40 PM, Matt Barber <brbrofsvl@gmail.com> wrote:
A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt. As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR. On Wed, Oct 14, 2015 at 6:12 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead of the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It behaves like print but instead of just printing the message, it treats all input as an error. On Oct 14, 2015 5:15 PM, "Matt Barber" brbrofsvl@gmail.com wrote:
I think error is in the log library.
Did the license issue with expr ever get sorted? On Oct 14, 2015 4:40 PM, "Jonathan Wilkes" jancsika@yahoo.com wrote:
Hi Matt, Looks like expr has '^'.
What is [error]? Is it in Max?
-Jonathan
On Wednesday, October 14, 2015 2:40 PM, Matt Barber brbrofsvl@gmail.com wrote:
A simpler thing would be to just have any object that deals with file i/o to return something like an "exit status" on a read or after a write attempt.
As long as we're wishing for stuff, I wish vanilla included the [error] object for proper error handling in abstractions. And a bitwise XOR.
On Wed, Oct 14, 2015 at 6:12 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-10-14 12:07, IOhannes m zmoelnig wrote:
On 2015-10-14 09:34, Roman Haefeli wrote:
I don't see why [textfile] shouldn't report that to the patch instead
of
the console.
because it would require a lot of code to be added to all use-cases of [ŧextfile] in order to not break the feedback where it is indeed desired and needed.
this should have read: "because it would require code to be added to all uses of [ŧextfile] where the error is indeed desired and needed."
this *could* be done in a way satisfying to both, if Pd had some kind of exception handling. however, it doesn't.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
i go bananas -
IOhannes m zmoelnig -
Jonathan Wilkes -
Liam Goodacre -
Matt Barber -
Roman Haefeli