On 23/02/17 19:26, Esteban Lorenzano wrote: > >> On 23 Feb 2017, at 19:21, raffaello.giulie...@lifeware.ch >> <mailto:raffaello.giulie...@lifeware.ch> wrote: >> >> On 23/02/17 19:17, Esteban Lorenzano wrote: >>> >>>> On 23 Feb 2017, at 19:11, raffaello.giulie...@lifeware.ch >>>> <mailto:raffaello.giulie...@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
