Heinrich Apfelmus | 9 Feb 20:17
Picon
Favicon
Gravatar

Fancy REPL

Dear list,

the  Show  class is extremely useful for exploring Haskell in a 
terminal, but sometimes, I just want something fancier. For instance, 
I'm currently dabbling with sound generation and it is only natural that 
I want to hear the sound instead of seeing a textual representation. 
Another example would be graphics, that are simply drawn on screen 
whenever you evaluate their value.

Of course, this is simple to implement with a class

     class Demonstrable a where
         demo :: a -> IO ()

     instance Demonstrable Sound where demo = play
     instance Demonstrable Sound where demo = draw
     instance Demonstrable GUI   where demo = run
     etc.

However, I don't want to reinvent the wheel, small as it may be, hence 
my question: is there a package on hackage that already defines a class 
similar to  Demonstrable ? Or any other projects in this direction, 
like, say, a fancy REPL built on wxHaskell?

Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com
(Continue reading)

mukesh tiwari | 9 Feb 20:12
Picon

Error in installing dph-examples on Mac OS X 10.7.3

Hello all
I am trying to install dph-examples on Mac OS X version 10.7.3 but getting this error. I am using ghc-7.4.1.

Error running clang! you need clang installed to use the LLVM backend
cabal: Error: some packages failed to install:
dph-examples-0.6.1.3 failed during the building phase. The exception was:
ExitFailure 1

I have already installed Xcode 4.2 and it shows

Macintosh-0026bb610428:tmp mukesh$ clang
clang clang++
Macintosh-0026bb610428:tmp mukesh$ clang -v
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix
Macintosh-0026bb610428:tmp mukesh$ clang++ -v
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix
Macintosh-0026bb610428:tmp mukesh$ l
Display all 113 possibilities? (y or n)
Macintosh-0026bb610428:tmp mukesh$ llvm-
llvm-ar llvm-config llvm-diff llvm-extract llvm-gcc llvm-link llvm-objdump llvm-rtdyld llvm-tblgen
llvm-as llvm-cov llvm-dis llvm-g++ llvm-gcc-4.2 llvm-mc llvm-prof llvm-size
llvm-bcanalyzer llvm-cpp-4.2 llvm-dwarfdump llvm-g++-4.2 llvm-ld llvm-nm llvm-ranlib llvm-stub
Macintosh-0026bb610428:tmp mukesh$ llvm-g++ -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

Regards
Mukesh Tiwari


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ben | 9 Feb 19:43
Picon
Gravatar

Transactional memory going mainstream with Intel Haswell

http://arstechnica.com/business/news/2012/02/transactional-memory-going-mainstream-with-intel-haswell.ars

would any haskell STM expert care to comment on the possibilities of hardware acceleration?

best, ben
Clark Gaebel | 9 Feb 19:32
Picon
Picon
Favicon
Gravatar

ANN: stm-conduit-0.2.1

Hi all,

I've just released stm-conduit [1] on Hackage. This package introduces conduits to the wonderful world of concurrency.

My package solves the common problem of constant bottleneck switching loaders have. This is when, for example, we stream XML from the disk and then parse the XML in one conduit pipeline. While it streams a file from the disk, the process is clearly IO bound, and while it parses the XML, the process is CPU bound. By putting each task on its own thread, the disk IO doesn't need to wait for the CPU to parse a document before loading the next file. By using stm-based conduits, we have full resource utilization.

The way it does this is by creating a source and sink for TChans, letting us stream data between conduits and channels. There are more examples in the docs.

Check it out!

Regards,
  - clark

[1] http://hackage.haskell.org/package/stm-conduit
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Richard Wallace | 9 Feb 07:46
Gravatar

Is ListT a valid MonadPlus?

It appears to me that the MonadPlus instance for ListT breaks the
following MonadPlus law

    m >> mzero   =  mzero

I've tried with every implementation of ListT I could find - the one
in mtl, transformers, List, even "ListT done right" and it's
alternative.  They all seem to violate the above law.  Following is a
ghci session that shows this with the mtl impl.

