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
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 th
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 uns
> 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
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 shoul
> 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
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
> 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-
> 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
> 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 fail
> 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 pl
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
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 i
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 en
> 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
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). Try
> 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
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
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 differen
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.
> 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 bi
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 thos
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 al
> 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
24 matches
Mail list logo
