Hi Denis, On Wed, 15 May 2019 at 10:16, Denis Kudriashov <dionisi...@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 <akgrant0...@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 >>
