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
<squeakl...@gmail.com
<mailto:squeakl...@gmail.com>> wrote:

This is off topic.

I tried to post it as a top level thread but I have become unknown.

I don't know if you want this crap in here but I have decided not to
wait for the

postmaster to get back to me on the subject of becoming known.  Feel free.





( Original-SUBJECT:     "( picoVerse-:( what about state , is state
really evil? ) )"       )






I am a Smalltalker.

But in the past few months i have been running with the Haskellers.

The Haskellers hate state.

This seemed strange at first because as a Smalltalker i love(d)
state.  State iswas my friend.

90% of my life as a Smalltalker is state wrangling.  I am a state herder.

The debugger is my staff I use to whack the state.  And TestCase is my
sheep dog.

But to the Haskellers

state is

the evil trinity

of

satan the anti christ and the false prophet

all rolled into one.

State is the true dev incarnation of the total catastrophe of
development Armageddon.

Blood up to the bridles for hundreds of miles.  Dogs and cats living
together.  Mass hysteria.

They say.

I'm not sure i quite get it yet but they keep preaching on this one
point most of all.

State is evil.

You must keep all state in a Monad.  As many methods/functions m as
possible

must be 100% dependent on the input parameters ONLY.

No hidden instance variables affecting the return value of m are allowed.

The only effect m can have is to return a value.

If all this is true then m is pure.

And pure is good.   Pure is very good.  And the wind says

very.

So i wonder if any of you fellow

Smalltalkers

have thought about this at all.

Thanks

Kjell E Godø









(((((((((( Maybe Smalltalk should be called Statewalk

as in yak it up fuzz ball. ))))))))))


On Tuesday, November 4, 2014, Alain Rastoul
<alf.mmm....@gmail.com
<mailto:alf.mmm....@gmail.com>> wrote:

    Stef,
    As I said to Igor, the main problem about NativeBoost was between
    the chair and the keyboard... :)
    It is my first use of NativeBoost, I simply overlooked the very good
    existing chapter of EnterprisePharo on NativeBoost
    (NativeBoost recipes, the X11 journey) and misused the
    NativeBoost marshalling of data types.
    NAtiveBoost is great.

    If I achieve my experiments with zeromq and ends up with
    something clean (not the case actually, and not my first goal),
    I will be glad to add  a chapter about that.

    My current problem is about a different socket behaviour between
    windows and linux.
    I think this is not a problem with ZeroMQ, the C program works as
    expected,
    I have to look for an explanation.
    No stress about that


    Alain


    Le 04/11/2014 10:39, stepharo a écrit :

        Alain

        which nativeboost chapter :)?
        Could you propose a paragraph so that we cover the problem you
        faced?

        Stef

        On 4/11/14 00:44, Alain Rastoul wrote:

            Hi Igor,

            Thank you for your answer, it worked perfectly
            Looks like I overlooked the nativeboost chapter
            .. 10 timesRepeatAfterMe: [self rtfm ] .
            And my suggestion about testing nil was stupid, much
            better to fail soon.
            ...  I am an ass on this one...

            However, I am struggling on another point you already
            answered in the
            past
            in the mailing list to a guy who wanted to use socket.io
            <http://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
                <alf.mmm....@gmail.com
                <mailto:alf.mmm....@gmail.com>>
                wrote:

                    Hi,

                    I have a problem with a nativeboost call, but  I
                don't see what I do
                    wrong.

                       library function prototype is:
                      int zmq_getsockopt (void *socket, int
                option_name, void
                    *option_value, size_t *option_len);

                    my calling method in pharo is:
                    zmq_getsockopt: socket option_name: option_name
                option_value:
                    option_value option_len: option_len
                             <primitive: #primitiveNativeCall module:
                #NativeBoostPlugin
                    error: errorCode>
                             ^self nbCall: #(int zmq_getsockopt (void
                *socket, int
                    option_name, void * option_value, size_t*
                option_len)  )

                    when I call it with
                    ...
                    optionValue := (NBExternalArray ofType: 'int')
                externalNew: 1.
                    optionLen := (NBExternalArray ofType: 'size_t' )
                externalNew: 1.
                    [       optionValue at: 1 put: 0 .
                             optionLen at: 1 put: (NBExternalType
                sizeOf: 'int')  .
                             rc := self zmq_getsockopt: socket
                option_name: option_name
                                             option_value:  optionValue
                                             option_len: optionLen  .
                             value := optionValue at: 1 .
                    ] ensure: [  optionValue free.
                                     optionLen free  ].
                    ...
                    I allways get an exception: "error during FFI call
                : nil"


                    After stepping in NBFFICallout generation, I found
                something
                    strange, the code
                    generation seems not to be called because
                lastError stays at nil ?

                    handleFailureIn: aContext nativeCode: aBlock
                             lastError := self getErrorFrom: aContext
                lastError:
                    NativeBoost lastError.

                             >>getErrorFrom: aContext lastError: errorCode
                              ...  checks  pragmas etc
                             >>getErrorFrom: aContext lastError: errorCode
                             ...             lastError := aContext
                tempAt: method
                numTemps.
                                     => lastError = nil ???  shouldn't be
                    ErrNoNativeCodeInMethod ?
                             "install native code and retry the send"
                             lastError = ErrNoNativeCodeInMethod
                                     ifTrue: [ ^ self generateCode:
                aBlock andRetry:
                    aContext ].
                          never gets called ...

                             "ok, we're out of options, signal an
                error here"
                             ^ self signalError: lastError

                    Could it be because I use this image on windows
                and unix ?
                    Or because I had an exception at prototype parsing
                the first time
                    because I forgot a ; at the end of the prototype ?

                    Is my prototype correct or is it the origin of the
                error ?
                    Is there a way to reset the lastError (aContext
                tempAt: method
                    numTemps) ?
                    I will try to reset it in debugger but may be
                there is a cleaner
                way ?
                    would it be ok to change  the test in handleFailure to
                    (lastError = ErrNoNativeCodeInMethod) or:[
                lastError isNil ] ?
                    (I can open a bug in this case )

                    Any idea or comment is welcome
                    Thanks in advance

                    Alain





                --
                Best regards,
                Igor Stasenko.















Reply via email to