hi all,
i recently got this error message on my graphic heavy patch: error: .x8a96420: no such object
i'm using pd-0.37-1test3 with yves threaded gui patch and tot
any idea what could cause that?
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
hi Tim,
the most likely immediate reason is the pd-gui layer trying to talk to a non-existent glist editor (which is patching window's representation, and the handler, at the pd layer side).
The source might be timing problems (perhaps, due to sending thread exceeding the one-second timeout during editor destruction), or it might be tot-related.
Does that happen while opening/closing of windows? What are the other symptoms, apart from the error message?
Krzysztof
Tim Blechmann wrote: ...
i recently got this error message on my graphic heavy patch: error: .x8a96420: no such object
i'm using pd-0.37-1test3 with yves threaded gui patch and tot
the most likely immediate reason is the pd-gui layer trying to talk to a non-existent glist editor (which is patching window's representation, and the handler, at the pd layer side).
The source might be timing problems (perhaps, due to sending thread exceeding the one-second timeout during editor destruction), or it might be tot-related.
Does that happen while opening/closing of windows? What are the other symptoms, apart from the error message?
usually i happens while closing a patch ... well, the patch doesn't close properly, all objects vanish, but the window doesn't close...
cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
On Fri, 19 Mar 2004, Tim Blechmann wrote:
Does that happen while opening/closing of windows? What are the other symptoms, apart from the error message?
usually i happens while closing a patch ... well, the patch doesn't close properly, all objects vanish, but the window doesn't close...
Are you sure all objects vanish? I made tests using hundreds of objects in Pd, and when I moved or deleted stuff, almost all of the stuff vanished, but there are apparently some kind of dropouts in the client-server connection, which means it loses some messages or part of messages when there are too many object operations. This is in addition to having audio dropouts at once, and so I would very much like to solve at least one of the two problems, and as much as possible the two at once...
Mathieu Bouchard http://artengine.ca/matju
On Fri, 19 Mar 2004, Tim Blechmann wrote:
Does that happen while opening/closing of windows? What are the other symptoms, apart from the error message?
usually i happens while closing a patch ... well, the patch doesn't close properly, all objects vanish, but the window doesn't close...
Are you sure all objects vanish? I made tests using hundreds of objects in Pd, and when I moved or deleted stuff, almost all of the stuff vanished, but there are apparently some kind of dropouts in the client-server connection, which means it loses some messages or part of messages when there are too many object operations. This is in addition to having audio dropouts at once, and so I would very much like to solve at least one of the two problems, and as much as possible the two at once...
currently i can't reproduce these errors, and i don't have enough time to test it completely right now ...
anyway, i think the combination of yves' patch / toxy and pd's core isn't working very good ... but on the other hand i can't use my patch without yves' patch without getting clicks :-(
cheers...
Tim mailto:TimBlechmann@gmx.de ICQ: 96771783 -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
hi again Tim,
there is a limit of 20000 bytes that can be transferred up to the gui ``at once''. If exceeded, the gui chokes. During closing of a window, the sequence is:
- send ".x%x.c delete all\n" to the gui (%x takes the glist's
addresss)
do some clean-up
send "destroy .x%x\n" to the gui
If there is some bulk data sent up in the intermediate stage (2), possibly through a tot, then there will be a possibility of loosing the command "destroy" -- particularly so, when using threaded transfer, which tends to glue data into larger `bursts'.
No proof, however, that this is actually the case... If it is, then, perhaps, spreading tot's activity more evenly in time will help? Or, somehow filtering the data stream?
Krzysztof
Tim Blechmann wrote: ...
usually i happens while closing a patch ... well, the patch doesn't close properly, all objects vanish, but the window doesn't close...
Tim Blechmann wrote:
On Fri, 19 Mar 2004, Tim Blechmann wrote:
Does that happen while opening/closing of windows? What are the other symptoms, apart from the error message?
usually i happens while closing a patch ... well, the patch doesn't close properly, all objects vanish, but the window doesn't close...
Are you sure all objects vanish? I made tests using hundreds of objects in Pd, and when I moved or deleted stuff, almost all of the stuff vanished, but there are apparently some kind of dropouts in the client-server connection, which means it loses some messages or part of messages when there are too many object operations. This is in addition to having audio dropouts at once, and so I would very much like to solve at least one of the two problems, and as much as possible the two at once...
currently i can't reproduce these errors, and i don't have enough time to test it completely right now ...
anyway, i think the combination of yves' patch / toxy and pd's core isn't working very good ... but on the other hand i can't use my patch without yves' patch without getting clicks :-(
i had such errors already without the patch, it's simply a question of communication between pd and pd-gui which happens either if it's threaded or not.
cheers, sevy
hi Yves and others,
I see two problems with pd-gui's handling of tcl stuff sent by the pd layer.
- The 20k limit can be hit very easily with array redraws, or
with toxy -- the more so, the bigger is the effect of glueing several commands, and sending them at once.
- The handler at the pd-gui side, pd_readsocket(), is not
reentrant -- some commands (like tk_getOpenFile) enter event loop, which might invoke the handler reentrantly, thus overwriting any additional commands that are glued to the end of the blocking command. However, I guess, making pd_readsocket() reentrant would have to involve some sort of stamping sys_gui data (with serial numbers?).
Basically, the weakness is of the pd-gui, not of the threading patch (which sometimes makes that weakness more evident, perhaps).
Krzysztof
Yves Degoyon wrote: ...
it's simply a question of communication between pd and pd-gui which happens either if it's threaded or not.
-
Krzysztof Czaja -
Mathieu Bouchard -
Tim Blechmann -
Yves Degoyon