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.