NAtiveBoost error

On 07 Nov 2014, at 16:51, Kjell Godo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;squeaklist@gmail.com&#39;);" target="_blank">squeaklist@...> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Tuesday, November 4, 2014, Alain Rastoul <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;alf.mmm.cat@gmail.com&#39;);" target="_blank">alf.mmm.cat@...> wrote:

Stef,
As I said to Igor, the main problem about NativeBoost was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.

If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my first goal),
I will be glad to add  a chapter about that.

My current problem is about a different socket behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C program works as expected,
I have to look for an explanation.
No stress about that


Alain


Le 04/11/2014 10:39, stepharo a écrit :

Alain

which nativeboost chapter :)?
Could you propose a paragraph so that we cover the problem you faced?

Stef

On 4/11/14 00:44, Alain Rastoul wrote:

Hi Igor,

Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid, much better to fail soon.
...  I am an ass on this one...

However, I am struggling on another point you already answered in the
past
in the mailing list to a guy who wanted to use socket.io :
(http://forum.world.st/socket-io-td3891592.html#a3893031)
"Sockets in Pharo are not blocking the whole VM.
What they block is the process which working with concrete socket. But
other processes can still run, while
one waiting data / even from single socket. "
on windows, zmq socket receive is blocking, on linux, not blocking
(hence not working).
As zmq is doing is IO on another thread, I guess there is some side
effect of
socket receive timeout settings somewhere (in the plugin ?) - just a
guess...
Getting socket options shows no difference, but I don't know how it is
done on the vm
side with regards to threads and if the socket is the same (zmq socket
is not the tcp socket)...
And on linux, the equivalent C program of to the smalltalk version
blocks as expected.

I a mperplexified ...
may be I should look at vm and plugin code (VMMaker package IIRC) ?
Do you have another advice ?

Thanks you

Alain
Le 03/11/2014 02:12, Igor Stasenko a écrit :

NBExternalArray instances cannot be passed directly to functions
expecting pointers.

use 'myarray address' for arguments.

On 3 November 2014 00:20, Alain Rastoul
<[hidden email]
<mailto:[hidden email]>> wrote:

    Hi,

    I have a problem with a nativeboost call, but  I don't see what I do
    wrong.

       library function prototype is:
      int zmq_getsockopt (void *socket, int option_name, void
    *option_value, size_t *option_len);

    my calling method in pharo is:
    zmq_getsockopt: socket option_name: option_name option_value:
    option_value option_len: option_len
             <primitive: #primitiveNativeCall module: #NativeBoostPlugin
    error: errorCode>
             ^self nbCall: #(int zmq_getsockopt (void *socket, int
    option_name, void * option_value, size_t* option_len)  )

    when I call it with
    ...
    optionValue := (NBExternalArray ofType: 'int') externalNew: 1.
    optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1.
    [       optionValue at: 1 put: 0 .
             optionLen at: 1 put: (NBExternalType sizeOf: 'int')  .
             rc := self zmq_getsockopt: socket option_name: option_name
                             option_value:  optionValue
                             option_len: optionLen  .
             value := optionValue at: 1 .
    ] ensure: [  optionValue free.
                     optionLen free  ].
    ...
    I allways get an exception: "error during FFI call : nil"


    After stepping in NBFFICallout generation, I found something
    strange, the code
    generation seems not to be called because lastError stays at nil ?

    handleFailureIn: aContext nativeCode: aBlock
             lastError := self getErrorFrom: aContext lastError:
    NativeBoost lastError.

             >>getErrorFrom: aContext lastError: errorCode
              ...  checks  pragmas etc
             >>getErrorFrom: aContext lastError: errorCode
             ...             lastError := aContext  tempAt: method
numTemps.
                     => lastError = nil ???  shouldn't be
    ErrNoNativeCodeInMethod ?
             "install native code and retry the send"
             lastError = ErrNoNativeCodeInMethod
                     ifTrue: [ ^ self generateCode: aBlock andRetry:
    aContext ].
          never gets called ...

             "ok, we're out of options, signal an error here"
             ^ self signalError: lastError

    Could it be because I use this image on windows and unix ?
    Or because I had an exception at prototype parsing the first time
    because I forgot a ; at the end of the prototype ?

    Is my prototype correct or is it the origin of the error ?
    Is there a way to reset the lastError (aContext  tempAt: method
    numTemps) ?
    I will try to reset it in debugger but may be there is a cleaner
