Pd-dev October 2006

pd-dev@lists.iem.at

13 participants
72 discussions

[ pure-data-Bugs-1494449 ] configure script change for intel Mac
by SourceForge.net 25 Oct '06

25 Oct '06

Bugs item #1494449, was opened at 2006-05-24 10:03 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1494449&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: christopher clepper (cclepper) Assigned to: Nobody/Anonymous (nobody) Summary: configure script change for intel Mac Initial Comment: Attached diff to detect for x86 or PowerPc based Macs ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-10-24 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 08:16 Message: Logged In: YES user_id=564396 set to pending; is this a bug-report or really just a "patch" ....? ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-08-31 01:10 Message: Logged In: YES user_id=564396 it seems like this is now handled differently. should this bug-report be therefore closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1494449&group_…

1 0

[regex] on MinGW
by Hans-Christoph Steiner 21 Oct '06

21 Oct '06

Zexy's regex.c isn't linking on MinGW: http://autobuild.puredata.info/auto-build/latest/logs/ 2006-10-20_18.12.52_mingw32_nt-5.1_windowsxp-i386_pd-extended_run- automated-builder.txt I think you need to add "-lregex" to your LDFLAGS on MinGW. For the Pd-extended build, I use in addition to the standards: "-lwsock32 -lpthreadGC2 -lkernel32 -luser32 -lgdi32 -lregex" .hc ------------------------------------------------------------------------ Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams

1 0

Re: config.h enhancements
by IOhannes m zmoelnig 21 Oct '06

21 Oct '06

hi Hans Steiner wrote: > > Just a thought: Miller has started, just barely, to use a config.h > generated by ./configure in pd/src. How about adding the stuff that you > have in zexyconf.h there? Then every library can benefit. For now, we > can just use patches in the Pd-extended build until Miller accepts them. > > I was planning on starting to make the externals/Makefile stuff use > pd/src/config.h anyway, instead of doing a separate ./configure for > externals/ > in theory i second this. in parctice there are 2 caveats: a) this would actually mean, that people would either change pd's configure.in (which is not possible dues to ACLs) or they would have to patch pd before building an external (which is not acceptable for me, since building against pd-vanilla is really a must for me) b) in zexy and Gem i use some customized m4-modules which i find really cool and would hate to abandon (but i understand if somebody would not want to use them). i think that they are much more elegant than simply using uname's output to decide which flags to use. so i'm sure that i would want to change the configure.in to make it fit to my aesthetics which might break everything, and we surely don't want that. (most likely this is pure vanity, but...) mf.asdr IOhannes PS: btw, i was forwarding all of your personal emails to pd-dev (since i consider them to be of archive-able value); i hope this is ok for you.

2 1

[ pure-data-Bugs-1371511 ] declaration of `y1' shadows a global declaration
by SourceForge.net 20 Oct '06

20 Oct '06

Bugs item #1371511, was opened at 2005-12-02 02:41 Message generated for change (Comment added) made by matju You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1371511&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Pending Resolution: None Priority: 5 Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: declaration of `y1' shadows a global declaration Initial Comment: When using math.h on Darwin, the y1 variable causes lots of warnings. ../../pd/src/g_canvas.h:247: warning: declaration of `y1' shadows a global declaration /usr/include/architecture/ppc/math.h:483: warning: shadowed declaration is here Renaming y1 in g_canvas.h would fix this problem. ---------------------------------------------------------------------- Comment By: Mathieu Bouchard (matju) Date: 2006-10-18 09:47 Message: Logged In: YES user_id=801174 Whatever about calling functions y0,y1,yn, they've been there since almost the beginning of unix. They're Bessel functions defined in <math.h>. You won't be able to move them out of it. This suggests that the -Wshadow warning is of questionable use. I'd turn it off, personally. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-18 04:33 Message: Logged In: YES user_id=564396 a) has this been fixed already? (i cannot reproduce this anymore; also the pd(-extended) buildlogs do not show this warning) b) i don't think that this is a bug in pd; no global include file (/usr/include/architecture/ppc/math.h) should use global variable names like "i", "y1" and the like. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1371511&group_…

3 4

Re: zexy build error on Windows XP/MinGW
by IOhannes m zmoelnig 19 Oct '06

19 Oct '06

Hans-Christoph Steiner wrote: > > > gcc -DPD -O3 -funroll-loops -fomit-frame-pointer -mcpu=i586 > -mtune=pentium3 -I/home/pd/auto-build/pd-extended/pd/src -W -ggdb > -mms-bitfields -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' > -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' -o > "/home/pd/auto-build/pd-extended/externals/build/src/lpt.o" -c > "/home/pd/auto-build/pd-extended/externals/build/src/lpt.c" > In file included from > C:/msys/1.0/home/pd/auto-build/pd-extended/externals/build/src/lpt.c:2: > C:/msys/1.0/home/pd/auto-build/pd-extended/externals/build/src/../../zexy/src/lpt.c:51:25: > sys/ioctl.h: No such file or directory this was due to the wrongly checked in zexyconf.h (which had linux-parallelport-device support enabled). i thought i had fixed this yesterday. mf.asdr IOhannes

2 1

[ pure-data-Patches-1094912 ] message-based access to the audio api
by SourceForge.net 19 Oct '06

19 Oct '06

Patches item #1094912, was opened at 2005-01-03 11:56 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist >Status: Open Resolution: None Priority: 6 Submitted By: Tim Blechmann (timblech) Assigned to: Miller Puckette (millerpuckette) Summary: message-based access to the audio api Initial Comment: attached is a patch that simplifies message-based access to the audio api: pd understands the following messages: audio-samplerate audio-delay audio-dacblocksize audio-scheduler audio-device audio-device-in audio-device-out audio-dacblocksize and audio-scheduler require devel_0_38 ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-18 09:58 Message: Logged In: YES user_id=564396 as carmen has pointed out on the list, miller had just very recently articulated a very similar idea. even though it is unlikely that he will use the patch here, i reopen this issue (and hopefully will close it again soon when an equivalent mechanism will be part of pd) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-10-17 07:41 Message: Logged In: YES user_id=27104 this has been here for a long while with no activity, so I am setting it to Pending. It'll be automatically set to closed after a while if no one tends to it. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-01-29 03:34 Message: Logged In: YES user_id=27104 I am liking the idea of sending messages to pd to get all of this kind of information more and more. I am thinking that a generic "get" message would be useful here. Like this: [;pd get audio-samplerate( [;pd get audio-delay( [;pd get audio-dacblocksize( [;pd get audio-scheduler( [;pd get audio-device( [;pd get audio-device-in( [;pd get audio-device-out( Then also: [;pd get path( [;pd get libs( [;pd get version( [;pd get dsp( Then you could get similar messages from each canvas/patch: [;pd-my_patch.pd get editmode( [;pd-my_patch.pd get vis( [;pd-my_patch.pd get namespace( [;pd-my_patch.pd get canvasname( You would retrieve these messages with a [receive] of the same name, i.e.: [r pd] | [route version] | ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-05-18 06:36 Message: Logged In: YES user_id=313747 I'm scared of this one... how important is it to have all the different audio parameters handled by separate messages? I think the "audio_dialog" message should suffice for setting audio parameters... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_…

2 1

[ pure-data-Patches-1094912 ] message-based access to the audio api
by SourceForge.net 19 Oct '06

19 Oct '06

Patches item #1094912, was opened at 2005-01-03 05:56 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: wishlist >Status: Pending Resolution: None Priority: 6 Submitted By: Tim Blechmann (timblech) Assigned to: Miller Puckette (millerpuckette) Summary: message-based access to the audio api Initial Comment: attached is a patch that simplifies message-based access to the audio api: pd understands the following messages: audio-samplerate audio-delay audio-dacblocksize audio-scheduler audio-device audio-device-in audio-device-out audio-dacblocksize and audio-scheduler require devel_0_38 ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-10-17 01:41 Message: Logged In: YES user_id=27104 this has been here for a long while with no activity, so I am setting it to Pending. It'll be automatically set to closed after a while if no one tends to it. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-01-28 21:34 Message: Logged In: YES user_id=27104 I am liking the idea of sending messages to pd to get all of this kind of information more and more. I am thinking that a generic "get" message would be useful here. Like this: [;pd get audio-samplerate( [;pd get audio-delay( [;pd get audio-dacblocksize( [;pd get audio-scheduler( [;pd get audio-device( [;pd get audio-device-in( [;pd get audio-device-out( Then also: [;pd get path( [;pd get libs( [;pd get version( [;pd get dsp( Then you could get similar messages from each canvas/patch: [;pd-my_patch.pd get editmode( [;pd-my_patch.pd get vis( [;pd-my_patch.pd get namespace( [;pd-my_patch.pd get canvasname( You would retrieve these messages with a [receive] of the same name, i.e.: [r pd] | [route version] | ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2005-05-18 00:36 Message: Logged In: YES user_id=313747 I'm scared of this one... how important is it to have all the different audio parameters handled by separate messages? I think the "audio_dialog" message should suffice for setting audio parameters... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1094912&group_…

4 4

[ pure-data-Bugs-1531757 ] Opening curly brace causes freeze until a closing brace
by SourceForge.net 19 Oct '06

