Hi, A recent thread on Pd Everywhere suggests that the function rtext_senditup in g_rtext.c sometimes divides by a font width. This causes occasional crashes because the font width may be 0 when running with the nogui flag: http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-subpa...
This raises a couple of questions: First, why does any part of the code look at font properties at all when nogui is set? Second, how do we fix this?
I suppose the best solution would be to make sure that font properties are never queried when nogui is set. In the meantime, a quick fix might be to modify the initialization of sys_fontlist (s_main.c, lines 126-128), setting fi_hostfontsize, fi_width, and fi_height equal to one. Any thoughts would be appreciated! Cheers, Peter
It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size.
Anyway, yes, I'm fixing a couple of bugs and will change that -- it sounds quite safe to me.
cheers Miller On Sun, Feb 19, 2012 at 09:18:00AM -0800, Peter Brinkmann wrote:
Hi, A recent thread on Pd Everywhere suggests that the function rtext_senditup in g_rtext.c sometimes divides by a font width. This causes occasional crashes because the font width may be 0 when running with the nogui flag: http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-subpa...
This raises a couple of questions: First, why does any part of the code look at font properties at all when nogui is set? Second, how do we fix this?
I suppose the best solution would be to make sure that font properties are never queried when nogui is set. In the meantime, a quick fix might be to modify the initialization of sys_fontlist (s_main.c, lines 126-128), setting fi_hostfontsize, fi_width, and fi_height equal to one. Any thoughts would be appreciated! Cheers, Peter
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Le 2012-02-19 à 10:05:00, Miller Puckette a écrit :
It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size.
You don't have to call gobj_getrect(), you need only te_xpix to figure out the order.
But run-time semantics that depend on screen location is a bug. When it's like that by design, it's a bug by design, because there's a bug in the design.
It's not as palpable as a bug in the implementation, which you can tell because the programme does not do as the design says. So people can argue endlessly about it, but you can still recognise that there's a problem with the design because people spend significant time talking about the gotcha, suggesting workarounds for the gotcha, teaching the gotcha, avoiding the gotcha, complaining about the gotcha ; and all along, things could have been better (unlike other things that look like a design bug but in which all solutions are equally annoying).
It's also not hilarious... I mean, people who want to make fun of Pd may and will laugh about it, but for the users, it's not a big big fun.
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
That it's painful doesn't make it any less funny to me. It would take pages to explain the considerations that went, in 1987 or early 1988, into the decision to arrange inlets/outlets that way but the circumstances were quite different from today's - and seeing this particular unintended consequence (and the remoteness of its connection with the original situation) well, I just find it hilarious. I'll know never to make that particular mistake again :)
cheers Miller
It's also not hilarious... I mean, people who want to make fun of Pd may and will laugh about it, but for the users, it's not a big big fun.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Le 2012-02-19 à 10:30:00, Miller Puckette a écrit :
That it's painful doesn't make it any less funny to me.
CROC Magazine's motto was : « C'est pas parce qu'on rit que c'est drôle », in the sense that just because we laugh doesn't mean it's funny.
pages to explain the considerations that went, in 1987 or early 1988,
That's the past. What do you want the future to be ?
into the decision to arrange inlets/outlets that way but the circumstances were quite different from today's
There were different circumstances, but I don't think that the forces at work and the goals are any different, when you just think about the ability to program something (anything) with Pd. Perhaps the ambient beliefs (zeitgeist) are different now. In any case, that's history, and Pd has always had the opportunity to switch people to a new inlet/outlet system with a new name... it has just never taken it. Many things are a lot harder to change than this.
and seeing this particular unintended consequence (and the remoteness of its connection with the original situation) well, I just find it hilarious. I'll know never to make that particular mistake again :)
How would you ever have the opportunity of ever making that mistake again ? I mean, apart from keeping the current meanings of [inlet] and [outlet] instead of migrating to a new system...
Besides, why did you repeat the same design when rewriting MAX from scratch under the name PureData ?
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Feb 19, 2012, at 1:15 PM, Mathieu Bouchard wrote:
Le 2012-02-19 à 10:05:00, Miller Puckette a écrit :
It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size.
You don't have to call gobj_getrect(), you need only te_xpix to figure out the order.
But run-time semantics that depend on screen location is a bug. When it's like that by design, it's a bug by design, because there's a bug in the design.
It's not as palpable as a bug in the implementation, which you can tell because the programme does not do as the design says. So people can argue endlessly about it, but you can still recognise that there's a problem with the design because people spend significant time talking about the gotcha, suggesting workarounds for the gotcha, teaching the gotcha, avoiding the gotcha, complaining about the gotcha ; and all along, things could have been better (unlike other things that look like a design bug but in which all solutions are equally annoying).
It's also not hilarious... I mean, people who want to make fun of Pd may and will laugh about it, but for the users, it's not a big big fun.
I think that the order of the [inlet]s and [outlet]s on the screen matching the order of the inlets and outlets on the abstraction that patch creates is a wonderful idea, far from being a bug, really a clever design. The inlets and outlets on an object box are inescapably visually ordered. That visual order can then be represented by a number in the implementation. Therefore it fits that the visual placement of the [inlet] and [outlet] object would define the visual placement of the inlets and outlets.
Perhaps in the implementation, that doesn't need to be so.
.hc
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Le 2012-02-19 à 17:46:00, Hans-Christoph Steiner a écrit :
I think that the order of the [inlet]s and [outlet]s on the screen matching the order of the inlets and outlets on the abstraction that patch creates is a wonderful idea,
which is the only thing that makes it impossible to just move chunks of patches around without wondering whether you might be changing semantics.
So close to following a principle and so unable to apply it thoroughly.
______________________________________________________________________ | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Hi Miller, Thanks for taking care of this! I noticed one leftover zero in the initialization of sys_fontlist. I'm assuming that that's an oversight, and I changed it to one in the libpd repository. Cheers, Peter
On Sun, Feb 19, 2012 at 1:05 PM, Miller Puckette msp@ucsd.edu wrote:
It's hilarious - there's exactly one aspect of Pd run-time semantics that depends on screen location -- inlets/outlets of subpatches are numbered in left-to-right order on teh screen. To to thins someone has to call gobj_getrect() on the inlet/outlet, which then not only has to report the northwest corner but the entire rectangle, which depends on font size.
Anyway, yes, I'm fixing a couple of bugs and will change that -- it sounds quite safe to me.
cheers Miller On Sun, Feb 19, 2012 at 09:18:00AM -0800, Peter Brinkmann wrote:
Hi, A recent thread on Pd Everywhere suggests that the function rtext_senditup in g_rtext.c sometimes divides by a font width. This causes occasional crashes because the font width may be 0 when running with the nogui flag: http://noisepages.com/groups/pd-everywhere/forum/topic/any-issues-with-subpa...
This raises a couple of questions: First, why does any part of the code look at font properties at all when nogui is set? Second, how do we fix this?
I suppose the best solution would be to make sure that font properties are never queried when nogui is set. In the meantime, a quick fix might be to modify the initialization of sys_fontlist (s_main.c, lines 126-128), setting fi_hostfontsize, fi_width, and fi_height equal to one. Any thoughts would be appreciated! Cheers, Peter
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Hans-Christoph Steiner -
Mathieu Bouchard -
Miller Puckette -
Peter Brinkmann