Re: [Pharo-users] Pharo-users Question about the symbols

2016-04-07 Thread Brad Selfridge 
And symbols are immutable 

Brad 

Sent from my iPad

> On Apr 7, 2016, at 9:41 PM, Markus Stumptner  wrote:
> 
> As a result, internal names (e.g., method names) are usually symbols. Strings 
> are normally used for string manipulation, symbols for unambiguous (but 
> humanly readable!) internal reference (vulgo 'naming').
> 
> Markus
> 
> 
>> On 08/04/16 10:53, Ben Coman wrote:
>> A symbol is like a string, except that all symbols with the same value
>> are in fact the same object; that is, every #hello symbol is the exact
>> same object as every other #hello symbol.
>> 
>> See "identically equal" section here...
>> http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/08%20-%20Chapter%206%20-%20Special%20Symbol.pdf
>> 
>> cheers, ben
>> 
>> On Fri, Apr 8, 2016 at 7:20 AM, Valentin Ryckewaert
>>  wrote:
>>> Hello everyone,
>>> 
>>> i'm learning Pharo and i'm having difficulties to understand the symbols,
>>> what are they? How are they different of the ByteString ? Why are they
>>> usefull ?
>>> Why should I put #string where I can put 'string' ?
>>> 
>>> Thanks in advance for your answer.
>>> Valentin Ryckewaert
> 
>

Re: [Pharo-users] Pharo-users Question about the symbols

2016-04-07 Thread Markus Stumptner 
As a result, internal names (e.g., method names) are usually symbols. 
Strings are normally used for string manipulation, symbols for 
unambiguous (but humanly readable!) internal reference (vulgo 'naming').


Markus


On 08/04/16 10:53, Ben Coman wrote:

A symbol is like a string, except that all symbols with the same value
are in fact the same object; that is, every #hello symbol is the exact
same object as every other #hello symbol.

See "identically equal" section here...
http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/08%20-%20Chapter%206%20-%20Special%20Symbol.pdf

cheers, ben

On Fri, Apr 8, 2016 at 7:20 AM, Valentin Ryckewaert
 wrote:

Hello everyone,

i'm learning Pharo and i'm having difficulties to understand the symbols,
what are they? How are they different of the ByteString ? Why are they
usefull ?
Why should I put #string where I can put 'string' ?

Thanks in advance for your answer.
Valentin Ryckewaert

Re: [Pharo-users] Pharo-users Question about the symbols

2016-04-07 Thread Ben Coman 
A symbol is like a string, except that all symbols with the same value
are in fact the same object; that is, every #hello symbol is the exact
same object as every other #hello symbol.

See "identically equal" section here...
http://sdmeta.gforge.inria.fr/FreeBooks/ByExample/08%20-%20Chapter%206%20-%20Special%20Symbol.pdf

cheers, ben

On Fri, Apr 8, 2016 at 7:20 AM, Valentin Ryckewaert
 wrote:
> Hello everyone,
>
> i'm learning Pharo and i'm having difficulties to understand the symbols,
> what are they? How are they different of the ByteString ? Why are they
> usefull ?
> Why should I put #string where I can put 'string' ?
>
> Thanks in advance for your answer.
> Valentin Ryckewaert

[Pharo-users] Pharo-users Question about the symbols

2016-04-07 Thread Valentin Ryckewaert 
Hello everyone,

i'm learning Pharo and i'm having difficulties to understand the symbols,
what are they? How are they different of the ByteString ? Why are they
usefull ?
Why should I put #string where I can put 'string' ?

Thanks in advance for your answer.
Valentin Ryckewaert

Re: [Pharo-users] FFI return by reference

2016-04-07 Thread Damien Pollet 
I think in that case you need to pass an instance of FFIExternalValueHolder.

On 7 April 2016 at 17:42, Thibault Raffaillac 
wrote:

> Hi again,
>
> Does anyone know what is the state of return by reference in FFI?
> Example:
> glGetAttribute: attr into: value
>  errorCode>
> ^ self nbCall: #( int SDL_GL_GetAttribute(SDL_GLattr attr, int
> *value) )
>
> On my image (50666) it does nothing on value yet (if nil, remains nil, if
> SmallInteger 0, remains 0).
> (SDL2 glGetAttribute: 6 into: value) should return 16.
> I've seen NBOpenGL put "out" before value in method header, should it
> matter? (does not make it work though)
> Last but not least, should we attach '*' to the type or variable for FFI
> to understand it is a pointer?
>
> Cheers,
> Thibault Raffaillac
>
>

[Pharo-users] Passing nil with FFI

2016-04-07 Thread Thibault Raffaillac 
Hi,

I am having trouble passing nil to a function with FFI (i.e. NULL, i.e. 0).
For example: SDL2 glCreateContext: nil.
The function expects a subclass of FFIExternalObject, so calls instVarAt: 1 but 
nil has no such field!
Am I missing something? (like a special nil instance of FFIExternalObject)
Note however that putting nil works when FFI expects a String.

Cheers,
Thibault Raffaillac

Re: [Pharo-users] Installation on Ubuntu 15.10 (64 bits)

2016-04-07 Thread Stephan Eggermont 

On 07-04-16 11:34, Marion Noirbent wrote:

Hi,

I have installed Pharo on Ubuntu 15.10 (64 bits) with help of another
user who ask me to report the troubles we have encountered.

Thank you for the feedback.

Stephan

[Pharo-users] Installation on Ubuntu 15.10 (64 bits)

2016-04-07 Thread Marion Noirbent 
Hi,

I have installed Pharo on Ubuntu 15.10 (64 bits) with help of another
user who ask me to report the troubles we have encountered.

By following the instruction on the page
http://pharo.org/gnu-linux-installation (and make "sudo apt-get install
pharo-vm-core" then "sudo apt-get install pharo-launcher"), the file
vm-display-X11 was missing.

Then we have try "sudo apt-get install pharo-desktop pharo-launcher", we
got the VM but without "PharoV40.sources", it was from 1 to 3 only.

So we have donwload it from sources and fix it manually
"
wget -O- get.pharo.org/50+vm | bash
sudo cp ~/pharo/pharo-vm/PharoV40.sources ../../share/pharo-vm/
sudo ln -s ../../share/pharo-vm/PharoV40.sources
"

Cordially,

Marion Noirbent

Re: [Pharo-users] [ANN] Pomodoro 1.6 for Pharo 5 + video

2016-04-07 Thread Stephan Eggermont 

On 07-04-16 00:53, Torsten Bergmann wrote:

I did a new pass on the Pomodoro timer for Pharo 5:

Nice.

Stephan

Re: [Pharo-users] flags in pharo

2016-04-07 Thread Damien Cassou 
"p...@highoctane.be"  writes:

> Bah, we have MetaLinks now, what's so scary about MethodWrappers?

I know what Thibault is trying to achieve, and there is no reason to use
anything like that :-). I can't say more because I want him to find by
himself the simplest solution (and it does not involve metaprogramming).

-- 
Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill