Hi Esteban, yes, I already looked at LibC's memcpy, but that doesn't help in case you need to copy a *portion* of the ByteArray that does not start at index 1. While one can do pointer arithmetic on ExternalAddress, this does not, of course, apply to ByteArray.
To sum up, I think Pharo 5 currently lacks an efficient way to copy parts of ByteArrays to/from the C heap. One has to instantiate additional temporary ByteArrays and perform copies between ByteArrays in addition to LibC>>memcpy. But I see there's an Alien class which seems to better support such copying. Thus, I wonder if it is somehow compatible with the rest of UFFI. On 23/02/17 17:35, Esteban Lorenzano wrote: > Sorry, I forgot to answer and now I'm in movement. > Look in LibC memcpy method (is not called exactly like that) and his uses. > That's the faster you can move things inside the image. > > And remember: an EA is a pointer and a ByteArray is an array who will be > passed as pointer too. > > Esteban > >> On 23 Feb 2017, at 17:21, raffaello.giulie...@lifeware.ch wrote: >> >> Hi, >> >> browsing through ByteArray's and ExternalAddress's code, I'm getting the >> impression that copying *portions* of ByteArrays from/to the C heap can >> be quite costly. >> >> Copying *to* the C heap sometimes requires first copying the portion of >> the ByteArray into a newly instantiated temporary ByteArray, then >> copying the latter to the C heap. >> >> Copying *from* the C heap might require explicitly looping over the >> single bytes. I say "might" because I still cannot find more direct way, >> as using ByteArray>>replaceFrom:to:with:startingAt: doesn't seem to work. >> >> Any suggestion on more effective copy operations? >> >> Thanks >> Raffaello >> >> >> >> >> >> >>> On 22/02/17 15:08, Raffaello Giulietti wrote: >>> Hi Esteban, >>> >>> not sure I'm understanding your snippet correctly. >>> >>> Below is my try. It throws a SubscriptOutOfBounds exception in the last >>> line. The reason is that the implementation of ByteArray >>> replaceFrom:to:with:startingAt: does not consider that ea is meant to be >>> a pointer to a C byte array, not an object whose content is to be copied >>> directly. >>> >>> >>> | ea ba | >>> ea := ExternalAddress gcallocate: 200. >>> ba := ByteArray new: 100. >>> ba replaceFrom: 1 to: 50 with: ea startingAt: 51. >>> >>> >>> Am I missing some point? >>> >>> >>> >>> >>>> On 2017-02-21 17:20, Esteban Lorenzano wrote: >>>> usually, something more or less like this: >>>> >>>> sourceByteArrayOrExternalAddress := … some ... >>>> destEnternalAddressOrByteArray >>>> replaceFrom: 1 >>>> to: sourceByteArrayOrExternalAddress size >>>> with: sourceByteArrayOrExternalAddress >>>> startingAt: 1 >>>> >>>> and or course you can play with the starting points and sizes. >>>> >>>> cheers, >>>> Esteban >>>> >>>> >>>>> On 21 Feb 2017, at 17:13, Raffaello Giulietti >>>>> <raffaello.giulie...@lifeware.ch> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm having a hard time finding documentation on how to copy a portion >>>>> of a ByteArray to/from another portion of a heap allocated C byte >>>>> array with UFFI. >>>>> >>>>> My current reference is >>>>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgress/lastSuccessfulBuild/artifact/book-result/UnifiedFFI/UnifiedFFI.pdf >>>>> >>>>> >>>>> Thanks for directing me at relevant docs or examples and sorry in >>>>> advance if I missed some important point in the docs. >>>>> >>>>> RG >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
