Oh, I see, I will try later, have to go for now. Thank you so much :) 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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 4 November 2014 00:44, Alain Rastoul <alf.mmm.cat@gmail.com> 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 ?

What is zmq sockets? Some kind of wrapper library? Then best i can advise is to follow its guidelines, since i'm not familiar with it.

Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, please read carefully NBExternalArray class comment, which explains all details.

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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

-- Best regards, Igor Stasenko.

Hi Alain, This is nice that you are working on a zmq binding for Pharo. Is it public and on Sthub? Cheers, #Luc 2014-11-04 7:43 GMT+01:00 Alain Rastoul <alf.mmm.cat@gmail.com>:

Le 04/11/2014 01:32, Igor Stasenko a écrit :

...

What is zmq sockets? Some kind of wrapper library? Then best i can advise is to follow its guidelines, since i'm not familiar with it.

Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, please read carefully NBExternalArray class comment, which explains all details.

ZeroMQ is an open source asynchronous inter-process communication messaging library/framework written in c++ zeromq sockets should not have been called sockets because they are more 'endpoints' or something like that in zmq realms, however, it uses tcp sockets in my tests and has different behaviours on linux and windows, I suspect something different about underlying tcp sockets states.

Thank you for the indication about performance, I will take it into account My first step is just to make experiments that works to be comfortable with both nativeboost and zeromq. This experiment is done with two different pharo vm processes (the client and the server) started manually, and the same in C. This library has nice patterns that makes it very interesting from a parallel computing perspective (request/response, publisher/subscriber, push/pull , etc). The guide is here and is worth looking at http://zguide.zeromq.org/page: all I know you will be interested in, it has similarities with your old hydra project :)

Those experiments are on smalltalkhub under DragonMQ with public access, a there_be_dragon_here debuglog filler for now (will probably be renamed), at the stage of a raw binding and basic experiments to become used to zeromq, but at some point if it works well, it should ends up in a wrapper plus some object oriented api on top of it. Le 04/11/2014 10:45, stepharo a écrit :

...

Hi Alain,

This is nice that you are working on a zmq binding for Pharo. Is it public and on Sthub?

+1

On 4 November 2014 07:43, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 04/11/2014 01:32, Igor Stasenko a écrit :

...

What is zmq sockets? Some kind of wrapper library? Then best i can advise is to follow its guidelines, since i'm not familiar with it.

Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, please read carefully NBExternalArray class comment, which explains all details.

ZeroMQ is an open source asynchronous inter-process communication messaging library/framework written in c++ zeromq sockets should not have been called sockets because they are more 'endpoints' or something like that in zmq realms, however, it uses tcp sockets in my tests and has different behaviours on linux and windows, I suspect something different about underlying tcp sockets states.

Ah, ZeroMQ. Yes, it is a well-known library written in C++. Concerning your problems: i never used it, and i cannot even guess why it behaves differently on different platforms, perhaps you should contact library authors first? Do you create socket via zeromq library, do sockets managed through it? To make sockets to not block the VM, just using a nice library is not enough: you must wire the socket events with VM process scheduling logic through signaling the semaphores etc.. Else you must always use non-blocking calls in C library.

Thank you for the indication about performance, I will take it into account My first step is just to make experiments that works to be comfortable with both nativeboost and zeromq. This experiment is done with two different pharo vm processes (the client and the server) started manually, and the same in C. This library has nice patterns that makes it very interesting from a parallel computing perspective (request/response, publisher/subscriber, push/pull , etc). The guide is here and is worth looking at http://zguide.zeromq.org/page: all I know you will be interested in, it has similarities with your old hydra project :)

Well, parallel computing is broad area.. with zillions goals and solutions. The setup you described is not what i wanted to achieve with Hydra. Running multiple instances of same VM ~= running single instance of VM which can manage multiple native threads. But sure thing you can achieve similar results using both approaches. The difference is in how fine grained your control over consumed resources, namely memory and CPU.

-- Best regards, Igor Stasenko.

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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

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 <alf.mmm.cat@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming. Now, there are clean and less clean ways of doing object oriented design. But I too have a hard time accepting or understanding how a useful real world piece of software can be written without some form of state. Mathematical functions are easy, but once you have a number of closures over some captured and shared state, you basically have a object. Passing a world object into and returning it modified from pure functions becomes heavy too. The world is not black or white, but a complex form of grey. There are many good ideas in (pure) functional programming, you can use all of them in Smalltalk, if you want.

