I added a test to the -base from May 20:
NSPoint point = {.x = 16.0, .y = 32.0};
NSValue *pointV = [NSValue valueWithPoint: point];
result = !strcmp(@encode(NSPoint), [pointV objCType]);
PASS(result, "@encoding(NSPoint) == pointV objCType");
result = strcmp(@encode(NSSize), [pointV objCType]);
PASS(result, "@encoding(NSSize) == pointV objCType");
with this temporarly ine:
NSLog(@"%s %s %s", @encode(NSPoint), @encode(NSSize), [pointV objCType]);
It passes and prints out:
2018-05-27 17:27:38.823 size-point-encoding[25395:25395] {_NSPoint=dd}
{_NSSize=dd} {_NSPoint=dd}
I''m annoyed at how I did not notice that I did use CGSize. I will
introduce support for NSSize/CGSize.
Thanks!
On Mon, May 21, 2018 at 12:53 AM Fred Kiefer <[email protected]> wrote:
> I added a bit of code in base that allows to use NSValue objects for size
> and point with methods for the other type. This is a bit closer to the
> Cocoa behaviour but will require more tweaking to have it fully correct. It
> will at least allow you to run this test code again.
>
> > Am 20.05.2018 um 16:02 schrieb Fred Kiefer <[email protected]>:
> >
> > I spend some time to understand this issue. But to be honest it took me
> more time to understand why this ever worked :-)
> >
> > The problem here is that base uses two different ways to provide
> concrete subclasses for NSValue. One being GSValue, which supports generic
> data and the other mechanism is to have a specific subclass for types like
> NSPoint and NSSize. For the later base only generates specific methods for
> that types. Resulting in different classes for NSPoint and NSSize, which
> are incompatible although they have the same underlying data size.
> > In your demo application that animation for shadowOffset tries to set
> the offset size with a suitable default value of class GSSizeValue. But the
> code in GSObjCSetVal only compares the type information without looking at
> the type names. That way NSSize is regarded as the same as NSPoint and the
> pointValue get executed, resulting in the error you reported. Either
> GSObjCSetVal has to be more careful and use a check for the actual type
> first. Or we need to make the NSValue subclasses more general.
> >
> > But why did it work before? Most likely because at that time CGSize and
> CGPoint, where different from NSSize and NSPoint so we did not get the
> specific optimisation in NSValue.
> >
> > Hope this helps,
> > Fred
> >
> >> Am 20.05.2018 um 14:03 schrieb Ivan Vučica <[email protected]>:
> >>
> >> Hi,
> >>
> >> Pretty much all Core Animation demos are currently broken under GNUstep
> with a variation on the following:
> >>
> >> 2018-05-20 12:54:25.464 QuartzCoreDemo[13476:13476] Problem posting
> notification: <NSException: 0x15b53b8> NAME:NSInvalidArgumentException
> REASON:[GSSizeValue-pointValue] should be overridden by subclass INFO:(null)
> >>
> >> CA is accessing -pointValue method if it determines that the passed
> NSValue matches the -objCType of NSPoint. It does not check for size values.
> >>
> >> Clearly, sometimes it is trying to interpolate size values, which will
> match the signature and it will incorrectly attempt to access -pointValue
> which is then not implemented by GSSizeValue. I am not sure where might it
> be interpolating size values, but it seems to be doing so. (Alternative bug
> is that NSValue is incorrectly ingesting points as sizes, then complaining
> when the point provided is being interpreted as a point. I can try checking
> this later.)
> >>
> >> I cannot check -respondsToSelector: because the class /does/ in fact
> respond to -pointValue; it just throws an exception.
> >>
> >> Adding a try/catch in this kind of situation would make for some very
> poor code hygiene, in my opinion.
> >>
> >> - Is NSValue supposed to be a class cluster like this? (Not on Mac at
> this time, can't check.)
> >> - Is there a way out?
> >> - Would it make sense to extend GSSizeValue and add -pointValue to it?
> (They're both 2d vectors.)
> >>
> >> Thanks
> >> _______________________________________________
> >> Gnustep-dev mailing list
> >> [email protected]
> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> >
> >
> > _______________________________________________
> > Gnustep-dev mailing list
> > [email protected]
> > https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> _______________________________________________
> Gnustep-dev mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
