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

[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 :

>
> > On 08 Jun 2015, at 4:41 , Matthieu Lacaton 
> 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
>

[Pharo-users] Fuel and graph update

[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

Re: [Pharo-users] Fuel and graph update

[Mariano Martinez Peck]

On Tue, Jun 9, 2015 at 9:21 AM, Hilaire  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

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

[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

"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  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  >:
> 
> > On 08 Jun 2015, at 4:41 , Matthieu Lacaton  > > 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:

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

[Henrik Johansen]

> On 09 Jun 2015, at 2:59 , Henrik Johansen  
> 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

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

[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.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[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 
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.

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

[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

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

[Jigyasa Grover]

Thanks HilaireFernandes 
But am afraid it gives the error " Message Not Understood: receiver of
'hand' is nil " .




--
View this message in context: 
http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831121p4831231.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Pharo on bitnami

[Esteban Lorenzano]

Hi,

Can we edit that? Because I do not thing thats a good description on how to 
install/use Seaside…at least  in Pharo (and no idea in GNUSmalltalk but since 
that blog post is from 2008 I bet it has changed a lot… if maintained at all).
This is how you install Seaside in a linux/mac/windows(as far as it has mingw 
installed) server: 

wget -O- get.pharo.org  | bash
./pharo Pharo.image config 
http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main 
ConfigurationOfSeaside3 --install=#stable

and this is how you run it:

./pharo Pharo.image eval "ZnZincServerAdaptor startOn: 8080” 

btw… I would like to add a command line handler for seaside to do this in a 
much better way… maybe soon(™) ;)

Esteban

> On 08 Jun 2015, at 16:42, Mircea S.  wrote:
> 
> Great!!! Contacted them myself too, with a contest entry for either Pharo 
> stand-alone or Seaside on Pharo, since the contest mainly focuses on 'web 
> frameworks'.
> 
> For vanilla Pharo this was their response:
> 
> "Thanks for your suggestion. Unfortunately we can not add Pharo in our 
> Bitnami contest. We are currently focused on web applications and Pharo is a 
> desktop IDE tool."
> 
> So I added an entry on Seaside, which he has yet to reply to, adding examples 
> on how to run headless cloud servers with that in mind:
> 
> "I made another request for "Seaside" which is a Smalltalk (language) web 
> framework that runs either on Pharo, GNU Smaltalk or other variants running 
> headless, connecting remotely to add code or modify the app. 
> 
> For example a GNU Smalltalk:
> 
> http://www.gnu.org/software/smalltalk/manual/html_node/Seaside.html 
> 
> 
> Seaside apps, including the entire memory footprint is stored in an "image 
> file", this image files acts like a miniVM virtual hard drive. When you save 
> all objects are saved as the are, and when you load it again it essentially 
> "resumes" exacly where it left off.
> 
> Images are started this way and the app becomes available on a port, you can 
> connect to it and "develop" de image and remotely write code and execute it 
> inside like this:
> 
> http://smalltalk.gnu.org/blog/bonzinip/seaside-development-gnu-smalltalk 
> 
> 
> Seaside is used mainly in the financial industry and for heavy duty erp apps. 
> Now it has gained a footprint in the community because of the advanced Object 
> Oriented approach to web development with Seaside."
> 
> He'll probably need more advice as things progress. You can reach David at 
> da...@bitnami.com 
> 
> Pe 7 iun. 2015, la 14:08, stepharo  > a scris:
> 
>> Hi pharoers
>> 
>> we got in contact with bitnami and I would love to see two bitnami apps 
>> around Pharo:
>>   - basic pharo
>>   - pharo + seaside + magritte + voyage (mongo pharo layer) + mongodb
>> 
>> So who would like to help pushing this effort?
>> 
>> Stef
>> 
>> Begin forwarded message:
>> 
>> From: Kevin Franklin mailto:ke...@bitnami.com>>
>> Subject: Introducing Bitnami...
>> Date: 5 Jun 2015 10:57:36 GMT+2
>> To: mailto:bo...@pharo.org>>
>> 
>> Hello Pharo Association
>> 
>> I wondered if you knew about Bitnami. Please check us out at www.bitnami.com 
>> . We provide over 120 apps and development stacks – 
>> many of them open-source.
>> If you would like Pharo to be included in our marketplace, we have a contest 
>> https://bitnami.com/contest  were you can 
>> nominate it, and encourage your community to vote for its inclusion.
>> 
>> Also, I wondered if you could put me in touch with any commercial companies 
>> within and around the Pharo ecosystem that might like to work with us as a 
>> software partner https://bitnami.com/partners/software 
>> 
>> 
>> Kind regards
>> Kevin
>> 
>> -- 
>> Kevin Franklin
>> Director of Business Development, Bitnami
>> +44 78 2525 6020
>> @kevinjfranklin
>> 
>> Run your favorite apps in the cloud with Bitnami
>> 
>> Confidential - All Rights Reserved.
>> Bitnami © 2015
>> 

Re: [Pharo-users] Mac Squeak binary virtual machine for Squeak 3.10.2

[stepharo]

I'm sorry to say that Pharo public API does not change that much.
We could port all Moose in one afternoon and Moose is certainly more 
complex :).


Stef


Le 9/6/15 18:07, Trygve Reenskaug a écrit :

Hi Chris,
I'm sorry to say that your advice didn't work. Worse: The Squeak 
community has lost a valuable contributor, a prime mover in the 
patterns and agile communities and the author of several books on OO. 
My friend wrote:
" /I still can’t find a version of Squeak for my Mac that will run 
Trygve’s current BabyIDE. At this point, even if one appears, it is 
obvious that my dependence on “the introvert Squeak community” will 
put me in a much more fragile position than with any of my other 
concept proofs. It will be extremely difficult to build a future on 
such fragile foundations./"


I came to Xerox PARC and Smalltalk in 1978 where I made my 
contributions to Smalltalk-80. Since then, I have been working almost 
exclusively with Smalltalk. My company invested in a VW class library 
of more than 100,000 lines of Smalltalk code and used it in our 
consulting. A strong selling point was that our tenders were 
accompanied by a demo version of the program we offered to deliver. 
Our library and applications were repeatedly threatened by new 
versions of VW. The code is now dead; there is no VM that will run our 
old images. The investment is lost.


I hoped Squeak would be better. It isn't. Squeak is less stable than 
VW ever was. My new programming paradigm, DCI, is supported by BabyIDE 
that runs under Squeak 3.10. I have ported BabyIDE to 4.5, but there 
are new bugs caused by differences between 3.10 and 4.5. The result is 
that I have reverted to 3.10 because it's too much hassle to run after 
the stream of Squeak releases. I thought Pharo would be better, but 
their mailing list conversations indicate that they do not understand 
that developers need a stable foundation for their work.


The result is that I too leave Smalltalk and concentrate on other 
environments. A pity, because I still believe Smalltalk has the 
potential to become a superior environment for non-professional 
programmers. I am particularly thinking of children and experts such 
as computational chemists who use computers in their work.


It's very painful, but I am now terminating development work in Squeak 
leave the Squeak and Pharo mailing lists. I will continue my work in  
some mainstream language. I have just done some work in Java with 
Netbeans and I am buying a book on JavaScript. It's heavy going, but 
better that working for the dustbin.


Cheers
--Trygve


On 31.05.2015 16:52, Trygve Reenskaug  wrote:
Hi,
A friend of mine is doing some experiments using a Mac and my program 
Baby IDE.  BabyIDE is works under Squeak 3.10.2. Is there a binary 
virtual machine for a current Mac that he can use?


On 31.05.2015 17:00, Chris Cunnington wrote:

You need a non-Cog vm. I usually download any Etoys vm. [1]
From there, drag it onto the vm or right click, choose “Open With” 
and choose Etoys.


Chris

[1] http://squeakland.org/download/

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

[stepharo]

Henrik

you amaze me :)

Stef

Le 9/6/15 14:59, Henrik Johansen a écrit :

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

"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 
mailto:matthieu.laca...@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 
mailto:henrik.s.johan...@veloxit.no>>:



> On 08 Jun 2015, at 4:41 , Matthieu Lacaton
mailto:matthieu.laca...@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

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

[Matthieu Lacaton]

*@ Igor*


> 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.


Yes ! Exactly that. I'm bad at explaining things :(


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).
>

Alright, thank you very much for your explanations ! By the way, is there a
way to disable the GC for a short period of time and then re-enable it ?



*@ Henrik*

I am not sure I understand every bit of your code right now but I will
definitely study it because it looks awesome.
Moreover, performance is quite important for me so your solution is very
attractive and I'll try to use it. Thanks a lot !

I find it both fun and amazing what you can do with Pharo. I never thought
I would do assembly inside Pharo !


Again, a big thanks to both of you,

Cheers,
Matthieu




2015-06-09 17:43 GMT+02:00 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 
> 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.
>

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

[Hilaire]

Le 09/06/2015 18:04, Jigyasa Grover a écrit :
> Thanks HilaireFernandes 
> But am afraid it gives the error " Message Not Understood: receiver of
> 'hand' is nil " .
>
>
>
>
> --
> View this message in context: 
> http://forum.world.st/Getting-a-user-input-string-using-Morphs-tp4831121p4831231.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>
I guess you tried with Pharo4.0.
I did with 3.0

-- 
Dr. Geo
http://drgeo.eu
http://google.com/+DrgeoEu

Re: [Pharo-users] Pharo on bitnami

[Mircea S.]

Forwarded your response to da...@bitnami.com



Pe 9 iun. 2015, la 20:15, Esteban Lorenzano  a scris:

> Hi,
> 
> Can we edit that? Because I do not thing thats a good description on how to 
> install/use Seaside…at least  in Pharo (and no idea in GNUSmalltalk but since 
> that blog post is from 2008 I bet it has changed a lot… if maintained at all).
> This is how you install Seaside in a linux/mac/windows(as far as it has mingw 
> installed) server: 
> 
> wget -O- get.pharo.org | bash
> ./pharo Pharo.image config 
> http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo40/main 
> ConfigurationOfSeaside3 --install=#stable
> 
> and this is how you run it:
> 
> ./pharo Pharo.image eval "ZnZincServerAdaptor startOn: 8080” 
> 
> btw… I would like to add a command line handler for seaside to do this in a 
> much better way… maybe soon(™) ;)
> 
> Esteban
> 
>> On 08 Jun 2015, at 16:42, Mircea S.  wrote:
>> 
>> Great!!! Contacted them myself too, with a contest entry for either Pharo 
>> stand-alone or Seaside on Pharo, since the contest mainly focuses on 'web 
>> frameworks'.
>> 
>> For vanilla Pharo this was their response:
>> 
>> "Thanks for your suggestion. Unfortunately we can not add Pharo in our 
>> Bitnami contest. We are currently focused on web applications and Pharo is a 
>> desktop IDE tool."
>> 
>> So I added an entry on Seaside, which he has yet to reply to, adding 
>> examples on how to run headless cloud servers with that in mind:
>> 
>> "I made another request for "Seaside" which is a Smalltalk (language) web 
>> framework that runs either on Pharo, GNU Smaltalk or other variants running 
>> headless, connecting remotely to add code or modify the app. 
>> 
>> For example a GNU Smalltalk:
>> 
>> http://www.gnu.org/software/smalltalk/manual/html_node/Seaside.html
>> 
>> Seaside apps, including the entire memory footprint is stored in an "image 
>> file", this image files acts like a miniVM virtual hard drive. When you save 
>> all objects are saved as the are, and when you load it again it essentially 
>> "resumes" exacly where it left off.
>> 
>> Images are started this way and the app becomes available on a port, you can 
>> connect to it and "develop" de image and remotely write code and execute it 
>> inside like this:
>> 
>> http://smalltalk.gnu.org/blog/bonzinip/seaside-development-gnu-smalltalk
>> 
>> Seaside is used mainly in the financial industry and for heavy duty erp 
>> apps. Now it has gained a footprint in the community because of the advanced 
>> Object Oriented approach to web development with Seaside."
>> 
>> He'll probably need more advice as things progress. You can reach David at 
>> da...@bitnami.com
>> 
>> Pe 7 iun. 2015, la 14:08, stepharo  a scris:
>> 
>>> Hi pharoers
>>> 
>>> we got in contact with bitnami and I would love to see two bitnami apps 
>>> around Pharo:
>>>   - basic pharo
>>>   - pharo + seaside + magritte + voyage (mongo pharo layer) + mongodb
>>> 
>>> So who would like to help pushing this effort?
>>> 
>>> Stef
>>> 
>>> Begin forwarded message:
>>> 
>>> From: Kevin Franklin 
>>> Subject: Introducing Bitnami...
>>> Date: 5 Jun 2015 10:57:36 GMT+2
>>> To: 
>>> 
>>> Hello Pharo Association
>>> 
>>> I wondered if you knew about Bitnami. Please check us out at 
>>> www.bitnami.com. We provide over 120 apps and development stacks – many of 
>>> them open-source.
>>> If you would like Pharo to be included in our marketplace, we have a 
>>> contest https://bitnami.com/contest were you can nominate it, and encourage 
>>> your community to vote for its inclusion.
>>> 
>>> Also, I wondered if you could put me in touch with any commercial companies 
>>> within and around the Pharo ecosystem that might like to work with us as a 
>>> software partner https://bitnami.com/partners/software
>>> 
>>> Kind regards
>>> Kevin
>>> 
>>> -- 
>>> Kevin Franklin
>>> Director of Business Development, Bitnami
>>> +44 78 2525 6020
>>> @kevinjfranklin
>>> 
>>> Run your favorite apps in the cloud with Bitnami
>>> 
>>> Confidential - All Rights Reserved.
>>> Bitnami © 2015
> 

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

[Igor Stasenko]

On 9 June 2015 at 20:05, Matthieu Lacaton 
wrote:

> *@ Igor*
>
>
>> 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.
>
>
> Yes ! Exactly that. I'm bad at explaining things :(
>
> me too, sometimes. :)


