Le 07/11/2014 23:14, Eliot Miranda a écrit :
On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul <[email protected]
<mailto:[email protected]>> wrote:
Well, it looks like this thread have somewhat derailed :)
My initial question was about a problem I now think (but have to
confirm) is a vm system call signals side effects with socket polling
in zeroMQ code (remember this is the vmdev mailing list not the
smalltalk
user list).
I don't like zealots of any kind (object, relational, functional,
religious ...),
my pun was essentially a joke about trying to send a stateless
electron :o)
over a wire as a computation to someone's answer I suspect beeing
a troll (plug a chakra socket here for a zealot effect).
But electrons are not stateless; they have spin and energy ;-)
that was the point (the :o) smiley)
...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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
This is off topic.
I tried to post it as a top level thread but I have become
unknown.
I don't know if you want this crap in here but I have
decided not to
wait for the
postmaster to get back to me on the subject of becoming
known. Feel
free.
( Original-SUBJECT: "( picoVerse-:( what about state ,
is state
really evil? ) )" )
I am a Smalltalker.
But in the past few months i have been running with the
Haskellers.
The Haskellers hate state.
This seemed strange at first because as a Smalltalker i love(d)
state. State iswas my friend.
90% of my life as a Smalltalker is state wrangling. I am a
state
herder.
The debugger is my staff I use to whack the state. And
TestCase is
my sheep dog.
But to the Haskellers
state is
the evil trinity
of
satan the anti christ and the false prophet
all rolled into one.
State is the true dev incarnation of the total catastrophe of
development Armageddon.
Blood up to the bridles for hundreds of miles. Dogs and
cats living
together. Mass hysteria.
They say.
I'm not sure i quite get it yet but they keep preaching on
this one
point most of all.
State is evil.
You must keep all state in a Monad. As many
methods/functions m as
possible
must be 100% dependent on the input parameters ONLY.
No hidden instance variables affecting the return value of
m are
allowed.
The only effect m can have is to return a value.
If all this is true then m is pure.
And pure is good. Pure is very good. And the wind says
very.
So i wonder if any of you fellow
Smalltalkers
have thought about this at all.
Thanks
Kjell E Godø
(((((((((( Maybe Smalltalk should be called Statewalk
as in yak it up fuzz ball. ))))))))))
On Tuesday, November 4, 2014, Alain Rastoul
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>__> wrote:
Stef,
As I said to Igor, the main problem about NativeBoost
was between
the chair and the keyboard... :)
It is my first use of NativeBoost, I simply overlooked
the very good
existing chapter of EnterprisePharo on NativeBoost
(NativeBoost recipes, the X11 journey) and misused the
NativeBoost marshalling of data types.
NAtiveBoost is great.
If I achieve my experiments with zeromq and ends up with
something clean (not the case actually, and not my
first goal),
I will be glad to add a chapter about that.
My current problem is about a different socket
behaviour between
windows and linux.
I think this is not a problem with ZeroMQ, the C
program works
as expected,
I have to look for an explanation.
No stress about that
Alain
Le 04/11/2014 10:39, stepharo a écrit :
Alain
which nativeboost chapter :)?
Could you propose a paragraph so that we cover the
problem
you faced?
Stef
On 4/11/14 00:44, Alain Rastoul wrote:
Hi Igor,
Thank you for your answer, it worked perfectly
Looks like I overlooked the nativeboost chapter
.. 10 timesRepeatAfterMe: [self rtfm ] .
And my suggestion about testing nil was stupid,
much
better to fail soon.
... I am an ass on this one...
However, I am struggling on another point you
already
answered in the
past
in the mailing list to a guy who wanted to use
socket.io <http://socket.io>
<http://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
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>__>
wrote:
Hi,
I have a problem with a nativeboost
call, but
I don't see what I do
wrong.
library function prototype is:
int zmq_getsockopt (void *socket, int
option_name, void
*option_value, size_t *option_len);
my calling method in pharo is:
zmq_getsockopt: socket option_name:
option_name
option_value:
option_value option_len: option_len
<primitive: #primitiveNativeCall
module: #NativeBoostPlugin
error: errorCode>
^self nbCall: #(int
zmq_getsockopt
(void *socket, int
option_name, void * option_value, size_t*
option_len) )
when I call it with
...
optionValue := (NBExternalArray
ofType: 'int')
externalNew: 1.
optionLen := (NBExternalArray ofType:
'size_t'
) externalNew: 1.
[ optionValue at: 1 put: 0 .
optionLen at: 1 put:
(NBExternalType
sizeOf: 'int') .
rc := self zmq_getsockopt: socket
option_name: option_name
option_value: optionValue
option_len:
optionLen .
value := optionValue at: 1 .
] ensure: [ optionValue free.
optionLen free ].
...
I allways get an exception: "error
during FFI
call : nil"
After stepping in NBFFICallout
generation, I
found something
strange, the code
generation seems not to be called because
lastError stays at nil ?
handleFailureIn: aContext nativeCode:
aBlock
lastError := self getErrorFrom:
aContext lastError:
NativeBoost lastError.
>>getErrorFrom: aContext
lastError:
errorCode
... checks pragmas etc
>>getErrorFrom: aContext
lastError:
errorCode
... lastError :=
aContext
tempAt: method
numTemps.
=> lastError = nil ???
shouldn't be
ErrNoNativeCodeInMethod ?
"install native code and
retry the send"
lastError =
ErrNoNativeCodeInMethod
ifTrue: [ ^ self
generateCode:
aBlock andRetry:
aContext ].
never gets called ...
"ok, we're out of options,
signal an
error here"
^ self signalError: lastError
Could it be because I use this image
on windows
and unix ?
Or because I had an exception at prototype
parsing the first time
because I forgot a ; at the end of the
prototype ?
Is my prototype correct or is it the
origin of
the error ?
Is there a way to reset the lastError
(aContext tempAt: method
numTemps) ?
I will try to reset it in debugger but
may be
there is a cleaner
way ?
would it be ok to change the test in
handleFailure to
(lastError = ErrNoNativeCodeInMethod) or:[
lastError isNil ] ?
(I can open a bug in this case )
Any idea or comment is welcome
Thanks in advance
Alain
--
Best regards,
Igor Stasenko.
--
best,
Eliot