way ?
    would it be ok to change  the test in handleFailure to
    (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ?
    (I can open a bug in this case )

    Any idea or comment is welcome
    Thanks in advance

    Alain





--
Best regards,
Igor Stasenko.

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Tuesday, November 4, 2014, Alain Rastoul <[hidden email]> wrote:

Stef,
As I said to Igor, the main problem about NativeBoost was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.

If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my first goal),
I will be glad to add  a chapter about that.

My current problem is about a different socket behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C program works as expected,
I have to look for an explanation.
No stress about that


Alain


Le 04/11/2014 10:39, stepharo a écrit :

Alain

which nativeboost chapter :)?
Could you propose a paragraph so that we cover the problem you faced?

Stef

On 4/11/14 00:44, Alain Rastoul wrote:

Hi Igor,

Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid, much better to fail soon.
...  I am an ass on this one...

However, I am struggling on another point you already answered in the
past
in the mailing list to a guy who wanted to use socket.io :
(http://forum.world.st/socket-io-td3891592.html#a3893031)
"Sockets in Pharo are not blocking the whole VM.
What they block is the process which working with concrete socket. But
other processes can still run, while
one waiting data / even from single socket. "
on windows, zmq socket receive is blocking, on linux, not blocking
(hence not working).
As zmq is doing is IO on another thread, I guess there is some side
effect of
socket receive timeout settings somewhere (in the plugin ?) - just a
guess...
Getting socket options shows no difference, but I don't know how it is
done on the vm
side with regards to threads and if the socket is the same (zmq socket
is not the tcp socket)...
And on linux, the equivalent C program of to the smalltalk version
blocks as expected.

I a mperplexified ...
may be I should look at vm and plugin code (VMMaker package IIRC) ?
Do you have another advice ?

Thanks you

Alain
Le 03/11/2014 02:12, Igor Stasenko a écrit :

NBExternalArray instances cannot be passed directly to functions
expecting pointers.

use 'myarray address' for arguments.

On 3 November 2014 00:20, Alain Rastoul
<[hidden email]
<mailto:[hidden email]>> wrote:

    Hi,

    I have a problem with a nativeboost call, but  I don't see what I do
    wrong.

       library function prototype is:
      int zmq_getsockopt (void *socket, int option_name, void
    *option_value, size_t *option_len);

    my calling method in pharo is:
    zmq_getsockopt: socket option_name: option_name option_value:
    option_value option_len: option_len
             <primitive: #primitiveNativeCall module: #NativeBoostPlugin
    error: errorCode>
             ^self nbCall: #(int zmq_getsockopt (void *socket, int
    option_name, void * option_value, size_t* option_len)  )

    when I call it with
    ...
    optionValue := (NBExternalArray ofType: 'int') externalNew: 1.
    optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1.
    [       optionValue at: 1 put: 0 .
             optionLen at: 1 put: (NBExternalType sizeOf: 'int')  .
             rc := self zmq_getsockopt: socket option_name: option_name
                             option_value:  optionValue
                             option_len: optionLen  .
             value := optionValue at: 1 .
    ] ensure: [  optionValue free.
                     optionLen free  ].
    ...
    I allways get an exception: "error during FFI call : nil"


    After stepping in NBFFICallout generation, I found something
    strange, the code
    generation seems not to be called because lastError stays at nil ?

    handleFailureIn: aContext nativeCode: aBlock
             lastError := self getErrorFrom: aContext lastError:
    NativeBoost lastError.

             >>getErrorFrom: aContext lastError: errorCode
              ...  checks  pragmas etc
             >>getErrorFrom: aContext lastError: errorCode
             ...             lastError := aContext  tempAt: method
numTemps.
                     => lastError = nil ???  shouldn't be
    ErrNoNativeCodeInMethod ?
             "install native code and retry the send"
             lastError = ErrNoNativeCodeInMethod
                     ifTrue: [ ^ self generateCode: aBlock andRetry:
    aContext ].
          never gets called ...

             "ok, we're out of options, signal an error here"
             ^ self signalError: lastError

    Could it be because I use this image on windows and unix ?
    Or because I had an exception at prototype parsing the first time
    because I forgot a ; at the end of the prototype ?

    Is my prototype correct or is it the origin of the error ?
    Is there a way to reset the lastError (aContext  tempAt: method
    numTemps) ?
    I will try to reset it in debugger but may be there is a cleaner
way ?
    would it be ok to change  the test in handleFailure to
    (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ?
    (I can open a bug in this case )

    Any idea or comment is welcome
    Thanks in advance

    Alain





--
Best regards,
Igor Stasenko.

On Friday, November 7, 2014, kilon alios <[hidden email]> wrote:

Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them !!!! DAMN THEM I SAY!!!! 

Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED !!!!

Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to  static type language. 

I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. 

So I cant say I am a big believer of Haskell. 

Also I real hate the terminology "side effect" ... sounds too..... elitist to me. 

bravo

that's the spirit

i like it

so i looked up some more about 

monads

http://book.realworldhaskell.org/read/monads.html

and the teacher said

no it was another teacher but i can't find him now

something that is really sticking in my head

he said

something like

he said

the state changes are in the monads

they are localised in the monads

like we stick the dangerous bits into a seperate Package ( info )

so we know where they are

the pure functions defined outside of the monads

are not really pure ( my take )

they are definitely manipulating state

 

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Tuesday, November 4, 2014, Alain Rastoul <[hidden email]> wrote:

Stef,
As I said to Igor, the main problem about NativeBoost was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.

If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my first goal),
I will be glad to add  a chapter about that.

My current problem is about a different socket behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C program works as expected,
I have to look for an explanation.
No stress about that


Alain


Le 04/11/2014 10:39, stepharo a écrit :

Alain

which nativeboost chapter :)?
Could you propose a paragraph so that we cover the problem you faced?

Stef

On 4/11/14 00:44, Alain Rastoul wrote:

Hi Igor,

Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid, much better to fail soon.
...  I am an ass on this one...

However, I am struggling on another point you already answered in the
past
in the mailing list to a guy who wanted to use socket.io :
(http://forum.world.st/socket-io-td3891592.html#a3893031)
"Sockets in Pharo are not blocking the whole VM.
What they block is the process which working with concrete socket. But
other processes can still run, while
one waiting data / even from single socket. "
on windows, zmq socket receive is blocking, on linux, not blocking
(hence not working).
As zmq is doing is IO on another thread, I guess there is some side
effect of
socket receive timeout settings somewhere (in the plugin ?) - just a
guess...
Getting socket options shows no difference, but I don't know how it is
done on the vm
side with regards to threads and if the socket is the same (zmq socket
is not the tcp socket)...
And on linux, the equivalent C program of to the smalltalk version
blocks as expected.

I a mperplexified ...
may be I should look at vm and plugin code (VMMaker package IIRC) ?
Do you have another advice ?

Thanks you

Alain
Le 03/11/2014 02:12, Igor Stasenko a écrit :

NBExternalArray instances cannot be passed directly to functions
expecting pointers.

use 'myarray address' for arguments.

On 3 November 2014 00:20, Alain Rastoul
<[hidden email]
<mailto:[hidden email]>> wrote:

    Hi,

    I have a problem with a nativeboost call, but  I don't see what I do
    wrong.

       library function prototype is:
      int zmq_getsockopt (void *socket, int option_name, void
    *option_value, size_t *option_len);

    my calling method in pharo is:
    zmq_getsockopt: socket option_name: option_name option_value:
    option_value option_len: option_len
             <primitive: #primitiveNativeCall module: #NativeBoostPlugin
    error: errorCode>
             ^self nbCall: #(int zmq_getsockopt (void *socket, int
    option_name, void * option_value, size_t* option_len)  )

    when I call it with
    ...
    optionValue := (NBExternalArray ofType: 'int') externalNew: 1.
    optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1.
    [       optionValue at: 1 put: 0 .
             optionLen at: 1 put: (NBExternalType sizeOf: 'int')  .
             rc := self zmq_getsockopt: socket option_name: option_name
                             option_value:  optionValue
                             option_len: optionLen  .
             value := optionValue at: 1 .
    ] ensure: [  optionValue free.
                     optionLen free  ].
    ...
    I allways get an exception: "error during FFI call : nil"


    After stepping in NBFFICallout generation, I found something
    strange, the code
    generation seems not to be called because lastError stays at nil ?

    handleFailureIn: aContext nativeCode: aBlock
             lastError := self getErrorFrom: aContext lastError:
    NativeBoost lastError.

             >>getErrorFrom: aContext lastError: errorCode
              ...  checks  pragmas etc
             >>getErrorFrom: aContext lastError: errorCode
             ...             lastError := aContext  tempAt: method
numTemps.
                     => lastError = nil ???  shouldn't be
    ErrNoNativeCodeInMethod ?
             "install native code and retry the send"
             lastError = ErrNoNativeCodeInMethod
                     ifTrue: [ ^ self generateCode: aBlock andRetry:
    aContext ].
          never gets called ...

             "ok, we're out of options, signal an error here"
             ^ self signalError: lastError

    Could it be because I use this image on windows and unix ?
    Or because I had an exception at prototype parsing the first time
    because I forgot a ; at the end of the prototype ?

    Is my prototype correct or is it the origin of the error ?
    Is there a way to reset the lastError (aContext  tempAt: method
    numTemps) ?
    I will try to reset it in debugger but may be there is a cleaner