>
> 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).
>>
>
> Alright, thank you very much for your explanations ! By the way, is there
> a way to disable the GC for a short period of time and then re-enable it ?
>
> Well, some aspects of GC behavior can be controlled, but they serve rather
for fine tuning or picking the strategy ahead of time, knowing, what
application is going to run. So, at application level, you can use them..
but not at the level of library/framework (like in case of NB), because
there's no way to determine what/where will be used, and so, fiddling with
GC is worst possible way to solve the problem :)

Also, in general, it would be a bad practice to rely on subtle and fuzzy
details of GC triggering logic, because it is one of the most sophisticated
parts of VM and subject of future changes.

So, instead relying on implementation details, a new contract between VM
and language side is introduced and it called 'object pinning'. So, that
pinned objects are no longer a subject of relocation in memory. It means
that you will be able to control, that chosen object(s) will be not
relocated in memory, regardless how often VM triggers GC and what is
involved.
And that comes with Spur.


>
> *@ Henrik*
>
> I am not sure I understand every bit of your code right now but I will
> definitely study it because it looks awesome.
> Moreover, performance is quite important for me so your solution is very
> attractive and I'll try to use it. Thanks a lot !
>
> I find it both fun and amazing what you can do with Pharo. I never thought
> I would do assembly inside Pharo !
>
>
> Again, a big thanks to both of you,
>
> Cheers,
> Matthieu
>
>
>
>
> 2015-06-09 17:43 GMT+02:00 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 
>> 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 

[Pharo-users] Using GTSpotter how do I find an implementor of #accept ?

[Paul DeBruicker]

when I hit shift+enter and type 'accept' I get things that are not #accept, 
e.g. #accept: and AbstractAcceptor.

If I add a space after accept it doesn't help.  


What do I not understand?  


Thanks


Paul