April 2010 - Libraries

Network library patches
by Neil Mitchell 20 Apr '10

20 Apr '10

Hi I finally got the network library (darcs) building, installing and basically working on Windows with GHC 6.12.1. To do this I set up my environment as follows: 1) Install Cygwin 1.7 (include autoreconf) 2) Install GHC 6.12.1 3) export PATH=/cygdrive/c/ghc/ghc-6.12.1/mingw/bin:$PATH I then did the network steps: 1) Grab network from darcs 2) autoreconf 3) Apply the patch attached, which just changes the .cabal file 4) Change all instances of CALLCONV to stdcall 5) cabal install Please can you apply the attached patch, which should be compatible with Linux/Mac too. I found lots of references to CALLCONV all over the place, but couldn't figure out where it started/ended up - my attempts at #define were rather unsuccessful. Could you please change the logic so Windows gets stdcall as standard? I'm happy to test any patches you come up with. Having a working network library on Windows will be really nice, as it's stopped me upgrading to GHC 6.12.1 for a while now. Thanks, Neil

3 5

Re: Patch to add process group support
by Simon Marlow 19 Apr '10

19 Apr '10

For future reference, the procedure for changes like this is to follow the Library Submissions guidelines at http://www.haskell.org/haskellwiki/Library_submissions. In this case you've already made a patch and a detailed proposal, so I don't see any reason why we shouldn't consider it anyway. My thoughts on the changes: - yes to adding new_group to the CreateProcess record, and corresponding support to System.Process.Internals - no to adding runCommandNewGroup, and the other *NewGroup functions. These were kept mostly for backwards compatibility anyway, the new API is createProcess, shell, proc, readProcess. I don't think people need new_group often enough to provide canned variants of runCommand etc. for it. Cheers, Simon On 17/04/2010 16:26, Hamish Mackenzie wrote: > The attached patch for the process package adds support for creating and interrupting process groups on Unix and Win32 systems. Currently we have to use a nasty hack in Leksah that only works on Unix systems (and even then not very well). On Win32 Leksah's background build feature is dreadful as a results (because it has no way to interrupt the build and start over when the user makes more changes). > > I would love to get this onto Hackage somehow, if not as a new version of the process package, perhaps as an alternative package ("process-groups" using System.Process.Groups instead of System.Process). > > Please can you have a look and let me know what you think? > > Thanks, > Hamish > > > This patch introduces the following functions to System.Process > > * runCommandNewGroup, runProcessNewGroup, runInteractiveCommandNewGroup and runInteractiveProcessNewGroup __ > These are variations on the existing functions for running processes. They create the child process as the lead process in a new process group. > Unix - calls setpgid in both the parent and the child process after fork. > Win32 - calls CreateProcess with the CREATE_NEW_PROCESS_GROUP set. I also had it unset CREATE_NO_WINDOW because this seems to prevent the child attaching to the parents console (and therefor stops interuptProcessGroup from working). > > * interruptProcessGroup > This function can be used interrupt a running process group. > Unix - calls signalProcessGroup to send sigINT > Win32 - If the process ID is known it calls generateConsoleCtrlEvent to send cTRL_BREAK_EVENT > > > __ Compatibility __ > > Backward Compatibility > CreateProcess has a new field new_group which may need to be added to some existing code. If set to False the current behaviour is preserved. As far as I know this is the only change that could break existing code. > > Linker Errors > I have renamed the C functions it used in order to prevent linker errors when using this new version with the existing process package. > > > __ Win32 Only __ > > On Win32 the process handle is not the same as the process ID and there is no reliable way to convert from one to the other. I have added an interface that allows access to the process ID, but does not change the behaviour of the existing functions. > > * PINFO > Replaces PHANDLE in the ProcessHandle type. > type PINFO = (PHANDLE, Maybe Word32) -- Handle and Process ID > > * mkProcessHandleWithPID > Like mkProcessHandle but allows you to specify the processes ID as well. This function is now used in all the run functions so the ProcessHandle they return will contain a process ID. > > * withProcessInfo and withProcessInfo_ > Like withProcessHandle functions but gives you access to the PINFO (not just the PHANDLE it contains). >

2 1

darcs patch: Provide a dummy input file for queryfdoption01
by Matthias Kilian 18 Apr '10

18 Apr '10

1 patch for repository http://darcs.volkswurst.de/packages/unix: Sun Apr 18 19:26:19 CEST 2010 Matthias Kilian <kili(a)outback.escape.de> * Provide a dummy input file for queryfdoption01

1 0

darcs patch: Ignore the return code of c_fcntl_write again
by Matthias Kilian 16 Apr '10

16 Apr '10

1 patch for repository http://darcs.volkswurst.de/packages/base: Thu Apr 15 16:04:52 CEST 2010 Matthias Kilian <kili(a)outback.escape.de> * Ignore the return code of c_fcntl_write again The return code has been ignored in the past on purpose, because O_NONBLOCK will fail on BSDs for some special files. This fixes the problem mentioned in http://www.haskell.org/pipermail/glasgow-haskell-users/2010-April/018698.ht…

2 1

Haskell time library: Weekday and Month
by Henning Thielemann 16 Apr '10

16 Apr '10

I recently wanted to move from old-time to time in my bibtex package, but I was no longer so enthusiastic about it, when I became aware, that for instance weekdays and months are handled as plain numbers. Wouldn't it be better to make them enumerations or newtypes (if efficiency is important)? For a complex matter like coping with time it would be nice to have precise types in order to know, what can be converted to what given what context. In case of weekdays and months a custom type would also make it irrelevant for the user, whether you count days and months starting from zero or one.

3 2

Re: Move MonadIO to base
by John Lato 13 Apr '10

13 Apr '10

> From: Isaac Dupree <ml(a)isaac.cedarswampstudios.org> > > On 04/10/10 11:35, Twan van Laarhoven wrote: >> If MonadIO were in base, then the base library itself could also use it. >> For example the functions in System.IO could be lifted to work on any >> MonadIO monad. Whether that is a good idea is completely orthogonal to >> this discussion, however. > > I think it is relevant to the discussion to consider whether the MonadIO > class is a good idea in general -- if it's not a broad enough use, then > maybe we shouldn't implicitly sanction it by putting it in 'base'. Is > it mainly to make monad-transformer code more readable* by requiring > fewer explicit lifts? Are there other reasons? (Pointing to example > code that uses MonadIO would be a good answer.) I think MonadIO is essential for writing polymorphic low-level libraries. In the iteratee library, I couldn't write e.g. Data.Iteratee.IO.Handle.enumHandle (or any of the enumerators) without MonadIO. This library interfaces with IO functions but it can't know the monad stack as that is meant to be determined by the client. Without MonadIO, I'd need to write multiple versions of the function for each level of nesting, or clients would need to write their own enumerators, neither of which is as good a solution as MonadIO. > > (I see nothing wrong with splitting MonadIO out into a new package > (besides that proliferation of packages is a bit annoying)... > ) I wouldn't mind if a new MonadIO package, whether it's in base or not. John

1 0

Re: Move MonadIO to base
by John Lato 12 Apr '10

12 Apr '10

> From: Yitzchak Gale <gale(a)sefer.org> > > Twan van Laarhoven wrote: >> If MonadIO were in base, then the base library itself could also use it. For >> example the functions in System.IO could be lifted to work on any MonadIO >> monad. Whether that is a good idea is completely orthogonal to this >> discussion, however. > > The main problem is that exceptions don't work well with > MonadIO in GHC. So really MonadIO is currently only a toy and > cannot be used in production code. > > The reason for this is that just about any operation involving exceptions > ultimately depends (via the source code of base library functions) > on the function > > block :: IO a -> IO a What about the approach used in MonadCatchIO, http://hackage.haskell.org/package/MonadCatchIO-mtl ? The MonadCatchIO class has two functions "block" and "unblock", which are implemented as e.g. instance MonadCatchIO IO where catch = E.catch block = E.block unblock = E.unblock instance MonadCatchIO m => MonadCatchIO (ReaderT r m) where m `catch` f = ReaderT $ \r -> (runReaderT m r) `catch` (\e -> runReaderT (f e) r) block = mapReaderT block unblock = mapReaderT unblock with mapReaderT :: (m a -> n b) -> ReaderT r m a -> ReaderT r n b mapReaderT f m = ReaderT $ f . runReaderT m To my eye this solves the problem of "block" and "unblock" being baked-in to GHC, because they will be applied through the stack to the underlying IO operations as the user would expect. I could be mistaken, though. If this approach is correct and MonadIO is moved to base, I would think that "block" and "unblock" at least should be added to MonadIO. John

1 0

problem getting cabal-install to work on CentOS 5.2
by Chris Dornan 11 Apr '10

11 Apr '10

Hi, I am trying to install cabal-install 0.8.2 with GHC 6.12.1 on a CentOS 5.2 system and am running up against a 'ExitFailure 127' error. I can download the package and run 'cabal install' inside the package directory and all will be fine, but if I let cabal download and install the package cabal runs into problems as soon as it tries to configure. For example, if I try 'cabal install permutation --verbose=3' it finishes like this: link: done *** Deleting temp files: Deleting: /tmp/ghc1324_0/ghc1324_0.lpp *** Deleting temp dirs: Deleting: /tmp/ghc1324_0 /tmp/permutation-0.4.132758/permutation-0.4.1/dist/setup/setup configure --verbose=3 --ghc --prefix=/home/chris/.cabal --user --constraint=base ==3.0.3.2 --constraint=ghc-prim ==0.2.0.0 cabal: Error: some packages failed to install: permutation-0.4.1 failed during the configure step. The exception was: ExitFailure 127 I have tried the same exercise with GHC 6.10.4 with cabal-install 0.8.0 the same results. I have downloaded the Cabal sources to try and add some instrumentation to find out what is going wrong I have yet to succeed. Does anybody have any suggestions? Is there an easier way of getting cabal-install working on CentOS? Any help much appreciated! Chris

1 0

Re: Haskell Platform 2010.1.0.0 Windows installer RC2 - library documentation?
by Mikhail Glushenkov 11 Apr '10

11 Apr '10

Hi, On Sat, Apr 10, 2010 at 2:45 PM, Arne Dehli Halvorsen <arne.d.h(a)gmail.com> wrote: > Hello, > I have installed the Haskell Platform under XP, and could't find the > documentation for non-core libraries (Parsec etc). > Have they gone missing? Or am I missing something? > I easily found them in the MacPorts Haskell Platform for 6.10.4. This is a known issue [1]. I plan to fix it in the 2010.2.0 release (due this month). [1] http://trac.haskell.org/haskell-platform/ticket/30 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 0

Derive Typeable and Eq instances for TMVar, TChan (and TArray)
by Bas van Dijk 10 Apr '10

10 Apr '10

Hello, I noticed the stm types TMVar and TChan don't have Typeable and Eq instances while their MVar counterparts do have them. I propose to add them: http://hackage.haskell.org/trac/ghc/ticket/3973 The patch bundle included in the ticket also contains patches that add these instances to TArray. However I'm not sure if it makes sense to have an Eq instance for TArray so it's probably wise to have some discussion on this. regards, Bas

1 0