On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul <[email protected]> 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 ;-) > 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 >> <[email protected] >> <mailto:[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] >> <mailto:[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://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 >> <[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. >> >> >> >> >> >> >> >> >> >> >> >> >> > > > -- best, Eliot