On 07 Nov 2014, at 16:51, Kjell Godo <squeaklist@gmail.com> 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 <alf.mmm.cat@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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 07 Nov 2014, at 17:31, Kjell Godo <squeaklist@gmail.com> wrote:

On Friday, November 7, 2014, Sven Van Caekenberghe <sven@stfx.eu> wrote: Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming.

Now, there are clean and less clean ways of doing object oriented design.

But I too have a hard time accepting or understanding how a useful real world piece of software can be written without some form of state. Mathematical functions are easy, but once you have a number of closures over some captured and shared state, you basically have a object. Passing a world object into and returning it modified from pure functions becomes heavy too.

Why do you say heavy.

Like you said, what they do is pass state as a parameter and return a modified state, often a copy with modifications added. In the real world, this state parameter will quickly become quite complex. How is handling and tediously passing around such a thing better ? And how is it different than referring to self ? My opinion is that you can write beautiful object code with clear abstractions, hiding implementation details behind nice APIs. But it is equally possible to write spaghetti code. It is up to you.

Are you talking about Haskell things that would be hard in Smalltalk?

Or basic things that are hard in Haskell?

When you say heavy do you mean slow or big? Smalltalk or Haskell.

Usually the Haskellers talk about putting small pieces of data into a Monad

and then working on it in there. using bind and return.

Everything outside of the Monad is pure. or something. not sure.

I'm not sure if the data inside of the Monad is acted upon by pure functions.

I'm not quite sure why sticking state into a Monad unstateifies it.

Why do Monads make state safe.

Can Smalltalk have a Monad system? Should it?

The world is not black or white, but a complex form of grey.

There are many good ideas in (pure) functional programming, you can use all of them in Smalltalk, if you want.

...

On 07 Nov 2014, at 16:51, Kjell Godo <squeaklist@gmail.com> 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 <alf.mmm.cat@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

Hmm… to me this mail looks like it is written by a Bot ? e.g. in a mailing list everyone can start a top level thread. unknown users can not post at all. And I am the “postmaster” of this list and I have not gotten any requests at all...

On 07 Nov 2014, at 16:51, Kjell Godo <squeaklist@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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://socket.io/> : (http://forum.world.st/socket-io-td3891592.html#a3893031 <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 <alf.mmm.cat@gmail.com <> <mailto:alf.mmm.cat@gmail.com <>>> 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, Marcus Denker <marcus.denker@inria.fr> wrote:

Hmm… to me this mail looks like it is written by a Bot ?

e.g. in a mailing list everyone can start a top level thread. unknown users can not post at all.

And I am the “postmaster” of this list and I have not gotten any requests at all...

well I don't know but i tried to post to the top level simon dimon himon and i got this error message that i am unknown and that if this condition persisted i should send a message to the postmaster so after failing over a couple times to figure out how to do that can't we just consider this to be it

On 07 Nov 2014, at 16:51, Kjell Godo <squeaklist@gmail.com <javascript:_e(%7B%7D,'cvml','squeaklist@gmail.com');>> 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 <alf.mmm.cat@gmail.com <javascript:_e(%7B%7D,'cvml','alf.mmm.cat@gmail.com');>> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

Well, it looks like this thread have somewhat derailed :) My initial question was about a problem I now think (but have to confirm) is a vm system call signals side effects with socket polling in zeroMQ code (remember this is the vmdev mailing list not the smalltalk user list). I don't like zealots of any kind (object, relational, functional, religious ...), my pun was essentially a joke about trying to send a stateless electron :o) over a wire as a computation to someone's answer I suspect beeing a troll (plug a chakra socket here for a zealot effect). To me at some point, we have to go into some kind of materialization and state, (even with pivotal who have to stores it's code as bits I guess ?) and certainly no judgement of any kind about other realms or langages, I like new ideas , new langages, and new experiences. Of course, functional programming, monads, lambda calculus interests everybody here (me too), I also would like to try functional programming too but have a project I want to take at some interesting level first, and this is my priority. If the intent was not a troll, and he wants to discuss about smalltalk object oriented realm why doesn't he *please* start a new thread and lot of people would give him valuable answers (some did here) about the small*talk* spirit which is (IMHO) essentially about object perception and message sending (hence behaviour or functional) but certainly not "only state" Regards, Alain Le 07/11/2014 22:04, kilon alios a écrit :

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.

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <squeaklist@gmail.com <mailto:squeaklist@gmail.com>> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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://socket.io> : (http://forum.world.st/socket-__io-td3891592.html#a3893031 <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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

Le 07/11/2014 23:14, Eliot Miranda a écrit :

On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote:

Well, it looks like this thread have somewhat derailed :)

