NAtiveBoost error
Locked
123
123
 
|
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 |
|
|
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]> wrote: Hi, -- Best regards,
Igor Stasenko. |
|
|
Oh, I see, I will try later, have to go for now.
Thank you so much :) 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 Igor Stasenko
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. |
|
|
On 4 November 2014 00:44, Alain Rastoul <[hidden email]> wrote: Hi Igor, I a mperplexified ... What is zmq sockets? Some kind of wrapper library? Then best i can
advise is to follow its guidelines, since i'm not familiar with it. Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, please read carefully NBExternalArray class comment, which explains all details.Thanks you -- Best regards,
Igor Stasenko. |
|
|
Le 04/11/2014 01:32, Igor Stasenko a écrit : > What is zmq sockets? Some kind of wrapper library? Then best i can > advise is to follow its guidelines, since i'm not familiar with it. > > Btw, using (NBExternalArray ofType: 'xyz') is highly expensive, > please read carefully NBExternalArray class comment, which explains all > details. > ZeroMQ is an open source asynchronous inter-process communication messaging library/framework written in c++ zeromq sockets should not have been called sockets because they are more 'endpoints' or something like that in zmq realms, however, it uses tcp sockets in my tests and has different behaviours on linux and windows, I suspect something different about underlying tcp sockets states. Thank you for the indication about performance, I will take it into account My first step is just to make experiments that works to be comfortable with both nativeboost and zeromq. This experiment is done with two different pharo vm processes (the client and the server) started manually, and the same in C. This library has nice patterns that makes it very interesting from a parallel computing perspective (request/response, publisher/subscriber, push/pull , etc). The guide is here and is worth looking at http://zguide.zeromq.org/page:all I know you will be interested in, it has similarities with your old hydra project :) |
|
|
Hi Alain,
This is nice that you are working on a zmq binding for Pharo. Is it public and on Sthub? Cheers, #Luc 2014-11-04 7:43 GMT+01:00 Alain Rastoul <[hidden email]>:
|
|
|
In reply to this post by Alain Rastoul-2
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 Luc Fabresse
> Hi Alain, > > This is nice that you are working on a zmq binding for Pharo. > Is it public and on Sthub? +1 |
|
|
In reply to this post by Alain Rastoul-2
On 4 November 2014 07:43, Alain Rastoul <[hidden email]> wrote:
Ah, ZeroMQ. Yes, it is a well-known library written in C++. Concerning your problems: i never used it, and i cannot even guess why it behaves differently on different platforms, perhaps you should contact library authors first? Do you create socket via zeromq library, do sockets managed through it? To make sockets to not block the VM, just using a nice library is not enough: you must wire the socket events with VM process scheduling logic through signaling the semaphores etc.. Else you must always use non-blocking calls in C library. Thank you for the indication about performance, I will take it into account Well, parallel computing is broad area.. with zillions goals and solutions. The setup you described is not what i wanted to achieve with Hydra. Running multiple instances of same VM ~= running single instance of VM which can manage multiple native threads. But sure thing you can achieve similar results using both approaches. The difference is in how fine grained your control over consumed resources, namely memory and CPU. -- Best regards,
Igor Stasenko. |
|
|
Le 04/11/2014 15:30, Igor Stasenko a écrit :
> > Do you create socket via zeromq library, do sockets managed through it? > yes > To make sockets to not block the VM, just using a nice library is not > enough: you must wire the socket events with VM process scheduling logic > through signaling the semaphores etc.. Else you must always use > non-blocking calls in C library. yes, this is done by zeromq, and one can specify blocking or non blocking socket option. By default (according to zeromq api) it should be blocking but it is not, I do not specify non blocking, but it is not blocking. > > Well, parallel computing is broad area.. with zillions goals and solutions. > The setup you described is not what i wanted to achieve with Hydra. Yes, I know, I know that you know, and now you know that I know that ... :) I made experiments with hydra in the past, I liked the idea very much. For now, personal circumstances allows me to have much more time to work on what interests me (still not enough but more than in the past) > Running multiple instances of same VM ~= running single instance of VM > which can manage multiple native threads. But sure thing you can > achieve similar results using both approaches. The difference is in how > fine grained your control over consumed resources, namely memory and CPU. > Working (more helping) on heavy load performance benchmarks on a very different platform (IIS, dotNet, MsSql), I got convinced that multiple single threaded programs could achieve at least the same or a higher throughput than the (even well written) single multi-threaded equivalent with a good nolocking behavior, less synchronisation and delays (semaphores, locks, critical sections), less cpu false sharing and cache invalidation... Regards, Alain > > > -- > Best regards, > Igor Stasenko. |
|
|
In reply to this post by stepharo
Those experiments are on smalltalkhub under DragonMQ with public access,
a there_be_dragon_here debuglog filler for now (will probably be renamed), at the stage of a raw binding and basic experiments to become used to zeromq, but at some point if it works well, it should ends up in a wrapper plus some object oriented api on top of it. Le 04/11/2014 10:45, stepharo a écrit : > >> Hi Alain, >> >> This is nice that you are working on a zmq binding for Pharo. >> Is it public and on Sthub? > > +1 > > > > |
|
|
oups, Dragon-ZeroMQ
Dragon is my personal debug_log_filler DragonMQ sounds well too :) Le 04/11/2014 19:48, Alain Rastoul a écrit : > Those experiments are on smalltalkhub under DragonMQ with public access, > a there_be_dragon_here debuglog filler for now (will probably > be renamed), > at the stage of a raw binding and basic experiments to become used > to zeromq, but at some point if it works well, it should ends up > in a wrapper plus some object oriented api on top of it. > > Le 04/11/2014 10:45, stepharo a écrit : >> >>> Hi Alain, >>> >>> This is nice that you are working on a zmq binding for Pharo. >>> Is it public and on Sthub? >> >> +1 >> >> >> >> > > > > |
|
|
In reply to this post by stepharo
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 >>> <[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. >> >> >> >> > > > |
|
|
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? ) )" ) 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]> wrote: Stef, |
|
|
please tell me where this could actually legitimately go.
On Friday, November 7, 2014, Kjell Godo <[hidden email]> wrote:
|
Re: NAtiveBoost error
|
|
In reply to this post by Kjell Godo
Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming.
Now, there are clean and less clean ways of doing object oriented design. But I too have a hard time accepting or understanding how a useful real world piece of software can be written without some form of state. Mathematical functions are easy, but once you have a number of closures over some captured and shared state, you basically have a object. Passing a world object into and returning it modified from pure functions becomes heavy too. The world is not black or white, but a complex form of grey. There are many good ideas in (pure) functional programming, you can use all of them in Smalltalk, if you want. > On 07 Nov 2014, at 16:51, Kjell Godo <[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]> 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 > <[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 Friday, November 7, 2014, Sven Van Caekenberghe <[hidden email]> wrote: Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming. Why do you say heavy. Are you talking about Haskell things that would be hard in Smalltalk? Or basic things that are hard in Haskell? When you say heavy do you mean slow or big? Smalltalk or Haskell. Usually the Haskellers talk about putting small pieces of data into a Monad Everything outside of the Monad is pure. or something. not sure. I'm not sure if the data inside of the Monad is acted upon by pure functions. I'm not quite sure why sticking state into a Monad unstateifies it. Why do Monads make state safe. Can Smalltalk have a Monad system? Should it?
|
|
|
In reply to this post by Sven Van Caekenberghe-2
Computing is not mathematical proof. It has to have side effect(s), else there will be no need to compute anything, if result is known beforehand.And who said that smalltalk is all about state? It is not. It is all about objects. " 90% of my life as a Smalltalker is state wrangling. I am a state herder. " it is fallacy.. you see only what object(s) wanna show you. if they would want to hide certain things (state) from your eyes, you won't even notice, nor will be able to retrieve it. Because you interacting with live objects, not with a dead state. -- Best regards,
Igor Stasenko. |
Re: NAtiveBoost error
|
|
In reply to this post by Kjell Godo
> On 07 Nov 2014, at 17:31, Kjell Godo <[hidden email]> wrote: > > > > On Friday, November 7, 2014, Sven Van Caekenberghe <[hidden email]> wrote: > Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming. > > Now, there are clean and less clean ways of doing object oriented design. > > But I too have a hard time accepting or understanding how a useful real world piece of software can be written without some form of state. Mathematical functions are easy, but once you have a number of closures over some captured and shared state, you basically have a object. Passing a world object into and returning it modified from pure functions becomes heavy too. > > Why do you say heavy. Like you said, what they do is pass state as a parameter and return a modified state, often a copy with modifications added. In the real world, this state parameter will quickly become quite complex. How is handling and tediously passing around such a thing better ? And how is it different than referring to self ? My opinion is that you can write beautiful object code with clear abstractions, hiding implementation details behind nice APIs. But it is equally possible to write spaghetti code. It is up to you. > Are you talking about Haskell things that would be hard in Smalltalk? > > Or basic things that are hard in Haskell? > > When you say heavy do you mean slow or big? Smalltalk or Haskell. > > Usually the Haskellers talk about putting small pieces of data into a Monad > > and then working on it in there. using bind and return. > > Everything outside of the Monad is pure. or something. not sure. > > I'm not sure if the data inside of the Monad is acted upon by pure functions. > > I'm not quite sure why sticking state into a Monad unstateifies it. > > Why do Monads make state safe. > > Can Smalltalk have a Monad system? Should it? > > > The world is not black or white, but a complex form of grey. > > There are many good ideas in (pure) functional programming, you can use all of them in Smalltalk, if you want. > > > On 07 Nov 2014, at 16:51, Kjell Godo <[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]> 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 > > <[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. > > > > > > > > > > > > > > > > > > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |