Hi Dan, I think I had the same issue with my plugin and PD 0.47. If I remember well, the solution was to call "sys_startgui(NULL)" after "pd_init()" (it should be in libpd_init() I think).
2016-09-24 19:26 GMT+02:00 Dan Wilcox <[email protected]>: > Digging further, looks like sys_zoomfontwidth() & sys_zoomfontheight() are > returning 0 in glist_fontwith()/glist_fontheight(). > > -------- > Dan Wilcox > @danomatika <https://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > On Sep 24, 2016, at 11:20 AM, Dan Wilcox <[email protected]> wrote: > > I’m playing with removing the @synchronized locks in the libpd Obj-C layer > since the updates to the libpd ringbuffer seem to be working now. > > Long story short, I’m only running into one issue: divide by 0s in > g_rtext.c rtext_senditup() when opening a file. It seems that the findx & > findy computations on line 215 & 216 fails since the previous > glist_fontwidth() & glist_fontheight() calls return 0. Could this be an > execution order issue where removing the lock is making something happen > earlier than it should? > > Adding the following before the findx & findy math works as a quick fix to > keep the divide by zero error: > > if (fontwidth <= 0) fontwidth = 1; > if (fontheight <= 0) fontheight = 1; > > I’m wondering if there is a better way to catch this... > > -------- > Dan Wilcox > @danomatika <https://twitter.com/danomatika> > danomatika.com > robotcowboy.com > > > > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev > >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
