- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] haskell mailing lists followup?
by wren ng thornton 16 Mar '11

16 Mar '11

On 3/14/11 2:01 AM, pteer(a)acanac.net wrote: > Hi Wren; > > I CC'ed you on email I sent Thu, 10 Mar after seeing your post on > haskell-cafe Thu Mar 10 07:24:45 CET "Haskell mail server fail?". Did > you see that email? I didn't see it; though it looks like it just showed up in my inbox. The only other replies I've seen are from: [cc: haskell-cafe] On 3/10/11 2:18 AM, David Virebayre [cc: haskell-cafe] On 3/10/11 7:44 AM, Daniel Fischer Earlier today I got messages from the three lists I'm on (libraries@, haskell-cafe@, glasgow-haskell-users@) about delivery being disabled due to excessive bounces. The re-enabling codes in those emails were expired ---which is supposed to take a few days--- despite only getting them at 4:00am today. I've since logged in to re-enable delivery, though it'll only be a matter of time until it happens again. > Have you tried to reply to pteer@acanac.net? Have > you started seeing Haskell mailing list traffic again? Nope (well now I have), and nope. Actually, while writing this, I did just see: [Haskell-cafe] ANN: Monad.Reader special Poetry and Fiction Edition On 3/15/11 7:35 PM, Brent Yorgey come through. So maybe re-enabling delivery fixed it this time? > [...] I've seen web pages > reporting problems with google-based lists tripping over SPF when > misconfigured for forwarding, and so forth. It would be helpful to > see the error messages. Yeah, I've run into problems with SPF before. But since it's not just me I don't think it's an @freegeek.org problem. > I've successfully transferred messages to myself dummied up using smtp > connecting directly to my haskell-cafe list address. I haven't > received any approval messages from recent attempts to set up new > target addresses on the same receiving email host. Non-Haskell > mailing lists have continued uninterrupted, but haskell lists to > teerlist(a)acanac.net last received on 04 Mar. Ditto. My other mailing lists are coming through fine (e.g., agda(a)lists.chalmers.se) which also indicates the issue is on the @haskell.org side. -- Live well, ~wren

3 2

Writing functions over GADTs
by Dominic Mulligan 16 Mar '11

16 Mar '11

Dear all, I'm working on a small proof assistant in Haskell. In the logic that I'm implementing it's very important that I distinguish between `large' and `small' types for consistency reasons. I have worked to get this distinction reflected in my types with the use of GADTs, like so: data Type :: * -> * where SVariable :: Decoration -> Type Small LVariable :: Decoration -> Type Large Bound :: Index -> Type Small Universal :: Decoration -> Type a -> Type Large LFormer :: Decoration -> ArgList Large -> Variety -> Type Large SFormer :: Decoration -> ArgList Small -> Variety -> Type Small where: data ArgList :: * -> * where Empty :: ArgList a SmallCons :: Type Small -> ArgList a -> ArgList a LargeCons :: Type Large -> ArgList a -> ArgList Large Great, but one problem. How do you write functions over these data types? Consider as an example the function `toList', which drops an `ArgList a' down into a vanilla Haskell list `[a]'. Attempting a straightforward implementation like so: toList :: ArgList a -> [Type a] toList Empty = [] toList (SmallCons h t) = h : toList t toList (LargeCons h t) = h : toList t Gives a type error, as the type variable `a' gets instantiated to Small when typechecking the second clause of the function definition, and Large when type checking the third clause. Perversely, it's much easier to write a more complex function: forget :: (forall a. Type a -> b) -> ArgList a -> [b] forget f Empty = [] forget f (SmallCons h t) = f h : forget f t forget f (LargeCons h t) = f h : forget f t As we can use RankNTypes to make things `more polymorphic', and prevent type variables being instantiated too soon. It seems plausible that `toList' could be defined in terms of `forget', taking `f' to be the identity function, but this does not work either as we then get type errors about inferred types being less polymorphic than expected. So, is there a standard way writing function like `toList' in Haskell? Am I going about thinking of using GADTs in the wrong way? I've searched everywhere and cannot seem to find the correct solution (and I'm now at the very border of my Haskell knowledge). My coworker showed me a way of doing this in O'Caml using polymorphic variants. This allows us to form a subtype of both `Small' and `Large'. I'm taken to believe that HList can simulate many of the properties that polymorphic variants enjoy, so perhaps the answer lies there? Any help gratefully received. Regards, Dominic Mulligan

2 1

Static linking problem // CentOS 5.5 - GHC 6.12.3
by frode k 16 Mar '11

16 Mar '11

I've installed GHC version 6.12.3 on CentOS 5.5 x86_64. I'm trying to run a very simple Haskell program as CGI following the guide at: http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell My .hs file I'm trying to use looks like this: -------------------------------------------------------------- import Network.CGI import Text.XHtml page :: Html page = body << h1 << "Hello World!" cgiMain :: CGI CGIResult cgiMain = output $ renderHtml page main :: IO () main = runCGI $ handleErrors cgiMain -------------------------------------------------------------- If I compile it using dynamic linking I can run it from the command line, since the environment is correct: # ghc haskell_v2.hs --make -o haskell_v2.cgi Linking haskell_v2.cgi ... # ./haskell_v2.cgi Content-type: text/html; charset=ISO-8859-1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" ><body ><h1 >Hello World!</h1 ></body ></html > [root@vps-1040050-2953 haskellTest]# However I do of course want to run it through CGI on a webserver. I'm running lighttpd. If I try to run the file compiled above I get "500 - Internal Server Error", most likely since the enviroment is not correct for dynamic linked files: # ldd haskell_v2.cgi librt.so.1 => /lib64/librt.so.1 (0x00002aff22c25000) libutil.so.1 => /lib64/libutil.so.1 (0x00002aff22e2e000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aff23031000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00002aff23236000) libm.so.6 => /lib64/libm.so.6 (0x00002aff2346f000) libc.so.6 => /lib64/libc.so.6 (0x00002aff236f2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aff23a4a000) /lib64/ld-linux-x86-64.so.2 (0x00002aff22a08000) # file haskell_v2.cgi haskell_v2.cgi: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped Hence I wanted to use static linking ( http://www.haskell.org/haskellwiki/Web/Literature/Static_linking ). However trying to compile using the "-optl-static" option fails: # ghc haskell_v2.hs --make -optl-static -fforce-recomp -o haskell_v2.cgi [1 of 1] Compiling Main ( haskell_v2.hs, haskell_v2.o ) Linking haskell_v2.cgi ... /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(HsNet.o): In function `hsnet_getaddrinfo': HsNet.c:(.text+0x11): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sAwu_info': (.text+0xd45d): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syh4_info': (.text+0x4364): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sygm_info': (.text+0x424f): warning: Using 'gethostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syx3_info': (.text+0x5318): warning: Using 'sethostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x12c6): warning: Using 'endhostent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syJY_info': (.text+0x605d): warning: Using 'getnetbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sycm_info': (.text+0x3e75): warning: Using 'getnetbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sybC_info': (.text+0x3de7): warning: Using 'getnetent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syyg_info': (.text+0x5458): warning: Using 'setnetent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x1296): warning: Using 'endnetent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syGE_info': (.text+0x5d42): warning: Using 'getprotobynumber' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sylC_info': (.text+0x474f): warning: Using 'getprotoent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syvQ_info': (.text+0x51d8): warning: Using 'setprotoent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x12f6): warning: Using 'endprotoent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syEu_info': (.text+0x5a25): warning: Using 'getprotobyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syAp_info': (.text+0x55c4): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syCX_info': (.text+0x584c): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `syoz_info': (.text+0x49ef): warning: Using 'getservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sytu_info': (.text+0x5098): warning: Using 'setservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/local/lib/network-2.3/ghc-6.12.3/libHSnetwork-2.3.a(BSD.o): In function `sxz5_info': (.text+0x1326): warning: Using 'endservent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_create.o): In function `timer_create': (.text+0x124): undefined reference to `pthread_once' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_create.o): In function `timer_create': (.text+0x171): undefined reference to `pthread_attr_init' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_create.o): In function `timer_create': (.text+0x1b8): undefined reference to `pthread_attr_setdetachstate' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x3f): undefined reference to `pthread_attr_init' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x4c): undefined reference to `pthread_attr_setstacksize' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0x92): undefined reference to `pthread_create' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0xc6): undefined reference to `pthread_attr_destroy' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `__start_helper_thread': (.text+0xd4): undefined reference to `pthread_atfork' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `timer_helper_thread': (.text+0x1e1): undefined reference to `pthread_exit' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/librt.a(timer_routines.o): In function `timer_helper_thread': (.text+0x21b): undefined reference to `pthread_create' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `init_mparams': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:2486:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:2490:0: undefined reference to `pthread_mutex_init' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:2493:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `internal_malloc_stats': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:2861:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:2888:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `internal_realloc': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:3777:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:3819:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `internal_memalign': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:3868:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:3915:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `ialloc': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:3998:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4052:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `dlmalloc': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4085:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4186:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `dlfree': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4211:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4285:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `dlmalloc_trim': /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4362:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/dlmalloc.c:4364:0: undefined reference to `pthread_mutex_unlock' /usr/haskell//lib/ghc-6.12.3/libHSffi.a(closures.o): In function `dlmmap': /home/ian/zz/ghc-6.12.3/libffi/build/src/closures.c:438:0: undefined reference to `pthread_mutex_lock' /home/ian/zz/ghc-6.12.3/libffi/build/src/closures.c:440:0: undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2.o): In function `uw_init_context_1': (.text+0x1be5): undefined reference to `pthread_once' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__deregister_frame_info_bases': (.text+0x10bc): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__deregister_frame_info_bases': (.text+0x10cd): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_table_bases': (.text+0x117f): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_bases': (.text+0x1238): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `_Unwind_Find_FDE': (.text+0x14b6): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `_Unwind_Find_FDE': (.text+0x14c7): undefined reference to `pthread_mutex_lock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_table_bases': (.text+0x119e): undefined reference to `pthread_mutex_unlock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/libgcc_eh.a(unwind-dw2-fde-glibc.o): In function `__register_frame_info_bases': (.text+0x1257): undefined reference to `pthread_mutex_unlock' collect2: ld returned 1 exit status There are two main categories of error messages above: 1 : ...requires at runtime the shared libraries from the glibc version used for linking 2a : undefined reference to `pthread_....' 2b : undefined reference to `pthread_mutex_lock' I've had no luck in sorting out how to solve this and an quite new to both Linux and Haskell. I never managed to install (build from source failed) the entire Haskell Platform on CentOS 5.5, is that needed? Anyone has got any idea what might causing these errors? Regards, Frode

3 4

unix-compat and GHC 7.0.2
by Michael Snoyman 15 Mar '11

15 Mar '11

Hi all, I'm having trouble compiling unix-compat with GHC 7.0.2. I'm fairly certain that other users are not running into this, but I'm not sure what would be wrong on my system. Here's the error I'm getting: Resolving dependencies... Configuring unix-compat-0.2.1.1... cabal: Missing dependency on a foreign library: * Missing header file: HsUnixCompat.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: unix-compat-0.2.1.1 failed during the configure step. The exception was: ExitFailure 1 Any ideas? Thanks, Michael

3 3

Question on a common pattern
by tsuraan 15 Mar '11

15 Mar '11

In my code, I'm doing this quite a lot: x <- someIO case x of Opt1 -> ... Having a line for extracting the value from the IO (or STM) and then acting on the value seems unnatural. Is there a more concise way to do this? This code: case someIO of Opt1 -> ... Doesn't work, but is there something like that, that is valid?

9 11

simple stm question
by qld3303 15 Mar '11

15 Mar '11

I recently upgraded to ghc 7.0.2 from 6.12.3, along with the Haskell platform, and noticed that the following code no longer works as expected: waitFor tvar = atomically $ do count <- readTVar tvar check (count == 0) worker tchan tvar = loop where loop = do putStrLn "checking" finished <- atomically $ isEmptyTChan tchan threadDelay 50000 if finished then atomically $ do val <- readTVar tvar writeTVar tvar $ (subtract 1) val else (atomically $ readTChan tchan) >> loop test = do tchan <- newTChanIO pure $ forM_ [1..5] $ writeTChan tchan -- THIS LINE tvar <- newTVarIO 1 forkIO $ worker tchan tvar waitFor tvar putStrLn "DONE" This will work if I use atomically, but otherwise it does nothing, tchan remains empty afterwards. I'm not clear how this should behave.

3 3

ANN: craftwerk-0.1, craftwerk-cairo-0.1, craftwerk-gtk-0.1
by Malte Harder 14 Mar '11

14 Mar '11

Dear all, I just released the first version of the Craftwerk graphics library for 2d vector graphics. Craftwerk is intended to act as an abstract interface to different backend drivers. The library itself has a TikZ (http://sourceforge.net/projects/pgf) driver builtin to output vector graphics for use in LaTeX documents. The craftwerk-cairo library supplies a Cairo output function to the library. The aim is to support these two backends in a seamless manner such that graphics created with either backend are not or nearly not distinguishable. The third package (craftwerk-gtk) contains convenience functions to display graphics created with craftwerk directly in a Gtk window, including the basic zooming, PDF & TikZ export via a file chooser dialog. It also allows to create a simple user interface that passes options to the rendering function. The feature support is rather rudimentary at the moment, but for current Cairo users most features should be already available from within the craftwerk API. The aim is to support more high level functions like TikZ offers. The project started when I realized that I need to prepare a lot of visualizations at university twice, once for display and once for print. I hope that this library proves to be useful for people with similar tasks. A great thing would be if the Chart library allows to plug another backend in. I haven't really looked into that, but this would allow me to leave Gnuplot and R behind for most purposes and at the same time get higher quality output that is better integrable. I started learning Haskell only half a year ago and this is my first real project. So far I have to say that I enjoy it very much. Therefore, if you find some weird constructions or have any comments about the design of the library, I'm looking forward for any feedback! The source repository can be found under: https://github.com/mahrz/Craftwerk and packages here: http://hackage.haskell.org/package/craftwerk-0.1 http://hackage.haskell.org/package/craftwerk-cairo-0.1 http://hackage.haskell.org/package/craftwerk-gtk-0.1 Best, Malte -- Malte Harder malte.harder(a)gmail.com

2 2

Re: [Haskell-cafe] Uninstall Haskell Platform on Mac OS X
by Jesse Schalken 14 Mar '11

14 Mar '11

This leaves the symlinks "alex", "cabal", "cabal.real", "cabal.wrap" and "happy" in "/usr/bin", and also leaves "/Library/Frameworks/HaskellPlatform.framework", and while I can remove those myself how can I be certain there isn't something else left behind? On Tue, Mar 15, 2011 at 1:31 AM, Anders Persson <anders.cj.persson(a)gmail.com > wrote: > This is what I do. > > At a terminal prompt: > > sudo /Library/Frameworks/GHC.framework/Versions/Current/Tools/Uninstaller > > sudo rm -r /Library/Haskell > > Cheers, > Anders > > On Mar 14, 2011, at 3:22 PM, Jesse Schalken wrote: > > Simple question which an hour of googling and a question on #haskell > couldn't satisfy. :( > > I have installed the Haskell Platform 2011.2.0.0 on Mac OS X 10.6.6. > > Now how do I *uninstall* it? > > Thanks, > Jesse > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > >

2 1

writing to a fifo when the reader stops reading
by briand＠aracnet.com 14 Mar '11

14 Mar '11

Hi all, here's the code: writer = do threadDelay 100000 threadWaitWrite fd fdWrite fd ((show x) ++ "\n") writer fd (x+1) pretty simple, it just keeps writing. What happens though is that, eventually, the reader goes away, i.e. "closes" the fifo. When that happens I get: ghc: fdWriteBuf: resource vanished (Broken pipe) which make sense, sort of. I write a value, let's say 10, and the reader reads it. It's the last value so it "closes" the fifo. Now there's nothing reading, so when I get to threadWaitWrite, I would expect the program to wait, just as it does when it starts up and there is no reader. looking for some guidance. Thank you, Brian

3 3

Uninstall Haskell Platform on Mac OS X
by Jesse Schalken 14 Mar '11

14 Mar '11

Simple question which an hour of googling and a question on #haskell couldn't satisfy. :( I have installed the Haskell Platform 2011.2.0.0 on Mac OS X 10.6.6. Now how do I *uninstall* it? Thanks, Jesse

3 3