On Mon, 27 Dec 2010, Ivica Ico Bukvic wrote:
BTW, I just encountered the crashes the other user reported before.
I thought you had said that you had gotten GF to work...
Simply cannot create a single object without crashing Pd when gridflow
is loaded. Opening preexisting patches is ok, however.
Using your g_canvas.h ? sounds like a t_widgetbehavior problem.
Backtrace gives nothing.
I was wondering whether it can make a difference to compile both pd and GF
with -O0 for backtracing, in cases where compiling one or the other with
-O0 is not sufficient... I know that compiling with -O3 does remove hints
that are necessary for backtracing, but I don't know what causes the
backtracing problem you are talking about, although I do reproduce it. I
don't remember how much I tried -O0 but I remember that it does make a
difference in some other cases.
I also found really weird behavior when opening docs (like
doc_also-help.pd patch) where when running pd with -d 99
-d 99 is useless : -d 3 is the same as -d 99, because the argument of d is
modulo 4.
it constantly draws and erases objects.
That's an annoyance that has been there for a year in GF and that is
climbing on my priority list because I am tired of it... especially
because it prevents the debugging of certain problems (GF has problems
with 0.43 too).
It has to do with how the doc bars are shown between edit and non-edit
modes as when I erase those thehy work fine.
The redraw of various items is controlled by a [metro] inside of the
[doc_h]. In itself, this redraw doesn't have directly to do with the
editmode.
I also found out that I crash pd every time I do mouse-over over the
segmented patch cords that are connected to each paragraph of the doc
text.
I didn't change the source code of pd's wire display : instead, it's a
part of [gf/lol] that modifies the cables often enough so that the
straight lines don't remain straight, but this involves only sys_vgui, not
widgetbehavior. There's nothing in [gf/lol] that is related to mouseover
in any way.
However, widgetbehavior of the comment class is modified, as I said
previously. This is done in [gf/lol]'s setup function, although it isn't
directly dependent (it would be a better classification, to move that code
to gridflow.cxx)
I suspect this may be something with the pd-l2ork iteration but am
unable to figure out what.
temporarily disable the widgetbehavior hack and see what happens. However,
that breaks most of the funny wires that are used in my helppatches
anyway, so, it may not give us the hint we'd like to have.
At first it was rtext_erase and then rtext_senditup both of which had
t_rtext *x being 0x0. Now that I added additional checks there, it
appears glist_findrtext triggers consistency check (this is against
gridflow v.9.12).
do you recommend any particular changes to gridflow ? did you find
anything that I'm doing wrong ?
Is this all perhaps due to widgetbehavior matter you mentioned before,
or did the latest changes to the pd-l2ork tree cause additional issues?
Dunno, I didn't try l2ork, and I know even less about the latest changes.
_______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
