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 <[email protected]> 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 <[email protected]> wrote: >> >>> This is off topic. >> >> >> > On Tuesday, November 11, 2014, Kjell Godo <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> >> >> On Friday, November 7, 2014, kilon alios <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 >>>>>>>> <[email protected] >>>>>>>> <mailto:[email protected]>> 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. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>
