Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Designing complex Haskell programs (Courtney Robinson)
2. Re: Constrained polymorphic functions as natural
transformations (Matt R)
3. Re: "Segmentation fault/access violation" when working with
FFI (Leza Morais Lutonda)
----------------------------------------------------------------------
Message: 1
Date: Sun, 5 Jan 2014 16:43:25 +0000
From: Courtney Robinson <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Designing complex Haskell programs
Message-ID:
<CAGo6xJYLaA8ONpYHK=Ti=tcua8gnbbs3zmd2bmbhxpwtvgy...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Okay, thanks. I'll do that.
On Sun, Jan 5, 2014 at 10:56 AM, Bob Ippolito <[email protected]> wrote:
> Okay, for that kind of usage I think an MVar or something like it is your
> best bet, since it really does sound like global state:
>
> startServer :: NodeSettings -> IO ()
> startServer conf = do
> print "Bootstrapping, trying to reach configured seed nodes"
> clusterVar <- newMVar . G.bootstrapNode $ seedNodes conf
> print "Initializing Gossip"
> gossip clusterVar conf
> print "Listening for client connections"
> listenForClients clusterVar conf
> print "Server shutting down..."
>
> In the clients when you need to read the latest state of the cluster, you
> would use:
>
> cluster <- readMVar clusterVar
>
> To update the state, you might have something like this:
>
> modifyMVar_ clusterVar (\_oldCluster -> return newCluster)
>
>
>
>
> On Sun, Jan 5, 2014 at 12:42 AM, Courtney Robinson <[email protected]>wrote:
>
>> Didn't see your response, my gmail auto filter marks my haskell messages
>> as read and puts them in a folder so I have to explicitly check to see.
>> Anyway:
>>
>> The bit of code I'm stuck on is:
>> startServer :: NodeSettings -> IO ()
>> startServer conf = do
>> print "Bootstrapping, trying to reach configured seed nodes"
>> let cluster = G.bootstrapNode $ seedNodes conf
>> print "Initializing Gossip"
>> gossip cluster conf
>> print "Listening for client connections"
>> listenForClients cluster conf
>> print "Server shutting down..."
>>
>> The recursive version I had that was similar to yours has long since gone
>> because I couldn't get it to work.
>> bootstrapNode returns [RemoteNode].
>> So at the moment the cluster info is fetched once and that's it, where it
>> falls apart in my head is when I try to change this so that cluster is
>> updated every n seconds.
>>
>> listenForClients is on the main thread with each accepted connection run
>> with forkIO.
>>
>> All I came up with was after "gossip conf" , I could do
>> forkIO someFn where
>>
>> someFn = do
>> threadDelay n
>> let cluster = G.bootstrapNode $ seedNodes conf
>>
>> but obviously this doesn't work because my "gossip" and
>> "listenForClients" functions already have an immutable version of cluster.
>> So I'm not sure how to get the updated version to those fns.
>>
>> Bare in mind that listenForClients and gossip are doing something similar
>> to
>>
>> withSocketsDo $ do
>> sock <- listenOn $ PortNumber(fromInteger gossipPort)
>>
>> so only accepting a new connection causes those threads to do anything,
>> but when a connection is accepted, if the request demands the cluster data
>> those fns shouldn't go off gathering the data and shouldn't send the
>> (probably) out dated one from the initialization but instead the one that's
>> been updated every n in the background.
>>
>> Thanks
>>
>>
>> On Fri, Jan 3, 2014 at 6:17 PM, Bob Ippolito <[email protected]> wrote:
>>
>>> I wouldn't recommend going down the path of using IORef or MVar for
>>> everything, it's not easy to build robust systems that way. Do you mind
>>> showing the code that you tried that "fell apart"? I'm sure there's a
>>> slightly different way to structure it that would work just fine, probably
>>> using some kind of message passing.
>>>
>>>
>>> On Fri, Jan 3, 2014 at 9:57 AM, Courtney Robinson
>>> <[email protected]>wrote:
>>>
>>>> Thanks to both of you for your reply.
>>>> I have something similar to your example Bob, wasn't sure if it was a
>>>> good way forward. Plus it fell apart when I tried contacting multiple hosts
>>>> on different threads using forkIO. But with Daniel's response I'll look
>>>> into MVars.
>>>>
>>>> Thanks again
>>>>
>>>>
>>>> On Fri, Jan 3, 2014 at 5:16 PM, Bob Ippolito <[email protected]> wrote:
>>>>
>>>>> Generally speaking, state lives on the call stack in functional
>>>>> programming languages that have tail call elimination. Modification of the
>>>>> state is done by recursion with a new value for the state. This is more or
>>>>> less equivalent to a "do while" loop in imperative programming.
>>>>>
>>>>> myServer :: State -> IO ()
>>>>> myServer state = do
>>>>> state' <- updateState state
>>>>> myServer state'
>>>>>
>>>>> For the concurrency, Control.Concurrent or Cloud Haskell (for a higher
>>>>> level Erlang-like approach) is probably the way to go here. Parallel and
>>>>> Concurrent Programming in Haskell is a great resource:
>>>>> http://chimera.labs.oreilly.com/books/1230000000929
>>>>>
>>>>>
>>>>> On Fri, Jan 3, 2014 at 8:45 AM, Courtney Robinson <[email protected]
>>>>> > wrote:
>>>>>
>>>>>> I'm trying to take the training wheels of and moving more of my code
>>>>>> base to Haskell from C++ but finding it increasingly tricky.
>>>>>>
>>>>>> I have a subset of a gossip protocol written in C++.
>>>>>> When a server comes online it connects to 1 or more nodes already in
>>>>>> the cluster and get data from them about other nodes they know of.
>>>>>>
>>>>>> The new node merges the information and keeps a copy of the merged
>>>>>> view. Every so often it contacts the nodes it knows about and refreshes
>>>>>> the
>>>>>> merged view. It also must have the up to date view ready to be sent in
>>>>>> response to a new node joining.
>>>>>>
>>>>>> I currently can't wrap my head around how to maintain this state. How
>>>>>> would a more experienced Haskeller approach this problem? Code is OK if
>>>>>> it
>>>>>> demonstrates a particular point but I'm more interested in the line of
>>>>>> thought that would go into designing a solution as I suspect that'll be
>>>>>> more useful as I get further into the migration.
>>>>>>
>>>>>> As a gauge to you for my current level in Haskell. I read and
>>>>>> understand most Haskell programs fine. I write some but currently heavily
>>>>>> rely on hackage/hoogle docs for APIs, even some common ones.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> _______________________________________________
>>>>>> Beginners mailing list
>>>>>> [email protected]
>>>>>> http://www.haskell.org/mailman/listinfo/beginners
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Beginners mailing list
>>>>> [email protected]
>>>>> http://www.haskell.org/mailman/listinfo/beginners
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Courtney Robinson
>>>> [email protected]
>>>> http://crlog.info
>>>> 07535691628 (No private #s)
>>>>
>>>> _______________________________________________
>>>> Beginners mailing list
>>>> [email protected]
>>>> http://www.haskell.org/mailman/listinfo/beginners
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Beginners mailing list
>>> [email protected]
>>> http://www.haskell.org/mailman/listinfo/beginn<http://www.haskell.org/mailman/listinfo/beginners>
>>>
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
--
Courtney Robinson
[email protected]
http://crlog.info
07535691628 (No private #s)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140105/bf51f356/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 5 Jan 2014 20:01:56 +0000
From: Matt R <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Constrained polymorphic functions as
natural transformations
Message-ID:
<CA+ixoL=hy2w5b0thwuNV2B+6JxMGpsGFU4e4Juj-kCqawk9=m...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On 22 December 2013 20:26, Brent Yorgey <[email protected]> wrote:
> You have encoded a Foo dictionary as an Either Int a -> Either a Int
> function, but that is very different than saying that having a Foo
> dictionary is *equivalent* to having an Either Int a -> Either a Int
> function. They are not equivalent; in particular, you could have a
> function which sends Left 5 to Right 6, which does not correpond to
> anything in Foo. Put another way, if you try to write a Foo instance
> given only some unknown function of type (Either Int a -> Either a
> Int), you will find that you cannot do it. So my point stands that it
> is not always possible to *characterize* a type class as a natural
> transformation.
OK, I think see what you're saying: while you can represent any Foo
instance as an "Either Int a -> Either a Int", not every "Either Int a ->
Either a Int" represents a Foo instance.
I guess I was originally hoping to encode a bunch of equations into a
single one, so that rather than a collection of similar equations, one for
each function in the type class...
fmap f . foo == foo . fmap f
fmap f . bar == bar . fmap f
fmap f . baz == baz . fmap f
...you could encode the typeclass signature as some function "sig" and
express the same condition as a single equation (which would be true if and
only if the above equations were true):
fmap f . sig == sig . fmap f
I don't know if that's always possible. As you pointed out, you'd need
dinatural transformations in general, which I've had a look at, although I
confess I find it hard to get the same intuition about them as for regular
natural transformations. If you wanted to write that blog post, you'd have
at least one guaranteed keen reader ;-)
Cheers,
-- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140105/4a3e0e63/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 06 Jan 2014 03:23:28 -0800
From: Leza Morais Lutonda <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] "Segmentation fault/access violation"
when working with FFI
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
El 1/4/2014 23:50, Henk-Jan van Tuyl escribi?:
> As far as I can tell, there is no good solution for this. You can try
> to get a stack trace[0][1], or, at Haskell level, find the location
> error with the GHCi debugger[2]
>
> Check if you have the correct versions of dynamic libraries, if
> applicable. Note, that a missing dynamic library is not always
> reported properly; sometimes, GHCi mentions a missing dynamic library,
> while this is not reported when running a compiled program. For
> Windows, there are cygcheck and Dependency Walker to get an overview
> of the DLL dependencies.
>
> Another problem, that might arise, is a changed calling convention;
> the Haskell binding to PortAudio uses ccall, the PortAudio C software
> might have recently adopted a different calling convention.
>
> Regards,
> Henk-Jan van Tuyl
>
Thanks for the answer.
Fortunately I could solve the problem (infortunately without knowing
exactly what was causing it). I guess there is a bug in Sound.PortAudio
module that causes the problem.
What I did is to work directly with the bindings functions to the C Api
in module Sound.PortAudio.Base and make my own `play` function (maybe
some day publishing a package for easily playing and recording sound).
--
Leza Morais Lutonda
https://github.com/lemol
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 67, Issue 9
****************************************
