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

[Stephan Eggermont]

On 09-06-15 20:10, Hilaire wrote:

I guess you tried with Pharo4.0.
I did with 3.0


It is a difference between Workspace and GTPlayground.
In GTPlayground, ActiveEvent is nil, so it doesn't work.
In Workspace it works.

launchMiniEditor: evt

| textMorph |
hasFocus := true.  "Really only means edit in progress for this morph"
textMorph := StringMorphEditor new contentsAsIs: contents.
textMorph beAllFont: self fontToUse.
textMorph bounds: (self bounds expandBy: 0@2).
self addMorphFront: textMorph.
evt hand newKeyboardFocus: textMorph.
textMorph editor selectFrom: 1 to: textMorph paragraph text string size

replace evt hand by ActiveHand to make it work in GTPlayground.

Stephan

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

[Trygve Reenskaug]

I rest my case.
--Trygve

On 10.06.2015 20:57, Serge Stinckwich wrote:

If I remember correctly, it was easy to port Moose from VW to Pharo,
because there was a lot of tests.
I'm currently working on porting another software from VW to Pharo
without any tests and I'm suffering;-)

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

[Cyril Ferlicot]

If you want to open a workspace or a playground we should use:

viewContentsInWorkspace
"View the contents of my selected file in a new workspace"

| aString |
self reference streamWritable: false do: [ :stream | aString :=
stream setConverterForCode contentsOfEntireFile ].
Smalltalk tools workspace openContents: aString label: 'Workspace
from ' , self reference basename

BUT!
If we open a file which is not a Smalltalk code the syntax coloring is
really a bad idea.
Someone know if we can desable the syntax coloring for an instance of
the playground or workspace ?

If we can't we should change the name on the menu and not the action
of the menu.
Thank.

On 6 June 2015 at 16:37, volkert  wrote:
> Is this change resonable. I have no idea, what the Design-Idea behind the
> UIManager what services is should provide. May be it make sense to have the
> extra services on UIManager, but think the bug is in
> FileList>>viewContentsInWorkspace and not in UIManager.
>
> 
> I propose for Workspace to change the current code:
>
> FileList>>viewContentsInWorkspace
> "View the contents of my selected file in a new workspace"
> | aString |
> self reference streamWritable: false do: [ :stream|
> aString := stream setConverterForCode contentsOfEntireFile ].
> UIManager default edit: aString label: 'Workspace from ', self reference
> basename  <- WRONG
>
> to :
>
> FileList>>viewContentsInWorkspace
> "View the contents of my selected file in a new workspace"
> | aString |
> self reference streamWritable: false do: [ :stream|
> aString := stream setConverterForCode contentsOfEntireFile ].
> Workspace openContents: aString label: 'Workspace from ', self reference
> basename
>
> And i also proposse the add a Playground case.
>
> New Method:
>
> FileList>>viewContentsInPlayground
> "View the contents of my selected file in a new playground"
> | aString |
> self reference streamWritable: false do: [ :stream|
> aString := stream setConverterForCode contentsOfEntireFile ].
> GTPlayground openContents: aString label: 'Playground from ', self
> reference basename.
>
> and also FileList>>serviceViewContentsInPlayground and the case in
> ListList>>itemsForAnyFile.
>
> If ok, i can fix Workspace and add Playground menu to FileList, after i have
> figured out how to send an fix ;-)
>
> BW,
> Volkert
>
>
> Am 03.06.2015 um 16:40 schrieb Ben Coman:
>
> Or do we now want such to open in Playground?
>
> btw, these are the relevant methods.
> FileList>>FileList>>viewContentsInWorkspace
> FileList>>viewContentsInWorkspace
>
> cheers -ben
>
> On Wed, Jun 3, 2015 at 6:57 PM, volkert 
> wrote:
>
> The File Browser has a Context Menu "Workspace with Contents". It opens an
> Edit Window (String Morph), but not a Workspace ...
>
> Is the Menu-Title wrong or the implementation?
>
> BW,
> Volkert
>
>



-- 
Cheers
Cyril Ferlicot

Re: [Pharo-users] ZnClient and percent characters

[PBKResearch]

Norbert

 

Some comments on your latest post below.

 

I just wrote because you told Jimmie to alter a method of a third-party 
library. And that is a no-go.

 

