hi IOhannes, hi list
my intention was to build a little helper that writes a list (not 'list'-datatype) of symbols into a textfile, so that in case of a pd-crash, the main-patch can restore the state before pd crashed. ironically, this helper causes pd to crash. i couldn't find a loop or similar. so i assume, it is an issue with zexy's [msgfile]and its [write(-to-file feature . i tried it on win / pd-0.39.0 and linux / pd-0.39.0 and on both pd crashed.
see attached patch. to intentionally make pd crash, just add a few symbols and remove a few. after 7-10 actions or so, pd crashes.
lg roman
hi
Roman Haefeli wrote:
hi IOhannes, hi list
see attached patch. to intentionally make pd crash, just add a few symbols and remove a few. after 7-10 actions or so, pd crashes.
first my rant of the day: i would highly appreciate if people would say which symbols they are entering to make it crash (even better would be a bugreport-patch that says "1st click here, 2nd click here, 3rd click here to crash") people tend to write "type some symbols and sometimes it will crash and sometimes not"; so what am i (as possible bugfixer) expected to do ?? guess which symbols people typed ? end of the rant
nevertheless it was quite easy to make the patch you sent crash, so it was not that hard to find out what was going on.
the problem turned out to be with most of msgfile's functions being "non-reentrant" (the output things while still running in a message-method; now the output is fed back to the object and modifies via a 2nd message the data of the object; the 1st method continues to execute and crashes since it assumes things of the data that aren't valid any more) anyhow, the CVS-version should be fixed now (i just commited it, so be patient if you check out as anonymous)
a note on your patch: i think it is not very clever to send a "delete"-message every time something is omitted on the 1st outlet (you do so by triggering an [f] (hopefully set to something valid by the 2nd outlet of [msgfile]) with the 1st outlet.) (but it could well be, that you only do so, because it proved to delay/circumvent/... the reentrance problem a bit) and "find" changes the current position to the first matching line. [delete( (without argument) deletes the current line (not specifying the line# is more efficient, as you don't have to seek for the line; but i know this only because i just read the code...)
mfg.asd. IOhannes
#N canvas 22 535 442 379 10; #N canvas 648 352 293 301 statebackup 0; #X obj 9 17 inlet; #X obj 113 12 inlet; #X obj 39 206 msgfile; #X msg 39 85 add $1; #X obj 9 41 symbol; #X msg 9 172 write aaaaaaa; #X obj 9 63 t b s; #X obj 83 228 route float; #X obj 9 150 del 20; #X msg 57 149 delete; #X msg 113 88 rewind , find $1; #X obj 27 126 t b b; #X connect 0 0 4 0; #X connect 1 0 10 0; #X connect 2 1 7 0; #X connect 3 0 2 0; #X connect 4 0 6 0; #X connect 5 0 2 0; #X connect 6 0 8 0; #X connect 6 1 3 0; #X connect 7 0 11 0; #X connect 8 0 5 0; #X connect 9 0 2 0; #X connect 10 0 2 0; #X connect 11 0 8 0; #X connect 11 1 9 0; #X restore 16 217 pd statebackup; #X symbolatom 16 157 10 0 0 0 - - -; #X symbolatom 109 190 10 0 0 0 - - -; #X text 93 154 <- add to file; #X text 188 189 <- remove from file; #X obj 16 127 symbol; #X msg 21 92 a , b , v; #X obj 202 123 symbol; #X msg 207 88 v , a , f; #X connect 1 0 0 0; #X connect 2 0 0 1; #X connect 5 0 1 0; #X connect 6 0 5 0; #X connect 7 0 2 0; #X connect 8 0 7 0;
hi IOhannes
many thanks for the the detailed answer.
On Sun, 02 Oct 2005 18:23:49 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
first my rant of the day: i would highly appreciate if people would say which symbols they are entering to make it crash (even better would be a bugreport-patch that says "1st click here, 2nd click here, 3rd click here to crash") people tend to write "type some symbols and sometimes it will crash and sometimes not"; so what am i (as possible bugfixer) expected to do ?? guess which symbols people typed ? end of the rant
i absolutely see your point. in this case i was pretty sure, that it will crash for sure (not somtimes and sometimes not). so i thought, 'after 7 - 10 actions' would be information enough. it turned out, that it crashes after the second action, after the first time a symbol was removed, what would be a more accurate information. for me it was not obvious, that i should tell, what symbols i entered, because it does not depend on what symbols. maybe i should have explicitly wrote, that it does *not* depend.
a note on your patch: i think it is not very clever to send a "delete"-message every time something is omitted on the 1st outlet (you do so by triggering an [f] (hopefully set to something valid by the 2nd outlet of [msgfile]) with the 1st outlet.) (but it could well be, that you only do so, because it proved to delay/circumvent/... the reentrance problem a bit) and "find" changes the current position to the first matching line. [delete( (without argument) deletes the current line (not specifying the line# is more efficient, as you don't have to seek for the line; but i know this only because i just read the code...)
thanks again for the explanation and hints.
lg roman
mfg.asd. IOhannes
Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx
Roman Haefeli wrote:
hi IOhannes
i absolutely see your point. in this case i was pretty sure, that it will crash for sure (not somtimes and sometimes not). so i thought, 'after 7 - 10 actions' would be information enough. it turned out, that it crashes after the second action, after the first time a symbol was removed, what would be a more accurate information. for me it was not obvious, that i should tell, what symbols i entered, because it does not depend on what symbols. maybe i should have explicitly wrote, that it does *not* depend.
yes of course. as i wrote, it was pretty easy to find some input that did crash. (but adding "mfg vfew bntr" and removing "juzt vwre yxdf", which is the first thing i tried, did not crash...) so your bug-report would have been _even nicer_ (although it was already quite nice), if it would have contained things like 'add "a", add "b", remove "a", remove "c"'
this way, we could start and build an "automatic unit test" suite for objects.
anyhow, i hope it works for now.
mfg.asd.r IOhannes
anyhow, i hope it works for now.
mfg.asd.r IOhannes
yes. thanks for fixing it.
roman
Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx
Hi everyone, I was just wondering if there is a way to display what the user is typing into the keyboard in a dynamically expanding string to appear in a message box? By using the set message I can see each seperate char but can I actually put these all together within a message box?
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Rory Walsh wrote:
Hi everyone, I was just wondering if there is a way to display what the user is typing into the keyboard in a dynamically expanding string to appear in a message box? By using the set message I can see each seperate char but can I actually put these all together within a message box?
using "add2" (instead of "set") you can append things to your message-box (but you will get spaces between each character; you could then use [list2symbol] (zexy) to merge the list of characters into one symbol)
mfg.ads.r IOhannes
Cheers, that did the tricvk it's a puty about the spaces between each char, thanks again, Rory. --- IOhannes m zmoelnig zmoelnig@iem.at wrote:
Rory Walsh wrote:
Hi everyone, I was just wondering if there is a
way to
display what the user is typing into the keyboard
in a
dynamically expanding string to appear in a
message
box? By using the set message I can see each
seperate
char but can I actually put these all together
within
a message box?
using "add2" (instead of "set") you can append things to your message-box (but you will get spaces between each character; you could then use [list2symbol] (zexy) to merge the list of characters into one symbol)
mfg.ads.r IOhannes
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com