way ?
    would it be ok to change  the test in handleFailure to
    (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ?
    (I can open a bug in this case )

    Any idea or comment is welcome
    Thanks in advance

    Alain





--
Best regards,
Igor Stasenko.

something happened

gmail just blew a main spring

so continuing from below above

like we stick the dangerous bits into a seperate Package ( info )

so we know where they are

the pure functions defined outside of the monads

are not really pure ( my take )

they are definitely manipulating state

but the state is hidden inside the pipes

inside the pure functions

and no global variables or other places where state hangs out

can be accessed from in there

the bind >>= and return functions are confusing

but >>= takes in a Monad m with a data value a in it

m a

and also a function [ :a |    m ( a message )    ] <---[ mixing metaphors languages ]

and returns a Monad

m a'

to the next >>= in line.

So the a is taken out of the Monad m and manipulated by a pure function I'm guessing

namely the function #message which is pure or can be pure

and then the data a is put back into the Monad m

and m is passed to the next >>= bind in line

return is like takes in a data a and returns m a

so the function [ :a |     m ( a message )   ]

is actually [ :a |     ( a message ) return    ]

or [ :a :monad |    ( a message ) return: monad   ]

so this is all optimized by the compiler down into native code.

So to get away from this >>= bind nonsense the compiler has a

do { s1 ;  s2  ; s3 ; s4 ... }

which gets translated by a preprocessor into

( ( ( s1 >>= s2 ) >>= s3 ) >>= s4 ) ...

where s1 returns an

m a

and the si have the form [ :a | ( a messagei) return: m ]

another gmail blow out 

I can't see what I am typing 

I'm typing blind

oh well

snow blind

 

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

On Tuesday, November 11, 2014, Kjell Godo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;squeaklist@gmail.com&#39;);" target="_blank">squeaklist@...> wrote:

On Friday, November 7, 2014, kilon alios <[hidden email]> wrote:

Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them !!!! DAMN THEM I SAY!!!! 

Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED !!!!

Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to  static type language. 

I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. 

So I cant say I am a big believer of Haskell. 

Also I real hate the terminology "side effect" ... sounds too..... elitist to me. 

bravo

that's the spirit

i like it

so i looked up some more about 

monads

http://book.realworldhaskell.org/read/monads.html

and the teacher said

no it was another teacher but i can't find him now

something that is really sticking in my head

he said

something like

he said

the state changes are in the monads

they are localised in the monads

like we stick the dangerous bits into a seperate Package ( info )

so we know where they are

the pure functions defined outside of the monads

are not really pure ( my take )

they are definitely manipulating state

 

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Tuesday, November 4, 2014, Alain Rastoul <[hidden email]> wrote:

Stef,
As I said to Igor, the main problem about NativeBoost was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.

If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my first goal),
I will be glad to add  a chapter about that.

My current problem is about a different socket behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C program works as expected,
I have to look for an explanation.
No stress about that


Alain


Le 04/11/2014 10:39, stepharo a écrit :

Alain

which nativeboost chapter :)?
Could you propose a paragraph so that we cover the problem you faced?

Stef

On 4/11/14 00:44, Alain Rastoul wrote:

Hi Igor,

Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid, much better to fail soon.
...  I am an ass on this one...

However, I am struggling on another point you already answered in the
past
in the mailing list to a guy who wanted to use socket.io :
(http://forum.world.st/socket-io-td3891592.html#a3893031)
"Sockets in Pharo are not blocking the whole VM.
What they block is the process which working with concrete socket. But
other processes can still run, while
one waiting data / even from single socket. "
on windows, zmq socket receive is blocking, on linux, not blocking
(hence not working).
As zmq is doing is IO on another thread, I guess there is some side
effect of
socket receive timeout settings somewhere (in the plugin ?) - just a
guess...
Getting socket options shows no difference, but I don't know how it is
done on the vm
side with regards to threads and if the socket is the same (zmq socket
is not the tcp socket)...
And on linux, the equivalent C program of to the smalltalk version
blocks as expected.

I a mperplexified ...
may be I should look at vm and plugin code (VMMaker package IIRC) ?
Do you have another advice ?

Thanks you

Alain
Le 03/11/2014 02:12, Igor Stasenko a écrit :

NBExternalArray instances cannot be passed directly to functions
expecting pointers.

use 'myarray address' for arguments.

On 3 November 2014 00:20, Alain Rastoul
<[hidden email]
<mailto:[hidden email]>> wrote:

    Hi,

    I have a problem with a nativeboost call, but  I don't see what I do
    wrong.

       library function prototype is:
      int zmq_getsockopt (void *socket, int option_name, void
    *option_value, size_t *option_len);

    my calling method in pharo is:
    zmq_getsockopt: socket option_name: option_name option_value:
    option_value option_len: option_len
             <primitive: #primitiveNativeCall module: #NativeBoostPlugin
    error: errorCode>
             ^self nbCall: #(int zmq_getsockopt (void *socket, int
    option_name, void * option_value, size_t* option_len)  )

    when I call it with
    ...
    optionValue := (NBExternalArray ofType: 'int') externalNew: 1.
    optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1.
    [       optionValue at: 1 put: 0 .
             optionLen at: 1 put: (NBExternalType sizeOf: 'int')  .
             rc := self zmq_getsockopt: socket option_name: option_name
                             option_value:  optionValue
                             option_len: optionLen  .
             value := optionValue at: 1 .
    ] ensure: [  optionValue free.
                     optionLen free  ].
    ...
    I allways get an exception: "error during FFI call : nil"


    After stepping in NBFFICallout generation, I found something
    strange, the code
    generation seems not to be called because lastError stays at nil ?

    handleFailureIn: aContext nativeCode: aBlock
             lastError := self getErrorFrom: aContext lastError:
    NativeBoost lastError.

             >>getErrorFrom: aContext lastError: errorCode
              ...  checks  pragmas etc
             >>getErrorFrom: aContext lastError: errorCode
             ...             lastError := aContext  tempAt: method
numTemps.
                     => lastError = nil ???  shouldn't be
    ErrNoNativeCodeInMethod ?
             "install native code and retry the send"
             lastError = ErrNoNativeCodeInMethod
                     ifTrue: [ ^ self generateCode: aBlock andRetry:
    aContext ].
          never gets called ...

             "ok, we're out of options, signal an error here"
             ^ self signalError: lastError

    Could it be because I use this image on windows and unix ?
    Or because I had an exception at prototype parsing the first time
    because I forgot a ; at the end of the prototype ?

    Is my prototype correct or is it the origin of the error ?
    Is there a way to reset the lastError (aContext  tempAt: method
    numTemps) ?
    I will try to reset it in debugger but may be there is a cleaner
way ?
    would it be ok to change  the test in handleFailure to
    (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ?
    (I can open a bug in this case )

    Any idea or comment is welcome
    Thanks in advance

    Alain





--
Best regards,
Igor Stasenko.

so i do start to think Smalltalk might suffer from a

random state 

problem

which as you say is greatly made a lot lot lot easier by

coding in the debugger and mass test driven development on

LIVE OBJECTS

which hide the state.

but the state is still in there and a method ffffff that takes in

data1 

at time t0

and returns 

data2

and then at time t1 does

data3 := data1 ffffff

where ( data1 isNotEquivalentTo: data3 )

causes the ability to reason about ffffff to get a lot harder so that

automated and manual proof methods refuse to halt.

On Tuesday, November 11, 2014, Kjell Godo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;squeaklist@gmail.com&#39;);" target="_blank">squeaklist@...> wrote:

something happened

gmail just blew a main spring

so continuing from below above

like we stick the dangerous bits into a seperate Package ( info )

so we know where they are

the pure functions defined outside of the monads

are not really pure ( my take )

they are definitely manipulating state

but the state is hidden inside the pipes

inside the pure functions

and no global variables or other places where state hangs out

can be accessed from in there

the bind >>= and return functions are confusing

but >>= takes in a Monad m with a data value a in it

m a

and also a function [ :a |    m ( a message )    ] <---[ mixing metaphors languages ]

and returns a Monad

m a'

to the next >>= in line.

So the a is taken out of the Monad m and manipulated by a pure function I'm guessing

namely the function #message which is pure or can be pure

and then the data a is put back into the Monad m

and m is passed to the next >>= bind in line

return is like takes in a data a and returns m a

so the function [ :a |     m ( a message )   ]

is actually [ :a |     ( a message ) return    ]

or [ :a :monad |    ( a message ) return: monad   ]

so this is all optimized by the compiler down into native code.

So to get away from this >>= bind nonsense the compiler has a

do { s1 ;  s2  ; s3 ; s4 ... }

which gets translated by a preprocessor into

( ( ( s1 >>= s2 ) >>= s3 ) >>= s4 ) ...

where s1 returns an

m a

and the si have the form [ :a | ( a messagei) return: m ]

another gmail blow out 

I can't see what I am typing 

I'm typing blind

oh well

snow blind

 

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

On Tuesday, November 11, 2014, Kjell Godo <[hidden email]> wrote:

On Friday, November 7, 2014, kilon alios <[hidden email]> wrote:

Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them !!!! DAMN THEM I SAY!!!! 

Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED !!!!

Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to  static type language. 

I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. 

So I cant say I am a big believer of Haskell. 

Also I real hate the terminology "side effect" ... sounds too..... elitist to me. 

bravo

that's the spirit

i like it

so i looked up some more about 

monads

http://book.realworldhaskell.org/read/monads.html

and the teacher said

no it was another teacher but i can't find him now

something that is really sticking in my head

he said

something like

he said

the state changes are in the monads

they are localised in the monads

like we stick the dangerous bits into a seperate Package ( info )

so we know where they are

the pure functions defined outside of the monads

are not really pure ( my take )

they are definitely manipulating state

 

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <[hidden email]> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Tuesday, November 4, 2014, Alain Rastoul <[hidden email]> wrote:

Stef,
As I said to Igor, the main problem about NativeBoost was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.

If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my first goal),
I will be glad to add  a chapter about that.