My initial question was about a problem I now think (but have to confirm) is a vm system call signals side effects with socket polling in zeroMQ code (remember this is the vmdev mailing list not the smalltalk user list).

I don't like zealots of any kind (object, relational, functional, religious ...), my pun was essentially a joke about trying to send a stateless electron :o) over a wire as a computation to someone's answer I suspect beeing a troll (plug a chakra socket here for a zealot effect).

But electrons are not stateless; they have spin and energy ;-)

that was the point (the :o) smiley) ...how far we go :)

To me at some point, we have to go into some kind of materialization and state, (even with pivotal who have to stores it's code as bits I guess ?) and certainly no judgement of any kind about other realms or langages, I like new ideas , new langages, and new experiences. Of course, functional programming, monads, lambda calculus interests everybody here (me too), I also would like to try functional programming too but have a project I want to take at some interesting level first, and this is my priority.

If the intent was not a troll, and he wants to discuss about smalltalk object oriented realm why doesn't he *please* start a new thread and lot of people would give him valuable answers (some did here) about the small*talk* spirit which is (IMHO) essentially about object perception and message sending (hence behaviour or functional) but certainly not "only state"

Regards,

Alain

Le 07/11/2014 22:04, kilon alios a écrit :

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.

On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo <squeaklist@gmail.com <mailto:squeaklist@gmail.com> <mailto:squeaklist@gmail.com <mailto:squeaklist@gmail.com>>> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com> <mailto:alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>>__> 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://socket.io> <http://socket.io> :

(http://forum.world.st/socket-____io-td3891592.html#a3893031 <http://forum.world.st/socket-__io-td3891592.html#a3893031>

<http://forum.world.st/socket-__io-td3891592.html#a3893031 <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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com> <mailto:alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>>__> 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.

-- best, Eliot

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 <squeaklist@gmail.com> wrote:

...

This is off topic.

On Tuesday, November 11, 2014, Kjell Godo <squeaklist@gmail.com> wrote:

On Friday, November 7, 2014, kilon alios <kilon.alios@gmail.com> 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 <squeaklist@gmail.com> 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 <alf.mmm.cat@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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'm saying what if we use Haskell to make Smalltalk better. what if we use something like lambda lisp which is a merger of Smalltalk and Lisp and used it as syntactic sugar on top of ghc = Haskell by sticking this TFTruthHaskell into a tree based code editor pane which prevents common syntax errors by not allowing them to happen and stick the native ghc output into the CompiledMethod and create a new Smalltalk which has the best of both worlds Smalltalk Lisp and Haskell this also gives the ability to do Lisp macros. And it will be fast. blazing fast me buckos. Ok so it's strongly typed. But we can bend that nonsense and create a new Smalltalk that has a live image and live Objects ( don't ask me ) just like in real Smalltalk but is blazing fast native and it's good sales marketing to increase mindshare because it is strongly typed. who's with me Gentlemen! ok I'm out On Tuesday, November 11, 2014, Kjell Godo <squeaklist@gmail.com> wrote:

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 <squeaklist@gmail.com <javascript:_e(%7B%7D,'cvml','squeaklist@gmail.com');>> 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 <squeaklist@gmail.com> wrote:

...

This is off topic.

On Tuesday, November 11, 2014, Kjell Godo <squeaklist@gmail.com> wrote:

...

On Friday, November 7, 2014, kilon alios <kilon.alios@gmail.com> 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 <squeaklist@gmail.com> 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 <alf.mmm.cat@gmail.com> 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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

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.wacknitz@gmx.de> wrote:

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

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

Hi Kjell, On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist@gmail.com> 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.

Thank you

Eliot (phone)

On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:

...

...

Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist@gmail.com>:

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

is there anybody here who knows both Haskell and Smalltalk ? Can Smalltalk benefit from functional ideas and Haskell's ideas about Immutability Currying Function composition and the State and IO Monads ? I like the way Haskell is now based on Category Theory which is the mathematics of function composition . Haskell was not always thus it had a pre Category Theory epoch . which apparently was a UM or Ugly Mess . Can these ideas be applied to Smalltalk? And would it be good? Can Smalltalk have a way of making a framework that has an API and is statically typed inside using a Haskell like type system? On Saturday, August 1, 2015, Kjell Godo <squeaklist@gmail.com> wrote:

On Monday, July 6, 2015, Eliot Miranda <eliot.miranda@gmail.com <javascript:_e(%7B%7D,'cvml','eliot.miranda@gmail.com');>> wrote:

...

Hi Kjell,

On Jul 6, 2015, at 6:16 AM, Kjell Godo <squeaklist@gmail.com> 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 <a.wacknitz@gmx.de> wrote:

...

Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist@gmail.com>:

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

Object Orientation seems to freak out most Haskell programmers. They are opposed to it. They have never tried Smalltalk. They see OOP as bad practice in the languages they have seen it in and say it promotes chaotic program behaviour and unmaintainable software that is brittle and full of costly bugs. They have never tried Smalltalk and some are a bit bewildered when i say Smalltalk is usually very stable. i just wonder if functional state management would make Smalltalk development faster and less Chaotic and how you could marry OOP and functional and if you did then how would you do it how can the concepts of functional and OOP be combined is my question what are all the concepts and how can they be combined because i do think that perhaps Smalltalk development is slowed down and made more Chaotic and unmaintainable by mutable data in Objects so in order to correct this in my opinion the first step would be to create immutable Objects my Generator package i published for Pharo is perhaps an example of how immutable sequences can be done in Smalltalk but the basic idea is that you create new Objects that link into the pieces of old ones instead of mutating the old ones no instance variables can be rebound once they have been bound ok so this boggles the mind a bit but they swear by it in Haskell so what exactly are the Haskellers talking about? and can it be applied to Smalltalk to Smalltalk's benefit? On Monday, July 6, 2015, Kjell Godo <squeaklist@gmail.com> 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?

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.wacknitz@gmx.de <javascript:_e(%7B%7D,'cvml','a.wacknitz@gmx.de');>> wrote:

...

Am 07.11.2014 um 16:51 schrieb Kjell Godo <squeaklist@gmail.com>:

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

Haskell fits well for those, who wants a proof instead of solution. -- Best regards, Igor Stasenko.

I have removed the sender from the list. The pharo board decided already last year (from the time when the mails that he is answering now) were written that these emails are just disturbing our work, with no positive value whatsoever. Marcus

On 01 Aug 2015, at 16:29, Kjell Godo <squeaklist@gmail.com> wrote:

On Saturday, November 8, 2014, Andreas Wacknitz <a.wacknitz@gmx.de <mailto:a.wacknitz@gmx.de>> wrote:

...

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

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.

I had an idea

BorgLisp

where different dialects of Lisp

coexist

in a single language

and these dialects can be

combined

as in the

Cola and Maru languages

developed by

Alan Kay's institute .

Hopefully this would satisfy your objection to multi paradigm languages because each dialect is pure in itself and can be combined with another dialect or left alone and used by itself .

And there would be Lisp dialects made that are isomorphic to all the existing languages like C C++ C# Java Scala Clojure Prolog Haskell Lua CommonLisp Scheme Perl Smalltalk etc

And all these Lisp dialects can be combined like in Cola but like ... ( haskell-- ...AHaskellLispDialectExpression... ) ... which can have other dialects inside or be used in its seperate pureness

and there is one or more functional OOP Macro systems and Haskell like category theories of composition across all the dialects

image based or generating seperate small executables

This kind of a manoeuvre is designed to kill off the original languages eventually by assimilation into the BorgLisp collective

each isomorphic language dialect need not be as phabulous as its original inspiration as whatever it lacks can be gotten from one of the other dialects so not isomorphic but subset isomorphic or isomorphic to a subset of the original language

these isomorphic dialects are designed like sirens to drive programmers of those languages mad with desire so they get ship wrecked on the rocks of their dialect in the BorgLisp pleasure dome never to return

to what do you object to that kind of thing

how can Smalltalk mix with anything else? that's oil and water?

BorgLisp is image based

but it can generate seperate executables

it can generate itself

using the Cola Maru bootstrapping process

to what do you object?

how should it be modified

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

Le 07/11/2014 21:11, stepharo a écrit :

On 4/11/14 20:30, Alain Rastoul 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.

ok je le note ;)

Avec plaisir :) But to be honest, I am very disappointed with zeroMQ library, not what I was expecting reading docs and books (some hype, not only sure but some), lots of asserts in code like unlikely(condition), return code tests not clear, looks very fragile, breakable and somewhat uncertain (and often crashed). In fact about the linux problem, I suspect (really not sure yet) a side effect with the pharo vm signals, that should not be the case for a library. Reading some posts and answers about python interfacing problems, I think ZeroMQ works well in a program that is designed to use it and only. It may work well with other systems, but not designed in that mindset (assertions in posts like : failing here must abort the program?!). Things that make me think that zeroMQ is probably not a reliable thing to use in Pharo. Plus the only answer I had on the mq list was my own answer (or comment) on debugging the library :( BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too.

...

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 <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> 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.

Very interesting pointers, thank you Sven. Pure Pharo sounds really good to me, I lost my appetite for debugging multithreaded C or C++ (am I aging ?) and I need some kind of MOM functionality for my project, that was the starting point of my ZeroMQ rants. In fact, I am looking for a "SOM" (streaming) server as a part of my musing project which is about clustering and parallel processing with pharo: essentially next, nextput: functionalities to PUSH/PULL pools (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and monitoring. I have the feeling that based on your excellent work in zinc, it should not be that difficult to built it on top, but may be you know a project of that kind I could reuse ? Do you know about some kind of MOM server in Pharo ? Or a STOMP or alike server I could vampirize ? Thank you Alain Le 08/11/2014 09:09, Sven Van Caekenberghe a écrit :

...

On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too.

About Zinc Web Sockets:

https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md

But there is also 'STAMP', a STOMP implementation, which is a generic message queue client:

https://github.com/svenvc/docs/blob/master/neo/stamp.md

Both are pure Pharo.

Sven

Hi Phil, Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack what I am looking for is streaming (on top of a queuing server I presume). Regards, Alain Le 08/11/2014 10:43, phil@highoctane.be a écrit :

I have been using Pharo successfully with RabbitMQ.

Phil

Le 8 nov. 2014 10:16, "Alain Rastoul" <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> a écrit :

Very interesting pointers, thank you Sven. Pure Pharo sounds really good to me, I lost my appetite for debugging multithreaded C or C++ (am I aging ?) and I need some kind of MOM functionality for my project, that was the starting point of my ZeroMQ rants. was ramblings here not rants (sorry for my bad english) In fact, I am looking for a "SOM" (streaming) server as a part of my musing project which is about clustering and parallel processing with pharo: essentially next, nextput: functionalities to PUSH/PULL pools (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and monitoring. I have the feeling that based on your excellent work in zinc, it should not be that difficult to built it on top, but may be you know a project of that kind I could reuse ? Do you know about some kind of MOM server in Pharo ? Or a STOMP or alike server I could vampirize ?

Thank you

Alain

Le 08/11/2014 09:09, Sven Van Caekenberghe a écrit :

On 08 Nov 2014, at 00:23, Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote:

BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too.

About Zinc Web Sockets:

https://github.com/svenvc/__docs/blob/master/zinc/zinc-__websockets-paper.md <https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md>

But there is also 'STAMP', a STOMP implementation, which is a generic message queue client:

https://github.com/svenvc/__docs/blob/master/neo/stamp.md <https://github.com/svenvc/docs/blob/master/neo/stamp.md>

Both are pure Pharo.

Sven

Perfectly correct, I agree, and do you have an opinion or pointers about building a streaming server in pharo ? queuing send/receives (nextPut:, next) from producers and consumers ? Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :>

...

On 08 Nov 2014, at 10:56, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack what I am looking for is streaming (on top of a queuing server I presume).

RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers.

Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view.

About RabbitMQ and others, I did quite some investigations and already use some (working with MSMQ in dotnet at work). I could spend months here but would not like to. My last question (in fact my real interrogation) here is especially to you, as the Zn developer, about a server implementation in pharo: not a true generic enterprise class server, a very small and simple dedicated server to start with, like Teapot is with respects to a big http enterprise class server. I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. (*): except for the reusing part that of course has to be taken into account, for example websockets. Does it sounds realistic to you or totally undoable, and why ? Did you made experiments in that direction ? What would be your opinion, and do you have thoughts to share about that ? Thanks in advance Regards, Alain Le 08/11/2014 11:25, Sven Van Caekenberghe a écrit :

...

On 08 Nov 2014, at 11:21, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Perfectly correct, I agree, and do you have an opinion or pointers about building a streaming server in pharo ? queuing send/receives (nextPut:, next) from producers and consumers ?

Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md Don't forget to read a bit about RabbitMQ itself too. You can load the code and look at the tests.

...

Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :>

...

...

On 08 Nov 2014, at 10:56, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack what I am looking for is streaming (on top of a queuing server I presume).

RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers.

Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view.

Le 08/11/2014 17:14, Sven Van Caekenberghe a écrit :

Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor.

I don't know what you are looking for, I would just do some prototyping and see what happens.

Thanks, somewhat what I'm thinking. To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? May be the question was not clear or too broad, apologizes, this is my fault. About protocols, I tend to be focused on what I want to do and know I'm wrong here. Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? ... given that you are good at networking stuff, that would be great :) I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. TIA regards, Alain