Okay- I've traced to Gridflow library- I've taken it out and no crashes -any tips how I can have it installed would be appreciated- thanks again for your time on this :)
On Wed, Nov 24, 2010 at 12:57 PM, Ivica Ico Bukvic <i...@vt.edu> wrote: > Try loading one lib at a time and doing the same. I don't know for sure but > it might be that one or more of them is having issues with the new move > algorithm. > > ALAN BROOKER <alan.brooker2...@gmail.com> wrote: > > >Hi Just to clarify the message > >Program received signal SIGSEGV, Segmentation fault. > >0x00000011 in ?? () > > > >is printed on the terminal when ctrl-1 is used > > > >Thanks again > >On Wed, Nov 24, 2010 at 10:11 AM, ALAN BROOKER > ><alan.brooker2...@gmail.com>wrote: > > > >> Hi Ico > >> > >> > >> Ive got it working and have loaded some libraries, Gem, Gridflow, Zexy, > pdp > >> - however PD crashes out when I ctrl-1 to put an object on the canvas. > >> > >> I've done a backtrace (thanks Mathieu for the tip previously) with the > >> following results: > >> > >> Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd > >> [Thread debugging using libthread_db enabled] > >> <init> : Avifile RELEASE-0.7.48-100119-21:44-../src/configure > >> <init> : Available CPU flags: fpu vme de pse tsc msr pae mce cx8 apic > mtrr > >> pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext > >> fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc > extd_api > >> <init> : 800.00 MHz AMD Phenom(tm) II X2 555 Processor detected > >> [New Thread 0xb47e1b70 (LWP 4084)] > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x00000011 in ?? () > >> (gdb) where > >> #0 0x00000011 in ?? () > >> #1 0x080a94d5 in gobj_displace_withtag (x=0x8206cb8, > >> dx=<value optimised out>, dy=0) at g_editor.c:68 > >> #2 canvas_displaceselection (x=0x8206cb8, dx=<value optimised out>, > dy=0) > >> at g_editor.c:1900 > >> #3 0x080a98a5 in canvas_motion (x=0x8206cb8, xpos=232, ypos=76, fmod=2) > >> at g_editor.c:2089 > >> #4 0x080ca4f6 in pd_typedmess (x=0x8206cb8, s=0x8135eb8, argc=3, > >> argv=0xbffff08c) at m_class.c:792 > >> #5 0x080ca0dc in pd_typedmess (x=0x814ac60, s=0x8135eb8, argc=3, > >> argv=0xbffff08c) at m_class.c:813 > >> #6 0x080cfbaa in binbuf_eval (x=0x8149688, target=<value optimised > out>, > >> argc=0, argv=0x0) at m_binbuf.c:726 > >> #7 0x080dde5f in socketreceiver_read (x=0x81496a8, fd=6) at > s_inter.c:560 > >> #8 0x080dd81a in sys_domicrosleep (microsec=<value optimised out>, > >> pollem=<value optimised out>) at s_inter.c:198 > >> #9 0x080de502 in sys_pollgui () at s_inter.c:862 > >> #10 0x080d9321 in m_pollingscheduler () at m_sched.c:490 > >> #11 m_mainloop () at m_sched.c:560 > >> #12 0x080dc8a9 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 > >> #13 0x080e556b in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 > >> (gdb) quit > >> A debugging session is active. > >> > >> Inferior 1 [process 4078] will be killed. > >> > >> Quit anyway? (y or n) y > >> socket receive error: Connection reset by peer (104) > >> > >> Thanks for your help with this! It's a great package to work from > >> Cheers > >> > >> > >> > >> > >> On Wed, Nov 24, 2010 at 5:29 AM, Ivica Ico Bukvic <i...@vt.edu> wrote: > >> > >>> > Notice that both [cyclone/Scope~] and [flatspace/entry] have a > >>> > bug: a sudden increase in height/width by about 5-10 pixels when you > >>> > initially drag to resize. This makes it difficult if not > >>> > impossible to make minor size changes (especially since there is no > >>> > Properties dialogue). > >>> > >>> Good to know. I will look into this when I get there. Currently working > on > >>> accelerating iemgui objects as well as exposing them to sarlo's > highlighting > >>> magic. > >>> > >>> > Wouldn't it be easier just to toggle the text for that menu option > >>> > between "Edit mode" and "Run mode"? (That's what they're called in > >>> > the manual.) > >>> > >>> Sure. There are other options, too, like the one 0.43 and now l2ork > >>> version of 0.42 uses by changing option's background which works > visually > >>> relatively well (albeit at the expense of consistency). This is however > not > >>> the issue. The issue is finding out that after an hour of debugging the > >>> problem is not in you or your code but the toolkit you are using and in > 2010 > >>> for a toolkit that has been around for more than a decade that is > plainly > >>> sad. > >>> > >>> > How would you go about doing that? > >>> > >>> A: Ugly path: Isolate pd<->gui hooks and port the entire thing to Qt. > >>> > >>> B: Better (albeit more time-consuming) path: clean-up code first so > that > >>> all objects can utilize the same gobj_<whatever> calls and then do the > A: > >>> (which at that point won't be nearly as ugly or difficult to maintain). > >>> > >>> FWIW, my first ever GUI app was RTMix I did back in 2001 and it was > (and > >>> remains) the ugliest hack ever (basically I tried to learn how to > program > >>> doing that app). Yet, the fact remains even in 2001 qt was way better > than > >>> what Tk is today. Another advantage is avoiding socket bottlenecks as > the > >>> entire thing could be done simply in C. License-wise it should be fine > and > >>> cross-platform-wise miles ahead of Tcl/Tk. Heck, you could even throw > in Qt > >>> for mobile devices for good measure since that is apparently hot item > these > >>> days. > >>> > >>> That said, I need some more time working with Pd code before I can > >>> undertake this. Perhaps more importantly, I just need a generous, > >>> uninterrupted chunk of time to do this. > >>> > >>> Best wishes, > >>> > >>> Ico > >>> > >>> > >>> _______________________________________________ > >>> Pd-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > >>> http://lists.puredata.info/listinfo/pd-list > >>> > >> > >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list