Zinc, like almost all of Pharo, is MIT licenced, “including without limitation 
the rights to use, copy, modify, merge, publish…” Once the code is on my 
machine, I am entitled to alter it for my own use in any way I see fit; so is 
Jimmie. It is clear from Sven’s comments that not encoding commas is a design 
decision, and a departure from earlier Zinc working. Sven himself says “ maybe 
we made a mistake, maybe not.” I am entitled to disagree with that decision, 
and to act on that disagreement; so is Jimmie. I just told him how to do it 
quickly and safely.

 

The way to change it and have Sven it commited is doable. 

 

Obviously it would be ideal if Sven made a change which allowed encoding of 
commas. However, that does not seem likely to happen any time soon. Meanwhile, 
Jimmie was stuck with a program which would not carry out a function that 
should be quite normal.

 

As is my proposal that you can change the code in a reliable way without 
changing a third-party library. That's all I wanted to say. 

 

No doubt your subclassing approach would work, though not as easily as you 
imply. The method that encodes the key-value pairs of a query is not 
#encodeQuery:on:, it is #printQueryOn: (see ZnUrl>>#printPathQueryFragmentOn:); 
changing that would involve having variant versions of 
ZnResourceMetaUtils>>#writeQueryFields:on: and 
>>writeQueryFields:withEncoder:on:, as well as a new safe list.

 

And yes I think it applies to monkey patching. Choosing weaker terms just to 
avoid problems is not the way to go IMHO.

 

I was not asking for a weaker term, I was asking for a less offensive one. I 
think this term is offensive in all contexts, and should not be used. Henry’s 
comment implies that it is widely used, and everyone knows what it means. In my 
youth, 60-70 years ago, the n-word was widely used to refer to people of 
African origin, and everyone knew what it meant. Now, thank goodness, we see 
how offensive it was. To me, this expression is equally offensive. You used it, 
in a derogatory sense, to criticise what I had done in helping Jimmie. Frankly, 
I do not think you were sincere in saying “No offense meant.”

 

I had thought of just ignoring your comment, thinking that we will have to 
agree to differ. However, your reiteration of the m-word has got me 
sufficiently riled to make another protest. I may be a lone voice here, but 
that does not make my views any less valid.

 

Peter Kenny

 

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Norbert Hartl
Sent: 11 June 2015 17:07
To: Pharo users users
Subject: Re: [Pharo-users] ZnClient and percent characters

 

 

Am 11.06.2015 um 16:51 schrieb PBKResearch mailto:pe...@pbkresearch.co.uk> >:

 

Norbert

 

Apology accepted – I had never heard this term before. However, having read the 
Wikipedia article Henry mentioned, I do not think it applies to what I had 
done. If Sven accepts the argument that commas should always be encoded in 
query lines – and I can see a strong argument for that from what I have read – 
then the change I made is just what he will need to do. I simply anticipated 
the decision. If it goes the other way, then it was just a hack to solve 
Jimmie’s problem – but it might be better to say ‘hack’ rather than use a term 
which is potentially offensive.

 

I just wrote because you told Jimmie to alter a method of a third-party 
library. And that is a no-go. The way to change it and have Sven it commited is 
doable. As is my proposal that you can change the code in a reliable way 
without changing a third-party library. That's all I wanted to say. And yes I 
think it applies to monkey patching. Choosing weaker terms just to avoid 
problems is not the way to go IMHO. 





I also note Jimmie’s argument that, as long as there are some sites which 
insist on encoded commas, it must be possible to generate such lines if Zinc is 
to be generally useful. Whether this should be a user-controlled option, as 
Sven seems to suggest, is open to discussion – but if so I would argue for 
encoding of commas as the safe default, which can be overridden if necessary.

 

Sure. Zinc should behave correctly and it should provide functionalities to 
make it "less correct". And these functionalities shouldn't be too easy to use 
;)

 

Norbert





Peter Kenny

 

From: Pharo-users [  
mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of Norbert Hartl
Sent: 11 June 2015 11:25
To: Pharo users users
Subject: Re: [Pharo-users] ZnClient and percent characters

 

No offense meant. I assumed you would know the term. Sorry! Henry explained it 
quite good what I meant.

 

Norbert

 

Am 11.06.2015 um 09:51 schrieb PBKResearch <  
pe...@pbkresearch.co.uk>:

 

I don’t q

Re: [Pharo-users] ZnClient and percent characters

[Norbert Hartl]

> Am 12.06.2015 um 12:03 schrieb PBKResearch :
> 
> Norbert
>  
> Some comments on your latest post below.
>  
> I just wrote because you told Jimmie to alter a method of a third-party 
> library. And that is a no-go.
>  
> Zinc, like almost all of Pharo, is MIT licenced, “including without 
> limitation the rights to use, copy, modify, merge, publish…” Once the code is 
> on my machine, I am entitled to alter it for my own use in any way I see fit; 
> so is Jimmie. It is clear from Sven’s comments that not encoding commas is a 
> design decision, and a departure from earlier Zinc working. Sven himself says 
> “ maybe we made a mistake, maybe not.” I am entitled to disagree with that 
> decision, and to act on that disagreement; so is Jimmie. I just told him how 
> to do it quickly and safely.
>  
So, the misunderstanding is because we seem to have different views on the 
topic. I have always projects in mind that are built together by a build system 
and they produce something deployable. Your proposal doesn't fit in this view 
for me. If you alter a third-party function you need to make that a repeatable 
task which is having an expression to patch the third-party library again if 
you build the project again. 

> The way to change it and have Sven it commited is doable. 
>  
> Obviously it would be ideal if Sven made a change which allowed encoding of 
> commas. However, that does not seem likely to happen any time soon. 
> Meanwhile, Jimmie was stuck with a program which would not carry out a 
> function that should be quite normal.
>  
> As is my proposal that you can change the code in a reliable way without 
> changing a third-party library. That's all I wanted to say. 
>  
> No doubt your subclassing approach would work, though not as easily as you 
> imply. The method that encodes the key-value pairs of a query is not 
> #encodeQuery:on:, it is #printQueryOn: (see 
> ZnUrl>>#printPathQueryFragmentOn:); changing that would involve having 
> variant versions of ZnResourceMetaUtils>>#writeQueryFields:on: and 
> >>writeQueryFields:withEncoder:on:, as well as a new safe list.

Yes, but it is still the thing you can do immediately without having to patch 
code that is not under your control. That's my whole point. I wouldn't consider 
my approach good or even nice. 
>  
> And yes I think it applies to monkey patching. Choosing weaker terms just to 
> avoid problems is not the way to go IMHO.
>  
> I was not asking for a weaker term, I was asking for a less offensive one. I 
> think this term is offensive in all contexts, and should not be used. Henry’s 
> comment implies that it is widely used, and everyone knows what it means. In 
> my youth, 60-70 years ago, the n-word was widely used to refer to people of 
> African origin, and everyone knew what it meant. Now, thank goodness, we see 
> how offensive it was. To me, this expression is equally offensive. You used 
> it, in a derogatory sense, to criticise what I had done in helping Jimmie. 
> Frankly, I do not think you were sincere in saying “No offense meant.”
>  
I like the term monkey patching because it is as funny as it might be 
offensive. The rest I don't want to comment because I could easily be offended 
by your paragraph above…if I only had those kinds of sensitivities. And btw. 
don't hide behind something like not using a certain word. You can still be a 
racist without using the n-word. What is needed is to change attitude not 
words. 

> I had thought of just ignoring your comment, thinking that we will have to 
> agree to differ. However, your reiteration of the m-word has got me 
> sufficiently riled to make another protest. I may be a lone voice here, but 
> that does not make my views any less valid.

dito.

Let's close this case. To me it is a little misunderstanding that took the 
wrong route.

Norbert

>  
> Peter Kenny
>  
>  
> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
> Norbert Hartl
> Sent: 11 June 2015 17:07
> To: Pharo users users
> Subject: Re: [Pharo-users] ZnClient and percent characters
>  
>  
>> Am 11.06.2015 um 16:51 schrieb PBKResearch > >:
>>  
>> Norbert
>>  
>> Apology accepted – I had never heard this term before. However, having read 
>> the Wikipedia article Henry mentioned, I do not think it applies to what I 
>> had done. If Sven accepts the argument that commas should always be encoded 
>> in query lines – and I can see a strong argument for that from what I have 
>> read – then the change I made is just what he will need to do. I simply 
>> anticipated the decision. If it goes the other way, then it was just a hack 
>> to solve Jimmie’s problem – but it might be better to say ‘hack’ rather than 
>> use a term which is potentially offensive.
>>  
> I just wrote because you told Jimmie to alter a method of a third-party 
> library. And that is a no-go. The way to change it and have Sven it commited 
> is doable. As is my proposal that you can

[Pharo-users] Copy array of float to GPU memory

[cheikhou]

Hello.

I use OpenCL package developed by Ronie Salgado package to program on GPU.
When I initialize an array with ByteArray class and load data to GPU memory
it works without any problem. 

But the problem is it works only with ByteArray objects.
When I load array of floats to GPU , data are modify and I don't know how
and why and results are wrong.

Please someone have any idea 
First: how to load integer values upper than 255 (not possible with
ByteArray)
Second: use float arrays correctly in GPU memory.

Thanks for your help.



-
Cheikhou
--
View this message in context: 
http://forum.world.st/Copy-array-of-float-to-GPU-memory-tp4831970.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Use array of float to GPU memory

[cheikhou]

Finally I have found a useful method called "asCLFloatArray" that converts
float arrays of CPU as CL float arrays of GPU. The reverse action is
possible by using "asFloatArrayFromCL".(from GPU to CPU memory)

Thanks. 



-
Cheikhou
--
View this message in context: 
http://forum.world.st/Use-array-of-float-to-GPU-memory-tp4831970p4832088.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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

[Tudor Girba]

If I understand correctly, your case is that it is easier to move from
Squeak to JavaScript than to move from Squeak to Pharo.

I must be missing something important. Could you clarify?

Cheers,
Doru

On Fri, Jun 12, 2015 at 10:12 AM, Trygve Reenskaug 
wrote:

>  I rest my case.
> --Trygve
>
> On 10.06.2015 20:57, Serge Stinckwich wrote:
>
> If I remember correctly, it was easy to port Moose from VW to Pharo,
> because there was a lot of tests.
> I'm currently working on porting another software from VW to Pharo
> without any tests and I'm suffering ;-)
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Bug in Open Workspace from File-Browser?

[Cyril Ferlicot]

Thank you volkert for the correction!

On 12 June 2015 at 11:05, Cyril Ferlicot  wrote:
> If you want to open a workspace or a playground we should use:
>
> viewContentsInWorkspace
> "View the contents of my selected file in a new workspace"
>
> | aString |
> self reference streamWritable: false do: [ :stream | aString :=
> stream setConverterForCode contentsOfEntireFile ].
> Smalltalk tools workspace openContents: aString label: 'Workspace
> from ' , self reference basename
>
> BUT!
> If we open a file which is not a Smalltalk code the syntax coloring is
> really a bad idea.
> Someone know if we can desable the syntax coloring for an instance of
> the playground or workspace ?
>
> If we can't we should change the name on the menu and not the action
> of the menu.
> Thank.
>
> On 6 June 2015 at 16:37, volkert  wrote:
>> Is this change resonable. I have no idea, what the Design-Idea behind the
>> UIManager what services is should provide. May be it make sense to have the
>> extra services on UIManager, but think the bug is in
>> FileList>>viewContentsInWorkspace and not in UIManager.
>>
>> 
>> I propose for Workspace to change the current code:
>>
>> FileList>>viewContentsInWorkspace
>> "View the contents of my selected file in a new workspace"
>> | aString |
>> self reference streamWritable: false do: [ :stream|
>> aString := stream setConverterForCode contentsOfEntireFile ].
>> UIManager default edit: aString label: 'Workspace from ', self reference
>> basename  <- WRONG
>>
>> to :
>>
>> FileList>>viewContentsInWorkspace
>> "View the contents of my selected file in a new workspace"
>> | aString |
>> self reference streamWritable: false do: [ :stream|
>> aString := stream setConverterForCode contentsOfEntireFile ].
>> Workspace openContents: aString label: 'Workspace from ', self reference
>> basename
>>
>> And i also proposse the add a Playground case.
>>
>> New Method:
>>
>> FileList>>viewContentsInPlayground
>> "View the contents of my selected file in a new playground"
>> | aString |
>> self reference streamWritable: false do: [ :stream|
>> aString := stream setConverterForCode contentsOfEntireFile ].
>> GTPlayground openContents: aString label: 'Playground from ', self
>> reference basename.
>>
>> and also FileList>>serviceViewContentsInPlayground and the case in
>> ListList>>itemsForAnyFile.
>>
>> If ok, i can fix Workspace and add Playground menu to FileList, after i have
>> figured out how to send an fix ;-)
>>
>> BW,
>> Volkert
>>
>>
>> Am 03.06.2015 um 16:40 schrieb Ben Coman:
>>
>> Or do we now want such to open in Playground?
>>
>> btw, these are the relevant methods.
>> FileList>>FileList>>viewContentsInWorkspace
>> FileList>>viewContentsInWorkspace
>>
>> cheers -ben
>>
>> On Wed, Jun 3, 2015 at 6:57 PM, volkert 
>> wrote:
>>
>> The File Browser has a Context Menu "Workspace with Contents". It opens an
>> Edit Window (String Morph), but not a Workspace ...
>>
>> Is the Menu-Title wrong or the implementation?
>>
>> BW,
>> Volkert
>>
>>
>
>
>
> --
> Cheers
> Cyril Ferlicot



-- 
Cheers
Cyril Ferlicot

[Pharo-users] HTML Parser w. custom nodes

[Sean P. DeNigris]

Now that we have the cool new Catalog Browser, I see we have at least 4 HTML
parsing options - cool! Do any of these allow one to inject custom node
classes? Kind of like Zincs converter support, but for individual nodes.
When using Soup, I've often thought something like, "gee I wish I could have
told it that a tr with a certain background color was really a
ProjectDescriptionRow!". It seems clunky to have to parse it once, and then
query it again (usually procedurally) to make domain sense of the data, no?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/HTML-Parser-w-custom-nodes-tp4832169.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] ZnClient and percent characters

[PBKResearch]

Norbert

 

I agree. I was angry and went over the top – sorry. Let’s consider it closed.

 

Peter

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Norbert Hartl
Sent: 12 June 2015 12:18
To: Pharo users users
Subject: Re: [Pharo-users] ZnClient and percent characters

 

 

Am 12.06.2015 um 12:03 schrieb PBKResearch mailto:pe...@pbkresearch.co.uk> >:

 

Norbert

 

Some comments on your latest post below.

 

I just wrote because you told Jimmie to alter a method of a third-party 
library. And that is a no-go.

 

Zinc, like almost all of Pharo, is MIT licenced, “including without limitation 
the rights to use, copy, modify, merge, publish…” Once the code is on my 
machine, I am entitled to alter it for my own use in any way I see fit; so is 
Jimmie. It is clear from Sven’s comments that not encoding commas is a design 
decision, and a departure from earlier Zinc working. Sven himself says “ maybe 
we made a mistake, maybe not.” I am entitled to disagree with that decision, 
and to act on that disagreement; so is Jimmie. I just told him how to do it 
quickly and safely.

 