Prelude> import Control.Monad.List
Prelude Control.Monad.List> let nt = ListT Nothing :: ListT Maybe Int
Prelude Control.Monad.List> let e = mzero :: ListT Maybe Int

Prelude Control.Monad.List> runListT nt
Nothing
Prelude Control.Monad.List> runListT e
Just []
Prelude Control.Monad.List> runListT $ nt >> e
Nothing

According to the MonadPlus law above, that last line should evaluate
to `Just []`.

So is ListT a valid MonadPlus?  Or am I missing something?  If not,
can a valid MonadPlus instance for ListT be written?  I've tried a few
things and come up short.

Thanks,
Rich
Yves Parès | 8 Feb 22:56
Picon
Gravatar

Mersenne-random and standard random API

Hi,
I've been in the past told that mersenne-random was much better than the standard random package.

However, System.Random.Mersenne doesn't follow the general API described in System.Random, MTGen is not an instance of RandomGen.
But a sample on System.Random.Mersenne.getStdRandom documentation (http://hackage.haskell.org/packages/archive/mersenne-random/1.0.0.1/doc/html/System-Random-Mersenne.html) indicates this:

rollDice :: IO Int rollDice = getMTRandom (randomR (1,6))It looks like wrong documentation (checking of older versions show that getMTRandom have never lived or been exposed by this module), but suggests MTRandom should be an instance of RandomGen (if I assume well that randomR is that of System.Random).

So is it possible to use the fast and efficient mersenne generator with the convenient and general random API?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
JP Moresmau | 8 Feb 17:04
Picon
Gravatar

Concurrency strategy for 2 threads and rare events

Hello, I'm wondering what's the best strategy to use in the following scenario:
- 2 threads
  - One perform some work that will take time, possibly go on forever
  - Another waits for user input (like commands from the keyboard)
that affects thread 1 (causing it to stop, in the simplest case)

I've read a bit on MVar and channels, but they seem to be a lot for
cases where the reading thread block for input. In my case, I expect
to have "something" that thread 2 updates when an event occur, and
thread 1 checks it regularly. So thread 1 should not block, but should
check "is there something" and there is, act on it, otherwise continue
doing what it was currently doing. I suppose I could just tryTakeMVar
on a MVar, but is there something more adapted to my needs?

Thanks!

--

-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
Picon

Yesod and dependencies hell

For three days I can't compile dependencies for my project using
yesod, yesod-auth, yesod-persistent, persistent-template,
persistent-sqlite, persistent. When I varied version I received a
variety of broken dependencies: persistent (0.6.* vs 0.7.*), conduit
(0.1.* vs 0.2.*), conduit-pool, path-pieces, attoparsec and something
else. In this regard, I have a few questions. How to build these
packages together? And, Michael, why so bad?

--

-- 
Тимофеев Н.Д.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Holger Reinhardt | 7 Feb 23:29
Picon
Gravatar

Re: network-2.3.0.10 compiled for ghc 7.4.1 windows

I just use the version of MSys that is included with Git [1]. This puts a "Git bash" icon on your desktop which you can then use to build the network library. 


[1] http://code.google.com/p/msysgit/

2012/2/7 Alberto G. Corona <agocorona <at> gmail.com>
Nothing bur a long history of failures. The problem is the
configuration and versioning of MinGW and MSys. This  is a nighmare.

2012/2/7 Holger Reinhardt <hreinhardt <at> gmail.com>:
> Oh you are using Cygwin. I'm using MSys so this is why I cannot reproduce
> your problem. Is there anything preventing you from using MSys?
>
>
> 2012/2/7 Alberto G. Corona <agocorona <at> gmail.com>
>>
>> The "problem" this time is in "Configure" :
>>
>> case "$host" in
>> *-mingw32)
>>        EXTRA_SRCS="cbits/initWinSock.c, cbits/winSockErr.c,
>> cbits/asyncAccept.c"
>>        EXTRA_LIBS=ws2_32
>>        CALLCONV=stdcall ;;
>> *-solaris2*)
>>        EXTRA_SRCS="cbits/ancilData.c"
>>        EXTRA_LIBS="nsl, socket"
>>        CALLCONV=ccall ;;
>> *)
>>        EXTRA_SRCS="cbits/ancilData.c"
>>        EXTRA_LIBS=
>>        CALLCONV=ccall ;;
>> esac
>>
>>
>>
>> Since I´m cross-compiling with cygwin, the variable Host does not
>> contain ¨*-muingw32"  but "i686-pc-cygwin"
>>
>> changing the case , the library incorporates the lost C coded files.
>>
>> Now the library links fine win imported, but there is a runtime error:
>>
>> NetworkSocket.hsc:(948,3)-(1007,23): Non-exhaustive patterns in case
>>
>> maybe it is due to some other preprocessor directive mismatch
>>
>>
>> 2012/2/7 Holger Reinhardt <hreinhardt <at> gmail.com>:
>> > Did you also change the files in the /cbits/ folder? Because they also
>> > check
>> > for HAVE_WINSOCK_H.
>> >
>> >
>> > 2012/2/7 Alberto G. Corona <agocorona <at> gmail.com>
>> >>
>> >> The code is evolving and none of the versions match exactily with the
>> >> patch, but substituting HAVE_WINSOCK by HAVE WINSOCK2 in these files
>> >> solves the compilation problem at least in the network 2.3.0.10
>> >> version from hackage.
>> >>
>> >> However it produces the same undefined references when this library is
>> >> imported in my application. It seems that some object code is not
>> >> included in the final library.  I verified that at least some of these
>> >> undefined references correspond with  C code in the source, but
>> >> somehow this is not included in the object library....
>> >>
>> >> 2012/2/7 Johan Tibell <johan.tibell <at> gmail.com>:
>> >> > Note that there are two branches on github, master and stable. You
>> >> > want
>> >> > the
>> >> > latter.
>> >> >
>> >> > On Feb 7, 2012 8:23 AM, "Alberto G. Corona" <agocorona <at> gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> This is quite different.
>> >> >> I don´t know how but I was looking at some other older patch around
>> >> >> the same issue and I supposed that it was the one refered by Yohan
>> >> >> Tibell.
>> >> >>
>> >> >> I´ll try your patch.
>> >> >>
>> >> >> Thanks!.
>> >> >>
>> >> >> 2012/2/7 Holger Reinhardt <hreinhardt <at> gmail.com>:
>> >> >> > Hi,
>> >> >> >
>> >> >> > (I submitted the patch that Johan linked to)
>> >> >> > Network/Socket/Internal.hsc has the following code:
>> >> >> >
>> >> >> > #if defined(WITH_WINSOCK) || defined(cygwin32_HOST_OS)
>> >> >> > type CSaFamily = (#type unsigned short)
>> >> >> > #elif defined(darwin_HOST_OS)
>> >> >> > type CSaFamily = (#type u_char)
>> >> >> > #else
>> >> >> > type CSaFamily = (#type sa_family_t)
>> >> >> > #endif
>> >> >> >
>> >> >> > You have patched this part to always use 'unsigned short'. But the
>> >> >> > real
>> >> >> > issue is that WITH_WINSOCK is not defined, even though it should
>> >> >> > be. The
>> >> >> > reason for this lies in include/HsNet.h:
>> >> >> >
>> >> >> > #if defined(HAVE_WINSOCK_H) && !defined(cygwin32_HOST_OS)
>> >> >> > # define WITH_WINSOCK  1
>> >> >> > #endif
>> >> >> >
>> >> >> > The problem here is that it checks for HAVE_WINSOCK_H, but the
>> >> >> > configure
>> >> >> > script never defines this variable. Instead it
>> >> >> > defines HAVE_WINSOCK2_H.
>> >> >> > It
>> >> >> > seems that the network library used Winsock1 in the past and in
>> >> >> > the
>> >> >> > transition to Winsock2 someone forgot to change a few of the
>> >> >> > #ifdefs.
>> >> >> >
>> >> >> > My patch just changes all occurences of HAVE_WINSOCK_H
>> >> >> > to HAVE_WINSOCK2_H.
>> >> >> > You might want to try that and report back if it works for you.
>> >> >> >
>> >> >> > 2012/2/7 Alberto G. Corona <agocorona <at> gmail.com>
>> >> >> >>
>> >> >> >> Hi Johan,
>> >> >> >> The patch is not for the current version of network and the code
>> >> >> >> is
>> >> >> >> quite different. Basically it is necesary to  define this
>> >> >> >> variable
>> >> >> >> as
>> >> >> >> "unsigned short" that is the thing intended in the patch. however
>> >> >> >> I
>> >> >> >> put it by brute force, without regard of the prerpocessor
>> >> >> >> directives.
>> >> >> >> With this change the code compiles well with:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> http://neilmitchell.blogspot.com/2010/12/installing-haskell-network-library-on.html
>> >> >> >>
>> >> >> >> However my compiled library lack the methods defined as foreign.
>> >> >> >> I´ll
>> >> >> >> keep trying.
>> >> >> >>
>> >> >> >> 2012/2/6 Johan Tibell <johan.tibell <at> gmail.com>:
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > Someone recently contributed a fix that should make network
>> >> >> >> > build
>> >> >> >> > with
>> >> >> >> > 7.4: https://github.com/haskell/network/pull/25
>> >> >> >> >
>> >> >> >> > Can you see if that works for you? I haven't yet had time to
>> >> >> >> > merge
>> >> >> >> > and
>> >> >> >> > release that fix (I'm on vacation.)
>> >> >> >> >
>> >> >> >> > -- Johan
>> >> >> >> >
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Haskell-Cafe mailing list
>> >> >> >> Haskell-Cafe <at> haskell.org
>> >> >> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >> >> >
>> >> >> >
>> >
>> >
>
>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Douglas McClean | 7 Feb 21:19
Picon
Gravatar

-XPolyKinds and undefined arguments

There are all sorts of useful functions that would otherwise require explicit type applications which we work around by passing undefined and ignoring its value. (See http://www.haskell.org/pipermail/libraries/2010-October/014742.html for a prior discussion of why this is, how the use of undefined for something that is perfectly well defined smells, and various suggestions about one day changing it.)

Examples: Data.Typeable.typeOf, Foreign.Storable.sizeOf, etc.

It seems to me that the new -XPolyKinds extension might provide a good long-term solution to statically insuring that arguments like this are always undefined and are never inspected.

If we had a library definition:

  -- a kind-indexed family of empty types, Proxy :: AnyK -> *
  data Proxy a

then we could write things that resemble type applications such as "sizeOf <at> Int64". Unlike the current approach, we'd be assured that nobody tries to use the value of such a proxy in any meaningful way, since you can't pattern match it or pass a "Proxy t" in a context expecting a "t". We'd have formal documentation of which parameters are in this value-is-unused-and-only-type-matters category (which might help us erase more often?).

This is essentially the same Proxy type as in section 2.5 of the "Giving Haskell a Promotion" paper, except that by making it empty instead of isomorphic to () we end up with a type that only has one value (bottom) instead of two (Proxy and bottom), which should be a desirable property if we are trying to erase uses and forbid pattern matches and such, I think.

Adding a syntax extension (or even some TH?) to make something like " <at> Int64" desugar to "undefined :: Proxy Int64" would eliminate the clutter/smell from the undefineds.

Poly kinds allow us to use the same mechanism where the "undefined" parameter is a phantom type at a kind other than *. It seems to work nicely, and it cleaned up some of my code by unifying various proxy types I had made specialized at kinds like Bool.

How would you compare this to some of the proposals in the 2010 thread? Would people still prefer their fantasy-Haskell-of-the-future to include full-blown support for explicit type applications instead?


-Doug

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ivan Perez | 7 Feb 19:32
Picon
Gravatar

FP activities and researchers in Warwickshire

Hello,
 I recently moved to Kenilworth, Warwickshire, UK, and I'd like
to know if there are meetings, talks, or any FP-related activities
going on around here. I contacted somebody at Warwick
University but, from what I understood, their Formal Methods
group doesn't exist as such any longer and they don't carry out
any coordinated, regular events regarding FP anymore.

Cheers,
Ivan

Gmane