It seems that the verbose level pulldown menu in the Pd window isn't fully implemented. Or am I missing something?
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hmm, this might be the problem, in doverbose():
sys_vgui("::pdwindow::post %d {%s}\n", level+4, strnescape(upbuf, s, MAXPDSTRING));
Why is there level+4? Why not just pass level straight thru?
.hc
On Feb 14, 2011, at 7:50 PM, Hans-Christoph Steiner wrote:
It seems that the verbose level pulldown menu in the Pd window isn't fully implemented. Or am I missing something?
.hc
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-15 01:59, Hans-Christoph Steiner wrote:
Hmm, this might be the problem, in doverbose():
sys_vgui("::pdwindow::post %d {%s}\n", level+4, strnescape(upbuf, s, MAXPDSTRING));
Why is there level+4? Why not just pass level straight thru?
because level#0==pd_error, level#1=error, level#2=post, ... or similar (and without looking at the code, i don't know what level#3 is for)
fgamdr IOhannes
On Feb 15, 2011, at 4:04 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-15 01:59, Hans-Christoph Steiner wrote:
Hmm, this might be the problem, in doverbose():
sys_vgui("::pdwindow::post %d {%s}\n", level+4, strnescape(upbuf, s, MAXPDSTRING));
Why is there level+4? Why not just pass level straight thru?
because level#0==pd_error, level#1=error, level#2=post, ... or similar (and without looking at the code, i don't know what level#3 is for)
I get the ranked levels, that stuff make sense. I am wondering about the algorithm. In both C and Tcl, the verbose() posting is adding 4 to the level value, so that means if people are doing verbose(4, "my message"), it actually gets set to (8, "my message"), and from what I see, then it never gets printed, since the available display levels are 0-5.
.hc
fgamdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1aQaEACgkQkX2Xpv6ydvQ9/gCffurcYLodCgIrY2ibhnfv1taj +qwAnieI23vNVLxjshHGXIJ/krRRwMB/ =t561 -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-15 16:15, Hans-Christoph Steiner wrote:
I get the ranked levels, that stuff make sense. I am wondering about the algorithm. In both C and Tcl, the verbose() posting is adding 4 to the level value, so that means if people are doing verbose(4, "my message"), it actually gets set to (8, "my message"), and from what I see, then it never gets printed, since the available display levels are 0-5.
yes, that (having only display-levels 0-5) is probably a problem/bug. maybe it would be good to have a level "all".
fgmasdr IOhannes
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
There is no way to peace, peace is the way. -A.J. Muste
On Feb 15, 2011, at 10:53 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-15 16:15, Hans-Christoph Steiner wrote:
I get the ranked levels, that stuff make sense. I am wondering about the algorithm. In both C and Tcl, the verbose() posting is adding 4 to the level value, so that means if people are doing verbose(4, "my message"), it actually gets set to (8, "my message"), and from what I see, then it never gets printed, since the available display levels are 0-5.
yes, that (having only display-levels 0-5) is probably a problem/bug. maybe it would be good to have a level "all".
Do you remember why those "incr 4" and "level+4" are there to begin with? I think removing that is the best solution, and then leave 0-5 levels. That way 5=all.
.hc
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-16 04:53, Hans-Christoph Steiner wrote:
Do you remember why those "incr 4" and "level+4" are there to begin
yes, so that "verbose(0," is not the same as "error("
with? I think removing that is the best solution,
the duplication should be removed.
and then leave 0-5 levels. That way 5=all.
i don't think so. "verbose(3," should have higher priority than "verbose(6,"
even if nobody uses such high verbosity levels now (at least i don't know any use cases), "all" should be ALL, and not <=5.
it's a conceptual difference, and we shan't mingle our ideas with what might be practical with conceptual differences (ah, it's still early in the morning; forgive my pompousness)
vbsmtf IOhannes
On Feb 16, 2011, at 4:26 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-16 04:53, Hans-Christoph Steiner wrote:
Do you remember why those "incr 4" and "level+4" are there to begin
yes, so that "verbose(0," is not the same as "error("
with? I think removing that is the best solution,
the duplication should be removed.
and then leave 0-5 levels. That way 5=all.
i don't think so. "verbose(3," should have higher priority than "verbose(6,"
even if nobody uses such high verbosity levels now (at least i don't know any use cases), "all" should be ALL, and not <=5.
it's a conceptual difference, and we shan't mingle our ideas with what might be practical with conceptual differences (ah, it's still early in the morning; forgive my pompousness)
I'm fine with "all" idea. I'm talking about something a bit different. I think its confusing that the verbose() function adds 4. That means there are two number schemes: the post 0-5 and beyond, and the verbose number scheme which is 4 and beyond, but they don't line up, i.e. verbose(4,"") is not the same as post(4,""). And there is no post(4,"") is C space. And 4 is totally arbitrary since the normal levels are 0-5.
How about we choose just function/proc: post(level, message) or verbose(level, message), allow them to use any number, and remove the +4? Then have this the same on Tcl and C? We lose no functionality and its much easier to understand.
.hc
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
On Feb 16, 2011, at 4:26 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-16 04:53, Hans-Christoph Steiner wrote:
Do you remember why those "incr 4" and "level+4" are there to begin
yes, so that "verbose(0," is not the same as "error("
with? I think removing that is the best solution,
the duplication should be removed.
and then leave 0-5 levels. That way 5=all.
i don't think so. "verbose(3," should have higher priority than "verbose(6,"
even if nobody uses such high verbosity levels now (at least i don't know any use cases), "all" should be ALL, and not <=5.
it's a conceptual difference, and we shan't mingle our ideas with what might be practical with conceptual differences (ah, it's still early in the morning; forgive my pompousness)
So how about this:
- keep verbose() as it is - add logpost(level, message) to both Tcl and C - change ::pdwindow::post to mirror the C post() i.e. remove level - remove ::pdwindow::fatal, ::pdwindow::warn, ::pdwindow::info since they are not used anywhere - keep ::pdwindow::post ::pdwindow::error ::pdwindow::bug
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
On Feb 21, 2011, at 5:42 PM, Hans-Christoph Steiner wrote:
On Feb 16, 2011, at 4:26 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-16 04:53, Hans-Christoph Steiner wrote:
Do you remember why those "incr 4" and "level+4" are there to begin
yes, so that "verbose(0," is not the same as "error("
with? I think removing that is the best solution,
the duplication should be removed.
and then leave 0-5 levels. That way 5=all.
i don't think so. "verbose(3," should have higher priority than "verbose(6,"
even if nobody uses such high verbosity levels now (at least i don't know any use cases), "all" should be ALL, and not <=5.
it's a conceptual difference, and we shan't mingle our ideas with what might be practical with conceptual differences (ah, it's still early in the morning; forgive my pompousness)
So how about this:
- keep verbose() as it is
- add logpost(level, message) to both Tcl and C
- change ::pdwindow::post to mirror the C post() i.e. remove level
- remove ::pdwindow::fatal, ::pdwindow::warn, ::pdwindow::info since
they are not used anywhere
- keep ::pdwindow::post ::pdwindow::error ::pdwindow::bug
I just pushed to pd-extended.git a reworking of the Pd window and the post code, adding logpost() and dynamic updating of the log level. It now keeps all messages in a buffer, then when you select a loglevel from the Pd window, it'll clear the Pd window and refilter the whole log based on the new log level. In the process I found some tweaks that make things run much faster when posting lots of messages, so that's nice. It also includes all of the changes above except the "remove" one.
I'd like to refactor this into something for Pd 0.43. Miller, IOhannes, what do you think?
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-22 07:32, Hans-Christoph Steiner wrote:
So how about this:
- keep verbose() as it is
- add logpost(level, message) to both Tcl and C
- change ::pdwindow::post to mirror the C post() i.e. remove level
- remove ::pdwindow::fatal, ::pdwindow::warn, ::pdwindow::info since
they are not used anywhere
- keep ::pdwindow::post ::pdwindow::error ::pdwindow::bug
seems like a good idea.
I just pushed to pd-extended.git a reworking of the Pd window and the
i haven't looked into that yet.
post code, adding logpost() and dynamic updating of the log level. It now keeps all messages in a buffer, then when you select a loglevel from the Pd window, it'll clear the Pd window and refilter the whole log based on the new log level.
i don't know whether this is so practical. e.g. in my personal way of working i find that i often (ab?)use the pd-console as a scratchpad, where i add comments or (more often) insert spaces to group important information together.
but maybe the 2 interests don't clash in reality, so i don't have s very strong opinion about it.
In the process I found some tweaks that make things run much faster when posting lots of messages, so that's nice.
sounds good.
I'd like to refactor this into something for Pd 0.43. Miller, IOhannes, what do you think?
while we are at it, there is one more thing which i would like to have in post() on the long run: attach the calling object to a special message. the idea is, that (esp. with errors, but why not other messages as well?), that you could double click on a message and it will bring you to the object that sent it (if available/applicable)
right now this is only possible with pd_error (as this is the only fun that explicitely gets a reference to the sending object), but it would be nice if this could be done for all printouts.
this would obviously need another argument on the tcl-side.
fgasdmr IOhannes
On Tue, 2011-02-22 at 09:17 +0100, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-22 07:32, Hans-Christoph Steiner wrote:
So how about this:
- keep verbose() as it is
- add logpost(level, message) to both Tcl and C
- change ::pdwindow::post to mirror the C post() i.e. remove level
- remove ::pdwindow::fatal, ::pdwindow::warn, ::pdwindow::info since
they are not used anywhere
- keep ::pdwindow::post ::pdwindow::error ::pdwindow::bug
seems like a good idea.
Ok, I'll go ahead and submit a patch for pure-data.git.
I just pushed to pd-extended.git a reworking of the Pd window and the
i haven't looked into that yet.
post code, adding logpost() and dynamic updating of the log level. It now keeps all messages in a buffer, then when you select a loglevel from the Pd window, it'll clear the Pd window and refilter the whole log based on the new log level.
i don't know whether this is so practical. e.g. in my personal way of working i find that i often (ab?)use the pd-console as a scratchpad, where i add comments or (more often) insert spaces to group important information together.
but maybe the 2 interests don't clash in reality, so i don't have s very strong opinion about it.
I personally think this is awesome. It means you can have your log hiding everything but errors, but then when you get an error, you can expand the log to full detail. It turns out it that the buffering part doesn't seem to impact the performance noticably. Plus with the "after idle" performance tweak, I think this new logging will have more features and be faster.
In the process I found some tweaks that make things run much faster when posting lots of messages, so that's nice.
sounds good.
I'd like to refactor this into something for Pd 0.43. Miller, IOhannes, what do you think?
while we are at it, there is one more thing which i would like to have in post() on the long run: attach the calling object to a special message. the idea is, that (esp. with errors, but why not other messages as well?), that you could double click on a message and it will bring you to the object that sent it (if available/applicable)
right now this is only possible with pd_error (as this is the only fun that explicitely gets a reference to the sending object), but it would be nice if this could be done for all printouts.
this would obviously need another argument on the tcl-side
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
.hc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
fmar IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
mfgasdr IOhannes
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
It seems to me the way to really do this would be to have post() and logpost() find out the calling object instance on its own, if that's possible. Then it would automatically apply to all externals, which would be sweet.
Is there a way to get the current object instance that is being processed? That way post() could just use that as the object for the traceback in the Pd window.
.hc
----------------------------------------------------------------------------
kill your television
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 21:52, Hans-Christoph Steiner wrote:
It seems to me the way to really do this would be to have post() and logpost() find out the calling object instance on its own, if that's possible. Then it would automatically apply to all externals, which would be sweet.
i think this is partly possible (afair, maju had something like this in desiredata).
however, i imagine it will only work for objects which are triggered via messages (as Pd could track when a message enters an instance, and set a static variable to this instance)
otoh, it most likely won't work with objects triggered directly by t_clock events, it makes delegation hard (e.g. when creating an abstraction, you might want to appear a message to come from the abstraction itself, rather than from one of the objects inside of the abstraction...cf. iemgut's "pderror" object) and it will go havoc with multithreading (not that Pd properly supports multithreading; however, i'm a firm believer that global states are evil and we should try to generate as few "thread-unsafe-by-design" code)
finally, "post()" is sometimes used to printout messages that are not associated with an object at all. e.g., where do you want to jump to at "I/O error, audio stuck", or at "GEM: Authors : Mark Danks (original version)"
therefore i think it is a good idea to make the new logpost() behave similar to pd_error(), as it allows us to explicitely associate an object (of our choice!) with a message. since it might be a nice feature to have traditional "error" and "post" messages associated with an object, this functionality could be added for the sake of those old APIs
but let's not do automagic if there is no need at all.
fgmasdr IOhannes
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu:
0 fatal 1 error 2 normal 3 info ALL
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On Feb 23, 2011, at 5:50 PM, Hans-Christoph Steiner wrote:
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu:
0 fatal 1 error 2 normal 3 info ALL
.hc
Ok, I pushed my changes to origin/master in pd-extended.git. I think its looking pretty good. There are even labels on the menu like above and a working 'all' :)
.hc
----------------------------------------------------------------------------
I hate it when they say, "He gave his life for his country." Nobody gives their life for anything. We steal the lives of these kids. - Admiral Gene LeRocque
Hi all,
Sorry to reopen this old thread -- I think there's a more recent message from HC but I can't find it right now.
I wonder if, in the interest of putting 0.43 out, we should just hide the verbosity level control and let all printout through for 0.43, then try to figure out how to do this correctly for 0.44. I'm worried that the verbosity level and the "verbose" flag (in the search path menu) aren't coordinated. and I think they really should be. We would need to figure out whether verbosity can just be a level or should be a bitfield (file open attempts, warnings, blah blah). Also, the filtering almost certainly should be done down in Pd, not in the Tcl code, unless there's a significant amount of printout coming from the Tcl layer which I think there isn't.
I still need to test Pd on a couple more hardware/software combinations, but would dearly love to get the damn thing done so I can start working on some things I'm delaying for 0.44.
thanks Miller
On Wed, Feb 23, 2011 at 05:50:56PM -0500, Hans-Christoph Steiner wrote:
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu:
0 fatal 1 error 2 normal 3 info ALL
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I agree that there should only be one set of levels, that would just mean removing the "+4" from two places, and it would be that way. Tomorrow morning I can complete a patch for 0.43 based on a tested and debugged version of all this that I have mostly in the pd-extended.git patch_series branch with some bug fixes that are currently only on my machine. It makes the Pd window log much more usable and has little risk as I see it, so I think is worth including.
Other than that, yes, let's release 0.43!
hc
On Mar 9, 2011, at 12:32 AM, Miller Puckette wrote:
Hi all,
Sorry to reopen this old thread -- I think there's a more recent message from HC but I can't find it right now.
I wonder if, in the interest of putting 0.43 out, we should just hide the verbosity level control and let all printout through for 0.43, then try to figure out how to do this correctly for 0.44. I'm worried that the verbosity level and the "verbose" flag (in the search path menu) aren't coordinated. and I think they really should be. We would need to figure out whether verbosity can just be a level or should be a bitfield (file open attempts, warnings, blah blah). Also, the filtering almost certainly should be done down in Pd, not in the Tcl code, unless there's a significant amount of printout coming from the Tcl layer which I think there isn't.
I still need to test Pd on a couple more hardware/software combinations, but would dearly love to get the damn thing done so I can start working on some things I'm delaying for 0.44.
thanks Miller
On Wed, Feb 23, 2011 at 05:50:56PM -0500, Hans-Christoph Steiner wrote:
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu:
0 fatal 1 error 2 normal 3 info ALL
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
Ok, finally, its all cooked into a nice, decently-tested series of patches against the HEAD of master. This patch set completes a set of inter-related things related to the Pd window and the logging functions. I think you'll find it a huge improvement. It is a combo of work that IOhannes and I recently did.
- completes the post/error/verbose API on the Tcl side - adds logpost() proc/function for logging at a set level - adds symbolic labels to the Log: menu numbers - adds 'pd findinstance' to allow Ctrl/Cmd-clicking or hitting Enter on a log message to show which instance generated that message - makes posting to the log MUCH more efficient due to good integration with the Tk loop (i.e. after idle) - complete buffer of all log messages that is filterable using the Log: menu (can filter about 100,000 lines per second on my machine) - makes the text in the Pd window un-editable but still copy-n-paste- able (patch #3) - separates the idea of the -verbose flag and log level since they are different - adjust the post() statements that should be error statements, like "... couldn't create". (patch #4)
https://sourceforge.net/tracker/?func=detail&aid=3204677&group_id=55...
To get an idea of the improvements, try the attached patch on an older version of Pd vs a version with these patches applied.
.hc
On Mar 9, 2011, at 12:32 AM, Miller Puckette wrote:
Hi all,
Sorry to reopen this old thread -- I think there's a more recent message from HC but I can't find it right now.
I wonder if, in the interest of putting 0.43 out, we should just hide the verbosity level control and let all printout through for 0.43, then try to figure out how to do this correctly for 0.44. I'm worried that the verbosity level and the "verbose" flag (in the search path menu) aren't coordinated. and I think they really should be. We would need to figure out whether verbosity can just be a level or should be a bitfield (file open attempts, warnings, blah blah). Also, the filtering almost certainly should be done down in Pd, not in the Tcl code, unless there's a significant amount of printout coming from the Tcl layer which I think there isn't.
I still need to test Pd on a couple more hardware/software combinations, but would dearly love to get the damn thing done so I can start working on some things I'm delaying for 0.44.
thanks Miller
On Wed, Feb 23, 2011 at 05:50:56PM -0500, Hans-Christoph Steiner wrote:
On Feb 23, 2011, at 5:38 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-02-23 09:05, IOhannes m zmoelnig wrote:
On 2011-02-22 23:26, Hans-Christoph Steiner wrote:
This would be very nice, I could see being about to double-click any line in the log and have it pop up which object made the log message. I won't have time to implement this in the foreseeable future.
well, the thing is that for now we only have to reserve an additional variable "objectID" for the logpost(), which could be NULL/empty.
logpost(objectID, level, msg,...)
then, time permitting, fill in the missing code on both the C and the tcl side.
i only try to avoid re-defining functions in each release.
anyhow, here is a draft for how this would work (to be applied on top of pd-extended.git#fac011b1)
apart from changing the logpost() functions, it also adds a new global method to Pd that allows for selecting/highlighting an object based on a symbolic representation of it's address.
like alway, most work was spent in trying to figure out things in tcl :-)
Now I'm starting to think that these would be appropriate levels, and use both the number and the name for the Log menu:
0 fatal 1 error 2 normal 3 info ALL
.hc
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
-
Hans-Christoph Steiner -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette