Re: [PD] Gridflow+ L2Ork pd-extended (was: L2Ork pd-extended release candidate 1 now available)
I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended?
ALAN BROOKER alan.brooker2010@gmail.com wrote:
If I press ctrl+1 to create an object that's when it crashes out, opening pd patches is fine but if I try to edit them then a crash will occur as well. Also opening Grdiflow help index causes crashes without loading the index patch at all
On Sat, Nov 27, 2010 at 5:43 PM, Ivica Ico Bukvic ico@vt.edu wrote:
This looks like an incompatibility between tagged moving of an object and something in the gridflow.
Does this occur with any object or just some specific object(s)?
Mathieu, The offending call should be the same like the Regular call except that is this place is using a tag. It can be found in the g_text.c file.
Cheers!
ALAN BROOKER alan.brooker2010@gmail.com wrote:
Hi Mathieu,
Thanks for this, I have done a trace back with the following output on the terminal :
(gdb) run Starting program: /usr/local/bin/pd -oss -channels 2 my-bug-test.pd [Thread debugging using libthread_db enabled] [New Thread 0xb6168b70 (LWP 5214)] <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> : 3200.00 MHz AMD Phenom(tm) II X2 555 Processor detected where
Program received signal SIGSEGV, Segmentation fault. 0x00000011 in ?? () (gdb) where #0 0x00000011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, pollem=<value optimised out>) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32 (gdb) where #0 0x00000011 in ?? () #1 0x080a9665 in gobj_displace_withtag (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:70 #2 canvas_displaceselection (x=0x8215790, dx=<value optimised out>, dy=0) at g_editor.c:1913 #3 0x080a9a35 in canvas_motion (x=0x8215790, xpos=161, ypos=56, fmod=2) at g_editor.c:2102 #4 0x080ca856 in pd_typedmess (x=0x8215790, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:792 #5 0x080ca43c in pd_typedmess (x=0x8211678, s=0x8136eb8, argc=3, argv=0xbffff08c) at m_class.c:813 #6 0x080cff0a in binbuf_eval (x=0x814d610, target=<value optimised out>, argc=0, argv=0x0) at m_binbuf.c:726 #7 0x080de1bf in socketreceiver_read (x=0x814d630, fd=6) at s_inter.c:560 #8 0x080ddb7a in sys_domicrosleep (microsec=<value optimised out>, pollem=<value optimised out>) at s_inter.c:198 #9 0x080de662 in sys_pollgui () at s_inter.c:862 #10 0x080d9681 in m_pollingscheduler () at m_sched.c:490 #11 m_mainloop () at m_sched.c:560 #12 0x080dcc09 in sys_main (argc=5, argv=0xbffff4e4) at s_main.c:310 #13 0x080e56cb in main (argc=5, argv=0xbffff4e4) at s_entry.c:32
Thanks again
Al On Sat, Nov 27, 2010 at 11:37 AM, Mathieu Bouchard <matju@artengine.ca wrote:
On Sat, 27 Nov 2010, ALAN BROOKER wrote:
Also Gridflow as mentioned previously causes crashes but not so hard as
py. When I swapped the L2Orkt file to normal extended, I could use
Gridflow
in the new gui as normal- so perhaps the issue is not in the tk file
but
else where?
If you (or someone else) can narrow down the l2ork<->gridflow problems,
I
could try to fix them.
Is it something happening mostly with the helpfiles, or also with
something
else ? Is it happening at startup, or later ?
What is the "L20rkt file" ?
| Mathieu Bouchard ------------------------------------- Aix-en-Provence
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 27 Nov 2010, Ivica Ico Bukvic wrote:
I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended?
If you do this, then you also need to modify "bundled/m_pd.h" to add that field. Well, I think GridFlow still would work if you replace the m_pd.h by the one from your pd distro, but I won't guarantee that this will work in the future. I'd rather have a loadtime check for the size of t_widgetbehavior.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
This is not actually in m_pd.h but in g_canvas.h according to the original pd code. All other includes (apart from g_canvas.h) have remained intact. More so, since this is the last entry and I have a check inside added l2ork code whether this last entry is null before trying to invoke it (and if it is null then fall back to the regular version of displace) it should not require any alteration to the code other than making sure that the source at compile-time is referencing newer version of g_canvas.h.
I've recompiled most of the externals that come with pd-extended (still waiting to hear back from Hans why the latest SVN snapshot fails to compile flatspace, toxy, and flib) and none of them have any problems whatsoever (sure there is a warning at compile-time how that last widgetbehavior is not initialized properly but that does not matter when the code checks for null pointer before trying to invoke it).
Cheers!
Ico
-----Original Message----- From: Mathieu Bouchard [mailto:matju@artengine.ca] Sent: Friday, December 03, 2010 10:06 AM To: Ivica Ico Bukvic Cc: ALAN BROOKER; Pd-list@iem.at Subject: Re: [PD] Gridflow+ L2Ork pd-extended (was: L2Ork pd-extended release candidate 1 now available)
On Sat, 27 Nov 2010, Ivica Ico Bukvic wrote:
I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended?
If you do this, then you also need to modify "bundled/m_pd.h" to add that field. Well, I think GridFlow still would work if you replace the m_pd.h by the one from your pd distro, but I won't guarantee that this will work in the future. I'd rather have a loadtime check for the size of t_widgetbehavior.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 3 Dec 2010, Ivica Ico Bukvic wrote:
This is not actually in m_pd.h but in g_canvas.h according to the original pd code. All other includes (apart from g_canvas.h) have remained intact.
Ah, yeah. But to me, now, the difference doesn't matter much, as GF comes with both .h files in advance.
More so, since this is the last entry and I have a check inside added l2ork code whether this last entry is null before trying to invoke it (and if it is null then fall back to the regular version of displace) it should not require any alteration to the code other than making sure that the source at compile-time is referencing newer version of g_canvas.h.
But I want all GF binaries to work on both your pd and pd-extended (and as much as possible pd-vanilla too).
I've recompiled most of the externals that come with pd-extended (still waiting to hear back from Hans why the latest SVN snapshot fails to compile flatspace, toxy, and flib) and none of them have any problems whatsoever
It just means that none of them are made so that the binaries work on several versions of pd at once. I don't care about those. I want binaries that work on several versions of pd at once. (Can I repeat it once more ?)
(sure there is a warning at compile-time how that last widgetbehavior is not initialized properly but that does not matter when the code checks for null pointer before trying to invoke it).
This only works because the struct is directly a global variable, and not a result of malloc.
If the pd-l2ork binary of GridFlow happens to work with pd-extended as well, it's a coïncidence... with a picky debugger, you'd find that there is a bug with copying a small t_widgetbehavior as if it were a large one. I need some kind of if-statement to fix that.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
This only works because the struct is directly a global variable, and not a result of malloc.
Exactly.
If the pd-l2ork binary of GridFlow happens to work with pd-extended as well, it's a coïncidence... with a picky debugger, you'd find that there is a bug with copying a small t_widgetbehavior as if it were a large one.
Why would you copy it? My understanding is you declare it per-object to link specific behaviors and there are already examples in code (e.g. g_mycanvas.c).
I guess you could always use pd-l2ork's as a foundation and that will generate backwards-compatible binaries, no?
Ico
Why would you copy it? My understanding is you declare it per-object to link specific behaviors and there are already examples in code (e.g. g_mycanvas.c).
...meant to say, there are already examples with NULL behaviors.
On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote:
Why would you copy it? My understanding is you declare it per-object to link specific behaviors and there are already examples in code (e.g. g_mycanvas.c).
...meant to say, there are already examples with NULL behaviors.
Why would I need examples with null behaviours ? This is beyond me.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote:
If the pd-l2ork binary of GridFlow happens to work with pd-extended as well, it's a coïncidence... with a picky debugger, you'd find that there is a bug with copying a small t_widgetbehavior as if it were a large one.
Why would you copy it?
I don't remember, but chances are that it was that on one OS, the t_widgetbehavior that I wanted to modify was in a readonly memory segment.
My understanding is you declare it per-object
I'd rather have you call it per-class.
But anyway, as I said already, I need to modify the widgetbehavior of the comment-class. Nearly 100 % of GF's help-patches depend on it.
I guess you could always use pd-l2ork's as a foundation and that will generate backwards-compatible binaries, no?
no.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Fri, 2010-12-03 at 10:06 -0500, Mathieu Bouchard wrote:
On Sat, 27 Nov 2010, Ivica Ico Bukvic wrote:
I am not sure if you already mentioned this but did you actually try recompiling gridflow from scratch or are you using one of the precompiled packages in conjunction with the l2ork pd-extended?
If you do this, then you also need to modify "bundled/m_pd.h" to add that field. Well, I think GridFlow still would work if you replace the m_pd.h by the one from your pd distro, but I won't guarantee that this will work in the future. I'd rather have a loadtime check for the size of t_widgetbehavior.
FWIW, I just compiled gridflow from scratch having replaced g_canvas.h (as per my earlier email) and it works just fine here. That said, there are a couple tutorial patches that when triggered crash immediately but others are rock-solid which leads me to believe that this may have to do something with a specific lib gridflow is linked against and/or an object within the library rather than point to an incompatibility with l2ork iteration of pd. Some objects are also missing inside the patch (they fail to be created). Camera input also works perfectly fine.
All this is with ver. 9.12.
HTH
Ico
On Fri, 3 Dec 2010, Ivica Ico Bukvic wrote:
something with a specific lib gridflow is linked against and/or an object within the library rather than point to an incompatibility with l2ork iteration of pd. Some objects are also missing inside the patch (they fail to be created).
Can you find which those are ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
For starters, all tests/#fft-test*.pd crash as soon as you trigger the bang/toggle that starts the patch (they open/close ok). No warnings on console or in pd's printout.
#many-test.pd misses #many-piece object (located at the bottom-center).
When I get a chance, if you like I can create a comprehensive list of issues I've encountered here.
Ico
On Sun, 2010-12-05 at 12:16 -0500, Mathieu Bouchard wrote:
On Fri, 3 Dec 2010, Ivica Ico Bukvic wrote:
something with a specific lib gridflow is linked against and/or an object within the library rather than point to an incompatibility with l2ork iteration of pd. Some objects are also missing inside the patch (they fail to be created).
Can you find which those are ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
On Sun, 5 Dec 2010, Ivica Ico Bukvic wrote:
For starters, all tests/#fft-test*.pd crash as soon as you trigger the bang/toggle that starts the patch (they open/close ok). No warnings on console or in pd's printout.
Ah. I know that there are bugs in [#fft], but I don't know that one. Does that also happen to you in pd-extended, or not ?
#many-test.pd misses #many-piece object (located at the bottom-center).
Normal... that's for a feature that wasn't finished.
The «-test.pd» patches still aren't organised so that anyone can readily see whether things are working or not. That idea alone would be worthy of another coding frenzy (such as the one that led to the current helpfile system of GF...)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
For starters, all tests/#fft-test*.pd crash as soon as you trigger the bang/toggle that starts the patch (they open/close ok). No warnings on console or in pd's printout.
Ah. I know that there are bugs in [#fft], but I don't know that one. Does that also happen to you in pd-extended, or not ?
Not sure. Haven't tried.
Ico
On Sun, 5 Dec 2010, ico@vt.edu wrote:
Ah. I know that there are bugs in [#fft], but I don't know that one. Does that also happen to you in pd-extended, or not ?
Not sure. Haven't tried.
Well, I don't ask to say that you should do it, I ask because that's the information we'd need if we were trying to find out how to fix the problem.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
ico＠vt.edu -
Ivica Ico Bukvic
-
Mathieu Bouchard