please tell me where this could actually legitimately go. On Friday, November 7, 2014, 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] > <javascript:_e(%7B%7D,'cvml','[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. >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >>
