On 23/02/17 19:26, Esteban Lorenzano wrote:
On 23 Feb 2017, at 19:21, raffaello.giulietti@lifeware.ch <mailto:raffaello.giulietti@lifeware.ch> wrote:
On 23/02/17 19:17, Esteban Lorenzano wrote:
On 23 Feb 2017, at 19:11, raffaello.giulietti@lifeware.ch <mailto:raffaello.giulietti@lifeware.ch> wrote:
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.
Which Alien class?
Esteban
What do you mean? I see it in package Alien-Core.
ah, problem is that #copyInto:from:to:in:startingAt: requires an Alien instead a ExternalAddress (and they are not the same). But I guess you can use it if you have two ByteArrays.
in the times of old NativeBoost, Igor implemented a memcpy as you want it, because yes, is a problem we have⦠if is seriously needed, you can always compile your own library with such symbol⦠a memcpy with start positions. function in C is more or less trivial because you will receive two pointers and you can perform pointer arithmetic on both.
Esteban
What about an existing library that I don't want or cannot modify? Really, I agree that this is a problem that Pharo has to solve. I think the UFFI deserves a more general and cheaper way of copying between ByteArrays and the C heap. Can I expect it to appear in the short term? Can I help somehow? Raffaello