Re: NSControls failing to set status/label on BigEndian/64bit
> Am 08.01.2021 um 01:23 schrieb Riccardo Mottola : > > Richard Frith-Macdonald wrote: >> Changing the type of the masks from NSInteger to uint32_t would also fix the >> encoding/decoding of course. Maybe that has other issues though. > > perhaps we should try a mixed approach: encode/decode in the format with > uint32_t and int32_t, but then always cast to NSUInteger/NSInteger. That way > we have that data "Fixed" as 32bits in the Gorm file from whatever platform > we write into, but then cast/convert it to whatever we need. I still prefer your original approach as it is less intrusive. There definitely is no use for two different encodings. I also see no big issue in living with the old, wrong encoding of these values as unsigned. > A big doubt I have always is about typdefs, if they are signed or not, since > I think to remember this is architecture/compiler dependent. I tried to leave > that out to the compiler for now. I think this is mostly true for char and maybe for enums, otherwise it should be well defined. > I just finished a first proposal, what do you think? What I like about your change is that we now make explicit the actual size that gets stored in the archive. This is always the same and should be the same independent of the architecture the code runs on. It would be a big improvement to have that changed all over GNUstep. > The keyed path has two bFlags, which I think and I am worried about the code > where buttonCellFlags are copied with a memcpy.. of which size? it needs to > be of uint32_t to fit in memory, but is it?.. later is copied back with the > struct size. Scary. The good thing here is that in all these flag structures (and we have plenty of them) we explicitly state the size of each element in bits. So nothing to worry here, apart from the sign. Fred
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Richard, Richard Frith-Macdonald wrote: Changing the type of the masks from NSInteger to uint32_t would also fix the encoding/decoding of course. Maybe that has other issues though. perhaps we should try a mixed approach: encode/decode in the format with uint32_t and int32_t, but then always cast to NSUInteger/NSInteger. That way we have that data "Fixed" as 32bits in the Gorm file from whatever platform we write into, but then cast/convert it to whatever we need. A big doubt I have always is about typdefs, if they are signed or not, since I think to remember this is architecture/compiler dependent. I tried to leave that out to the compiler for now. I just finished a first proposal, what do you think? The keyed path has two bFlags, which I think and I am worried about the code where buttonCellFlags are copied with a memcpy.. of which size? it needs to be of uint32_t to fit in memory, but is it?.. later is copied back with the struct size. Scary. Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Wolfgang, Wolfgang Lux wrote: So perhaps the mistake here (apart from not type in the decodeValueOfObjCType call) was that _highlightsByMask and _altStateMask attributes were changed from unsigned int to NSInteger rather than NSUInteger? Although, admittedly, the real mistake was that those fields were unsigned ints in the first place, given that the corresponding methods always used to have (signed) int arguments and results (at least since the OpenStep era). that's an alternative approach then. If we check this commit: https://github.com/gnustep/libs-gui/commit/8ad4aa86c4f875d3b81dd67c78039b5c03b357cc#diff-fc96130d9804d445491ac5062baeb96a7f4a5217f44fb1f1fdccd645dcef6bbe the bug was introduced years ago when Fred changed "unsigned int" di NSInteger masks (at least, concerning the signedness difference, not the 32bit vs 64bit encoding). So I tried to do some historic research http://mirror.informatimago.com/next/developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSButtonCell.html#//apple_ref/doc/uid/2093/CJBDHAFA here we see: - (|void|)|setKeyEquivalentModifierMask:|(|unsigned int|)/mask //- (|void|)|setShowsStateBy:|(|int|)/aType - (|void|)|setHighlightsBy:|(|int|)/aType /// This shows an unsigned mask, integer types: Fred surely just fixed our method signatures by looking at Apple's doc, which is equivalent to old OpenStep stuff: http://www.gnustep.org/resources/OpenStepSpec/ApplicationKit/Classes/NSButtonCell.html So.. our Gorm format is "wrong" since ever. Apple in the meanwhile made types of state and hightlight with an enum type NSCellStyleMask Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
> On 7 Jan 2021, at 17:12, Wolfgang Lux wrote:
>
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola :
>>
>> Hi all,
>>
>>
>> Wolfgang Lux wrote:
>>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods
>>> is a, errm, not so bright idea. The types are included in the binary
>>> archives. So, trying to decode a value with a different type will give you
>>> an error (for your own safety and sanity). Trying to encode values with a
>>> different type is even worse, as you would be creating archives that cannot
>>> be read by anybody else (because they are expecting some other type). If
>>> you (have to) make such changes, be sure to introduce a new archive version
>>> and be sure to include backward compatibility code for reading the old
>>> archive format.
>>
>> I had a call with Gregory yesterday.. since this is a delciate subject I
>> made a branch with a proposed initial change (as I have other controls
>> failing, it will not be the conly class affected either)
>>
>> BE-64-Fixes
>>
>> What do you think?
>
> I think that introducing a new archive format to address the issue with the
> _highlightsByMask and _altStateMask attributes is a bit over the top. Either
> decoding the attributes as NSUInteger values as Fred mentioned or decoding
> them as unsigned int into a temporary variable and then copying the values
> from those temporary variable into the respective attribute would do. BTW, I
> don't consider the latter a hack. It's a perfectly sane solution for dealing
> with backward compatible archives.
>
I just had a chance for a quick look.
It sounds like the problem is he code
[aCoder encodeValueOfObjCType: @encode(unsigned int)
at: &_highlightsByMask];
where _highlightsByMask is actually NSInteger (signed 64bit)
If you are on a big endian machine, that would presumably encode the upper
32bits of the value ... which are probably all zero ... so the data never gets
into the archive.
So I agree, the bugfix would be to copy _highlightsByMask (lower 32bits) into a
32bit unsigned integer value first
uint32_t tmp = (uint32_t) _highlightsByMask
[aCoder encodeValueOfObjCType: @encode(unsigned int) at: ];
So the correct value is stored in the archive.
A similar change would be needed to decode into a uint32_t and then copy that
into place.
Re: NSControls failing to set status/label on BigEndian/64bit
Changing the type of the masks from NSInteger to uint32_t would also fix the encoding/decoding of course. Maybe that has other issues though.
Re: NSControls failing to set status/label on BigEndian/64bit
Am 07.01.2021 um 14:33 schrieb Riccardo Mottola :
>
> Hi all,
>
>
> Wolfgang Lux wrote:
>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is
>> a, errm, not so bright idea. The types are included in the binary archives.
>> So, trying to decode a value with a different type will give you an error
>> (for your own safety and sanity). Trying to encode values with a different
>> type is even worse, as you would be creating archives that cannot be read by
>> anybody else (because they are expecting some other type). If you (have to)
>> make such changes, be sure to introduce a new archive version and be sure to
>> include backward compatibility code for reading the old archive format.
>
> I had a call with Gregory yesterday.. since this is a delciate subject I made
> a branch with a proposed initial change (as I have other controls failing, it
> will not be the conly class affected either)
>
> BE-64-Fixes
>
> What do you think?
I think that introducing a new archive format to address the issue with the
_highlightsByMask and _altStateMask attributes is a bit over the top. Either
decoding the attributes as NSUInteger values as Fred mentioned or decoding them
as unsigned int into a temporary variable and then copying the values from
those temporary variable into the respective attribute would do. BTW, I don't
consider the latter a hack. It's a perfectly sane solution for dealing with
backward compatible archives.
Wolfgang
Re: NSControls failing to set status/label on BigEndian/64bit
Am 06.01.2021 um 23:11 schrieb Fred Kiefer : > > > >> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux : >> >>> good catch. We have two differences here 32bit vs 64bit, but also signed vs >>> unsigned! >> >> the difference between signed and unsigned is irrelevant for encoding and >> decoding, as you pass a pointer to the memory being encoded or decoded. >> However, the size of the value you want to encode or decode should agree >> with the type that is used for coding. > > Things are even a bit more complicated here. Richard tries very hard to > handle different integer and float types in NSUnarchiver. The code tries to > match the data in the archive to the expected type and that works for many > cases. For some reason, I am not sure whether this is intentional, it does > not map between unsigned and signed. So although you are correct that this is > not a good idea, the code would work with > > [aDecoder decodeValueOfObjCType: @encode(NSUInteger) > at: &_highlightsByMask]; Ah, thanks. I (obviously) wasn't aware of that extra smartness in the decoding function. The code makes sense to me as NSInteger expands to different types depending on whether you are on 32-bit or 64-bit architecture. Same for the NSUInteger. On the other hand, signed types should not become unsigned or vice versa if you change your architecture. So perhaps the mistake here (apart from not type in the decodeValueOfObjCType call) was that _highlightsByMask and _altStateMask attributes were changed from unsigned int to NSInteger rather than NSUInteger? Although, admittedly, the real mistake was that those fields were unsigned ints in the first place, given that the corresponding methods always used to have (signed) int arguments and results (at least since the OpenStep era). > Most likely we have this issue in other places of gui as well. We were just > lucky that the bits in little endian systems fall into the expected places. Yes, presumably somebody should inspect the code to check that all attributes that were changed from int or unsigned int to NSInteger and NSUInteger had their decoders and encoders changed accordingly. Wolfgang
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola :
>
> Wolfgang Lux wrote:
>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is
>> a, errm, not so bright idea. The types are included in the binary archives.
>> So, trying to decode a value with a different type will give you an error
>> (for your own safety and sanity). Trying to encode values with a different
>> type is even worse, as you would be creating archives that cannot be read by
>> anybody else (because they are expecting some other type). If you (have to)
>> make such changes, be sure to introduce a new archive version and be sure to
>> include backward compatibility code for reading the old archive format.
>
> I had a call with Gregory yesterday.. since this is a delciate subject I made
> a branch with a proposed initial change (as I have other controls failing, it
> will not be the conly class affected either)
>
> BE-64-Fixes
>
> What do you think?
I commented on your code already.
> A question: what is the current version? I used 3 as versino.. just because I
> found that one when decoding Gorms and debugging.
> Where is it to be increased?
The version is set via setVersion: in the initialization of the class. Look at
the very beginning of the file after the imports.
>
> PS:any clues on why NSPopUpMenus don't show their items, but retain Item1
> Item2, Item3? I had a look if there were similar type issues, but didn't find
> any, the decoding is a little different. I wonder which roperty could be: a
> tag, a connector missing…
To many possibilities what might go wrong here. It may be on any class involved
in the decoding.
Re: NSControls failing to set status/label on BigEndian/64bit
Hi all,
Wolfgang Lux wrote:
Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is a,
errm, not so bright idea. The types are included in the binary archives. So,
trying to decode a value with a different type will give you an error (for your
own safety and sanity). Trying to encode values with a different type is even
worse, as you would be creating archives that cannot be read by anybody else
(because they are expecting some other type). If you (have to) make such
changes, be sure to introduce a new archive version and be sure to include
backward compatibility code for reading the old archive format.
I had a call with Gregory yesterday.. since this is a delciate subject I
made a branch with a proposed initial change (as I have other controls
failing, it will not be the conly class affected either)
BE-64-Fixes
What do you think?
A question: what is the current version? I used 3 as versino.. just
because I found that one when decoding Gorms and debugging.
Where is it to be increased?
Riccardo
PS:any clues on why NSPopUpMenus don't show their items, but retain
Item1 Item2, Item3? I had a look if there were similar type issues, but
didn't find any, the decoding is a little different. I wonder which
roperty could be: a tag, a connector missing...
Riccardo
- I try to keep compatibility with old versions
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux :
>
>> good catch. We have two differences here 32bit vs 64bit, but also signed vs
>> unsigned!
>
> the difference between signed and unsigned is irrelevant for encoding and
> decoding, as you pass a pointer to the memory being encoded or decoded.
> However, the size of the value you want to encode or decode should agree with
> the type that is used for coding.
Things are even a bit more complicated here. Richard tries very hard to handle
different integer and float types in NSUnarchiver. The code tries to match the
data in the archive to the expected type and that works for many cases. For
some reason, I am not sure whether this is intentional, it does not map between
unsigned and signed. So although you are correct that this is not a good idea,
the code would work with
[aDecoder decodeValueOfObjCType: @encode(NSUInteger)
at: &_highlightsByMask];
It just throws the exception for NSInteger. Still the solution that Riccardo
calls a dirty hack seems to be the better way to handle the issue.
>> The first thing I tried was to use NSInteger/NSUInteger as approriate in
>> encodeWithCode and initWithCoder, but Gorm files fail to load
>> "Exception occurred while loading model: expected long long and got unsigned
>> int"
>>
>> I then tried just to use int to match NSInteger and reduce the signedness
>> problem, then I get insted
>> "Exception occurred while loading model: expected int and got unsigned int"
>
> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is
> a, errm, not so bright idea. The types are included in the binary archives.
> So, trying to decode a value with a different type will give you an error
> (for your own safety and sanity). Trying to encode values with a different
> type is even worse, as you would be creating archives that cannot be read by
> anybody else (because they are expecting some other type). If you (have to)
> make such changes, be sure to introduce a new archive version and be sure to
> include backward compatibility code for reading the old archive format.
Maybe we should wait before fixing this to hear from Richard what is the
intended behaviour here. The current code is of course wrong, Providing a
variable of one type and stating another is bound to fail in some cases. But
should we rely on the archiver to correct the type or should we use the „dirty
hack“, which for me is a rather clean solution.
Most likely we have this issue in other places of gui as well. We were just
lucky that the bits in little endian systems fall into the expected places.
Fred
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Riccardo,
> good catch. We have two differences here 32bit vs 64bit, but also signed vs
> unsigned!
the difference between signed and unsigned is irrelevant for encoding and
decoding, as you pass a pointer to the memory being encoded or decoded.
However, the size of the value you want to encode or decode should agree with
the type that is used for coding.
> The first thing I tried was to use NSInteger/NSUInteger as approriate in
> encodeWithCode and initWithCoder, but Gorm files fail to load
> "Exception occurred while loading model: expected long long and got unsigned
> int"
>
> I then tried just to use int to match NSInteger and reduce the signedness
> problem, then I get insted
> "Exception occurred while loading model: expected int and got unsigned int"
Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is a,
errm, not so bright idea. The types are included in the binary archives. So,
trying to decode a value with a different type will give you an error (for your
own safety and sanity). Trying to encode values with a different type is even
worse, as you would be creating archives that cannot be read by anybody else
(because they are expecting some other type). If you (have to) make such
changes, be sure to introduce a new archive version and be sure to include
backward compatibility code for reading the old archive format.
Wolfgang
Re: NSControls failing to set status/label on BigEndian/64bit
Hallo, Fred Kiefer wrote: The next step would be to compare these values with the ones you get on amd64. But before that, could you please run the base tests on ppc64? Maybe you get already a failing test there and this would just explain the behaviour. We always should start looking for an issue from ground up. If base is already broken there is no use in trying to pin it down in gui. in base things don't look bad, according to tests: 9456 Passed tests 38 Dashed hopes 14 Skipped sets All OK! Did you read my mail about tests I did after Wolfgangs' suggestions? We replied almost together. The "cast" hack proves that we are investigating in the correct direction. Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Wolfgang!
Wolfgang Lux wrote:
I don’t think you need any further testing. The _highlightsByMask member is
declared as NSInteger in NSButtonCell.h (which means 64 bits on x86-64 and
ppc64) but unarchived as unsigned int in NSButtonCell.m (which means 32 bits)
and big endian architectures as less forgiving on such mismatches.
The same applies to (at least) _showAltState mask.
And encodeWithCoder: seems to get this wrong for both members, too.
good catch. We have two differences here 32bit vs 64bit, but also signed
vs unsigned!
The first thing I tried was to use NSInteger/NSUInteger as approriate in
encodeWithCode and initWithCoder, but Gorm files fail to load
"Exception occurred while loading model: expected long long and got
unsigned int"
I then tried just to use int to match NSInteger and reduce the
signedness problem, then I get insted
"Exception occurred while loading model: expected int and got unsigned int"
I did a simple thing like this:
@@ -1715,9 +1715,9 @@
at: &_keyEquivalentModifierMask];
}
- [aCoder encodeValueOfObjCType: @encode(unsigned int)
+ [aCoder encodeValueOfObjCType: @encode(int)
at: &_highlightsByMask];
- [aCoder encodeValueOfObjCType: @encode(unsigned int)
+ [aCoder encodeValueOfObjCType: @encode(int)
at: &_showAltStateMask];
if([NSButtonCell version] >= 2)
@@ -1771,6 +1771,7 @@
unsigned int bFlags = [aDecoder decodeIntForKey:
@"NSButtonFlags"];
GSButtonCellFlags buttonCellFlags;
memcpy((void *),(void
*),sizeof(struct _GSButtonCellFlags));
+ NSLog(@"for %@ - bFlags: %u %u", _contents, bFlags, (unsigned
int)(void*));
[self setTransparent: buttonCellFlags.isTransparent];
[self setBordered: buttonCellFlags.isBordered];
@@ -1902,9 +1903,9 @@
{
_keyEquivalentModifierMask = _keyEquivalentModifierMask << 16;
}
- [aDecoder decodeValueOfObjCType: @encode(unsigned int)
+ [aDecoder decodeValueOfObjCType: @encode(int)
at: &_highlightsByMask];
- [aDecoder decodeValueOfObjCType: @encode(unsigned int)
+ [aDecoder decodeValueOfObjCType: @encode(int)
at: &_showAltStateMask];
the "unsigned int" it getting (while expecting the type I get) is
written somewhere else or is it inside the gorm file itself? that would
be perhaps an issue, since it would mean changing the gorm format.
I attempted a super-ugly hack which I refrain from committing, relying
on the compiler to do the cast and signed/unsigned conversion:
diff --git a/Source/NSButtonCell.m b/Source/NSButtonCell.m
index fe33626af..ae1d15bd4 100644
--- a/Source/NSButtonCell.m
+++ b/Source/NSButtonCell.m
@@ -1695,6 +1695,8 @@
}
else
{
+ unsigned int tmp2;
+
[aCoder encodeObject: _keyEquivalent];
[aCoder encodeObject: _keyEquivalentFont];
[aCoder encodeObject: _altContents];
@@ -1715,10 +1717,12 @@
at: &_keyEquivalentModifierMask];
}
+ tmp2 = (unsigned int)_highlightsByMask;
[aCoder encodeValueOfObjCType: @encode(unsigned int)
- at: &_highlightsByMask];
+ at: ];
+ tmp2 = (unsigned int)_showAltStateMask;
[aCoder encodeValueOfObjCType: @encode(unsigned int)
- at: &_showAltStateMask];
+ at: ];
if([NSButtonCell version] >= 2)
{
@@ -1887,6 +1891,7 @@
BOOL tmp;
int version = [aDecoder versionForClassName: @"NSButtonCell"];
NSString *key = nil;
+ unsigned int tmp2;
[aDecoder decodeValueOfObjCType: @encode(id) at: ];
[self setKeyEquivalent: key]; // Set the key equivalent...
@@ -1903,9 +1908,11 @@
_keyEquivalentModifierMask = _keyEquivalentModifierMask << 16;
}
[aDecoder decodeValueOfObjCType: @encode(unsigned int)
- at: &_highlightsByMask];
+ at: ];
+ _highlightsByMask = (NSInteger)tmp2;
[aDecoder decodeValueOfObjCType: @encode(unsigned int)
- at: &_showAltStateMask];
+ at: ];
+ _showAltStateMask = (NSInteger)tmp2;
if (version >= 2)
{
what do you think? That way... things load and radio buttons and
checkboxes work. I find it ugly. Also I want to be sure that Gorms are
encoded correctly if created here
Then,. also, we have some Labels and especially MenuItems not loading in
PopUpButtons. Maybe someting does not decode, e.g. Tags ?
Riccardo
Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 17:20 schrieb Wolfgang Lux : > > > >> Am 06.01.2021 um 17:15 schrieb Wolfgang Lux : >> >> >> >>> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : >>> >>> >>> The next step would be to compare these values with the ones you get on >>> amd64. But before that, could you please run the base tests on ppc64? Maybe >>> you get already a failing test there and this would just explain the >>> behaviour. We always should start looking for an issue from ground up. If >>> base is already broken there is no use in trying to pin it down in gui. >> >> I don’t think you need any further testing. The _highlightsByMask member is >> declared as NSInteger in NSButtonCell.h (which means 64 bits on x86-64 and >> ppc64) but unarchived as unsigned int in NSButtonCell.m (which means 32 >> bits) and big endian architectures as less forgiving on such mismatches. >> >> The same applies to (at least) _showAltState mask. > > And encodeWithCoder: seems to get this wrong for both members, too. Thank you Wolfgang, I will try to correct the code there. Cheers, Fred
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 17:15 schrieb Wolfgang Lux : > > > >> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : >> >> >> The next step would be to compare these values with the ones you get on >> amd64. But before that, could you please run the base tests on ppc64? Maybe >> you get already a failing test there and this would just explain the >> behaviour. We always should start looking for an issue from ground up. If >> base is already broken there is no use in trying to pin it down in gui. > > I don’t think you need any further testing. The _highlightsByMask member is > declared as NSInteger in NSButtonCell.h (which means 64 bits on x86-64 and > ppc64) but unarchived as unsigned int in NSButtonCell.m (which means 32 bits) > and big endian architectures as less forgiving on such mismatches. > > The same applies to (at least) _showAltState mask. And encodeWithCoder: seems to get this wrong for both members, too. Wolfgang
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : > > > The next step would be to compare these values with the ones you get on > amd64. But before that, could you please run the base tests on ppc64? Maybe > you get already a failing test there and this would just explain the > behaviour. We always should start looking for an issue from ground up. If > base is already broken there is no use in trying to pin it down in gui. I don’t think you need any further testing. The _highlightsByMask member is declared as NSInteger in NSButtonCell.h (which means 64 bits on x86-64 and ppc64) but unarchived as unsigned int in NSButtonCell.m (which means 32 bits) and big endian architectures as less forgiving on such mismatches. The same applies to (at least) _showAltState mask. Wolfgang
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 15:32 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> >> You should concentrate on the _highlightByMask which gets decoded in line >> 1905 (_showAltStateMask is handled just below). > > I put a log statement "after" and I always get back zero, like this: > > 2021-01-06 15:18:32.285 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 > state 0 > 2021-01-06 15:18:32.286 Ink[10368:10368] Replace All not keycoding version 3 > 2021-01-06 15:18:32.291 Ink[10368:10368] _highlightsByMask 0 - > _showAltStateMask 0 > 2021-01-06 15:18:32.292 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 > state 0 > 2021-01-06 15:18:32.292 Ink[10368:10368] Replace not keycoding version 3 > 2021-01-06 15:18:32.293 Ink[10368:10368] _highlightsByMask 0 - > _showAltStateMask 0 > 2021-01-06 15:18:32.294 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 > state 0 > 2021-01-06 15:18:32.295 Ink[10368:10368] Replace & Find not keycoding version > 3 > 2021-01-06 15:18:32.296 Ink[10368:10368] _highlightsByMask 0 - > _showAltStateMask 0 > 2021-01-06 15:18:32.296 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 > state 0 > 2021-01-06 15:18:32.297 Ink[10368:10368] Previous not keycoding version 3 > 2021-01-06 15:18:32.298 Ink[10368:10368] _highlightsByMask 0 - > _showAltStateMask 0 > 2021-01-06 15:18:32.299 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 > state 0 > 2021-01-06 15:18:32.300 Ink[10368:10368] Next not keycoding version 3 > 2021-01-06 15:18:32.302 Ink[10368:10368] _highlightsByMask 0 - > _showAltStateMask 0 > > this is coherent to it being 0 later... (It is always after the output of the > line saying "notkeycoding version 3)... how to delve deeper? The next step would be to compare these values with the ones you get on amd64. But before that, could you please run the base tests on ppc64? Maybe you get already a failing test there and this would just explain the behaviour. We always should start looking for an issue from ground up. If base is already broken there is no use in trying to pin it down in gui. Hope this helps, Fred
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Fred, Fred Kiefer wrote: This on PPC64 2021-01-06 00:12:47.720 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.722 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.724 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.727 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.729 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.792 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 1 - highlightByMask 0 2021-01-06 00:12:47.862 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.866 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 1 - highlightByMask 0 we see indeed state is always zero and the highlightByMask too Where is it decoded? You should concentrate on the _highlightByMask which gets decoded in line 1905 (_showAltStateMask is handled just below). I put a log statement "after" and I always get back zero, like this: 2021-01-06 15:18:32.285 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 15:18:32.286 Ink[10368:10368] Replace All not keycoding version 3 2021-01-06 15:18:32.291 Ink[10368:10368] _highlightsByMask 0 - _showAltStateMask 0 2021-01-06 15:18:32.292 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 15:18:32.292 Ink[10368:10368] Replace not keycoding version 3 2021-01-06 15:18:32.293 Ink[10368:10368] _highlightsByMask 0 - _showAltStateMask 0 2021-01-06 15:18:32.294 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 15:18:32.295 Ink[10368:10368] Replace & Find not keycoding version 3 2021-01-06 15:18:32.296 Ink[10368:10368] _highlightsByMask 0 - _showAltStateMask 0 2021-01-06 15:18:32.296 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 15:18:32.297 Ink[10368:10368] Previous not keycoding version 3 2021-01-06 15:18:32.298 Ink[10368:10368] _highlightsByMask 0 - _showAltStateMask 0 2021-01-06 15:18:32.299 Ink[10368:10368] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 15:18:32.300 Ink[10368:10368] Next not keycoding version 3 2021-01-06 15:18:32.302 Ink[10368:10368] _highlightsByMask 0 - _showAltStateMask 0 this is coherent to it being 0 later... (It is always after the output of the line saying "notkeycoding version 3)... how to delve deeper? Riccardo Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 06.01.2021 um 01:06 schrieb Riccardo Mottola : > > On 2021-01-05 08:07:59 + Fred Kiefer wrote: > >>> line 1094, after the mask is calculated, do you expect it to be always 0, >>> both for on and off state? It is always 0 for me. >> As you can see a few lines above the value of mask depends on >> _cell.is_highlighted and _cell.state. You should output these two values as >> well. Next it could be either _highlightsByMask or _showAltStateMask. Sou >> you need to check these values as well. If they are zero you should go back >> to the decoding method and see wether these values get decoded correctly. >> The best way to check is to do the same on a 32 bit or 64 little endian >> system and compare the results. Form files should decode the same for both >> systems. > > It looks totally different, this is what I see on amd64: > 2021-01-05 23:15:22.654 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:22.683 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:22.746 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.179 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.180 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.181 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.182 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.182 Ink[2501:123181007659016] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 6 > 2021-01-05 23:15:31.187 Ink[2501:123181007659016] is highlghted 0 - state 1 - > altStateMask 1 - highlightByMask 1 > 2021-01-05 23:15:31.191 Ink[2501:123181007659016] is highlghted 0 - state 1 - > altStateMask 0 - highlightByMask 1 > 2021-01-05 23:15:31.195 Ink[2501:123181007659016] is highlghted 0 - state 1 - > altStateMask 1 - highlightByMask 1 > > This on PPC64 > 2021-01-06 00:12:47.720 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.722 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.724 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.727 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.729 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.792 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 1 - highlightByMask 0 > 2021-01-06 00:12:47.862 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 0 - highlightByMask 0 > 2021-01-06 00:12:47.866 Ink[48256:48256] is highlghted 0 - state 0 - > altStateMask 1 - highlightByMask 0 > > > we see indeed state is always zero and the highlightByMask too Where is > it decoded? You should concentrate on the _highlightByMask which gets decoded in line 1905 (_showAltStateMask is handled just below).
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Fred, On 2021-01-05 08:07:59 + Fred Kiefer wrote: line 1094, after the mask is calculated, do you expect it to be always 0, both for on and off state? It is always 0 for me. As you can see a few lines above the value of mask depends on _cell.is_highlighted and _cell.state. You should output these two values as well. Next it could be either _highlightsByMask or _showAltStateMask. Sou you need to check these values as well. If they are zero you should go back to the decoding method and see wether these values get decoded correctly. The best way to check is to do the same on a 32 bit or 64 little endian system and compare the results. Form files should decode the same for both systems. It looks totally different, this is what I see on amd64: 2021-01-05 23:15:22.654 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:22.683 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:22.746 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.179 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.180 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.181 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.182 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.182 Ink[2501:123181007659016] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 6 2021-01-05 23:15:31.187 Ink[2501:123181007659016] is highlghted 0 - state 1 - altStateMask 1 - highlightByMask 1 2021-01-05 23:15:31.191 Ink[2501:123181007659016] is highlghted 0 - state 1 - altStateMask 0 - highlightByMask 1 2021-01-05 23:15:31.195 Ink[2501:123181007659016] is highlghted 0 - state 1 - altStateMask 1 - highlightByMask 1 This on PPC64 2021-01-06 00:12:47.720 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.722 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.724 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.727 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.729 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.792 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 1 - highlightByMask 0 2021-01-06 00:12:47.862 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:12:47.866 Ink[48256:48256] is highlghted 0 - state 0 - altStateMask 1 - highlightByMask 0 we see indeed state is always zero and the highlightByMask too Where is it decoded? However, look here, if I toggle a checkbox on ppc64: 2021-01-06 00:26:48.328 Ink[48271:48271] is highlghted 1 - state 0 - altStateMask 1 - highlightByMask 0 2021-01-06 00:26:48.364 Ink[48271:48271] NSOffState 2021-01-06 00:26:48.366 Ink[48271:48271] is highlghted 0 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:27:03.385 Ink[48271:48271] is highlghted 1 - state 0 - altStateMask 0 - highlightByMask 0 2021-01-06 00:27:03.411 Ink[48271:48271] NSOnState 2021-01-06 00:27:03.414 Ink[48271:48271] is highlghted 0 - state 0 - altStateMask 1 - highlightByMask 0 the state never changes... only the altStateMask! The same on amd64 2021-01-05 23:31:34.188 Ink[8573:132194998521864] is highlghted 1 - state 1 - altStateMask 1 - highlightByMask 1 2021-01-05 23:31:34.300 Ink[8573:132194998521864] is highlghted 0 - state 1 - altStateMask 0 - highlightByMask 1 2021-01-05 23:31:36.416 Ink[8573:132194998521864] is highlghted 1 - state 1 - altStateMask 0 - highlightByMask 1 2021-01-05 23:31:36.476 Ink[8573:132194998521864] is highlghted 0 - state 1 - altStateMask 1 - highlightByMask 1 there "state" is always true and highlighted toggles. I would concentrate on cell state thus, but highlightByMask is also the opposite. In NSButtonCell it is never set. How can it not change with the explicit set state I traced in NSCell? I noticed this in NSCell. like 2583: [aCoder encodeValueOfObjCType: @encode(unsigned int) at: _int]; // FIXME: State may be -1, why do we encode it as unsigned? tmp_int = _cell.state; But this code is not used. However, of course, the non keyed version is used, line 2764 2021-01-06 01:01:57.427 Ink[52733:52733] NSCell initWithCoder tmp_int: 1 state 1 2021-01-06 01:01:57.427 Ink[52733:52733] NSCell initWithCoder tmp_int: 1 state 1 2021-01-06 01:01:57.428 Ink[52733:52733] NSCell initWithCoder tmp_int: 0 state 0 2021-01-06 01:01:57.438 Ink[52733:52733] NSCell initWithCoder tmp_int: 0 state 0 Here it looks that sometimes the state
Re: NSControls failing to set status/label on BigEndian/64bit
> Am 05.01.2021 um 01:28 schrieb Riccardo Mottola : > > > Fred Kiefer wrote: >> thank you for pointing out this issue. As I don’t have a Bigendian 64 bit >> system you will have to do the testing to pin this down. First I would >> propose that you add a few NSLog statements in NSButtonCell.m after line >> 1773. Most likely the data is not aligned in the unsigned int in the way the >> code expects it to be. The structure _GSButtonCellFlags is defined in >> GSCodingFlags.h and the code expects it to have 32 bits. > > for a moment, I thought the "state" could not be correct: since not only > buttons (but let's not forget also popupmenus and some fields) do not display > correctly, but even if I change the state by clicking they don't correct, so > it is not only an init problem of the state. > > I put some NSLogs in NSCell.m in setState: and the state is correctly set and > toggled. > > I then put my attention in drawInteriorWithFrame of NSButtonCell > > line 1094, after the mask is calculated, do you expect it to be always 0, > both for on and off state? It is always 0 for me. As you can see a few lines above the value of mask depends on _cell.is_highlighted and _cell.state. You should output these two values as well. Next it could be either _highlightsByMask or _showAltStateMask. Sou you need to check these values as well. If they are zero you should go back to the decoding method and see wether these values get decoded correctly. The best way to check is to do the same on a 32 bit or 64 little endian system and compare the results. Form files should decode the same for both systems. Hope this helps, Fred
Re: NSControls failing to set status/label on BigEndian/64bit
Hi, Fred Kiefer wrote: thank you for pointing out this issue. As I don’t have a Bigendian 64 bit system you will have to do the testing to pin this down. First I would propose that you add a few NSLog statements in NSButtonCell.m after line 1773. Most likely the data is not aligned in the unsigned int in the way the code expects it to be. The structure _GSButtonCellFlags is defined in GSCodingFlags.h and the code expects it to have 32 bits. for a moment, I thought the "state" could not be correct: since not only buttons (but let's not forget also popupmenus and some fields) do not display correctly, but even if I change the state by clicking they don't correct, so it is not only an init problem of the state. I put some NSLogs in NSCell.m in setState: and the state is correctly set and toggled. I then put my attention in drawInteriorWithFrame of NSButtonCell line 1094, after the mask is calculated, do you expect it to be always 0, both for on and off state? It is always 0 for me. Riccardo Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Fred, Fred Kiefer wrote: thank you for pointing out this issue. As I don’t have a Bigendian 64 bit system you will have to do the testing to pin this down. First I would propose that you add a few NSLog statements in NSButtonCell.m after line 1773. Most likely the data is not aligned in the unsigned int in the way the code expects it to be. The structure _GSButtonCellFlags is defined in GSCodingFlags.h and the code expects it to have 32 bits. Please report back the values you see there (bFlags and buttonCellFlags). First report is that an NSLog there returns nothing, neither when starting Ink nor GWorkspace. Apparently the other branch is used, the "non-keycoding" at line 1886 and I get a mix of versions 1,2 and 3. There, I don't fully understand where the values to pe encoded come from. However, the "look" of the radio button or checkbox looks correct to me, only its state is not correctly displayed and it does not appear to be in those flags, or am I wrong? Riccardo
Re: NSControls failing to set status/label on BigEndian/64bit
Hi Riccardo, thank you for pointing out this issue. As I don’t have a Bigendian 64 bit system you will have to do the testing to pin this down. First I would propose that you add a few NSLog statements in NSButtonCell.m after line 1773. Most likely the data is not aligned in the unsigned int in the way the code expects it to be. The structure _GSButtonCellFlags is defined in GSCodingFlags.h and the code expects it to have 32 bits. Please report back the values you see there (bFlags and buttonCellFlags). Hope this helps, Fred > Am 03.01.2021 um 21:01 schrieb Riccardo Mottola : > > Hello, > > I got in the past reports from some users about issue, now I can reproduce > myself. > > I have set up a BigEndian PowerPC with 64bit and running GNUstep with the > traditional gcc runtime. Environment is a fully up-to-date Linux Debian. > > I noticed that in different applications and panels, RadioButtons are not > working (no one appears set!) nor Check Boxes! and even clicking doesn't > change the status. > > I tried changing the default theme (supposing a simple issue of displaying > the correct image) but that is not the case, all are affected. Also, in some > places, I found working RadioButtons and Checkboxes. so that rules out this. > > As a start, I took out Ink - Fred's favourite minimal application. > > I open the "Find Panel" and see > > - Scope Entire File / Selection has no radio button selectedand selecting > does not change > > - ignore case checkbox can't be set, appears always unset! > > I tried and actually the ignore case feature works! so it appears to be a > "display" problem > > > Then I open the "Print Panel" > > - Page selection All/From radio button shows always unselected > > - Copies and Scale field do not display a numeric value (1 and 100% > respectively) but "Text" > > - Printer and Layout PopupButtons show "Item 1, Item 2" instead of real > content > > - hitting the "Option" button doesn't show an option panel but closes the > Print Panel! > > > Then I open the "Page Layout": > > - in "Page Attributes" the radio buttons do not work, but the "Scale" has 100 > > - in Custom Paper Size all fields which should hold the units (inch/cm) show > "un" which I believe is for undefined. > > > I ask particularly Fred and Gregory if there are ideas about what causes this > strange issue and what can be looked after. It could be a GUI issue as well > as an issue with Gorm files. > > > Then I open GWorkspace.. > > - in the Inspectpr, if I select a Folder, I have a series of radiobutton > which affect sorting, they display correcty and can be clicked > > - in Preferences, most things have issues: Terminal sevices checkbox and in > "Desktop" all properties of the docks don't display > > I tried Terminal and everything looks fine. > > I tried StepSync (which is very recently created and uses Gorm files) and > none of the checkboxes work. > > I tried GNUMail and in Preferences, most items appear to look fine: > RadioButtons, Checkboxen... > > > So we can have a problem in RadioButtons, Checkboxes, PopupMenus, Labels, but > they do not show "everywhere" > > > I am unable currently to test on PPC-BE/32bit, but will do so about in a week. > > Riccardo > >
