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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:20 AM, Dan Wilcox danomatika@gmail.com 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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 danomatika@gmail.com:
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 danomatika@gmail.com 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 Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks. Good catch! I’ll try it now.
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:34 AM, Pierre Guillot guillotpierre6@gmail.com wrote:
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 <danomatika@gmail.com mailto:danomatika@gmail.com>: 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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:20 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> 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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Seems to work in libpd_init(). Thanks
-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:35 AM, Dan Wilcox danomatika@gmail.com wrote:
Thanks. Good catch! I’ll try it now.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:34 AM, Pierre Guillot <guillotpierre6@gmail.com mailto:guillotpierre6@gmail.com> wrote:
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 <danomatika@gmail.com mailto:danomatika@gmail.com>: 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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sep 24, 2016, at 11:20 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> 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 http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-
Dan Wilcox -
Pierre Guillot