February 2017 - Pharo-users

Re: [Pharo-users] UFFI and ByteArray

by raffaello.giulietti＠lifeware.ch

On 23/02/17 19:26, Esteban Lorenzano wrote: > >> On 23 Feb 2017, at 19:21, raffaello.giulietti(a)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(a)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

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by Esteban Lorenzano

> On 23 Feb 2017, at 19:21, raffaello.giulietti(a)lifeware.ch wrote: > > On 23/02/17 19:17, Esteban Lorenzano wrote: >> >>> On 23 Feb 2017, at 19:11, raffaello.giulietti(a)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 > > >> >>> >>> >>> >>> >>> >>> >>> 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.giulietti(a)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.giulietti(a)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/PharoBookWorkInProgre… >>>>>>>> >>>>>>>> >>>>>>>> Thanks for directing me at relevant docs or examples and sorry in >>>>>>>> advance if I missed some important point in the docs. >>>>>>>> >>>>>>>> RG

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by raffaello.giulietti＠lifeware.ch

On 23/02/17 19:17, Esteban Lorenzano wrote: > >> On 23 Feb 2017, at 19:11, raffaello.giulietti(a)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. > >> >> >> >> >> >> >> 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.giulietti(a)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.giulietti(a)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/PharoBookWorkInProgre… >>>>>>> >>>>>>> >>>>>>> Thanks for directing me at relevant docs or examples and sorry in >>>>>>> advance if I missed some important point in the docs. >>>>>>> >>>>>>> RG >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by Esteban Lorenzano

> On 23 Feb 2017, at 19:11, raffaello.giulietti(a)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 > > > > > > > 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.giulietti(a)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.giulietti(a)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/PharoBookWorkInProgre… >>>>>> >>>>>> >>>>>> Thanks for directing me at relevant docs or examples and sorry in >>>>>> advance if I missed some important point in the docs. >>>>>> >>>>>> RG >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by raffaello.giulietti＠lifeware.ch

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.giulietti(a)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.giulietti(a)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/PharoBookWorkInProgre… >>>>> >>>>> >>>>> Thanks for directing me at relevant docs or examples and sorry in >>>>> advance if I missed some important point in the docs. >>>>> >>>>> RG >>>>> >>>>> >>>> >>>> >>> >>> >> >> >

Feb. 23, 2017

Re: [Pharo-users] Crash in Athens

by stepharong

Hi alexander Thanks for reporting to us your findings. Can you report on which - os - version os - which pharo vm (there is a system report option) - which image Stef > Hello. > > I can reproduce the bug "semi-automatically". The tree classes I use to > crash are attached. > Run > > AthensFlyingStickMorph new openInWorld > > and wait. Sometimes it crashes immediately. Sometimes I have to wait a > couple of minutes. > If I done not resize the crash never or almost never happens. > > Thank you, > Alex > On Wed, Feb 22, 2017 at 11:56 AM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: >> Hello, >>http://forum.world.st/Too-frequent-crashes-td4927143i20.html#a4934027 >> >> Try changing AthensCairoSurface >> asForm into the following method: >> >> asForm >> >> "create a form and copy an image data there" >> | form | >> self checkSession. >> self flush. >> form := Form extent: (self width@self height) depth: 32. >> form unhibernate. >> LibC memCopy: self getDataPtr to: form bits size: self width*self >> height*4. >> ^ form >> >>>> This seems to improve the stability a lot. I have already told >>>> Esteban to take a better look. >> >>>> Best regards, >> Ronie >> >> 2017-02-22 13:47 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> Dear Alexander, >>> >>> Sine the new FFI of Pharo, using Athens has become unreliable. This is >>> a pity, but fixing this is not trivial at all (we have been trying for >>> years). >>> >>> What exactly are you doing with Athens? >>> >>> Alexandre >>> >>> >>>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich >>>> <samoylovich(a)gmail.com> wrote: >>>> >>>> Hello >>>> >>>> I am writing graphic demo programs using Athens on Mac Sierra. >>>> Time by time Pharo VM crashes. Programs not using Athens work >>>> reliably. >>>> I believe the behavior is reproducible. >>>> How should I report a bug? >>>> >>>> Alex >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by stepharong

Hi rafaello once you find the solution can you do a pull request on the UFFI doc? Your question is important we should improve the documentation. tx Stf > 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.giulietti(a)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/PharoBookWorkInProgre… >>>> >>>> >>>> Thanks for directing me at relevant docs or examples and sorry in >>>> advance if I missed some important point in the docs. >>>> >>>> RG >>>> >>>> >>> >>> >> >> > > -- Using Opera's mail client: http://www.opera.com/mail/

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by Esteban Lorenzano

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.giulietti(a)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.giulietti(a)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/PharoBookWorkInProgre… >>>> >>>> >>>> Thanks for directing me at relevant docs or examples and sorry in >>>> advance if I missed some important point in the docs. >>>> >>>> RG >>>> >>>> >>> >>> >> >> > >

Feb. 23, 2017

Re: [Pharo-users] UFFI and ByteArray

by raffaello.giulietti＠lifeware.ch

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.giulietti(a)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/PharoBookWorkInProgre… >>> >>> >>> Thanks for directing me at relevant docs or examples and sorry in >>> advance if I missed some important point in the docs. >>> >>> RG >>> >>> >> >> > >

Feb. 23, 2017

Re: [Pharo-users] Data Encryption

by Ben Coman

This is speculation without knowing your scope and architecture, but perhaps part of the puzzle is two factor authentication via a $20 Yubico FIDO U2F Security Key. https://www.yubico.com/store/ https://www.yubico.com/about/background/fido/ https://www.yubico.com/2016/02/use-of-fido-u2f-security-keys-focus-of-2-yea… BSD licensed C library for server-side.. https://developers.yubico.com/libu2f-server/ https://developers.yubico.com/U2F/Libraries/Using_a_library.html cheers -ben P.S. It might be cool to link the yubico client-side libraries (LGPL) into the VM for Iceberg to authenticate via U2F to github. https://github.com/blog/2071-github-supports-universal-2nd-factor-authentic… https://www.yubico.com/why-yubico/for-individuals/github/ https://github.com/Yubico/libu2f-host On Thu, Feb 23, 2017 at 9:31 PM, sergio ruiz <sergio.rrd(a)gmail.com> wrote: > Now that i think about it.. this will contain a list of passwords for > servers, etc.. each user will need to access about a dozen company > passwords.. trying to thing about how to keep this buttoned down.. > > > On February 22, 2017 at 9:19:05 AM, Alexandre Bergel ( > alexandre.bergel(a)me.com) wrote: > > If it help Iâm using NaCl to do secure the passwords. You should not store > the passwords of your users, not even encrypted. > > ---- > peace, > sergio > photographer, journalist, visionary > >

Feb. 23, 2017