TelePharo / Seamless Bitmaps are all 0s
Locked
TelePharo / Seamless Bitmaps are all 0s
 
|
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 |
Re: TelePharo / Seamless Bitmaps are all 0s
|
|
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, |
Re: TelePharo / Seamless Bitmaps are all 0s
|
|
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 >> |
Re: TelePharo / Seamless Bitmaps are all 0s
|
|
Hi Alistair ср, 15 мая 2019 г. в 10:11, Alistair Grant <[hidden email]>: Hi Denis, 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.
|
Re: TelePharo / Seamless Bitmaps are all 0s
|
|
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 >> >> >> |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |