- Haskell-Cafe - Haskell.org

System.Win32.Registry... Help?
by Dave Buznik 22 Jul '12

22 Jul '12

---------- Forwarded message ---------- From: Anonymous Void <bitsofchaos(a)gmail.com> Date: Sun, Jul 22, 2012 at 2:10 AM Subject: Re: [Haskell-cafe] System.Win32.Registry... Help? To: Tim Matthews <tim.matthews7(a)gmail.com> I've looked into their docs, but I can't for the life of me figure out how to convert a string to lptstr, for example: set_key :: HKEY -> String -> String -> IO () set_key cat loc key = do foo <- okey regSetValueEx foo "foo" rEG_SZ "foo" 0 where okey = regOpenKeyEx cat loc kEY_ALL_ACCESS will give me an error about it expecting LPTSTR and not [char] for "foo", but I have no idea how to convert the c/win32 types using Haskell, and msdn docs aren't helping any... I know in Python the following works, but I don't want to use Python for this app... key = OpenKey(HKEY_CURRENT_USER, "Software\\7-Zip", 0, KEY_ALL_ACCESS) SetValueEx(key, "test", 0, REG_SZ, "foobar") CloseKey(key) but that's basically where I'm stuck at right now, I've searched but wasn't able to find one single use case of regSetValueEx in Haskell, otherwise I'd be done already... I've been stuck on this for days and it's a two-hour app... I'm ashamed. LOL. On Sun, Jul 22, 2012 at 1:44 AM, Tim Matthews <tim.matthews7(a)gmail.com> wrote: > > > On Sun, Jul 22, 2012 at 5:43 PM, Tim Matthews <tim.matthews7(a)gmail.com> > wrote: >> >> >> >> On Sun, Jul 22, 2012 at 5:11 PM, Anonymous Void <bitsofchaos(a)gmail.com> >> wrote: >>> >>> >>> but I have no idea what to put into some of the arguments for >>> regSetValueEx or regCreateKeyEx, >> >> >> Those are just plain bindings to windows function so refer to msdn > > -- mysql> insert into female (vagina) select male.penis from male where penis='sperm'; Query OK, 1 row affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> select * from female; +--------+ | vagina | +--------+ | sperm | +--------+ 1 row in set (0.00 sec) mysql> ... N' that's how programmers make babies.

2 1

Re: [Haskell-cafe] System.Win32.Registry... Help?
by Tim Matthews 21 Jul '12

21 Jul '12

On Sun, Jul 22, 2012 at 5:43 PM, Tim Matthews <tim.matthews7(a)gmail.com>wrote: > > > On Sun, Jul 22, 2012 at 5:11 PM, Anonymous Void <bitsofchaos(a)gmail.com>wrote: > >> >> but I have no idea what to put into some of the arguments for >> regSetValueEx or regCreateKeyEx, >> > > Those are just plain bindings to windows function so refer to msdn > <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724923%28v=vs.85%…> >

1 0

Darcs / ByteString optimisation
by Luke Worth 21 Jul '12

21 Jul '12

Hi, I'm currently investigating darcs' performance issues. The first thing I looked at was ByteString.concat, which seems to allocate a lot of extra objects. Here is the standard definition: >concat :: [ByteString] -> ByteString >concat [] = empty >concat [ps] = ps >concat xs = unsafeCreate len $ \ptr -> go xs ptr > where len = P.sum . P.map length $ xs > go a b | a `seq` b `seq` False = undefined > go [] _ = return () > go (PS p s l:ps) ptr = do > withForeignPtr p $ \fp -> memcpy ptr (fp `plusPtr` s) (fromIntegral l) > go ps (ptr `plusPtr` l) I had a bad feeling about (sum . map) inside len, so I replaced it (inside darcs) with a stricter-looking one: >myconcat :: [B.ByteString] -> B.ByteString >myconcat [] = B.empty >myconcat [ps] = ps >myconcat xs = BI.unsafeCreate len $ \ptr -> go xs ptr > where len = foldl' (\a b -> a + B.length b) 0 xs > go a b | a `seq` b `seq` False = undefined > go [] _ = return () > go (BI.PS p s l:ps) ptr = do > withForeignPtr p $ \fp -> BI.memcpy ptr (fp `plusPtr` s) (fromIntegral l) > go ps (ptr `plusPtr` l) Profiling the original one gives me 2,042,215,624 bytes allocated in the heap 3,131,672,496 bytes copied during GC 363,380,328 bytes maximum residency (43 sample(s)) 2,517,336 bytes maximum slop 643 MB total memory in use (50 MB lost due to fragmentation) while the second, with no other changes, gives 1,774,403,640 bytes allocated in the heap 2,656,774,296 bytes copied during GC 358,131,264 bytes maximum residency (42 sample(s)) 1,577,080 bytes maximum slop 614 MB total memory in use (50 MB lost due to fragmentation) Is it possible that the code using ByteString.concat is preventing the compiler from doing this optimisation? Thankyou, Luke Worth

1 0

Re: [Haskell-cafe] Monads with "The" contexts?
by oleg＠okmij.org 21 Jul '12

21 Jul '12

The bad news is that indeed you don't seem to be able to do what you want. The good news: yes, you can. The enclosed code does exactly what you wanted: > sunPerMars :: NonDet Double > sunPerMars = (/) <$> sunMass <*> marsMass > > sunPerMars_run = runShare sunPerMars > sunPerMars_run_len = length sunPerMars_run > -- 27 where earthMass, sunMass, marsMass are all top-level bindings, which can be defined in separate and separately-compiled modules. Let's start with the bad news however. Recall the original problem: > earthMass, sunMass, marsMass :: [Double] > earthMass = [5.96e24, 5.97e24, 5.98e24] > sunMass = (*) <$> [2.5e5, 3e5, 4e5] <*> earthMass > marsMass = (*) <$> [0.01, 0.1, 1.0] <*> earthMass The problem was that the computation sunPerMars = (/) <$> sunMass <*> marsMass produces too many answers, because earthMass in sunMass and earthMass in marsMass were independent non-deterministic computations. Thus the code says: we measure the earthMass to compute sunMass, and we measure earthMass again to compute marsMass. Each earthMass measurement is independent and gives us, in general, a different value. However, we wanted the code to behave differently. We wanted to measure earthMass only once, and use the same measured value to compute masses of other bodies. There does not seem to be a way to do that in Haskell. Haskell is pure, so we can substitute equals for equals. earthMass is equal to [5.96e24, 5.97e24, 5.98e24]. Thus the meaning of program should not change if we write > sunMass = (*) <$> [2.5e5, 3e5, 4e5] <*> [5.96e24, 5.97e24, 5.98e24] > marsMass = (*) <$> [0.01, 0.1, 1.0] <*> [5.96e24, 5.97e24, 5.98e24] which gives exactly the wrong behavior (and 81 answers for sunPerMars, as easy to see). Thus there is no hope that the original code should behave any differently. > I don't know if memo can solve this problem. I have to test. Is the > `memo` in your JFP paper section 4.2 Memoization, a psuedo-code? (What > is type `Thunk` ?) and seems like it's not in explicit-sharing > hackage. BTW, the memo in Hansei is different from the memo in the JFP paper. In JFP, memo is a restricted version of share: memo_jfp :: m a -> m (m a) In Hansei, memo is a generalization of share: memo_hansei :: (a -> m b) -> m (a -> m b) You will soon need that generalization (which is not mention in the JFP paper). Given such a let-down, is there any hope at all? Recall, if Haskell doesn't do what you want, embed a language that does. The solution becomes straightforward then. (Please see the enclosed code). Exercise: how does the approach in the code relate to the approaches to sharing explained in http://okmij.org/ftp/tagless-final/sharing/sharing.html Good luck with the contest! {-# LANGUAGE FlexibleContexts, DeriveDataTypeable #-} -- Sharing of top-level bindings -- Solving Takayuki Muranushi's problem -- http://www.haskell.org/pipermail/haskell-cafe/2012-July/102287.html module TopSharing where import qualified Data.Map as M import Control.Monad.State import Data.Dynamic import Control.Applicative -- Let's pretend this is one separate module. -- It exports earthMass, the mass of the Earth, which -- is a non-deterministic computation producing Double. -- The non-determinism reflects our uncertainty about the mass. -- Exercise: why do we need the seemingly redundant EarthMass -- and deriving Typeable? -- Could we use TemplateHaskell instead? data EarthMass deriving Typeable earthMass :: NonDet Double earthMass = memoSta (typeOf (undefined::EarthMass)) $ msum $ map return [5.96e24, 5.97e24, 5.98e24] -- Let's pretend this is another separate module -- It imports earthMass and exports sunMass -- Muranushi: ``Let's also pretend that we can measure the other -- bodies' masses only by their ratio to the Earth mass, and -- the measurements have large uncertainties.'' data SunMass deriving Typeable sunMass :: NonDet Double sunMass = memoSta (typeOf (undefined::SunMass)) mass where mass = (*) <$> proportion <*> earthMass proportion = msum $ map return [2.5e5, 3e5, 4e5] -- Let's pretend this is yet another separate module -- It imports earthMass and exports marsMass data MarsMass deriving Typeable marsMass :: NonDet Double marsMass = memoSta (typeOf (undefined::MarsMass)) mass where mass = (*) <$> proportion <*> earthMass proportion = msum $ map return [0.01, 0.1, 1.0] -- This is the main module, importing the masses of the three bodies -- It computes ``how many Mars mass object can we create -- by taking the sun apart?'' -- This code is exactly the same as in Takayuki Muranushi's message -- His question: ``Is there a way to represent this? -- For example, can we define earthMass'' , sunMass'' , marsMass'' all -- in separate modules, and yet have (length $ sunPerMars'' == 27) ? sunPerMars :: NonDet Double sunPerMars = (/) <$> sunMass <*> marsMass sunPerMars_run = runShare sunPerMars sunPerMars_run_len = length sunPerMars_run -- 27 -- The following is essentially Control.Monad.Sharing.Memoization -- with one important addition -- Can you spot the important addition? type NonDet a = StateT FirstClassStore [] a data Key = KeyDyn Int | KeySta TypeRep deriving (Show, Ord, Eq) -- I wish TypeRep were in Ord by default. The implementation permits that! instance Ord TypeRep where compare x y = compare (show x) (show y) data FirstClassStore = FirstClassStore { freshKey :: Int, store :: M.Map Key Dynamic } emptyStore :: FirstClassStore emptyStore = FirstClassStore { freshKey = 1, store = M.empty } getFreshKey :: MonadState FirstClassStore m => m Key getFreshKey = do key <- gets freshKey modify (\s -> s { freshKey = succ key }) return (KeyDyn key) insertVal :: (Typeable a, MonadState FirstClassStore m) => Key -> a -> m () insertVal key val = modify (\s -> s { store = M.insert key (toDyn val) (store s) }) lookupVal :: (Typeable a, MonadState FirstClassStore m) => Key -> m (Maybe a) lookupVal key = liftM (liftM (flip fromDyn err) . M.lookup key) (gets store) where err = error $ "lookupVal: bad key " ++ show key memo :: (Typeable a, MonadState FirstClassStore m) => m a -> m (m a) memo a = getFreshKey >>= \key -> return (memoKey key a) memoSta :: (Typeable a, MonadState FirstClassStore m) => TypeRep -> m a -> m a memoSta trep a = memoKey (KeySta trep) a memoKey :: (Typeable a, MonadState FirstClassStore m) => Key -> m a -> m a memoKey key a = do valM <- lookupVal key case valM of Just x -> return x Nothing -> do x <- a insertVal key $! x return x runShare :: Monad m => StateT FirstClassStore m a -> m a runShare m = evalStateT m emptyStore -- In My GHC, StateT is still not an Applicative. More bolierplate instance Monad m => Applicative (StateT s m) where pure = return (<*>) = liftM2 ($)