My current problem is about a different socket behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C program works as expected,
I have to look for an explanation.
No stress about that


Alain


Le 04/11/2014 10:39, stepharo a écrit :

Alain

which nativeboost chapter :)?
Could you propose a paragraph so that we cover the problem you faced?

Stef

On 4/11/14 00:44, Alain Rastoul wrote:

Hi Igor,

Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid, much better to fail soon.
...  I am an ass on this one...

However, I am struggling on another point you already answered in the
past
in the mailing list to a guy who wanted to use socket.io :
(http://forum.world.st/socket-io-td3891592.html#a3893031)
"Sockets in Pharo are not blocking the whole VM.
What they block is the process which working with concrete socket. But
other processes can still run, while
one waiting data / even from single socket. "
on windows, zmq socket receive is blocking, on linux, not blocking
(hence not working).
As zmq is doing is IO on another thread, I guess there is some side
effect of
socket receive timeout settings somewhere (in the plugin ?) - just a
guess...
Getting socket options shows no difference, but I don't know how it is
done on the vm
side with regards to threads and if the socket is the same (zmq socket
is not the tcp socket)...
And on linux, the equivalent C program of to the smalltalk version
blocks as expected.

I a mperplexified ...
may be I should look at vm and plugin code (VMMaker package IIRC) ?
Do you have another advice ?

Thanks you

Alain
Le 03/11/2014 02:12, Igor Stasenko a écrit :

NBExternalArray instances cannot be passed directly to functions
expecting pointers.

use 'myarray address' for arguments.

On 3 November 2014 00:20, Alain Rastoul
<[hidden email]
<mailto:[hidden email]>> wrote:

    Hi,

    I have a problem with a nativeboost call, but  I don't see what I do
    wrong.

       library function prototype is:
      int zmq_getsockopt (void *socket, int option_name, void
    *option_value, size_t *option_len);

    my calling method in pharo is:
    zmq_getsockopt: socket option_name: option_name option_value:
    option_value option_len: option_len
             <primitive: #primitiveNativeCall module: #NativeBoostPlugin
    error: errorCode>
             ^self nbCall: #(int zmq_getsockopt (void *socket, int
    option_name, void * option_value, size_t* option_len)  )

    when I call it with
    ...
    optionValue := (NBExternalArray ofType: 'int') externalNew: 1.
    optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1.
    [       optionValue at: 1 put: 0 .
             optionLen at: 1 put: (NBExternalType sizeOf: 'int')  .
             rc := self zmq_getsockopt: socket option_name: option_name
                             option_value:  optionValue
                             option_len: optionLen  .
             value := optionValue at: 1 .
    ] ensure: [  optionValue free.
                     optionLen free  ].
    ...
    I allways get an exception: "error during FFI call : nil"


    After stepping in NBFFICallout generation, I found something
    strange, the code
    generation seems not to be called because lastError stays at nil ?

    handleFailureIn: aContext nativeCode: aBlock
             lastError := self getErrorFrom: aContext lastError:
    NativeBoost lastError.

             >>getErrorFrom: aContext lastError: errorCode
              ...  checks  pragmas etc
             >>getErrorFrom: aContext lastError: errorCode
             ...             lastError := aContext  tempAt: method
