NAtiveBoost error
Locked
123
123
 
|
Hmm… to me this mail looks like it is written by a Bot ? e.g. in a mailing list everyone can start a top level thread. unknown users can not post at all. And I am the “postmaster” of this list and I have not gotten any requests at all...
|
|
|
yeah,
big electron computation over the wire will tell open your chakras to monads or die :) Le 07/11/2014 19:03, Marcus Denker a écrit : > > Hmm… to me this mail looks like it is written by a Bot ? > > e.g. in a mailing list everyone can start a top level thread. unknown users > can not post at all. > > And I am the “postmaster” of this list and I have not gotten any > requests at all... > > >> On 07 Nov 2014, at 16:51, Kjell Godo >> <[hidden email] >> <mailto:[hidden email]>> 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 >> <[hidden email] >> <mailto:[hidden email]>> 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 >> <[hidden email] >> <mailto:[hidden email]>> >> 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. >> >> >> >> >> >> >> >> >> >> >> > |
|
|
In reply to this post by Alain Rastoul-2
On 4/11/14 20:30, Alain Rastoul 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. ok je le note ;) > > 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 >>>> <[hidden email] >>>> <mailto:[hidden email]>> 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. >>> >>> >>> >>> >> >> >> > > > > |
|
In reply to this post by Kjell Godo
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 <[hidden email]> 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). 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 > <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] > <mailto:[hidden email]>> 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 > <[hidden email] > <mailto:[hidden email]>> > 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. > > > > > > > > > > > > |
|
|
On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul <[hidden email]> wrote: Well, it looks like this thread have somewhat derailed :) 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, best,
Eliot |
|
|
Le 07/11/2014 23:14, Eliot Miranda a écrit :
> > > On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul <[hidden email] > <mailto:[hidden email]>> 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 ;-) ...how far we go :) > > 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 > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] <mailto:[hidden email]>>> 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 > <[hidden email] <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>__> 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://socket.io> : > > (http://forum.world.st/socket-____io-td3891592.html#a3893031 > <http://forum.world.st/socket-__io-td3891592.html#a3893031> > > <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 > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>__> > 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 |
|
|
In reply to this post by stepharo
Le 07/11/2014 21:11, stepharo a écrit :
> > On 4/11/14 20:30, Alain Rastoul 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. > > ok je le note ;) > But to be honest, I am very disappointed with zeroMQ library, not what I was expecting reading docs and books (some hype, not only sure but some), lots of asserts in code like unlikely(condition), return code tests not clear, looks very fragile, breakable and somewhat uncertain (and often crashed). In fact about the linux problem, I suspect (really not sure yet) a side effect with the pharo vm signals, that should not be the case for a library. Reading some posts and answers about python interfacing problems, I think ZeroMQ works well in a program that is designed to use it and only. It may work well with other systems, but not designed in that mindset (assertions in posts like : failing here must abort the program?!). Things that make me think that zeroMQ is probably not a reliable thing to use in Pharo. Plus the only answer I had on the mq list was my own answer (or comment) on debugging the library :( BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too. >> >> 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 >>>>> <[hidden email] >>>>> <mailto:[hidden email]>> 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. >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > |
Re: NAtiveBoost error
|
|
> On 08 Nov 2014, at 00:23, Alain Rastoul <[hidden email]> wrote: > > BTW, I have the websocket B plan for that (first tests make me > think it could be a better plan for my needs). > It will be a different animal, but interesting too. About Zinc Web Sockets: https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md But there is also 'STAMP', a STOMP implementation, which is a generic message queue client: https://github.com/svenvc/docs/blob/master/neo/stamp.md Both are pure Pharo. Sven |
Musings (Was: NAtiveBoost error)
|
|
In reply to this post by Kjell Godo
Why do you expect that? Many people here are using Smalltalk for years. Just because you have been silent for some time doesn’t mean everybody will forget about you :)
First, there are no good definitions of what is an object oriented language and what is a functional language. Thus, languages like C++, C#, Java are being considered object oriented. But their object orientation is not the same like Smalltalk’s. The same problem exists in the functional language world: Some consider LISP being functional, some deny that. Second, for some years I am constantly seeking for „the best“ language to solve my problems in. Alas I wasn’t successful yet and don’t expect to be successful in the future. Every programming paradigm has its strengths and weaknesses when it comes to real world problems. So in my eyes it is best to know the different programming paradigms and its representative languages in order to be able to choose the best fitting language for your problem at hand. Third, there have been many attempts to create multi-paradigm languages (like C++, C#, Java, Scala, …). The idea behind is simple: combine the best characteristics. In my eyes all of them failed because what always have been created is Frankenstein’s monster. When you combine paradigms you will may get some advantages of all but sure you will get a lot of additional complexity. Fourth, it has been said many times before: What makes Smalltalk so nice is not only the language. It’s the whole system: the language, duck typing, the image (object world), the tools, the VM, the simplicity, the elegance, … And last but not least the communities around. Regards Andreas PS: If you are interested in functional programming and don’t like static typing you should have a look at Clojure. It has some nice ideas about how to deal with state concurrently.
|
|
|
In reply to this post by Sven Van Caekenberghe-2
Very interesting pointers, thank you Sven.
Pure Pharo sounds really good to me, I lost my appetite for debugging multithreaded C or C++ (am I aging ?) and I need some kind of MOM functionality for my project, that was the starting point of my ZeroMQ rants. In fact, I am looking for a "SOM" (streaming) server as a part of my musing project which is about clustering and parallel processing with pharo: essentially next, nextput: functionalities to PUSH/PULL pools (may be PUB/SUB REQ/RECV or others?) with some controlling, signaling and monitoring. I have the feeling that based on your excellent work in zinc, it should not be that difficult to built it on top, but may be you know a project of that kind I could reuse ? Do you know about some kind of MOM server in Pharo ? Or a STOMP or alike server I could vampirize ? Thank you Alain Le 08/11/2014 09:09, Sven Van Caekenberghe a écrit : > >> On 08 Nov 2014, at 00:23, Alain Rastoul <[hidden email]> wrote: >> >> BTW, I have the websocket B plan for that (first tests make me >> think it could be a better plan for my needs). >> It will be a different animal, but interesting too. > > About Zinc Web Sockets: > > https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md > > But there is also 'STAMP', a STOMP implementation, which is a generic message queue client: > > https://github.com/svenvc/docs/blob/master/neo/stamp.md > > Both are pure Pharo. > > Sven > |
|
|
I have been using Pharo successfully with RabbitMQ. Phil Le 8 nov. 2014 10:16, "Alain Rastoul" <[hidden email]> a écrit :
Very interesting pointers, thank you Sven. |
|
|
Hi Phil,
Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack what I am looking for is streaming (on top of a queuing server I presume). Regards, Alain Le 08/11/2014 10:43, [hidden email] a écrit : > I have been using Pharo successfully with RabbitMQ. > > Phil > > Le 8 nov. 2014 10:16, "Alain Rastoul" > <[hidden email] > <mailto:[hidden email]>> a écrit : > > Very interesting pointers, thank you Sven. > Pure Pharo sounds really good to me, I lost my appetite for > debugging multithreaded C or C++ > (am I aging ?) and I need some kind of MOM functionality for my > project, that was the > starting point of my ZeroMQ rants. > In fact, I am looking for a "SOM" (streaming) server as a part of my > musing project > which is about clustering and parallel processing with pharo: > essentially next, nextput: functionalities to PUSH/PULL pools > (may be PUB/SUB REQ/RECV or others?) with some controlling, > signaling and monitoring. > I have the feeling that based on your excellent work in zinc, it should > not be that difficult to built it on top, but may be you know a > project of that kind > I could reuse ? > Do you know about some kind of MOM server in Pharo ? > Or a STOMP or alike server I could vampirize ? > > Thank you > > Alain > > Le 08/11/2014 09:09, Sven Van Caekenberghe a écrit : > > > On 08 Nov 2014, at 00:23, Alain Rastoul > <[hidden email] > <mailto:[hidden email]>> wrote: > > BTW, I have the websocket B plan for that (first tests make me > think it could be a better plan for my needs). > It will be a different animal, but interesting too. > > > About Zinc Web Sockets: > > https://github.com/svenvc/__docs/blob/master/zinc/zinc-__websockets-paper.md > <https://github.com/svenvc/docs/blob/master/zinc/zinc-websockets-paper.md> > > But there is also 'STAMP', a STOMP implementation, which is a > generic message queue client: > > https://github.com/svenvc/__docs/blob/master/neo/stamp.md > <https://github.com/svenvc/docs/blob/master/neo/stamp.md> > > Both are pure Pharo. > > Sven > > > > |
Re: NAtiveBoost error
|
|
> On 08 Nov 2014, at 10:56, Alain Rastoul <[hidden email]> wrote: > > Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM > (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack > what I am looking for is streaming (on top of a queuing server I presume). RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. |
|
|
Perfectly correct, I agree,
and do you have an opinion or pointers about building a streaming server in pharo ? queuing send/receives (nextPut:, next) from producers and consumers ? Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :> >> On 08 Nov 2014, at 10:56, Alain Rastoul <[hidden email]> wrote: >> >> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >> what I am looking for is streaming (on top of a queuing server I presume). > > RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. > > Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. > |
Re: NAtiveBoost error
|
|
> On 08 Nov 2014, at 11:21, Alain Rastoul <[hidden email]> wrote: > > Perfectly correct, I agree, > and do you have an opinion or pointers about building a streaming server in pharo ? > queuing send/receives (nextPut:, next) from producers and consumers ? Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md Don't forget to read a bit about RabbitMQ itself too. You can load the code and look at the tests. > Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :> >>> On 08 Nov 2014, at 10:56, Alain Rastoul <[hidden email]> wrote: >>> >>> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >>> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >>> what I am looking for is streaming (on top of a queuing server I presume). >> >> RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. >> >> Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. >> > > > |
|
|
About RabbitMQ and others, I did quite some investigations and already
use some (working with MSMQ in dotnet at work). I could spend months here but would not like to. My last question (in fact my real interrogation) here is especially to you, as the Zn developer, about a server implementation in pharo: not a true generic enterprise class server, a very small and simple dedicated server to start with, like Teapot is with respects to a big http enterprise class server. I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. (*): except for the reusing part that of course has to be taken into account, for example websockets. Does it sounds realistic to you or totally undoable, and why ? Did you made experiments in that direction ? What would be your opinion, and do you have thoughts to share about that ? Thanks in advance Regards, Alain Le 08/11/2014 11:25, Sven Van Caekenberghe a écrit : > >> On 08 Nov 2014, at 11:21, Alain Rastoul <[hidden email]> wrote: >> >> Perfectly correct, I agree, >> and do you have an opinion or pointers about building a streaming server in pharo ? >> queuing send/receives (nextPut:, next) from producers and consumers ? > > Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md > Don't forget to read a bit about RabbitMQ itself too. > You can load the code and look at the tests. > >> Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :> >>>> On 08 Nov 2014, at 10:56, Alain Rastoul <[hidden email]> wrote: >>>> >>>> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >>>> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >>>> what I am looking for is streaming (on top of a queuing server I presume). >>> >>> RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. >>> >>> Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. >>> >> >> >> > > > |
Re: NAtiveBoost error
|
|
> On 08 Nov 2014, at 12:33, Alain Rastoul <[hidden email]> wrote: > > About RabbitMQ and others, I did quite some investigations and already use some > (working with MSMQ in dotnet at work). > I could spend months here but would not like to. > > My last question (in fact my real interrogation) here is especially to you, as the Zn developer, > about a server implementation in pharo: > not a true generic enterprise class server, > a very small and simple dedicated server to start with, > like Teapot is with respects to a big http enterprise class server. > I don't really mind not following existing MQ protocols and RFCs (*), it would be dedicated. > (*): except for the reusing part that of course has to be taken into account, > for example websockets. > > Does it sounds realistic to you or totally undoable, and why ? > Did you made experiments in that direction ? > What would be your opinion, and do you have thoughts to share about that ? > > Thanks in advance Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. I don't know what you are looking for, I would just do some prototyping and see what happens. > Regards, > Alain > > Le 08/11/2014 11:25, Sven Van Caekenberghe a écrit : >> >>> On 08 Nov 2014, at 11:21, Alain Rastoul <[hidden email]> wrote: >>> >>> Perfectly correct, I agree, >>> and do you have an opinion or pointers about building a streaming server in pharo ? >>> queuing send/receives (nextPut:, next) from producers and consumers ? >> >> Please start by reading https://github.com/svenvc/docs/blob/master/neo/stamp.md >> Don't forget to read a bit about RabbitMQ itself too. >> You can load the code and look at the tests. >> >>> Le 08/11/2014 11:09, Sven Van Caekenberghe a écrit :> >>>>> On 08 Nov 2014, at 10:56, Alain Rastoul <[hidden email]> wrote: >>>>> >>>>> Thank you for reporting this, I have considered using RabbitMQ or other kind of MOM >>>>> (apacheMQ, other JMS or other implementations) but I tend to prefer a full pharo stack >>>>> what I am looking for is streaming (on top of a queuing server I presume). >>>> >>>> RabbitMQ _is_ the queueing server. STAMP/STOMP is a client for both producers and consumers. >>>> >>>> Yes, it is an extra dependency, just like a database, a shared memory cache, a proxy, etc. It fits in the enterprise world view. >>>> >>> >>> >>> >> >> >> > > > |
|
|
Le 08/11/2014 17:14, Sven Van Caekenberghe a écrit :
> Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. > > I don't know what you are looking for, I would just do some prototyping and see what happens. Thanks, somewhat what I'm thinking. To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? May be the question was not clear or too broad, apologizes, this is my fault. About protocols, I tend to be focused on what I want to do and know I'm wrong here. Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? ... given that you are good at networking stuff, that would be great :) I have loaded your stamp package (very nice), and ran it against rabbitmq . If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? or should I publish my own package ? What is the best practice with SmalltalkHub and what do you prefer ? No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. TIA regards, Alain |
Re: NAtiveBoost error
|
|
> On 10 Nov 2014, at 19:07, Alain Rastoul <[hidden email]> wrote: > > Le 08/11/2014 17:14, Sven Van Caekenberghe a écrit : > >> Zn implements both classic HTTP client & server functionality as well as WebSockets client & server functionality - based on the known standards. It all works pretty well. You can build various things on top of that. You can get quite far performance wise, but it is definitively slower than highly optimised C or C++ code. I think that does not matter in most cases as the network overhead is always a factor. >> >> I don't know what you are looking for, I would just do some prototyping and see what happens. > > Thanks, somewhat what I'm thinking. > > To me , 'highly optimized C or C++' is not a clear advantage, because as you said, there is some network latency (although nearly none when clustered VMs are running under the same hypervisor and physical hardware), but also because other MQ systems are not all written in C or C++. > Knowing that RabbitMQ is written in erlang and ActiveMQ in java, what do you think about Pharo here was my kind of question. > I was also asking about networking or vm issues (processes, or sockets) you could be thinking of, if any ? > May be the question was not clear or too broad, apologizes, this is my fault. > > About protocols, I tend to be focused on what I want to do and know I'm wrong here. > Do you have plans about implementing more elaborated (and complex) protocols like openwire or amqp ? > ... given that you are good at networking stuff, that would be great :) At the moment I have no plans in this direction. Writing something is not the biggest problem. Documentation, making it somewhat feature complete, supporting it for years, fulfilling requests, that is much more work. It is an ongoing responsibility. > I have loaded your stamp package (very nice), and ran it against rabbitmq . > If I do some benchmarking code against the rabbit, should I put the code in Stamp package and commit to stamp package ? > or should I publish my own package ? > What is the best practice with SmalltalkHub and what do you prefer ? > No problem to publish a new package or to add it to Stamp, whatever you advise me, I'm not familiar with Pharo community practices and need some guidance here. It (Stamp) is open source. Feedback and contributions are most welcome. There is already some benchmarking in there if I remember correctly. You can continue discussing it in this mailing list (but maybe under a different thread). > TIA > > regards, > Alain > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |