else/click in conflict with method 'click' for class 'canvas' when compiling for camomile
Hi, we're compiling camomile with externals from ELSE, the only issue I have is that else/click gets in conflict with an internal "click" class in Pd (which doesn't happen if it's an external), this happens because of this line of code https://github.com/porres/pd-else/blob/master/Classes/Source/click.c#L156
and the warning given by camomile is "*warning: old method 'click' for class 'canvas' renamed 'click_aliased*"
My plan is to simply disable this external when compiling for camomile, because it's just not really pertinent to camomile at all, at least I believe so (this is used to react to clicks on non GOP abstractions/subpatches). I also believe the conflict won't make a difference to the functionality of Pd. What do you say?
One way or another, I wanna get rid of the warning and I wonder if there's a way to not interfere with Pd itself instead of disabling the external. I guess there's no way, but I hope it doesn't hurt to ask :)
thanks
On 10/7/20 11:12 PM, Alexandre Torres Porres wrote:
Hi, we're compiling camomile with externals from ELSE, the only issue I have is that else/click gets in conflict with an internal "click" class in Pd (which doesn't happen if it's an external), this happens because of this line of code https://github.com/porres/pd-else/blob/master/Classes/Source/click.c#L156
and the warning given by camomile is "*warning: old method 'click' for class 'canvas' renamed 'click_aliased*"
i get the same with Pd-0.51.2. the warning is only emitted in "-verbose" mode, which you probably haven't enabled in your local settings of Pd, but which is probably on-by-default in camomile.
apart from that: calling class_addmethod() in the constructor sounds like a bug to me. it ought to be called in the setup function (along with the other class_addmethod() calls) - only once, when the library gets loaded. this will also greatly reduce the number of times the warning is printed from N to 1.
One way or another, I wanna get rid of the warning and I wonder if there's a way to not interfere with Pd itself instead of disabling the external. I guess there's no way,
no there's no way (apart from disabling the object itself; which - as i explained above - you also need to do for the Pd-vanilla version). it's Pd's way of saying "something is overriding an internal (it's probably ok, but i want you to know)" - and this is exactly what [else/click] is doing.
gfamdsr IOhannes
Em qui., 8 de out. de 2020 às 03:24, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
i get the same with Pd-0.51.2. the warning is only emitted in "-verbose" mode, which you probably haven't enabled in your local settings of Pd, but which is probably on-by-default in camomile.
right, I thought it was only for camomile as the objects would be treated as vanilla internals. I see it now.
no there's no way (apart from disabling the object itself; which - as i
explained above - you also need to do for the Pd-vanilla version). it's Pd's way of saying "something is overriding an internal (it's probably ok, but i want you to know)" - and this is exactly what [else/click] is doing.
But I see that overriding it is not really dangerous in any way to Pd, at least I never had any issue. So I guess this is more about being able to set this -verbose flag in camomile.
Thanks!
On 10/8/20 11:04 PM, Alexandre Torres Porres wrote:
But I see that overriding it is not really dangerous in any way to Pd, at least I never had any issue.
it *can* be very dangerous. that is, you can completely brick Pd by overriding the right (or wrong) messages without providing sane alternatives.
an anecdote (that goes without "completely bricking" Pd) would be zexy's [pack] reimplementation (that doesn't do any type-enforcement), which used to happily override Pd's internal [pack] object (and as you know this is done by overriding the "pack" message of the objectmaker) - until this caused so much stir among the comunity that i had to revert the overriding (and you can now use the objects as [zexy/pack]).
now overriding a method to the objectmaker might break a single object. overriding a method to canvas might break patching.
having said that: overriding methods to canvas is a powerful tool to extend the patching capabilities of Pd itself.
oh btw: when you override a canvas method, you should have a plan to deal with overrides of the same method from other libraries. (and probably document that plan).
hamdsrt IOhannes
-
Alexandre Torres Porres -
IOhannes m zmoelnig