numTemps.
                     => lastError = nil ???  shouldn't be
    ErrNoNativeCodeInMethod ?
             "install native code and retry the send"
             lastError = ErrNoNativeCodeInMethod
                     ifTrue: [ ^ self generateCode: aBlock andRetry:
    aContext ].
          never gets called ...

             "ok, we're out of options, signal an error here"
             ^ self signalError: lastError

    Could it be because I use this image on windows and unix ?
    Or because I had an exception at prototype parsing the first time
    because I forgot a ; at the end of the prototype ?

    Is my prototype correct or is it the origin of the error ?
    Is there a way to reset the lastError (aContext  tempAt: method
    numTemps) ?
    I will try to reset it in debugger but may be there is a cleaner
way ?
    would it be ok to change  the test in handleFailure to
    (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ?
    (I can open a bug in this case )

    Any idea or comment is welcome
    Thanks in advance

    Alain





--
Best regards,
Igor Stasenko.

Am 07.11.2014 um 16:51 schrieb Kjell Godo <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;squeaklist@gmail.com&#39;);" target="_blank">squeaklist@...>:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

Why do you expect that? Many people here are using Smalltalk for years.

Just because you have been silent for some time doesn’t mean everybody will forget about you :)

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

First, there are no good definitions of what is an object oriented language and what is a functional language.

Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalk’s.

The same problem exists in the functional language world: Some consider LISP being functional, some deny that.

Second, for some years I am constantly seeking for „the best“ language to solve my problems in. Alas I wasn’t successful yet and don’t expect

to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems.

So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the

best fitting language for your problem at hand.

Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, …). The idea behind is simple: combine

the best characteristics. In my eyes all of them failed because what always have been created is Frankenstein’s monster. When you combine

paradigms you will may get some advantages of all but sure you will get a lot of additional complexity.

Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. It’s the whole system: the language, duck typing,

the image (object world), the tools, the VM, the simplicity, the elegance, … And last but not least the communities around.

Regards

Andreas

PS: If you are interested in functional programming and don’t like static typing you should have a look at Clojure. It has some nice ideas about

how to deal with state concurrently.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

i have been wondering about taking a crack at implementing these

in Smalltalk and i wonder if it would be 

theoretically possible 

to speed them up by inlining them via the Smalltalk compiler

Thank you

On Saturday, November 8, 2014, Andreas Wacknitz <[hidden email]> wrote:

Am 07.11.2014 um 16:51 schrieb Kjell Godo <<a href="javascript:_e(%7B%7D,'cvml','squeaklist@gmail.com');" target="_blank">squeaklist@...>:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

Why do you expect that? Many people here are using Smalltalk for years.

Just because you have been silent for some time doesn’t mean everybody will forget about you :)

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

First, there are no good definitions of what is an object oriented language and what is a functional language.

Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalk’s.

The same problem exists in the functional language world: Some consider LISP being functional, some deny that.

Second, for some years I am constantly seeking for „the best“ language to solve my problems in. Alas I wasn’t successful yet and don’t expect

to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems.

So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the

best fitting language for your problem at hand.

Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, …). The idea behind is simple: combine

the best characteristics. In my eyes all of them failed because what always have been created is Frankenstein’s monster. When you combine

paradigms you will may get some advantages of all but sure you will get a lot of additional complexity.

Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. It’s the whole system: the language, duck typing,

the image (object world), the tools, the VM, the simplicity, the elegance, … And last but not least the communities around.

Regards

Andreas

PS: If you are interested in functional programming and don’t like static typing you should have a look at Clojure. It has some nice ideas about

how to deal with state concurrently.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

Thank you for the detailed reply Andreas

Are there any Smalltalk packages implementing 

Category Theory based

functional programming constructs 

for function composition like

functors , applicatives , monads , arrows , etc ?

Do people have opinions about whether or not 

these plus immutable data structures would be good for managing state

in Smalltalk like they do it in Haskell etc?  i know that monads are not built

into Haskell but are implemented as addons via Haskell packages.

My Haskell friend said all you need to do functional programming is

first class functions

which Smalltalk Block contexts almost are except they lack their own stack?

if you wrap a Block in a Function Object do you then get the stack

effect so you can essentially call the Block recursively?

i have been wondering about taking a crack at implementing these

in Smalltalk and i wonder if it would be 

theoretically possible 

to speed them up by inlining them via the Smalltalk compiler

Thank you

On Saturday, November 8, 2014, Andreas Wacknitz <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;a.wacknitz@gmx.de&#39;);" target="_blank">a.wacknitz@...> wrote:

