[Gridflow-dev] [PD] [PD-dev] is there a way for an object to detect whethere its inlet is connected to something

[Mathieu Bouchard]

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