- Haskell-Cafe - Haskell.org

How to daemonize a threaded Haskell program?
by Bas van Dijk 07 Mar '11

07 Mar '11

Hello, I like to turn my Haskell program into a unix daemon. One of the steps in "daemonizing" a process is to fork it then exit the parent and continue with the child. All this is nicely abstracted in hdaemonize[1] which internally calls forkProcess[2]. I would also like to use multiple simultaneous threads in my program. Unfortunately forkProcess is not supported when running with +RTS -N so I can't use hdaemonize. I understand why it's problematic to fork a process which is in the middle of running multiple simultaneous threads. However, in the case of a daemon the fork happens in the beginning of the program. So if I can manage to create a program that first daemonizes my process then starts the Haskell program, all is good. My current plan is to have a custom Haskell main function which is exported using the FFI: --------------------------------------------------------------------- {-# LANGUAGE ForeignFunctionInterface #-} module MyMain where import Control.Monad ( forM_ ) import Control.Concurrent ( threadDelay ) -- from hsyslog: import System.Posix.Syslog ( Priority(Debug), syslog ) foreign export ccall myMain :: IO () myMain :: IO () myMain = forM_ [1..10 :: Int] $ \n -> do syslog Debug $ "test " ++ show n threadDelay 1000000 --------------------------------------------------------------------- Then create a C program that first daemonizes my process (using the 'daemon'[3] function from unistd) then start up my custom Haskell main function: --------------------------------------------------------------------- #include <unistd.h> #include "HsFFI.h" #include "MyMain_stub.h" extern void __stginit_Main ( void ); int main(int argc, char *argv[]) { int r; r = daemon(0,0); if (r < 0) { return r; } hs_init(&argc, &argv); hs_add_root(__stginit_Main); myMain(); hs_exit(); return 0; } --------------------------------------------------------------------- My question is: how can I combine these two into a single program? I very much prefer to do this using Cabal since my actual program contains lots of dependencies. Thanks, Bas [1] http://hackage.haskell.org/package/hdaemonize [2] http://hackage.haskell.org/packages/archive/unix/latest/doc/html/System-Pos… [3] http://www.kernel.org/doc/man-pages/online/pages/man3/daemon.3.html

7 10

can't download haskell-mode for emacs: directory is empty
by Richard Cobbe 06 Mar '11

06 Mar '11

I'm trying to see if I'm running the latest version of haskell-mode.el. Unfortunately, the download link at the top of <http://www.haskell.org/haskellwiki/Haskell_mode_for_Emacs> points to a directory with nothing in it. Is there somewhere else I should be looking? I tried sending email to the maintainer a couple of weeks ago, but I haven't heard a response. What's the status on this package? Thanks, Richard

3 3

Benchmarks game updated
by Don Stewart 06 Mar '11

06 Mar '11

Isaac Gouy from the Language Benchmarks game tells me that they're starting to use GHC 7.0.2, there are a few tweaks, new flags (e.g. the LLVM backend) and other experiments people might like to try. Additionally, there are a couple of build failures that should be fixed. http://shootout.alioth.debian.org/u64q/measurements.php?lang=ghc -- Don

3 2

Creating a darcs repo and trac
by Dominic Steintiz 06 Mar '11

06 Mar '11

I'd like to create a darcs repo for a package I've just created so people can do: darcs get http://code.haskell.org/largeword I can logon to code.haskell.org but I don't have permission to create a directory in /srv/code which is what I thought I had to do. Ditto I would like to create a trac instance on trac.haskell.org. I recall using createtrac but that no longer seems to be available. Is there a wiki page that explains all? Thanks, Dominic.

2 1

Combinatorial Problems
by Richard Senington 06 Mar '11

06 Mar '11

Hello all, I have just uploaded a very early (0.0.1) version of a library I am working on to hackage. The library is for representing some well known combinatorial problems, and provide loading routines for standard repositories of these problems. At the moment is only support SAT-3 and the SATLIB loading routines. It does have a set of functions for TSP, but I have not yet finished reworking the TSPLIB loading code yet. Hopefully that will be coming soon. It is a very early version so not heavily tested, but I thought it would be better to put it up so that if anyone is interested they can have a look and make suggestions. Any comments, bug reports or modification ideas, please feel free to email me. RS

1 0

Use of uninstantiated type class
by Yves Parès 06 Mar '11

06 Mar '11

Hello, For testing purposes, I am trying to make an overlay to IO which carries a phantom type to ensure a context. I define contexts using empty type classes : class CtxFoo c class CtxBar c The overlay : newtype MyIO c a = MyIO (IO a) Then I define some methods that run only a specific context : runFoo :: (CtxFoo c) => MyIO c a -> IO a runFoo (MyIO x) = x runBar :: (CtxBar c) => MyIO c a -> IO a runBar (MyIO x) = x And then an action that runs in context 'Foo' : someAction :: (CtxFoo c) => MyIO c () someAction = putStrLn "FOO" Then I run it : main = runFoo someAction But obiously, GHC complains that my type 'c' remains uninstantiated : Ambiguous type variable `c' in the constraint: (CtxFoo c) arising from a use of `runFoo' Probable fix: add a type signature that fixes these type variable(s) In the expression: runFoo someAction In an equation for `main': main = runFoo someAction Is there a way to deal with this ? The interest of using type classes and not empty types to represent the contexts is that it stays simple, and that I can do that : someAction2 :: (CtxFoo c, CtxBar c) => MyIO c () someAction2 = putStrLn "FOO and BAR" ... a function that can run in both contexts.

4 5

Linking errors when compiling projects with the ncurses-0.2 library
by Román González 06 Mar '11

06 Mar '11

Greetings, Right now I'm developing an app, and I want to use the ncurses library, everything compiles correctly, however when I'm linking, ugly things start to happen: I'm on Mac OS X Snow Leopard, with Haskell Platform 2010.2.0.0<http://hackage.haskell.org/platform/changelog.html> This is the installation process I'm following, everything runs as expected until trying to build the project with Cabal. Thanks in advance. *$ brew install ncursesw --universal* Warning: It appears you have MacPorts or Fink installed. Software installed with MacPorts and Fink are known to cause problems. If you experience issues try uninstalling these tools. ==> Downloading http://ftp.gnu.org/pub/gnu/ncurses/ncurses-5.7.tar.gz File already downloaded and cached to /Users/roman/Library/Caches/Homebrew ==> ./configure --prefix=/Users/roman/.homebrew/Cellar/ncursesw/5.7 --mandir=/Users/roman/.homebrew/Cellar/ncursesw/5.7/share/man --disable-debug --disable-dependency-tracking --e ==> make install /Users/roman/.homebrew/Cellar/ncursesw/5.7: 2734 files, 14M, in 93 seconds *$ cabal install ncurses --extra-include-dirs=/Users/roman/.homebrew/include --extra-lib-dirs=/Users/roman/.homebrew/lib --reinstall* Resolving dependencies... Configuring ncurses-0.2... Preprocessing library ncurses-0.2... Building ncurses-0.2... [1 of 4] Compiling UI.NCurses.Enums ( dist/build/UI/NCurses/Enums.hs, dist/build/UI/NCurses/Enums.o ) [2 of 4] Compiling UI.NCurses.Types ( UI/NCurses/Types.hs, dist/build/UI/NCurses/Types.o ) [3 of 4] Compiling UI.NCurses ( dist/build/UI/NCurses.hs, dist/build/UI/NCurses.o ) [4 of 4] Compiling UI.NCurses.Panel ( dist/build/UI/NCurses/Panel.hs, dist/build/UI/NCurses/Panel.o ) UI/NCurses/Panel.chs:49:0: Warning: The import of `UI.NCurses' is redundant except perhaps to import instances from `UI.NCurses' To import instances alone, use: import UI.NCurses() Registering ncurses-0.2... Installing library in /Users/roman/.cabal/lib/ncurses-0.2/ghc-6.12.3 Registering ncurses-0.2... *$ cabal build* Preprocessing executables for TicTacToe-0.1... Building TicTacToe-0.1... Linking dist/build/TicTacToe/TicTacToe ... ld: warning: in /Users/roman/.homebrew/lib/libncursesw.dylib, file was built for unsupported file format which is not the architecture being linked (i386) Undefined symbols: "_start_color", referenced from: _s9ZP_info in libHSncurses-0.2.a(NCurses.o) "_wget_wch", referenced from: _sfkI_info in libHSncurses-0.2.a(NCurses.o) "_wenclose", referenced from: _s9Fs_info in libHSncurses-0.2.a(NCurses.o) "_beep", referenced from: _ncurseszm0zi2_UIziNCurses_beep1_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _ncurseszm0zi2_UIziNCurses_beep2_closure, _ncurseszm0zi2_UIziNCurses_beep1_srt , _ncurseszm0zi2_UIziNCurses_beep_srt , _ncurseszm0zi2_UIziNCurses_beep3_info , _ncurseszm0zi2_UIziNCurses_beep2_srt , _ncurseszm0zi2_UIziNCurses_beep3_srt , _ncurseszm0zi2_UIziNCurses_beep1_closure , _ncurseszm0zi2_UIziNCurses_beep_info , _ncurseszm0zi2_UIziNCurses_beep1_info , _ncurseszm0zi2_UIziNCurses_beep3_closure , _ncurseszm0zi2_UIziNCurses_beep2_info , _ncurseszm0zi2_UIziNCurses_beep_closure ) "_echo", referenced from: _sc50_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: ___hscore_echo) "_can_change_color", referenced from: _ncurseszm0zi2_UIziNCurses_canDefineColor1_info in libHSncurses-0.2.a(NCurses.o) "_init_color", referenced from: _s97K_info in libHSncurses-0.2.a(NCurses.o) _scw2_info in libHSncurses-0.2.a(NCurses.o) "_wnoutrefresh", referenced from: _s2JC_info in NCurses.o _scSh_info in libHSncurses-0.2.a(NCurses.o) "_noraw", referenced from: _scaE_info in libHSncurses-0.2.a(NCurses.o) "_wtouchln", referenced from: _sd53_info in libHSncurses-0.2.a(NCurses.o) _sd53_info in libHSncurses-0.2.a(NCurses.o) "_wcolor_set", referenced from: _sav6_info in libHSncurses-0.2.a(NCurses.o) "_meta", referenced from: _s9KC_info in libHSncurses-0.2.a(NCurses.o) _scV2_info in libHSncurses-0.2.a(NCurses.o) "_initscr", referenced from: _ncurseszm0zi2_UIziNCurses_runCurses2_info in libHSncurses-0.2.a(NCurses.o) "_stdscr", referenced from: _stdscr$non_lazy_ptr in NCurses.o _stdscr$non_lazy_ptr in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _stdscr$non_lazy_ptr) "_wbkgrndset", referenced from: _scOA_info in libHSncurses-0.2.a(NCurses.o) "_raw", referenced from: _scaE_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _ffi_closure_raw_SYSV$non_lazy_ptr, _ffi_closure_raw_SYSV , _ffi_raw_call , _ffi_prep_raw_closure_loc ) "__nc_has_mouse", referenced from: _hsncurses_has_mouse in libHSncurses-0.2.a(hsncurses-shim.o) "_wtimeout", referenced from: _s9KE_info in libHSncurses-0.2.a(NCurses.o) _scV4_info in libHSncurses-0.2.a(NCurses.o) _sfkG_info in libHSncurses-0.2.a(NCurses.o) "_doupdate", referenced from: _ncurseszm0zi2_UIziNCurses_render1_info in libHSncurses-0.2.a(NCurses.o) "_baudrate", referenced from: _ncurseszm0zi2_UIziNCurses_baudrate1_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _ncurseszm0zi2_UIziNCurses_baudrate1_info, _ncurseszm0zi2_UIziNCurses_baudrate_info , _ncurseszm0zi2_UIziNCurses_baudrate3_closure , _ncurseszm0zi2_UIziNCurses_baudrate_closure , _ncurseszm0zi2_UIziNCurses_baudrate_srt , _ncurseszm0zi2_UIziNCurses_baudrate2_info , _ncurseszm0zi2_UIziNCurses_baudrate2_closure , _ncurseszm0zi2_UIziNCurses_baudrate1_closure , _ncurseszm0zi2_UIziNCurses_baudrate3_info , _ncurseszm0zi2_UIziNCurses_baudrate1_srt , _ncurseszm0zi2_UIziNCurses_baudrate2_srt , _ncurseszm0zi2_UIziNCurses_baudrate3_srt ) "_whline_set", referenced from: _s9gs_info in libHSncurses-0.2.a(NCurses.o) "_wvline_set", referenced from: _s9fL_info in libHSncurses-0.2.a(NCurses.o) "_cbreak", referenced from: _s9ZJ_info in libHSncurses-0.2.a(NCurses.o) _sc7P_info in libHSncurses-0.2.a(NCurses.o) "_endwin", referenced from: _ncurseszm0zi2_UIziNCurses_endwin_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _ncurseszm0zi2_UIziNCurses_endwin_info, _ncurseszm0zi2_UIziNCurses_endwin_closure ) "_wattr_on", referenced from: _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) _saal_info in libHSncurses-0.2.a(NCurses.o) "_newwin", referenced from: _s9du_info in libHSncurses-0.2.a(NCurses.o) "_getmouse", referenced from: _sfkP_info in libHSncurses-0.2.a(NCurses.o) "_touchwin", referenced from: _sa69_info in libHSncurses-0.2.a(NCurses.o) "_untouchwin", referenced from: _sa6c_info in libHSncurses-0.2.a(NCurses.o) "_has_colors", referenced from: _ncurseszm0zi2_UIziNCurses_supportsColor1_info in libHSncurses-0.2.a(NCurses.o) _s9ZN_info in libHSncurses-0.2.a(NCurses.o) "_mousemask", referenced from: _s9ZL_info in libHSncurses-0.2.a(NCurses.o) "_use_default_colors", referenced from: _s9ZS_info in libHSncurses-0.2.a(NCurses.o) "_waddwstr", referenced from: _sduP_info in libHSncurses-0.2.a(NCurses.o) "_wmove", referenced from: _sdBo_info in libHSncurses-0.2.a(NCurses.o) "_dupwin", referenced from: _scTH_info in libHSncurses-0.2.a(NCurses.o) "_keypad", referenced from: _ncurseszm0zi2_UIziNCurses_zdwa3_info in libHSncurses-0.2.a(NCurses.o) _say8_info in libHSncurses-0.2.a(NCurses.o) _say8_info in libHSncurses-0.2.a(NCurses.o) _scV0_info in libHSncurses-0.2.a(NCurses.o) "_noecho", referenced from: _sc50_info in libHSncurses-0.2.a(NCurses.o) "_flash", referenced from: _ncurseszm0zi2_UIziNCurses_flash1_info in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _ncurseszm0zi2_UIziNCurses_flash1_closure, _ncurseszm0zi2_UIziNCurses_flash_info , _ncurseszm0zi2_UIziNCurses_flash_srt , _ncurseszm0zi2_UIziNCurses_flash_closure , _ncurseszm0zi2_UIziNCurses_flash1_info , _ncurseszm0zi2_UIziNCurses_flash2_info , _ncurseszm0zi2_UIziNCurses_flash3_closure , _ncurseszm0zi2_UIziNCurses_flash1_srt , _ncurseszm0zi2_UIziNCurses_flash2_srt , _ncurseszm0zi2_UIziNCurses_flash2_closure , _ncurseszm0zi2_UIziNCurses_flash3_info , _ncurseszm0zi2_UIziNCurses_flash3_srt ) "_wborder_set", referenced from: _scFt_info in libHSncurses-0.2.a(NCurses.o) "_COLS", referenced from: _COLS$non_lazy_ptr in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _COLS$non_lazy_ptr) "_init_pair", referenced from: _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _saTg_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) _scdx_info in libHSncurses-0.2.a(NCurses.o) "_nocbreak", referenced from: _sc7P_info in libHSncurses-0.2.a(NCurses.o) "_delwin", referenced from: _sb4T_info in libHSncurses-0.2.a(NCurses.o) "_getcurx", referenced from: _s9Iy_info in libHSncurses-0.2.a(NCurses.o) "_getcury", referenced from: _s9Ix_info in libHSncurses-0.2.a(NCurses.o) "_color_content", referenced from: _sff4_info in libHSncurses-0.2.a(NCurses.o) "_COLOR_PAIRS", referenced from: _COLOR_PAIRS$non_lazy_ptr in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _COLOR_PAIRS$non_lazy_ptr) "_wattr_get", referenced from: _s9vO_info in libHSncurses-0.2.a(NCurses.o) "_wattr_off", referenced from: _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) _saaF_info in libHSncurses-0.2.a(NCurses.o) "_wattr_set", referenced from: _s9vS_info in libHSncurses-0.2.a(NCurses.o) "_LINES", referenced from: _LINES$non_lazy_ptr in libHSncurses-0.2.a(NCurses.o) (maybe you meant: _LINES$non_lazy_ptr) ld: symbol(s) not found collect2: ld returned 1 exit status

3 3

GHC 7.0.2 and haddock
by Maciej Marcin Piechotka 06 Mar '11

06 Mar '11

Is there any version of haddock that builds with ghc 7.0.2? For 2.9.1 I get: src/Haddock/Interface/Create.hs:282:11: Couldn't match expected type `Located b0' with actual type `[LTyClDecl id0]' Expected type: HsGroup id0 -> [Located b0] Actual type: HsGroup id0 -> [[LTyClDecl id0]] In the first argument of `mkDecls', namely `hs_tyclds' In the first argument of `(++)', namely `mkDecls hs_tyclds TyClD group_' Regards

3 2

Re: [Haskell-cafe] Use of uninstantiated type class
by John Lato 05 Mar '11

05 Mar '11

> Message: 8 > Date: Sat, 5 Mar 2011 00:45:33 +0100 > From: Yves Par?s <limestrael(a)gmail.com> > Subject: [Haskell-cafe] Use of uninstantiated type class > To: Haskell-Cafe <haskell-cafe(a)haskell.org> > Message-ID: > <AANLkTimBg5TyG6ZNWCKaOT9dP%3DQE95MtC%3Dq_t7RRPQgv(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > For testing purposes, I am trying to make an overlay to IO which carries a > phantom type to ensure a context. > I define contexts using empty type classes : > > class CtxFoo c > class CtxBar c > > The overlay : > > newtype MyIO c a = MyIO (IO a) > > Then I define some methods that run only a specific context : > > runFoo :: (CtxFoo c) => MyIO c a -> IO a > runFoo (MyIO x) = x > > runBar :: (CtxBar c) => MyIO c a -> IO a > runBar (MyIO x) = x > > And then an action that runs in context 'Foo' : > > someAction :: (CtxFoo c) => MyIO c () > someAction = putStrLn "FOO" > > Then I run it : > > main = runFoo someAction > > But obiously, GHC complains that my type 'c' remains uninstantiated : > > Ambiguous type variable `c' in the constraint: > (CtxFoo c) arising from a use of `runFoo' > Probable fix: add a type signature that fixes these type variable(s) > In the expression: runFoo someAction > In an equation for `main': main = runFoo someAction > > > Is there a way to deal with this ? > The interest of using type classes and not empty types to represent the > contexts is that it stays simple, and that I can do that : > > someAction2 :: (CtxFoo c, CtxBar c) => MyIO c () > someAction2 = putStrLn "FOO and BAR" > > ... a function that can run in both contexts. > You can accomplish this with Rank2Types (and ScopedTypeVariables). Try this: class CtxFoo c class CtxBar c data Ctx instance CtxFoo Ctx where instance CtxBar Ctx where runFoo :: forall a. (forall c. (CtxFoo c) => MyIO c a) -> IO a runFoo x = case (x :: MyIO CtxFooD a) of (MyIO x') -> x' It's useful to compare the type of this "runFoo" with the old "runFoo" *Main> :t runFoo runFoo :: (forall c. CtxFoo c => MyIO c a) -> IO a *Main> :t runFooOld runBar :: CtxFoo c => MyIO c a -> IO a Note that the "c" type var is no longer universally quantified. This means that "runFoo" can't be used with any actions that specify a concrete context, the action must specify only the "CtxFoo" type class. There's a drawback to this approach though. The number of "run" functions is combinatorial in the number of contexts. With only two contexts, you already need "runFoo", "runBar", and "runFooBar". Unless you'll only ever need a single context, or you won't need to have combinations of them, this approach quickly grows unwieldy. John

1 0

Thoughts on program annotations.
by Jason Dusek 05 Mar '11

05 Mar '11

Hi List, I am working on a Bash config generation system. I've decided to factor out the Bash AST and pretty printer, here in a pre-release state: https://github.com/solidsnack/bash One thing I'd like to support is generic annotations, so that at a future time I can add (and render) comments, mark subscripts with what privilege (package install, sudo) they require or otherwise characterize the script outside its lexical structure. I ended up making my statement type a Functor with a Foldable instance. Given that every statement has an annotation, it seemed better to me to use mutually recursive datatypes, using one datatype to capture "annotatedness", like this: -- From https://github.com/solidsnack/bash/blob/c718de36d349efc9ac073a2c7082742c456… data Annotated t = Annotated t (Statement t) data Statement t = SimpleCommand Expression [Expression] | ... | IfThen (Annotated t) (Annotated t) | ... I wonder what folks think of this approach? It does mean I end up with all leaf-level annotations being potentially without annotations; this allows for relatively generic definitions, on the one hand; but forces type annotations at the use-site in many cases. It also means I have mutually recursive Functor and Foldable instances. Another option for annotations would be a sort of tree of zippers pointing in to the statement tree; this seems horrible at first glance since it leaves open the question of how the annotations are associated with their nodes in the first place. However, it does have the nice feature of simplifying the type of statements and also is just much more modular feeling. What does the list think? -- Jason Dusek Linux User #510144 | http://counter.li.org/

4 5