Hi Denis, On Wed, 15 May 2019 at 10:16, Denis Kudriashov <dionisiydk@gmail.com> 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 <akgrant0710@gmail.com>:

...

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

Hi Denis, On Thu, 16 May 2019 at 19:17, Denis Kudriashov <dionisiydk@gmail.com> wrote:

Hi Alistair

ср, 15 мая 2019 г. в 10:11, Alistair Grant <akgrant0710@gmail.com>:

...

Hi Denis,

On Wed, 15 May 2019 at 10:16, Denis Kudriashov <dionisiydk@gmail.com> 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 <akgrant0710@gmail.com>:

...

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