So, the misunderstanding is because we seem to have different views on the 
topic. I have always projects in mind that are built together by a build system 
and they produce something deployable. Your proposal doesn't fit in this view 
for me. If you alter a third-party function you need to make that a repeatable 
task which is having an expression to patch the third-party library again if 
you build the project again. 





The way to change it and have Sven it commited is doable. 

 

Obviously it would be ideal if Sven made a change which allowed encoding of 
commas. However, that does not seem likely to happen any time soon. Meanwhile, 
Jimmie was stuck with a program which would not carry out a function that 
should be quite normal.

 

As is my proposal that you can change the code in a reliable way without 
changing a third-party library. That's all I wanted to say. 

 

No doubt your subclassing approach would work, though not as easily as you 
imply. The method that encodes the key-value pairs of a query is not 
#encodeQuery:on:, it is #printQueryOn: (see ZnUrl>>#printPathQueryFragmentOn:); 
changing that would involve having variant versions of 
ZnResourceMetaUtils>>#writeQueryFields:on: and 
>>writeQueryFields:withEncoder:on:, as well as a new safe list.

 

Yes, but it is still the thing you can do immediately without having to patch 
code that is not under your control. That's my whole point. I wouldn't consider 
my approach good or even nice. 



 

And yes I think it applies to monkey patching. Choosing weaker terms just to 
avoid problems is not the way to go IMHO.

 

I was not asking for a weaker term, I was asking for a less offensive one. I 
think this term is offensive in all contexts, and should not be used. Henry’s 
comment implies that it is widely used, and everyone knows what it means. In my 
youth, 60-70 years ago, the n-word was widely used to refer to people of 
African origin, and everyone knew what it meant. Now, thank goodness, we see 
how offensive it was. To me, this expression is equally offensive. You used it, 
in a derogatory sense, to criticise what I had done in helping Jimmie. Frankly, 
I do not think you were sincere in saying “No offense meant.”

 

I like the term monkey patching because it is as funny as it might be 
offensive. The rest I don't want to comment because I could easily be offended 
by your paragraph above…if I only had those kinds of sensitivities. And btw. 
don't hide behind something like not using a certain word. You can still be a 
racist without using the n-word. What is needed is to change attitude not 
words. 





I had thought of just ignoring your comment, thinking that we will have to 
agree to differ. However, your reiteration of the m-word has got me 
sufficiently riled to make another protest. I may be a lone voice here, but 
that does not make my views any less valid.

 

dito.

 

Let's close this case. To me it is a little misunderstanding that took the 
wrong route.

 

Norbert

 

 

Peter Kenny

 

 

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Norbert Hartl
Sent: 11 June 2015 17:07
To: Pharo users users
Subject: Re: [Pharo-users] ZnClient and percent characters

 

 

Am 11.06.2015 um 16:51 schrieb PBKResearch <  
pe...@pbkresearch.co.uk>:

 

Norbert

 

Apology accepted – I had never heard this term before. However, having read the 
Wikipedia article Henry mentioned, I do not think it applies to what I had 
done. If Sven accepts the argument that commas should always be encoded in 
query lines – and I can see a strong argument for that from what I have read – 
then the change I made is just what he will need to do. I simply anticipated 
the decision. If it goes the other way, then it was just a hack to solve 
Jimmie’s problem – but it might be better to say ‘h

Re: [Pharo-users] Use array of float to GPU memory

[Ben Coman]

On Fri, Jun 12, 2015 at 10:38 PM, cheikhou  wrote:
>
> Finally I have found a useful method called "asCLFloatArray" that converts
> float arrays of CPU as CL float arrays of GPU. The reverse action is
> possible by using "asFloatArrayFromCL".(from GPU to CPU memory)

sounds interesting, but what is the context of this?  Is this built
into Pharo, what version?  Or what library?
cheers -ben

Re: [Pharo-users] Copy array of float to GPU memory

[Ronie Salgado]

Hi Cheikhou,

Sorry for the late answering. I needed to check some stuffs.

But the problem is it works only with ByteArray objects.
> When I load array of floats to GPU , data are modify and I don't know how
> and why and results are wrong.


What kind of error are you getting? a NativeBoost error or incorrect
results?

Since you were originally asking me about FloatArray or IntegerArray, I am
assuming you are getting incorrect results or a segmentation fault.

The OpenCL package is just a binding with a bit of object orientation to
the OpenCL C library that I wrote manually. Those binding don't try to do a
lot of magic when receiving a Pharo object. The OpenCL C API when
allocating a GPU side buffer is expecting a size in bytes. According to the
class comment in IntegerArray and in FloatArray, they are composed of 32
bits elements. So, when passing their size to OpenCL, you have to multiply
them by 4.

For an actual example, check the new tests that I just added to the
OpenCL-Tests packages. I tried using IntegerArray and FloatArray, and it
did work.

It seems that you found the asCLFloatArray and the asFloatArrayFromCL
methods, that are used to convert from an Array into a ByteArray and
backwards. For completeness, I just added the following new methods.

asCLInt16Array <-> asInt16ArrayFromCL
asCLInt32Array <-> asInt32ArrayFromCL
asCLInt64Array <-> asInt64ArrayFromCL
asCLUInt16Array <-> asUInt16ArrayFromCL
asCLUInt32Array <-> asUInt32ArrayFromCL
asCLUInt64Array <-> asUInt64ArrayFromCL
asCLDoubleArray <-> asDoubleArrayFromCL

Unlike passing an IntegerArray or a FloatArray, these are method are
creating a new array, looping over all elements and doing
marshalling/unmarshalling. These methods can be very inefficient. Be
careful when using them.

Best regards,
Ronie Salgado

2015-06-12 8:09 GMT-03:00 cheikhou :

> Hello.
>
> I use OpenCL package developed by Ronie Salgado package to program on GPU.
> When I initialize an array with ByteArray class and load data to GPU memory
> it works without any problem.
>
> But the problem is it works only with ByteArray objects.
> When I load array of floats to GPU , data are modify and I don't know how
> and why and results are wrong.
>
> Please someone have any idea
> First: how to load integer values upper than 255 (not possible with
> ByteArray)
> Second: use float arrays correctly in GPU memory.
>
> Thanks for your help.
>
>
>
> -
> Cheikhou
> --
> View this message in context:
> http://forum.world.st/Copy-array-of-float-to-GPU-memory-tp4831970.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>