Hi,
sorry for a not so precise bug-report, but it's all i can offer:
recently i discovered a strange behaviour in Windows PD 0.49 (32bit) when the closing of a patch window (or even the closing of a subpatch window) would result in a Tcl/Tk error that i have not excperienced up until PD 0.49.
so, i close a window (main or subpatch - mostly with STRG+w), the patch window turns white with some inlet relics still being displayed and the console prints out a Tcl/TK error message in red colour.
the console says for example this:
(Tcl) UNHANDLED ERROR: bad window path name ".x3b212c8" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path"" (procedure "pdtk_canvas_reflecttitle" line 15) invoked from within "pdtk_canvas_reflecttitle .x3b212c8 {D:/pd_0.49/_MYPATCHES_/MFPOW} {metronome} { [edit]} 0" ("uplevel" body line 718) invoked from within "uplevel #0 $docmds".x2596028: no such object .x2596028: no such object .x2596028: no such object .x2596028: no such object
from this point on nothing can be done in PD anymore, the only way to get out of this is to kill the PD process from the outside.
the patch contains several GOP subpatches and also some of my own GUI abstractions, that contain GOPs.
(the patch is very involved so i couldn't really check what would happen, if i replaced all of my abstractions with something else ...)
any ideas ? ...
best
oliver
hey oliver,
other users (including myself) have experienced this as well and it's a serious regression. Now that I have some time I want to investigate this. I've already fixed a related bug in September (https://github.com/pure-data/pure-data/pull/467).
can you do me a favour and file a bug report on GitHub? and can you try to find a minimal patch which triggers the problem (even if it doesn't happen all the time)? personally, I didn't have success in reproducing it, it only happenes very rarely and seemlingly randomly... to all the other people who have experienced this: please help!
Christof
Gesendet: Dienstag, 02. April 2019 um 11:37 Uhr Von: "oliver" oliver@klingt.org An: "pd-list@mail.iem.at" pd-list@mail.iem.at Betreff: [PD] Tcl/Tk error
Hi,
sorry for a not so precise bug-report, but it's all i can offer:
recently i discovered a strange behaviour in Windows PD 0.49 (32bit) when the closing of a patch window (or even the closing of a subpatch window) would result in a Tcl/Tk error that i have not excperienced up until PD 0.49.
so, i close a window (main or subpatch - mostly with STRG+w), the patch window turns white with some inlet relics still being displayed and the console prints out a Tcl/TK error message in red colour.
the console says for example this:
(Tcl) UNHANDLED ERROR: bad window path name ".x3b212c8" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path"" (procedure "pdtk_canvas_reflecttitle" line 15) invoked from within "pdtk_canvas_reflecttitle .x3b212c8 {D:/pd_0.49/_MYPATCHES_/MFPOW} {metronome} { [edit]} 0" ("uplevel" body line 718) invoked from within "uplevel #0 $docmds".x2596028: no such object .x2596028: no such object .x2596028: no such object .x2596028: no such object
from this point on nothing can be done in PD anymore, the only way to get out of this is to kill the PD process from the outside.
the patch contains several GOP subpatches and also some of my own GUI abstractions, that contain GOPs.
(the patch is very involved so i couldn't really check what would happen, if i replaced all of my abstractions with something else ...)
any ideas ? ...
best
oliver
-- \\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\ http://oliver.klingt.org \\\\\\\ ////////////////////////////////////////////////////////
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi, Christof.
I haven't been using PD much lately but I used to have that a lot. As far as I remember, it also used to happen when closing a window, specifically, an abstraction that I used to inspect signals by plotting them on arrays. When closing those windows, PD GUI would all freeze but it was still possible to change number boxes and everything else, though without having the visual feedback.
I'll get back to this if I can reproduce the bug.
D
http://dariosanfilippo.tumblr.com
On Tue, 2 Apr 2019 at 11:56, Christof Ressi christof.ressi@gmx.at wrote:
hey oliver,
other users (including myself) have experienced this as well and it's a serious regression. Now that I have some time I want to investigate this. I've already fixed a related bug in September ( https://github.com/pure-data/pure-data/pull/467).
can you do me a favour and file a bug report on GitHub? and can you try to find a minimal patch which triggers the problem (even if it doesn't happen all the time)? personally, I didn't have success in reproducing it, it only happenes very rarely and seemlingly randomly... to all the other people who have experienced this: please help!
Christof
Gesendet: Dienstag, 02. April 2019 um 11:37 Uhr Von: "oliver" oliver@klingt.org An: "pd-list@mail.iem.at" pd-list@mail.iem.at Betreff: [PD] Tcl/Tk error
Hi,
sorry for a not so precise bug-report, but it's all i can offer:
recently i discovered a strange behaviour in Windows PD 0.49 (32bit) when the closing of a patch window (or even the closing of a subpatch window) would result in a Tcl/Tk error that i have not excperienced up until PD 0.49.
so, i close a window (main or subpatch - mostly with STRG+w), the patch window turns white with some inlet relics still being displayed and the console prints out a Tcl/TK error message in red colour.
the console says for example this:
(Tcl) UNHANDLED ERROR: bad window path name ".x3b212c8" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path"" (procedure "pdtk_canvas_reflecttitle" line 15) invoked from within "pdtk_canvas_reflecttitle .x3b212c8 {D:/pd_0.49/_MYPATCHES_/MFPOW} {metronome} { [edit]} 0" ("uplevel" body line 718) invoked from within "uplevel #0 $docmds".x2596028: no such object .x2596028: no such object .x2596028: no such object .x2596028: no such object
from this point on nothing can be done in PD anymore, the only way to get out of this is to kill the PD process from the outside.
the patch contains several GOP subpatches and also some of my own GUI abstractions, that contain GOPs.
(the patch is very involved so i couldn't really check what would happen, if i replaced all of my abstractions with something else ...)
any ideas ? ...
best
oliver
-- \\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\ http://oliver.klingt.org \\\\\\\ ////////////////////////////////////////////////////////
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
Christof Ressi wrote:
hey oliver,
other users (including myself) have experienced this as well and it's a serious regression. Now that I have some time I want to investigate this. I've already fixed a related bug in September (https://github.com/pure-data/pure-data/pull/467).
can you do me a favour and file a bug report on GitHub?
just did it. but unfortunately (like other users said) it seems to occur completely at random, i tried to strip it down to a minimal patch but now of course nothing happens ;-)
i will hold on to observe this and try to narrow down the possible weak spots in my scenario
will report back asap
best
oliver
I have these errors on different platforms at the most inconvenient moments, but I also struggle to make it reproducible, hence no issue filed yet.
On 02.04.19 11:37, oliver wrote:
Hi,
sorry for a not so precise bug-report, but it's all i can offer:
recently i discovered a strange behaviour in Windows PD 0.49 (32bit) when the closing of a patch window (or even the closing of a subpatch window) would result in a Tcl/Tk error that i have not excperienced up until PD 0.49.
so, i close a window (main or subpatch - mostly with STRG+w), the patch window turns white with some inlet relics still being displayed and the console prints out a Tcl/TK error message in red colour.
the console says for example this:
(Tcl) UNHANDLED ERROR: bad window path name ".x3b212c8" while executing "wm title $mytoplevel "$name$dirtychar$arguments - $path"" (procedure "pdtk_canvas_reflecttitle" line 15) invoked from within "pdtk_canvas_reflecttitle .x3b212c8 {D:/pd_0.49/_MYPATCHES_/MFPOW} {metronome} { [edit]} 0" ("uplevel" body line 718) invoked from within "uplevel #0 $docmds".x2596028: no such object .x2596028: no such object .x2596028: no such object .x2596028: no such object
from this point on nothing can be done in PD anymore, the only way to get out of this is to kill the PD process from the outside.
the patch contains several GOP subpatches and also some of my own GUI abstractions, that contain GOPs.
(the patch is very involved so i couldn't really check what would happen, if i replaced all of my abstractions with something else ...)
any ideas ? ...
best
oliver
don't know if i missed something here:
i just tried the KIOSK plugin for the first time. while generally working, i am not able to change it's settings with the config file "kiosk.cfg"
the funny thing is, that some patches seem to reflect the config file's settings (i.e. the "WindowTitle" or the "ShowMenu" flag), while others completely ignore everything but the "HideMain" switch !
i can't seem to reproduce which patches work correctly and which do not. it seems that patches that take a longer startup time (to load audio or video files) seem more likely to fail, but i am really not sure.
also to ditch the "kiosk.cfg" file completely and to set the flags directly in the "kiosk-plugin.tcl" file doesn't change the random behaviour i described above.
the plugin version is 0.2 and displays a "loaded" message in the console.
oh, yes:
again it's PD 0.49 (but this also happens with 0.48) and windows 7/64bit
thanks for any hints
oliver
If this is unrelated to "Tcl/Tk error" (is it?) why not start a new thread instead?
On 02.04.19 19:46, oliver wrote:
don't know if i missed something here:
i just tried the KIOSK plugin for the first time. while generally working, i am not able to change it's settings with the config file "kiosk.cfg"
the funny thing is, that some patches seem to reflect the config file's settings (i.e. the "WindowTitle" or the "ShowMenu" flag), while others completely ignore everything but the "HideMain" switch !
i can't seem to reproduce which patches work correctly and which do not. it seems that patches that take a longer startup time (to load audio or video files) seem more likely to fail, but i am really not sure.
also to ditch the "kiosk.cfg" file completely and to set the flags directly in the "kiosk-plugin.tcl" file doesn't change the random behaviour i described above.
the plugin version is 0.2 and displays a "loaded" message in the console.
oh, yes:
again it's PD 0.49 (but this also happens with 0.48) and windows 7/64bit
thanks for any hints
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2019-04-03 20:33, Max wrote:
If this is unrelated to "Tcl/Tk error" (is it?) why not start a new thread instead?
i did.
it says: "KIOSK plugin (windows)", which is the same thread you just replied on.
did my message appear under a different thread on your machine ? or am i missing something here ?
(i don't use a threaded mail client, you know ...)
best
oliver
On 02.04.19 19:46, oliver wrote:
don't know if i missed something here:
i just tried the KIOSK plugin for the first time. while generally working, i am not able to change it's settings with the config file "kiosk.cfg"
the funny thing is, that some patches seem to reflect the config file's settings (i.e. the "WindowTitle" or the "ShowMenu" flag), while others completely ignore everything but the "HideMain" switch !
i can't seem to reproduce which patches work correctly and which do not. it seems that patches that take a longer startup time (to load audio or video files) seem more likely to fail, but i am really not sure.
also to ditch the "kiosk.cfg" file completely and to set the flags directly in the "kiosk-plugin.tcl" file doesn't change the random behaviour i described above.
the plugin version is 0.2 and displays a "loaded" message in the console.
oh, yes:
again it's PD 0.49 (but this also happens with 0.48) and windows 7/64bit
thanks for any hints
oliver
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
https://lists.puredata.info/pipermail/pd-list/2019-04/thread.html
Hitting reply on a random message and changing the title doesn't create a new thread. To start a new thread compose a fresh email to pd-list@lists.iem.at
http://puredata.info/community/lists/Netiquette
On 03.04.19 21:44, oliver wrote:
On 2019-04-03 20:33, Max wrote:
If this is unrelated to "Tcl/Tk error" (is it?) why not start a new thread instead?
i did.
it says: "KIOSK plugin (windows)", which is the same thread you just replied on.
did my message appear under a different thread on your machine ? or am i missing something here ?
(i don't use a threaded mail client, you know ...)
best
oliver
On 02.04.19 19:46, oliver wrote:
don't know if i missed something here:
i just tried the KIOSK plugin for the first time. while generally working, i am not able to change it's settings with the config file "kiosk.cfg"
the funny thing is, that some patches seem to reflect the config file's settings (i.e. the "WindowTitle" or the "ShowMenu" flag), while others completely ignore everything but the "HideMain" switch !
i can't seem to reproduce which patches work correctly and which do not. it seems that patches that take a longer startup time (to load audio or video files) seem more likely to fail, but i am really not sure.
also to ditch the "kiosk.cfg" file completely and to set the flags directly in the "kiosk-plugin.tcl" file doesn't change the random behaviour i described above.
the plugin version is 0.2 and displays a "loaded" message in the console.
oh, yes:
again it's PD 0.49 (but this also happens with 0.48) and windows 7/64bit
thanks for any hints
oliver
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-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 02/04/2019 11:37, oliver wrote:
"uplevel #0 $docmds".x2596028: no such object .x2596028: no such object
the same happens here. i have not been able to pinpoint it much further and thus not reported anything yet. it only happens on closing a patch, and it looks like it is only happening with rather complex patches, with gop-subpatcheres and after patching for a while. maybe it has something to do with the "undo history"?
from this point on nothing can be done in PD anymore, the only way to get out of this is to kill the PD process from the outside.
closing the pd console window still works here (pd 0.49, xubuntu 18.4)
bis denn! martin
-
Christof Ressi -
Dario Sanfilippo -
martin brinkmann -
Max -
oliver