19 Oct '06

Bugs item #1531757, was opened at 2006-07-31 09:46 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1531757&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Closed >Resolution: Postponed Priority: 5 Submitted By: Jamie Bullock (postlude) Assigned to: Nobody/Anonymous (nobody) Summary: Opening curly brace causes freeze until a closing brace Initial Comment: Typing a curly brace '{' anywhere in pd causes a freeze until a closing brace is given. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-10-18 20:25 Message: Logged In: YES user_id=27104 Since it wasn't really fixed, but rather just worked around, I changed the resolution to something hopefully more appropriate. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-18 04:13 Message: Logged In: YES user_id=564396 seems like this is fixed with pd-0.40-1 (probably earlier): typing opening curly brace results in "keycode 123: dropped". (the better solution would of course be to properly escape curly brackets so that they could be used) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1531757&group_…

1 0

[ pure-data-Bugs-1518048 ] percent symbol (%) behaves weirdly in iemgui object labels
by SourceForge.net 18 Oct '06

18 Oct '06

Bugs item #1518048, was opened at 2006-07-06 10:18 Message generated for change (Comment added) made by claudiusmaximus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.39.2 Status: Open Resolution: None Priority: 5 Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: percent symbol (%) behaves weirdly in iemgui object labels Initial Comment: When the properties window of a vslider is opened after the label has been set to a name containing %p, the label changes to something with the %p replaced by a seemingly random hexadecimal value. I haven't checked which other gui objects are affected, nor whether other % codes (eg, %d or %f) are similarly affected. See attached pd patch for an example - click the bng and then open the properties window for the vslider. ---------------------------------------------------------------------- >Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2006-10-18 16:50 Message: Logged In: YES user_id=769033 Fixed in DesireData 0.39.A (anon CVS checkout as of today). ---------------------------------------------------------------------- Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2006-10-18 16:12 Message: Logged In: YES user_id=769033 Behaves the same in pd-0.40-1 from Miller's site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518048&group_…

1 0

[ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
by SourceForge.net 18 Oct '06

18 Oct '06

Bugs item #1518030, was opened at 2006-07-06 09:54 Message generated for change (Comment added) made by claudiusmaximus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.40.1 Status: Open Resolution: None Priority: 7 Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Miller Puckette (millerpuckette) Summary: subpatch clearing itself crashes Pd Initial Comment: Tested on Linux with pd-0.39-2 from Miller's site. Steps to reproduce: start pd load the patch attached to this post click the bng close the patch load the patch again click the bng => crash OR start pd load the patch open the subpatch (optionally: close the subpatch) click the bng => crash Here's a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 27794)] pd_bang (x=0x11) at m_pd.c:269 269 m_pd.c: No such file or directory. in m_pd.c (gdb) where #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x0808a61b in outlet_bang (x=0x3) at m_obj.c:328 #2 0x080765ad in bng_bout2 (x=0x81f2790) at g_bang.c:294 #3 0x080767f6 in bng_newclick (z=0x11, glist=0x81f2338, xpix=74, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:343 #4 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #5 0x0805b557 in graph_click (z=0x81f2338, glist=0x11, xpix=74, ypix=70, shift=0, alt=0, dbl=17, doit=1) at g_graph.c:1059 #6 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #7 0x08070a97 in canvas_doclick (x=0x81ecd08, xpos=74, ypos=70, which=1, mod=0, doit=1) at g_editor.c:1094 #8 0x0807119d in canvas_mousedown (x=0x11, xpos=0, ypos=0, which=0, mod=0) at g_editor.c:1252 #9 0x08089789 in pd_typedmess (x=0x81ecd08, s=0x0, argc=0, argv=0x80cf488) at m_class.c:728 #10 0x08089665 in pd_typedmess (x=0x81f25f8, s=0x0, argc=4, argv=0x80cf468) at m_class.c:749 #11 0x0808c32f in binbuf_eval (x=0x11, target=0x81f25f8, argc=0, argv=0x0) at m_binbuf.c:574 #12 0x08091fdf in socketreceiver_read (x=0x81ec2f0, fd=7) at s_inter.c:540 #13 0x0809180f in sys_domicrosleep (microsec=17, pollem=1) at s_inter.c:180 #14 0x08092660 in sys_pollgui () at s_inter.c:823 #15 0x0808fe5b in m_scheduler () at m_sched.c:466 #16 0x08095b1b in main (argc=17, argv=0x11) at s_entry.c:27 ---------------------------------------------------------------------- >Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2006-10-18 16:30 Message: Logged In: YES user_id=769033 Some comments about pd-0.40-1 from Miller's site: 1. Start pd, load gop-subpatch-self-clear-crash.pd, click bang => no crash, subpatch is cleared correctly 2. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, click bang => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211095376 (LWP 13534)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82371f8) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x82415c8, glist=0x8241200, xpix=136, ypix=139, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0808a36a in canvas_doclick (x=0x8241200, xpos=136, ypos=139, which=1, mod=0, doit=1) at g_editor.c:92 #4 0x0808b14b in canvas_mousedown (x=0x8241200, xpos=136, ypos=139, which=1, mod=0) at g_editor.c:1242 #5 0x080a79c5 in pd_typedmess (x=0x8241200, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #6 0x080a7632 in pd_typedmess (x=0x8241418, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #7 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #8 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #9 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #10 0x080b7967 in sys_pollgui () at s_inter.c:825 #11 0x080b2f53 in m_scheduler () at m_sched.c:466 #12 0x080b651a in sys_main (argc=1, argv=0xbfcbb4a4) at s_main.c:316 #13 0x080bf7cf in main (argc=136563232, argv=0x8242b00) at s_entry.c:27 3. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, close subpatch, click bang => crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210849616 (LWP 13563)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82373c0) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x823cbc0, glist=0x8237230, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0805be1a in graph_click (z=0x8237230, glist=0x8237090, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_graph.c:1052 #4 0x0808a36a in canvas_doclick (x=0x8237090, xpos=72, ypos=70, which=1, mod=0, doit=1) at g_editor.c:92 #5 0x0808b14b in canvas_mousedown (x=0x8237090, xpos=72, ypos=70, which=1, mod=0) at g_editor.c:1242 #6 0x080a79c5 in pd_typedmess (x=0x8237090, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #7 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #8 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #9 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #10 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #11 0x080b7967 in sys_pollgui () at s_inter.c:825 #12 0x080b2f53 in m_scheduler () at m_sched.c:466 #13 0x080b651a in sys_main (argc=1, argv=0xbfeee6d4) at s_main.c:316 #14 0x080bf7cf in main (argc=136541136, argv=0x823e958) at s_entry.c:27 4. Start pd, load crash-1518030.pd, click "bang" => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210677584 (LWP 13575)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x8237408) at m_obj.c:328 #2 0x080aa8eb in outlet_bang (x=0x82373d0) at m_obj.c:328 #3 0x080aa8eb in outlet_bang (x=0x823cce0) at m_obj.c:328 #4 0x080a77a1 in pd_typedmess (x=0x823cccc, s=0x8119364, argc=0, argv=0x811a950) at m_class.c:641 #5 0x080abba4 in binbuf_eval (x=0x823cc68, target=<value optimized out>, argc=1, argv=0xbfa50e8c) at m_binbuf.c:673 #6 0x0805f46d in message_click (x=0x823ccb0, xpos=91, ypos=65, shift=0, ctrl=0, alt=0) at g_text.c:300 #7 0x08063721 in text_click (z=0x823ccb0, glist=0x8237080, xpix=91, ypix=65, shift=0, alt=0, dbl=0, doit=1) at g_text.c:1065 #8 0x0808a36a in canvas_doclick (x=0x8237080, xpos=91, ypos=65, which=1, mod=0, doit=1) at g_editor.c:92 #9 0x0808b14b in canvas_mousedown (x=0x8237080, xpos=91, ypos=65, which=1, mod=0) at g_editor.c:1242 #10 0x080a79c5 in pd_typedmess (x=0x8237080, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #11 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #12 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #13 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #14 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #15 0x080b7967 in sys_pollgui () at s_inter.c:825 #16 0x080b2f53 in m_scheduler () at m_sched.c:466 #17 0x080b651a in sys_main (argc=1, argv=0xbfa52a44) at s_main.c:316 #18 0x080bf7cf in main (argc=0, argv=0x0) at s_entry.c:27 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 15:13 Message: Logged In: YES user_id=564396 the really interesting thing here, is that your patch will not crash when you only click on the [bng] once. you have to follow the steps as described. i add another patch that triggers the crash reliable and without the complicated procedure (just click it and crash it) raised priority, since crashers should be fixed. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-07-06 18:48 Message: Logged In: YES user_id=564396 this has nothing to do with GOP, therefore i renamed the bug-report. what happens: an object emits a message; the calling function is pushed to the stack; the message triggers the deletion of the object; after the message is done, the calling function (of the now deleted object) is popped back from the stack: but alas! the entire environment has changed and nothing is as it should be....stack corruption -> crash. personally i think, that this is NOT a bug in pd but rather a bug in the patch (but i am repeating myself...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev October 2006