June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Getting a user input string using Morphs

by Hilaire

You can try and explore something like: *|| m ||** **|m := StringMorph contents: 'Edit me'.|** **|m openInWorld.|** **|m launchMiniEditor: ActiveEvent|* Hilaire Le 09/06/2015 15:25, Jigyasa Grover a Ã©crit : > Hi ! > > I am new to Pharo and am currently working on making an Offline Text Search > Application. > I plan to use Morphs to make a nice GUI. -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Igor Stasenko

As i understand, in general, the problem that you described is in following: - you want to pass an address of your buffer contents, but started not from very first element of your buffer, but somewhere inside a buffer. In smalltalk you cannot reference an element of array, only the object (array in that case) as a whole. The reason why it like so, because VM moves objects around, and you cannot control directly when that happens, and also VM responsible for updating all pointers (references) to moved object(s) for all interested parties (which could be other objects, stack etc) , making sure all references remain consistent upon such move. So, with such constraints, the only way to validly point to an element inside array would be to store two values separately: - a reference to an object, that represent your buffer (which VM would update at will) - an index (or offset) in that object, pointing to element in your buffer Unfortunately, this is the only way how we could implement such, lets say 'ElementPointer' safely. Which then can be used to pass to C function(s), converting object reference + offset into simple address just before invoking a function (and sure thing, knowing that there's no chance triggering GC, else it will turn into pointer to wrong place, but that's general problem of passing pointers on object memory heap, not just exclusively for 'element pointer' and such). For buffers allocated externally, e.g. outside heap governed by VM, there's nothing prevents you from having an address that pointing inside some buffer (or even outside it :) For NBExternalAddress: addr := self allocate: somespace. newAddr := NBExternalAddress value: addr value + someoffset. or newAddr := addr copy value: addr value + someoffset sure, it is up to you then, how to calculate offsets and buffer size(s) as well as allocating/deallocating memory for buffers you using. On 8 June 2015 at 16:41, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > Hello everyone, > > I have a small question about NativeBoost : How does the "+" operator when > applied to a pointer translates into NativeBoost code ? > > To give a bit of context, what I want to do is to reallocate some > non-contiguous bytes in memory to a buffer. Basically, I have an array of > integers in a buffer and I want to copy some chunks of it in another > buffer. The chunks are always the same size and the offset between each > chunk is always the same too. > > Because a bit of actual code is easier to understand here is what I'd like > to do in Pharo : > > ... > > int i, j; > int *data = malloc(1000*sizeof(int)); > int *newData = malloc(50*sizeof(int)); > > // Allocate initial data > for (i = 0 ; i < 1000, i++) { > data[i] = i; > } > > //Copy desired chunks into new buffer > for (i = 0; i < 5; i++ ) { > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > j++; > } > > free(data); > > ... > > Here basically I'll get in my buffer chunks of 10 integers starting at 200 > with an offset of 30 between chunks, and this 5 times. (200 201 202 ... 208 > 209 230 231 ... 238 239 260 ... 328 329). > > I am okay with the malloc, memcpy and free but I don't know how to handle > the "+" operator in my memcpy function. > > Thank you, > > Matthieu > -- Best regards, Igor Stasenko.

June 9, 2015

Getting a user input string using Morphs

by Jigyasa Grover

Hi ! I am new to Pharo and am currently working on making an Offline Text Search Application. I plan to use Morphs to make a nice GUI. Initially, I had thought of using /TextMorphForEditView/ to get an input string from the user, but I feel this is not giving the desired functionality. Would be great if anyone could suggest a way to get input string from the user in the same window using an 'input text box' interface element. Regards -- View this message in context: http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831121.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

> On 09 Jun 2015, at 2:59 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > MyClass createCacheOf: data in: cache. Forgot to change this; you need to pass in the ExternalArray addresses as parameters, not the ExternalArrays themselves. MyClass createCacheOf: data address in: cache address Cheers, Henry

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

There are many ways to Rome :) If you just need some externally allocated objects in the formats you specified you can do the cache extraction using nothing but normal Smalltalk: intArray := (NBExternalArray ofType: 'int'). data := intArray new: 1000. 1 to:data size do:[:i |data at:i put: i]. cache := intArray new: 50. 0 to: 4 do: [:j | 1 to: 10 do: [ :k | cache at: (j* 10) + k put: (data at: 199 + (30 * j ) + k)] ]. But if you want to take full advantage of the performance boost NB offers, you'd write a NativeBoost function to do the cache extraction*, as I outlined last time: MyClass class >> #createCacheOf: aSource in: aDestination createCacheOf: aSource in: aDestination <primitive: #primitiveNativeCall module: #NativeBoostPlugin> "Should work on both x86 and x64, as long as sizeOf: lookups work correctly" ^ self nbCallout function: #(void (int * aSource, int * aDestination) ) emit: [:gen :proxy :asm | |destReg srcReg tmpReg intSize ptrSize| intSize := NBExternalType sizeOf: 'int'. ptrSize := NBExternalType sizeOf: 'void *'. "Only use caller-saved regs, no preservation needed" destReg := asm EAX as: ptrSize. srcReg := asm ECX as: ptrSize. tmpReg := asm EDX as: intSize. asm pop: srcReg. asm pop: destReg. 0 to: 4 do: [ :j | 0 to: 9 do: [ :offset | asm "Displacement in bytes, not ptr element size :S, so we have to multiply offset by that manually :S" mov: tmpReg with: srcReg ptr + (199 + (j * 30) + offset * intSize); mov: destReg ptr + ((j* 10) + offset * intSize) with: tmpReg]]] and use that; intArray := (NBExternalArray ofType: 'int'). data := intArray new: 1000. 1 to:data size do:[:i |data at:i put: i]. cache := intArray new: 50. MyClass createCacheOf: data in: cache. The difference using a simple [] bench is about two orders of magnitude; 11million cache extractions per seconds for the inline assembly version, while the naive loop achieves around 110k. Cheers, Henry *as: is not yet defined, could be something like: AJx86GPRegister >> #as: aSize ^ self isHighByte ifTrue: [ self asLowByte as: aSize ] ifFalse: [ AJx86Registers generalPurposeWithIndex: self index size: aSize requiresRex: self index > (aSize > 1 ifTrue: [7] ifFalse: [ 3]) prohibitsRex: false ] > On 09 Jun 2015, at 9:46 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello Henrik, > > Thank you very much for your answer. However, the code you provided is some sort of assembly right ? So does it mean that I need to learn assembly to do what I want ? > > I'm asking that because I don't know anything about assembly so it will take me some time to learn. > > Cheers, > > Matthieu > > 2015-06-08 19:56 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > > > On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com <mailto:matthieu.lacaton@gmail.com>> wrote: > > > > Hello everyone, > > > > I have a small question about NativeBoost : How does the "+" operator when applied to a pointer translates into NativeBoost code ? > > > > To give a bit of context, what I want to do is to reallocate some non-contiguous bytes in memory to a buffer. Basically, I have an array of integers in a buffer and I want to copy some chunks of it in another buffer. The chunks are always the same size and the offset between each chunk is always the same too. > > > > Because a bit of actual code is easier to understand here is what I'd like to do in Pharo : > > > > ... > > > > int i, j; > > int *data = malloc(1000*sizeof(int)); > > int *newData = malloc(50*sizeof(int)); > > > > // Allocate initial data > > for (i = 0 ; i < 1000, i++) { > > data[i] = i; > > } > > > > //Copy desired chunks into new buffer > > for (i = 0; i < 5; i++ ) { > > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > > j++; > > } > > > > free(data); > > > > You can do relative addressing like this: > (destReg ptr: dataSize) + offsetReg + constant > > So with offSetRegs containing j* 10 and j* 30, you might end up with an unrolled inner loop (barring using any fancier longer-than-int moves) like: > > 0 to: 9 do: [:constantOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + srcOffsetReg + constantOffset] > > If the range of j is constant, you can just as easily unroll the whole thing in a similarly compact fashion, space and sensibilites permitting: > > 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) + constOffset] > > Cheers, > Henry >

June 9, 2015

Re: [Pharo-users] Fuel and graph update

by Mariano Martinez Peck

On Tue, Jun 9, 2015 at 9:21 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I want to use Fuel to persist a graph in file. > > The classic use case is "modify some part of the model and persist > immediately". > > Now, it is not really efficient to re-serialize the whole graph each > time, and I am wondering how you are approaching this particular point > when using Fuel as your persistence back-end. > > For example, various ideas coming to my mind: > - Is it possible to update some part of an already serialized graph? > - Should the graph be cut to pieces and serialized in several files? > - Or is Fuel fast enough to just re-serialize the whole graph? > > For Quuve app, when it runs on Pharo (for development and testing), we have a fuel backend and we do 2) and 3) of above. Quuve itself is split in different/isolated conceptual databases: clients, advisory, securities, system, application, etc. So each of them is a database. And yes, we have a fuel file per database and for each save we serialize the whole graph. You need to be careful about cross-references between databases.... Anyway, it works good enough for our scenario. Our database are around 5MB and the serialization is immediate. > How about you? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > > -- Mariano http://marianopeck.wordpress.com

June 9, 2015

Fuel and graph update

by Hilaire

Hi, I want to use Fuel to persist a graph in file. The classic use case is "modify some part of the model and persist immediately". Now, it is not really efficient to re-serialize the whole graph each time, and I am wondering how you are approaching this particular point when using Fuel as your persistence back-end. For example, various ideas coming to my mind: - Is it possible to update some part of an already serialized graph? - Should the graph be cut to pieces and serialized in several files? - Or is Fuel fast enough to just re-serialize the whole graph? How about you? Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Matthieu Lacaton

Hello Henrik, Thank you very much for your answer. However, the code you provided is some sort of assembly right ? So does it mean that I need to learn assembly to do what I want ? I'm asking that because I don't know anything about assembly so it will take me some time to learn. Cheers, Matthieu 2015-06-08 19:56 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > > On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > > > > Hello everyone, > > > > I have a small question about NativeBoost : How does the "+" operator > when applied to a pointer translates into NativeBoost code ? > > > > To give a bit of context, what I want to do is to reallocate some > non-contiguous bytes in memory to a buffer. Basically, I have an array of > integers in a buffer and I want to copy some chunks of it in another > buffer. The chunks are always the same size and the offset between each > chunk is always the same too. > > > > Because a bit of actual code is easier to understand here is what I'd > like to do in Pharo : > > > > ... > > > > int i, j; > > int *data = malloc(1000*sizeof(int)); > > int *newData = malloc(50*sizeof(int)); > > > > // Allocate initial data > > for (i = 0 ; i < 1000, i++) { > > data[i] = i; > > } > > > > //Copy desired chunks into new buffer > > for (i = 0; i < 5; i++ ) { > > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > > j++; > > } > > > > free(data); > > > > You can do relative addressing like this: > (destReg ptr: dataSize) + offsetReg + constant > > So with offSetRegs containing j* 10 and j* 30, you might end up with an > unrolled inner loop (barring using any fancier longer-than-int moves) like: > > 0 to: 9 do: [:constantOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + > constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + > srcOffsetReg + constantOffset] > > If the range of j is constant, you can just as easily unroll the whole > thing in a similarly compact fashion, space and sensibilites permitting: > > 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | > asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + > constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) > + constOffset] > > Cheers, > Henry >

June 9, 2015

Pharo sprint & Moose dojo this Friday

by Jean-Christophe Bach

Hello Pharoers, We propose a Pharo sprint / Moose dojo this Friday, 12th June, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come. JC

June 9, 2015

Re: [Pharo-users] NativeBoost pointer and "+"

by Henrik Johansen

> On 08 Jun 2015, at 4:41 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello everyone, > > I have a small question about NativeBoost : How does the "+" operator when applied to a pointer translates into NativeBoost code ? > > To give a bit of context, what I want to do is to reallocate some non-contiguous bytes in memory to a buffer. Basically, I have an array of integers in a buffer and I want to copy some chunks of it in another buffer. The chunks are always the same size and the offset between each chunk is always the same too. > > Because a bit of actual code is easier to understand here is what I'd like to do in Pharo : > > ... > > int i, j; > int *data = malloc(1000*sizeof(int)); > int *newData = malloc(50*sizeof(int)); > > // Allocate initial data > for (i = 0 ; i < 1000, i++) { > data[i] = i; > } > > //Copy desired chunks into new buffer > for (i = 0; i < 5; i++ ) { > memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int)); > j++; > } > > free(data); You can do relative addressing like this: (destReg ptr: dataSize) + offsetReg + constant So with offSetRegs containing j* 10 and j* 30, you might end up with an unrolled inner loop (barring using any fancier longer-than-int moves) like: 0 to: 9 do: [:constantOffset | asm mov: (destReg ptr: currentPlatform sizeOfInt) + dstOffsetReg + constantOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + srcOffsetReg + constantOffset] If the range of j is constant, you can just as easily unroll the whole thing in a similarly compact fashion, space and sensibilites permitting: 0 to: 4 do: [ :j | 0 to: 9 do: [ :consOffset | asm mov: (destReg ptr: currentPlatform sizeOfInt) + (j* 10) + constOffset with: (srcReg ptr: currentPlatform sizeOfInt) + 200 + (j * 30) + constOffset] Cheers, Henry

June 8, 2015