2 5

Cloud Haskell Appetiser: a taste of distributed programming in Haskell
by Eric Kow 21 Jul '12

21 Jul '12

HTML version: http://www.well-typed.com/blog/68 # Cloud Haskell Appetiser: (part 2 of Parallel Haskell Digest 11) Hello Haskellers! We mentioned in the [last digest][phd-11] that we'd have just a tiny bit more to say about Parallel Haskell. As promised, here is the completed word of month on *actors* and their use in Cloud Haskell. It so happens — what a coincidence! — that Well-Typed's Edsko de Vries has recently published a beta version of the new [distributed-process][dp-announce] implementation on Hackage. We'd love it if you could give it a try let us know any trouble you ran into or ways we could improve things. To help push things along a bit, this word of month will be using the new distributed-process implementation. Also, have you had a chance to fill out the Parallel Haskell Digest Survey? It's collecting data for another couple of weeks. Anything you can tell us in the survey will inform future efforts in building the Haskell community, so if you've got a couple of minutes before Cloud Haskell Time, head over to [Parallel Haskell Digest Survey](http://goo.gl/bP2fn) Many thanks! ## Word of the month The word of the month series has given us a chance to survey the arsenal of Haskell parallelism and concurrency constructs: * some low level foundations (sparks and threads), * three ways to do parallelism (parallel arrays, strategies, dataflow), * and some concurrency abstractions (locks, transactions, channels) The Haskell approach has been to explicitly recognise the vastness of the parallelism/concurrency space, in other words, to provide a multitude of right tools for a multitude of right jobs. Better still, the tools we have are largely interoperable, should we find ourselves with jobs that don't neatly fit into a single category. The Haskell of 2012 may be in a great place for parallelism and concurrency, but don't think this is the end of the story! What we've seen so far is only a snapshot of the technology as it hurtles through the twenty-tens (How quaint are we, Future Haskeller?). While we can't say what exactly the future will bring, we can look at one of the directions that Haskell might branch into in the coming decade. The series so far has focused on things you might do with a single computer, using parallelism to speed up your software, or using concurrency abstractions to preserve your sanity in the face of non-determinism. But now what if you have more than one computer? ### Actors Our final word of the month is *actor*. Actors are not specific to distributed programming; they are really more of a low level concurrency abstraction on a par with threads. And they certainly aren't new either. The actor model has been around since the 70s at least, and has been seriously used for distributed programming since the late 80s with Erlang. So what makes an actor an actor? Let's compare with threads +----------------------------------+---------------------------------+ | **Actor** | **Thread** | +==================================+=================================+ | can create more actors | can create more threads | +----------------------------------+---------------------------------+ | can have private local state | can have private local state | +----------------------------------+---------------------------------+ | has NO shared state | has limited shared state | | (isolated from other actors!) | | +----------------------------------+---------------------------------+ | communicates with other actors | communicates with other | | via asynchronous message passing | threads via shared variables | +----------------------------------+---------------------------------+ The essential difference between actors and threads is the isolation and message passing. There aren't any holes punched into lids here, but you can always shine a message from one jam jar to another, perhaps hoping they send you one of their own. The appeal of actors is thus a kind of simplicity, where avoiding shared state eliminates a class of concurrency bugs by definition, and where each actor can be reasoned about in isolation of its brethren. This sort of thing may perhaps strike a chord with us functional programmers, and actually, there is quite a bit of actor-related work in Haskell: a handful of packages offering the actor as concurrency primitive, Martin Sulzmann's [multi-headed twist][mh-actors] on the model; [Communicating Haskell Processes][chp] exploring an actor-ish cousin known as CSP. Finally, there's [Cloud Haskell][ch-pdf], which in explicit homage to Erlang, applies the actor model to distributed programming. ### Glimpse of Cloud Haskell We'll be taking a quick look at Cloud Haskell in this word of the month, unfortunately with only the most fleeting of glimpses. If squirting money between bank accounts is the transactional hello world, playing ping pong must surely be its distributed counterpart. Before working up to that, we first start with half a hello. The following example creates three processes — “process” is the Erlang-inspired word for the actor here — one which receives `Ping` messages and just prints them to screen, one which sends a single `Ping` message, and finally one which fires up the first two processes: {-# LANGUAGE DeriveDataTypeable #-} module Main where import Control.Concurrent ( threadDelay ) import Data.Binary import Data.Typeable import Control.Distributed.Process import Control.Distributed.Process.Node import Network.Transport.TCP -- Serializable (= Binary + Typeable) data Ping = Ping deriving (Typeable) instance Binary Ping where put Ping = putWord8 0 get = do { getWord8; return Ping } server :: ReceivePort Ping -> Process () server rPing = do Ping <- receiveChan rPing liftIO $ putStrLn "Got a ping!" client :: SendPort Ping -> Process () client sPing = sendChan sPing Ping ignition :: Process () ignition = do -- start the server sPing <- spawnChannelLocal server -- start the client spawnLocal $ client sPing liftIO $ threadDelay 100000 -- wait a while main :: IO () main = do Right transport <- createTransport "127.0.0.1" "8080" defaultTCPParameters node <- newLocalNode transport initRemoteTable runProcess node ignition This little package gives us a chance to look at three big pieces of Cloud Haskell, the `Serializable` typeclass, the `Process` monad, and channels. #### Serializable Actors send messages to each other. As programmers, we see the messages in nice high-level form (eg. `Ping`), but somewhere along the way, these messages are going to have to be encoded to something we can ship around on a network. Cloud Haskell makes this encoding explicit, but reasonably convenient at the same time. Things can be messages if they implement the `Serializable` typeclass, which is done indirectly by implementing `Binary` and deriving `Typeable`. You won't be starting from scratch, as implementations are already provided for primitives and some commonly used data structures. Things which don't make sense as messages are deliberately left unserializable, for example `MVar` and `TVar`, which are only meaningful in the context of threads with a shared memory. Our Cloud Haskell program is perfectly free to use these constructs within processes (or within processes on the same machine; a bit more on that below), just not to ship them around. #### Process We use “process” to mean “actor” in a similar fashion as Erlang, in other words nothing nearly so heavy as an operating system process. One different with Erlang, however, is that Cloud Haskell allows for both actor style concurrency and the thread-based approach. The infrastructure gears you towards using the actor model when talking across machines, but on the same machine, you could also conveniently do things the old way. Want to use STM to pass notes between processes? Fine, just spawn them locally via `spawnLocal` and give them a common `TVar`. As for the `Process` monad, we see again the idea of special monad either for special kinds of sequencing. Here the idea is that things like sending/receiving messages or spawning other processes only makes sense for processes, and so you can only do these things in a “process context”. `Process` implements `MonadIO`, though, so any input/output you'd like to do within a process is merely a `liftIO` away. Going the other way, running a process from IO, you would do with the `runProcess` function. #### Channels Cloud Haskell provides a notion of channels (somewhat similar to those we introduced in the last word of the month), typed unidirectional pipelines that go from one process to another. Using them is optional (there are simpler ways to bop messages back and forth), but worth trying out for the promise of sending messages only to processes that will understand them. Below is a quick glance at channels in action: data SendPort a -- Serializable data ReceivePort a -- NOT Serializable newChan :: Serializable a => Process (SendPort a, ReceivePort a) sendChan :: Serializable a => SendPort a -> a -> Process () receiveChan :: Serializable a => ReceivePort a -> Process a A channel comes with a send and receive port, both of which are parameterised on the same type variable. Creating a `Ping` channel thus gives a `ReceivePort Ping` out of which only `Ping`'s will ever emerge, and a `SendPort Ping` into which we can only put `Ping`'s. This looks a lot more attractive when you work with multiple channels. Replying to pings with pongs, for example, would require us to create a second channel with a send a receive port of its own, which means we have now 4 ports to juggle! Having the type distinctions makes things a bit clearer: `SendPort Ping` vs `ReceivePort Ping` vs `SendPort Pong`, vs `ReceivePort Pong`. Finally, it's worth noticing that `SendPort`'s are themselves Serializable, meaning that they can be copied and shipped around to other processes possibly on other computers. This allows a channel to accept data from more than one place, and also makes for idioms like including a reply-to `SendPort` in your messages. `ReceivePort`'s on the other hand are (deliberately) left unserializable which leaves them tied to single computer. ### Ping? What happened to Pong? Our little example was more “hello wo” than “hello world”; we'd only managed to send a `Ping` without even thinking about sending `Pong`'s back. Want to try your hand at Cloud Haskell? Here's a great opportunity! 1. **[Easy]** Start with a `cabal install distributed-process` and make sure you can run this example. Note that you'll need GHC 7.4.1 and up for this 2. **[Less easy]** Next, add a new `Pong` message (as a separate data type), extending the server to send this message back, and the client to receive that reply. There are some puzzle pieces to work through here. How does the server know where to send its replies? Moreover, how do we keep the server nice and decoupled from the client? We want it to receive pings from any client, and send a reply back to the ping'er (and not just some hard-coded client). Hint: you can solve this without touching `ignition` or `main`. Remember that `SendPort` is `Serializable`! 3. **[Easy]** You now have a single ping/pong interaction. Can you make the game go back and forth indefinitely (or until the `threadDelay` ends)? Hint: have a look at `Control.Monad`; it's not essential, but it's a bit nicer. ### Conclusion Stepping back from the technology a bit, we have introduced the notion of actors as a concurrency abstraction on a par with threads. While there's nothing that makes them specific to distributed programming, they do seem to fit nicely to the problem and have been used to great effect before. Cloud Haskell is one attempt to apply this actor model, taking some of the ideas from Erlang, and combining them with Haskell's purity and type system. You might notice that in a word of the month about distributed programming, we've kept things on a single machine, alas! Indeed, we have not been able to do Cloud Haskell justice in this article, but we have hopefully laid some foundations by introducing some of the basic layers, `Serializable` messages, processes, and channels. To escape from one-machine-island, we would need to get to grips with two more concepts, nodes and closures. Nodes can basically be thought of as separate machines (you could run multiple nodes on the same machine if you wanted to, say for development purposes). This makes for three layers: nodes (machines), which contain processes (actors), which can run any number of threads they wanted. We saw how processes can communicate by sending each other messages across channels; what we've left out is the crucial detail of what happens when the processes live on different nodes. The good news here is “nothing special”, still messages across channels. The bad news is a bit of infrastructural fiddliness setting up the nodes in the first place, assigning them to roles, and spawning remote processes… for which we need to know about closures. The basic story with closures is that we need to be able send functions back and forth in order to do anything really useful with Cloud Haskell, and to send functions we need to say how they are `Serializable`. This would be easy enough — assume for now that all nodes are running the same code and just send “run function `foo`” style instructions — were it not for the fact that Haskellers do all sorts of crazy things with functions all the time (partially applying them, returning them from other function…), crazy things that introduce free variables. Expressing the serializability of function-and-its-free-variables was a source of furious head-scratching for a while until somebody hit on the old Henry T. Ford idea: You can have any free variables you want so long as they are a ByteString. Where to from here? If you're looking for more introductory stuff and have not already seen, try Simon Peyton Jones's presentation of Cloud Haskell to the Scala community ([1h video][ch-skills]). Edsko has been hard at work at the [distributed-process Haddock][dp-haddock], so it's worth checking out when you're ready to roll up your sleeves and get hacking. It'd be a very good idea to have a look at the [simplelocalnet backend][simple], which will help you get started with the nitty gritty node management issues when you start yearning to go distributed. That's the practical stuff, but don't forget to read the [Cloud Haskell paper][ch-pdf] either! The API has some slight differences (for example, `ProcessM` has since been renamed to `Process`), but it should be fairly straightforwardly transferable to the new package. It's likely we'll need a wider spectrum of documentation to bring more Cloud Haskellers into the fold (early days, eh?). Hopefully this word of the month will help you get started, and maybe in turn write a blog post of your own? Happy Distributed Haskell'ing! [ch-github]: https://github.com/jepst/CloudHaskell [ch-pdf]: http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remot… [ch-skills]: http://skillsmatter.com/podcast/home/haskell-cloud/js-4179 [chp]: http://www.cs.kent.ac.uk/projects/ofa/chp/ [dist-p]: https://github.com/haskell-distributed/distributed-process [dp-announce]: https://groups.google.com/d/topic/parallel-haskell/dw5UPEg1ePI/discussion [dp-haddock]: http://hackage.haskell.org/packages/archive/distributed-process/latest/doc/… [mh-actors]: http://sulzmann.blogspot.co.uk/2008/10/actors-with-multi-headed-receive.html [phd-11]: http://www.well-typed.com/blog/67 [simple]: http://hackage.haskell.org/packages/archive/distributed-process-simplelocal… [survey]: http://goo.gl/bP2fn -- Eric Kow <http://erickow.com>

1 0

Fwd: hackage compile failure with QuickCheck 2.5
by Alexander Foremny 20 Jul '12

20 Jul '12

Dear Levent, I think this [1] could be related. Regards, Alexander Foremny PS. Sent this to Levent directly. Here's a copy for the mailing list. Sorry for the noise. [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html ---------- Forwarded message ---------- From: Alexander Foremny <alexanderforemny(a)gmail.com> Date: 2012/7/17 Subject: Re: [Haskell-cafe] hackage compile failure with QuickCheck 2.5 To: Levent Erkok <erkokl(a)gmail.com> Dear Levent, I think this [1] could be related. Regards, Alexander Foremny [1] http://haskell.1045720.n5.nabble.com/Bad-interface-problem-td5714184.html 2012/7/17 Levent Erkok <erkokl(a)gmail.com>: > [This message is more appropriate for a hackage mailing list I presume, but > that doesn't seem to exist. Let me know if there's a better place to send > it.] > > I'm having a hackage compile failure for a newly uplodaded package that has > a QuickCheck 2.5 dependence. The error message is: > > [13 of 13] Compiling Test.QuickCheck.All ( Test/QuickCheck/All.hs, > dist/build/Test/QuickCheck/All.o ) > > Test/QuickCheck/All.hs:15:1: > Bad interface file: > /usr/local/tmp/archive/install/lib/template-haskell-2.6.0.0/ghc-7.4.1/Language/Haskell/TH.hi > Something is amiss; requested module > template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the > interface file template-haskell:Language.Haskell.TH > > > The full log file is at (search for "Something is a miss" in it): > http://hackage.haskell.org/packages/archive/sbv/2.2/logs/failure/ghc-7.4 > > Needless to say, I don't see this problem when I compile this package at > home with the same compiler (ghc 7.4.1) as hackage is using; also Hackage > has a successfully compiled QuickCheck 2.5 package. > > Could it be something related to the particular cabal/ghc installation on > the hackage server? In particular, I don't understand why it picks > template-haskell 2.6.0.0 when there's a newer version (2.7.0.0). As far as I > can see, QuickCheck doesn't put an upper limit on its template haskell > version dependency. > > I'd appreciate any pointers with this. (Googling and questions on the > #haskell irc channel didn't help much, unfortunately.) > > -Levent. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

4 5

how to select random elements of a Data.Set?
by jwaldmann 20 Jul '12

20 Jul '12

Dear all, how would I quickly select an element of a Set (as in Data.Set) uniformly at random? Via the API, this can only be done in linear time? (via toList) If I could access the tree structure, then of course it could be logarithmic. But probably I'd need a weighted selection sooner or later, and this would require some specific code anyway. Or does it not? Actually I need a sequence of such selections (each selected element is deleted immediately). I don't need all elements (so, computing a random permuation might be too much). J.W.

4 3

COBOL-85 parser, anyone?
by Richard O'Keefe 20 Jul '12

20 Jul '12

Does anyone have a parser for COBOL-85 written in Haskell, or written using some freely available tool that communicates easily with Haskell? I don't need it _yet_, but I'm talking with someone who is trying to get access to a real legacy site with a bunch of, well, basically COBOL 85, but there are extensions... We're not talking about transformation at this stage, just analysis. I could probably hack up the extensions given a place to start. I've found some papers and more dead links than I care for and lots of mention of ASF+SDF which is apparently superseded by Rascal.

2 1

Bug or feature?
by Miguel Mitrofanov 20 Jul '12

20 Jul '12

Hi cafe! I'm a bit confused by the DefaultSignatures extension. It's unclear whether to consider the following an example of clever use of this extension, or an example of abuse of it: {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module SubClass where import GHC.Prim(Constraint) data Void (c :: * -> Constraint) = Void data Evidence c a where Evidence :: c a => Evidence c a class c1 :<= c2 where isSubClass :: c1 a => Void c1 -> Evidence c2 a default isSubClass :: c2 a => Void c1 -> Evidence c2 a isSubClass Void = Evidence instance Show :<= Show instance Floating :<= Fractional instance Real :<= Num -- instance Fractional :<= Floating -- NO ROTTEN WAY {- Examples -} data Wrapper c where Wrapper :: c a => a -> Wrapper c instance (c :<= Show) => Show (Wrapper c) where show (Wrapper (a :: t)) = case isSubClass (Void :: Void c) :: Evidence Show t of Evidence -> show a absWrap :: (c :<= Num) => Wrapper c -> Wrapper c absWrap (Wrapper (a :: t) :: Wrapper c) = case isSubClass (Void :: Void c) :: Evidence Num t of Evidence -> Wrapper (abs a) What do you think? Also, it's a bit strange that the first example (instance (c :<= Show) => Show (Wrapper c)) requires UndecidableInstances, while the second one (absWrap) requires FlexibleContexts - although being remarkably similar.

1 0

How to add constraint to .cabal?
by Magicloud Magiclouds 19 Jul '12

19 Jul '12

Hi, Say I have a package that only appends --constraint="template-haskell==2.7.0.0" --constraint="warp-tls==1.2.1" could I install it. Now I want to release the package, then how could I have these constraint into the .cabal so the user would not get troubled? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 1