Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Building xmonad / X11 fails on Mac OS X 10.11.3 El
Capitan. (Christoph R. Murauer)
2. Re: ODP: howto Pipe (PICCA Frederic-Emmanuel)
3. to avoid naming intermediate variables (Dennis Raddle)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Feb 2016 22:21:41 +0100
From: "Christoph R. Murauer" <n...@nawi.is>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] Building xmonad / X11 fails on Mac OS
X 10.11.3 El Capitan.
Message-ID: <5adde43c-9b1b-4ba3-824c-b9fc843d1...@nawi.is>
Content-Type: text/plain; charset=us-ascii
Solved. Documented at the xmonad mailing list.
------------------------------
Message: 2
Date: Mon, 22 Feb 2016 08:39:17 +0000
From: PICCA Frederic-Emmanuel
<frederic-emmanuel.pi...@synchrotron-soleil.fr>
To: "The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell" <beginners@haskell.org>
Subject: Re: [Haskell-beginners] ODP: howto Pipe
Message-ID:
<a2a20ec3b8560d408356cac2fc148e53b303b...@sun-dag3.synchrotron-soleil.fr>
Content-Type: text/plain; charset="us-ascii"
> First of all, (StateT Diffractometer (Pipe Engine Geometry IO) ())
> isn't the same as (Pipe Engine Geometry (StateT Diffractometer IO)
> ()), although I'm not sure what exactly the difference will be, as
> I've never used it the former way. This might be again a question for
> the Pipes mailing list.
ok, I will investigate this part :)
> Secondly:
> > but now if I remove the get and put lines, I get the segfault.
> Okay, I have no idea. As I see it, this shouldn't happen, as you're
> getting and putting the same pointer all the time. What if you remove
> the StateT altogether and just use the `dif` from the function
> argument, are you still getting segfaults? Also what about writting
> the function without using pipes, and using Pipes.mapM to make it a
> pipe like I mentioned? (if the only Pipes operation you're doing are
> an `await` in the beginning and a `yield` at the end, Pipes.mapM
> covers it)
Yes I get the segfault if I remove all the State Part and use directly the dif.
I think that I have something like this , I need to connect the life of one
foreignPtr to another one.
This is why I put them all into the Diffractometer data.
But it seems that this is not the magic bullet in order to garanty the same
life time for all of these foreignPtr.
I am wonderig if the fact that I use only one of the ForeignPtr in the
solveTrajPipe function does not give a clu to haskell that he just need to keep
a reference to the used one and get ride of the other one stored in dif.
withDiffractometer :: Diffractometer -> (Ptr HklEngineList -> IO b) -> IO b
withDiffractometer d fun = do
let f_engines = difEngineList d
withForeignPtr f_engines fun
then I extract a pointer from the engines one but as I am using the
withForeingPtr I think that it is ok.
I would say that I am not yet a specialist of FFI and haskell, but I love this
language a lot when I will manage this problem :))
solveTrajPipe' :: Diffractometer -> Pipe Engine Geometry IO ()
solveTrajPipe' dif = flip evalStateT dif $ forever $ do
-- Inside here we are using `StateT Int (Consumer a IO) r`
e <- lift await
-- dif <- get
let name = engineName e
solutions <- lift . lift $ withDiffractometer dif $ \engines ->
withCString name $ \cname -> do
engine <- c_hkl_engine_list_engine_get_by_name engines cname nullPtr
n <- c_hkl_engine_pseudo_axis_names_get engine >>= darrayStringLen
solve' engine n e >>= getSolution0
-- put dif
lift $ yield solutions
Cheers
Frederic
Ps: just for fun I got this adding just a lift print :)
:~/hkl/contrib/haskell$ cabal run
Preprocessing executable 'ghkl' for hkl-0.1.0.0...
[3 of 5] Compiling Hkl.C ( dist/build/ghkl/ghkl-tmp/Hkl/C.hs,
dist/build/ghkl/ghkl-tmp/Hkl/C.p_o )
src/Hkl/C.hsc:125:3:
Couldn't match kind `* -> *' with `*'
Expected type: Diffractometer -> Proxy () Engine () Geometry IO ()
Actual type: Diffractometer -> Proxy () Engine () Geometry IO ()
Kind incompatibility when matching types:
Diffractometer :: * -> *
Diffractometer :: *
The function `lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-unknown-linux):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
------------------------------
Message: 3
Date: Mon, 22 Feb 2016 00:40:53 -0800
From: Dennis Raddle <dennis.rad...@gmail.com>
To: Haskell Beginners <beginners@haskell.org>
Subject: [Haskell-beginners] to avoid naming intermediate variables
Message-ID:
<CAKxLvoqT6hfgNPRJF1_KSb=+txgmvgnxhfldb_w1ddzxw81...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I recently realized one important reason Haskell is so compact---it
provides structures that avoid the need to name intermediate variables. I
guess it's obvious, but coming from an imperative background I didn't see
this at first. I am starting to recognize situations where all the existing
wonderful typeclasses assist in eliminating variables.
Function composition is the simplest example. I sometimes write long chains
of composed functions. In an imperative language with a less compact
function call syntax, that would require so many parentheses that you would
probably break it over several statements, then forcing you to use more
variables.
Then I realized that Arrows allow a little more flexibility when you have
different numbers of arguments to feed, say when you split a single
argument into two, or want to construct a function that applies to one
argument and ignores the other.
...So I had to write something like this.
compute :: [Int] -> [Int] -> [Int] -> [(Int,Int)]
func :: [Int] -> [(Int,Int)]
func xs = compute xs (filter isSmall xs) (filter isLarge xs)
but I could also write
compute :: ([Int],([Int],[Int])) -> [(Int,Int)]
func = compute . (id &&& filter isSmall &&& filter isLarge)
So I had to change the inputs to 'compute' into this kind of awkward tuple
form, but I eliminated four 'xs', plus eliminated the need to come up with
the name 'xs'.
Can I get a comment on whether this makes sense as way to do things?
D
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20160222/15f9a64a/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 92, Issue 26
*****************************************