Am 07.11.2014 um 16:51 schrieb Kjell Godo <[hidden email]>:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

Why do you expect that? Many people here are using Smalltalk for years.

Just because you have been silent for some time doesn’t mean everybody will forget about you :)

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

First, there are no good definitions of what is an object oriented language and what is a functional language.

Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalk’s.

The same problem exists in the functional language world: Some consider LISP being functional, some deny that.

Second, for some years I am constantly seeking for „the best“ language to solve my problems in. Alas I wasn’t successful yet and don’t expect

to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems.

So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the

best fitting language for your problem at hand.

Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, …). The idea behind is simple: combine

the best characteristics. In my eyes all of them failed because what always have been created is Frankenstein’s monster. When you combine

paradigms you will may get some advantages of all but sure you will get a lot of additional complexity.

Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. It’s the whole system: the language, duck typing,

the image (object world), the tools, the VM, the simplicity, the elegance, … And last but not least the communities around.

Regards

Andreas

PS: If you are interested in functional programming and don’t like static typing you should have a look at Clojure. It has some nice ideas about

how to deal with state concurrently.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))

On Monday, July 6, 2015, Eliot Miranda <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;eliot.miranda@gmail.com&#39;);" target="_blank">eliot.miranda@...> wrote:

Hi Kjell,

On Jul 6, 2015, at 6:16 AM, Kjell Godo <[hidden email]> wrote:

Thank you for the detailed reply Andreas

Are there any Smalltalk packages implementing 

Category Theory based

functional programming constructs 

for function composition like

functors , applicatives , monads , arrows , etc ?

Do people have opinions about whether or not 

these plus immutable data structures would be good for managing state

in Smalltalk like they do it in Haskell etc?  i know that monads are not built

into Haskell but are implemented as addons via Haskell packages.

My Haskell friend said all you need to do functional programming is

first class functions

which Smalltalk Block contexts almost are except they lack their own stack?

if you wrap a Block in a Function Object do you then get the stack

effect so you can essentially call the Block recursively?

The Pharo & Squeak dialects, along with most others, now have closures, so blocks are fully recursive.

i have been wondering about taking a crack at implementing these

in Smalltalk and i wonder if it would be 

theoretically possible 

to speed them up by inlining them via the Smalltalk compiler

The compiler already inlines closures in a few key control messages such as ifTrue: whileTrue: and:.

I recommend spending some time reading the code for the core execution classes and the compiler, and running examples  interactively to learn how the system works.  It's a fun process and well supported by the tools.  Remember that the debugger includes a meta circular interpreter for executing the system's bytecode, and that the compiler compiles source to bytecode in the firm of CompiledMethod instances you can inspect, decompile and list their bytecode.

All the questions you have above you can answer for yourself by running examples and using the tools to observe what happens.  This is a route to mastering the system; IMNERHO the best.

is there any tutorial?

how do i do this?

 

Thank you

Eliot (phone)

 

On Saturday, November 8, 2014, Andreas Wacknitz <[hidden email]> wrote:

Am 07.11.2014 um 16:51 schrieb Kjell Godo <[hidden email]>:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

Why do you expect that? Many people here are using Smalltalk for years.

Just because you have been silent for some time doesn’t mean everybody will forget about you :)

I don't know if you want this crap in here but I have decided not to wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.

( Original-SUBJECT:     "( picoVerse-:( what about state , is state really evil? ) )"       )

I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d) state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.  

The debugger is my staff I use to whack the state.  And TestCase is my sheep dog.

But to the Haskellers

state is

the evil trinity 

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as possible

must be 100% dependent on the input parameters ONLY.   

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.   

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

First, there are no good definitions of what is an object oriented language and what is a functional language.

Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalk’s.

The same problem exists in the functional language world: Some consider LISP being functional, some deny that.

Second, for some years I am constantly seeking for „the best“ language to solve my problems in. Alas I wasn’t successful yet and don’t expect

to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems.

So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the

best fitting language for your problem at hand.

Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, …). The idea behind is simple: combine

the best characteristics. In my eyes all of them failed because what always have been created is Frankenstein’s monster. When you combine

paradigms you will may get some advantages of all but sure you will get a lot of additional complexity.

Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. It’s the whole system: the language, duck typing,

the image (object world), the tools, the VM, the simplicity, the elegance, … And last but not least the communities around.

Regards

Andreas

PS: If you are interested in functional programming and don’t like static typing you should have a look at Clojure. It has some nice ideas about

how to deal with state concurrently.

Thanks

Kjell E Godø

(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))