TelePharo / Seamless Bitmaps are all 0s

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TelePharo / Seamless Bitmaps are all 0s

alistairgrant
Hi Denis,

If I print:

remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)"

which is obviously correct, but:

remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ]

gives me a bitmap with all zeroes (running it locally does the expected thing).

I can see that the bitmap is being created correctly on the server,
but by the time it gets back the values have been lost (all converted
to 0s).  If I change the Bitmap>>seamlessDefaultTransferStrategy for
the Bitmap to #defaultByReference I can correctly access the values
(just for debugging, by reference isn't practical for the real
system).

Any hints on where to look?

Thanks again,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: TelePharo / Seamless Bitmaps are all 0s

Denis Kudriashov
Hi Alistair

I will look when have a time.
But you can try to write a test for bitmap serialization/materialization in TostSerializationTests (if I remember correctly the name).
It will show if bitmap transport requires extra logic.

ср, 15 мая 2019 г., 8:49 Alistair Grant <[hidden email]>:
Hi Denis,

If I print:

remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)"

which is obviously correct, but:

remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ]

gives me a bitmap with all zeroes (running it locally does the expected thing).

I can see that the bitmap is being created correctly on the server,
but by the time it gets back the values have been lost (all converted
to 0s).  If I change the Bitmap>>seamlessDefaultTransferStrategy for
the Bitmap to #defaultByReference I can correctly access the values
(just for debugging, by reference isn't practical for the real
system).

Any hints on where to look?

Thanks again,
Alistair

Reply | Threaded
Open this post in threaded view
|

Re: TelePharo / Seamless Bitmaps are all 0s

alistairgrant
Hi Denis,

On Wed, 15 May 2019 at 10:16, Denis Kudriashov <[hidden email]> wrote:
>
> Hi Alistair
>
> I will look when have a time.
> But you can try to write a test for bitmap serialization/materialization in TostSerializationTests (if I remember correctly the name).
> It will show if bitmap transport requires extra logic.

If I remove Bitmap>>travelGuide (so that it inherits the default
OrdinaryObjectTravelGuide instead of an empty travel guide) everything
seems to work OK.

This seems reasonable to me as a Bitmap's format is basically the same
as an Array, which doesn't seem to require any special processing.

I can add a simple test and submit a PR (in a few days time) if the
change sounds OK to you.

Thanks,
Alistair


> ср, 15 мая 2019 г., 8:49 Alistair Grant <[hidden email]>:
>>
>> Hi Denis,
>>
>> If I print:
>>
>> remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)"
>>
>> which is obviously correct, but:
>>
>> remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ]
>>
>> gives me a bitmap with all zeroes (running it locally does the expected thing).
>>
>> I can see that the bitmap is being created correctly on the server,
>> but by the time it gets back the values have been lost (all converted
>> to 0s).  If I change the Bitmap>>seamlessDefaultTransferStrategy for
>> the Bitmap to #defaultByReference I can correctly access the values
>> (just for debugging, by reference isn't practical for the real
>> system).
>>
>> Any hints on where to look?
>>
>> Thanks again,
>> Alistair
>>

Reply | Threaded
Open this post in threaded view
|

Re: TelePharo / Seamless Bitmaps are all 0s

Denis Kudriashov
Hi Alistair

ср, 15 мая 2019 г. в 10:11, Alistair Grant <[hidden email]>:
Hi Denis,

On Wed, 15 May 2019 at 10:16, Denis Kudriashov <[hidden email]> wrote:
>
> Hi Alistair
>
> I will look when have a time.
> But you can try to write a test for bitmap serialization/materialization in TostSerializationTests (if I remember correctly the name).
> It will show if bitmap transport requires extra logic.

If I remove Bitmap>>travelGuide (so that it inherits the default
OrdinaryObjectTravelGuide instead of an empty travel guide) everything
seems to work OK.

This seems reasonable to me as a Bitmap's format is basically the same
as an Array, which doesn't seem to require any special processing.

Not really. Bitmap is specifically array of integers. So it does not make sense to traverse it as a complex structure considering that all its items are real objects. it could be quite expensive.
Bitmap represents an image (form) and I think it is logical to trait it as a whole structure, like bytearray or string. And EmptyObjectTravelGuide marks such kind of objects to be not traversable.

