November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fwd: Webdoc: status?

by Max Leske

Iâve fixed the build and it successfully generates the docs. Iâve moved PetitMarkdown and WebDoc to my Smalltalkhub space in order to get the build working in an easy way and changed the configurations to use the Smalltalkhub urls instead of the filtree ones. THIS IS MEANT ONLY AS A TEMPORARY SOLUTION! I only wanted to get the build back up. If anyone wantâs to take care of PetitMarkdown or WebDoc, move them back to github or whatever, please feel free. @Esteban I hope this is an acceptable interim solution. Cheers, Max > On 11.11.2014, at 18:55, kilon alios <kilon.alios(a)gmail.com> wrote: > > yes I dont doubt that he was great contributor and I remember his post in the mailing when I was first flirting with Pharo but I find it a bit extreme to erase smalltalkhub repos , unless you move them to a better place. > > On Tue, Nov 11, 2014 at 7:29 PM, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@highoctane.be>> wrote: > Cami made a number of great contributions to Pharo. > Especially for the command line friendliness. > > I miss him being around. > > Phil > > Le 11 nov. 2014 18:10, "kilon alios" <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> a Ã©crit : > > another angry ex pharoer ? > > On Tue, Nov 11, 2014 at 5:13 PM, Stephan Eggermont <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > Camillo deleted his smalltalkhub repos. > > Stephan > > >

Nov. 11, 2014

Re: [Pharo-dev] Fwd: Webdoc: status?

by kilon alios

yes I dont doubt that he was great contributor and I remember his post in the mailing when I was first flirting with Pharo but I find it a bit extreme to erase smalltalkhub repos , unless you move them to a better place. On Tue, Nov 11, 2014 at 7:29 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Cami made a number of great contributions to Pharo. > Especially for the command line friendliness. > > I miss him being around. > > Phil > Le 11 nov. 2014 18:10, "kilon alios" <kilon.alios(a)gmail.com> a Ã©crit : > > another angry ex pharoer ? >> >> On Tue, Nov 11, 2014 at 5:13 PM, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> >>> Camillo deleted his smalltalkhub repos. >>> >>> Stephan >>> >>> >>

Nov. 11, 2014

Re: [Pharo-dev] NAtiveBoost error

by Kjell Godo

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(a)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(a)gmail.com > <javascript:_e(%7B%7D,'cvml','squeaklist(a)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(a)gmail.com> wrote: >>> >>>> This is off topic. >>> >>> >>> >> On Tuesday, November 11, 2014, Kjell Godo <squeaklist(a)gmail.com> wrote: >> >>> >>> >>> On Friday, November 7, 2014, kilon alios <kilon.alios(a)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(a)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(a)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(a)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. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>

Nov. 11, 2014

Re: [Pharo-dev] Fwd: Webdoc: status?

by phil＠highoctane.be

Cami made a number of great contributions to Pharo. Especially for the command line friendliness. I miss him being around. Phil Le 11 nov. 2014 18:10, "kilon alios" <kilon.alios(a)gmail.com> a Ã©crit : > another angry ex pharoer ? > > On Tue, Nov 11, 2014 at 5:13 PM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> Camillo deleted his smalltalkhub repos. >> >> Stephan >> >> >

Nov. 11, 2014

Re: [Pharo-dev] NAtiveBoost error

by Kjell Godo

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

Nov. 11, 2014

Re: [Pharo-dev] Fwd: Webdoc: status?

by kilon alios

another angry ex pharoer ? On Tue, Nov 11, 2014 at 5:13 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Camillo deleted his smalltalkhub repos. > > Stephan > >

Nov. 11, 2014

Re: [Pharo-dev] NAtiveBoost error

by Kjell Godo

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(a)gmail.com> wrote: > >> This is off topic. > > > On Tuesday, November 11, 2014, Kjell Godo <squeaklist(a)gmail.com> wrote: > > > On Friday, November 7, 2014, kilon alios <kilon.alios(a)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(a)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(a)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(a)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. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>

Nov. 11, 2014

Re: [Pharo-dev] Webdoc: status?

by Yuriy Tymchuk

Can we change the configuration in meta repo? Or if not, let me know if there will be other one. Iâm using it in my tutorial http://sleepycoders.blogspot.ch/2014/05/auto-documenting-your-pharo-project… <http://sleepycoders.blogspot.ch/2014/05/auto-documenting-your-pharo-project…> Uko > On 11 Nov 2014, at 17:31, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Philippe wrote: >> I got it working and it is full of useful code. > > Tell me where you put it on smalltalkhub and I'll point the build to it. > > Stephan >

Nov. 11, 2014

NAtiveBoost error

by Kjell Godo

On Friday, November 7, 2014, kilon alios <kilon.alios(a)gmail.com <javascript:_e(%7B%7D,'cvml','kilon.alios(a)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(a)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(a)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(a)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. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >

Nov. 11, 2014

Re: [Pharo-dev] Fwd: Webdoc: status?

by Stephan Eggermont

Philippe wrote: > I got it working and it is full of useful code. Tell me where you put it on smalltalkhub and I'll point the build to it. Stephan

Nov. 11, 2014