[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
Ivica Ico Bukvic
ico at vt.edu
Wed Nov 24 18:34:50 CET 2010
Unfortunately not at this point in time as I've not tested my stuff with
gridflow at all yet (it is on my TODO). Perhaps Mathieu might have some
suggestions? Mathieu, AFAIK in l2ork iteration of pd-extended the only
thing that changed fundamentally pd-wide is widgetbehavior got another
entry at the end.
BTW, this may seem a bit of a silly question but just to be safe, you
did try the same gridflow lib with the regular vanilla pd you used prior
to l2ork iteration and if so did it work there?
Cheers!
On Wed, 2010-11-24 at 16:39 +0000, ALAN BROOKER wrote:
> 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 <ico at 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.brooker2010 at 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.brooker2010 at 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
> <ico at 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 at iem.at mailing list
> >>> UNSUBSCRIBE and account-management ->
> >>> http://lists.puredata.info/listinfo/pd-list
> >>>
> >>
> >>
>
>
More information about the Pd-list
mailing list