So the issue was with missing implementation of Bitmap serialization. TostSerializer requires that any integral object implements couple of "primitive methods". And it was not done for Bitmap.

I fixed serializer and released all dependent projects. So try update TelePharo.
 

I can add a simple test and submit a PR (in a few days time) if the
change sounds OK to you.

Thanks,
Alistair


> ср, 15 мая 2019 г., 8:49 Alistair Grant <[hidden email]>:
>>
>> Hi Denis,
>>
>> If I print:
>>
>> remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)"
>>
>> which is obviously correct, but:
>>
>> remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ]
>>
>> gives me a bitmap with all zeroes (running it locally does the expected thing).
>>
>> I can see that the bitmap is being created correctly on the server,
>> but by the time it gets back the values have been lost (all converted
>> to 0s).  If I change the Bitmap>>seamlessDefaultTransferStrategy for
>> the Bitmap to #defaultByReference I can correctly access the values
>> (just for debugging, by reference isn't practical for the real
>> system).
>>
>> Any hints on where to look?
>>
>> Thanks again,
>> Alistair
>>

Reply | Threaded
Open this post in threaded view
|

Re: TelePharo / Seamless Bitmaps are all 0s

alistairgrant
Hi Denis,


On Thu, 16 May 2019 at 19:17, Denis Kudriashov <[hidden email]> wrote:

>
> Hi Alistair
>
> ср, 15 мая 2019 г. в 10:11, Alistair Grant <[hidden email]>:
>>
>> Hi Denis,
>>
>> On Wed, 15 May 2019 at 10:16, Denis Kudriashov <[hidden email]> wrote:
>> >
>> > Hi Alistair
>> >
>> > I will look when have a time.
>> > But you can try to write a test for bitmap serialization/materialization in TostSerializationTests (if I remember correctly the name).
>> > It will show if bitmap transport requires extra logic.
>>
>> If I remove Bitmap>>travelGuide (so that it inherits the default
>> OrdinaryObjectTravelGuide instead of an empty travel guide) everything
>> seems to work OK.
>>
>> This seems reasonable to me as a Bitmap's format is basically the same
>> as an Array, which doesn't seem to require any special processing.
>
>
> Not really. Bitmap is specifically array of integers. So it does not make sense to traverse it as a complex structure considering that all its items are real objects. it could be quite expensive.
> Bitmap represents an image (form) and I think it is logical to trait it as a whole structure, like bytearray or string. And EmptyObjectTravelGuide marks such kind of objects to be not traversable.

I meant "reasonable" as in I have a reasonable expectation that it
will work.  You are of course correct that it won't be as efficient.

> So the issue was with missing implementation of Bitmap serialization. TostSerializer requires that any integral object implements couple of "primitive methods". And it was not done for Bitmap.
>
> I fixed serializer and released all dependent projects. So try update TelePharo.

Yep, it looks like it is working correctly now.

Thanks!
Alistair



>>
>>
>> I can add a simple test and submit a PR (in a few days time) if the
>> change sounds OK to you.
>>
>> Thanks,
>> Alistair
>>
>>
>> > ср, 15 мая 2019 г., 8:49 Alistair Grant <[hidden email]>:
>> >>
>> >> Hi Denis,
>> >>
>> >> If I print:
>> >>
>> >> remotePharo evaluate: [ Array withAll: #(42 42 42) ] "==> #(42 42 42)"
>> >>
>> >> which is obviously correct, but:
>> >>
>> >> remotePharo evaluate: [ Bitmap withAll: #(42 42 42) ]
>> >>
>> >> gives me a bitmap with all zeroes (running it locally does the expected thing).
>> >>
>> >> I can see that the bitmap is being created correctly on the server,
>> >> but by the time it gets back the values have been lost (all converted
>> >> to 0s).  If I change the Bitmap>>seamlessDefaultTransferStrategy for
>> >> the Bitmap to #defaultByReference I can correctly access the values
>> >> (just for debugging, by reference isn't practical for the real
>> >> system).
>> >>
>> >> Any hints on where to look?
>> >>
>> >> Thanks again,
>> >> Alistair
>> >>
>>