- Libraries - Haskell.org

A bug in IntMap
by Simon Peyton-Jones 07 Jul '05

07 Jul '05

Dear library folk, Christian posted a bug to Sourceforge concerning the IntMap library, function split. Can anyone shed any light? Better still, fix it? Simon and I have too many other bugs to nail for 6.4.1 thanks Simon http://sourceforge.net/tracker/index.php?func=detail&aid=1195579&group_i d=8032&atid=108032 "keys $ split 5 $ theMap" sometimes returns values greater 5. I am still trying to pinpoint the bug, but since it shows itself only deep inside a complicated structure, I have problems doing so. One pointer might be, that my values are partially evaluated functions, but this is only a guess. (Changing the data structure to Data.Map restores normal operation in my algorithm)

4 4

another wash compile problem
by Frederik Eaton 06 Jul '05

06 Jul '05

When I compile WASH it takes forever for ghc to finish compiling HTMLMonad98, and on my powerpc system with 151MB free RAM, gcc crashes during the compile. Should some of the larger WASH modules maybe be split into multiple files? I get the sense that ghc compilation time/memory is super-linear in the size of the module being compiled. Frederik

1 1

Data.Monoid
by Ross Paterson 05 Jul '05

05 Jul '05

We can only have one instance of a class for a particular type, so how do we choose? The module Data.Monoid contains the instance instance Monoid (a -> a) where mempty = id mappend = (.) I want to argue that a more natural instance is the pointwise lifting: instance Monoid b => Monoid (a -> b) where mempty _ = mempty mappend f g x = f x `mappend` g x This instance is compositional, in that it builds instances for complex types (like functions of many arguments) out of instances for simpler ones, and it's consistent with the instances for tuples. It's also Haskell 98. If the second instance were used instead, the first could be replaced with one for data Endo a = Endo { runEndo :: a -> a } That's a bit awkward, but not as much as simulating the pointwise lifting by hand.

1 0

Re: wash compile problem
by Frederik Eaton 04 Jul '05

04 Jul '05

Actually I think there was an earlier error, it was refusing to write to package.conf for some reason. Maybe it should give up when this happens, so the relevant error message doesn't get buried? Also, how does one install WASH without root access? I tried to specify the user package.conf, but if this doesn't exist then it looks like the WASH installer won't create it, and also its pathname is not obvious so it seems unfriendly to require users to specify the literal path... Frederik On Sat, Jul 02, 2005 at 05:02:59PM +0200, Peter Thiemann wrote: > >>>>> "fe" == Frederik Eaton <frederik(a)a5.repetae.net> writes: > > fe> When I try to install the new version of WASH (2.4.6), I get errors > fe> saying that certain dependencies don't exist: > > fe> ... > fe> Reading package info from stdin... done. > fe> ghc-pkg: dependency Utility doesn't exist > > Strange. The Utility package is also provided by WASH. > Was there an error message in the Utility subdirectory? > What is the output of `ghc-pkg list' afterwards? > Did you run `make install' with sufficient karma to change the package > registry? Eg, as root? > > -Peter >

1 1

STM help
by John Meacham 04 Jul '05

04 Jul '05

I am attempting to use the STM to rewrite the screen handling code in ginsu, which frankly, I am a little embarassed of :) The basic needs are: - fully concurrent - all curses calls must go through a single thread (otherwise it gets real complicated) - atomic updates to multiple parts of the screen at once. - efficient update mechanism, screen _must not_ be needlessly redrawn. So, my idea was basically, have a screen update thread, this is the only one that will make curses calls. everything else communicates with the screen by modifying TVars holding data values like so data Widget = HBox { subWidgets :: [TVar Widget] } | Text { body :: TVar String } and the screen is represented by a top level 'TVar Widget' This gives the first three requirements very nicely, you can atomically update several widgets or tex boxes, and everything is very concurrent in a good way. The problem comes in when trying to implement an efficient update mechanism, the problem is that I can't figure out how to wait on only the relevant changed TVars. The structure of my curses thread would look like (essentially): cursesThread head = do atomically $ do tv <- readTVar head doit <- render tv -- returns an IO action which draws the screen, calling readTVar on subwidgets. return doit doit -- What to put here to block on relevant changes? cursesThread head The problem is that many TVars may contribute to the final screen, one can change a TVar several widgets down and the screen should be updated. In addition, the screen should not be redrawn if a TVar for an offscreen or hidden widget changes. other threads should be able to update state without worrying about the UI. Now, i can think of a couple things, neither of which I like very much. - create a wrapper monad around STM that accumulates a list of TVars read. This is just unappealing for a variety of reasons. - have render return some sort of keys to compare values too and retry if they are all equal to their old values. this would double the work, one pass to draw it, another pass to figure out we need to block. it would also really complicate the code. Now, the other reason these options are undesirable, is that the STM mechanism collects the exact information I need. AFAIK there is just no way to get at it. the STM must keep a log of all TVars read in order to know what to wait on when retrying. What I need is a way to somehow atomically commit (assuming the transaction succeeds) and then be able to block on the depended on TVars This could be done with the addition of a simple primitive: - | behave exactly like 'atomically' except after the transaction succeeeds, run the action on the result, and then block until one of the TVars read by the transaction changes. atomicallyBlock :: STM a -> (a -> IO b) -> IO b I think this could be very useful in general, but perhaps there is something I am not seeing? I am still figuring out idioms to use with STM. John -- John Meacham - ⑆repetae.net⑆john⑈

2 2

Network library: getting host address
by Manuel M T Chakravarty 03 Jul '05

03 Jul '05

Is there any good reason why I can get a bound socket's port with getPortSocket, but cannot get its host address (ie, IP number)? Sure, this makes only sense for ip sockets, but there it is sometimes crucial to get at this information. I can get the information using the lower-level Network.Socket using > SockAddrInet _ hostAddr <- getSocketName socket > host <- inet_ntoa hostAddr but I think that this is the kind of information that needs to be available in the high-level interface, too. BTW, shouldn't Network also reexport constants, such as aNY_PORT and iNADDR_ANY. Manuel

1 1

wash compile problem
by Frederik Eaton 02 Jul '05

02 Jul '05

When I try to install the new version of WASH (2.4.6), I get errors saying that certain dependencies don't exist: ... Reading package info from stdin... done. ghc-pkg: dependency Utility doesn't exist make[2]: *** [install-package] Error 1 make[2]: Leaving directory `/home/frederik/WashNGo-2.4.6/Mail' make[2]: Entering directory `/home/frederik/WashNGo-2.4.6/cgi' /usr/bin/install -c -d /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4 /usr/bin/install -c -d /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4/import /usr/bin/install -c -c -m 644 AbstractSelector.hi CGI.hi CGIConfig.hi CGIGraphics.hi CGIInternals.hi CGIMonad.hi CGIOutput.hi CGITypes.hi CGIXX.hi ContentType.hi Cookie.hi CookieIO.hi Debug.hi EventHandlers.hi Fields.hi Frames.hi GuaranteedCGI.hi HTMLMail.hi HTMLWrapper.hi Images.hi PPM.hi Persistent2.hi RawCGITypes.hi RawCGI.hi RawCGIInternal.hi StateItem.hi Style.hi Submit98.hi SubmitXX.hi Types.hi /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4/import /usr/bin/install -c -c -m 644 libWASH-CGI.a /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4 ranlib /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4/libWASH-CGI.a .././GenPKG/GenPKG WASH-CGI --ghc-version 6.4 --version 1.4.38 --license BSD3 --author 'Peter Thiemann' --exposed-modules AbstractSelector CGI CGIConfig CGIGraphics CGIInternals CGIMonad CGIOutput CGITypes CGIXX ContentType Cookie CookieIO Debug EventHandlers Fields Frames GuaranteedCGI HTMLMail HTMLWrapper Images PPM Persistent2 RawCGITypes RawCGI RawCGIInternal StateItem Style Submit98 SubmitXX Types --hidden-modules --import_dirs /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4/import --library_dirs /home/frederik/arch/ppc/lib/WASH-CGI-1.4.38/ghc-6.4 --hs_libraries WASH-CGI --package_deps haskell98 text WASHHTML WASHMail Utility | /usr/bin/ghc-pkg update - --package-conf ~/.ghc/powerpc-linux-6.4/package.conf --auto-ghci-libs Reading package info from stdin... done. ghc-pkg: dependency WASHHTML doesn't exist make[2]: *** [install-package] Error 1 Frederik -- http://ofb.net/~frederik/

1 0

RE: package mounting
by Simon Marlow 29 Jun '05

29 Jun '05

On 23 June 2005 10:14, Frederik Eaton wrote: > It looks like there's been a bit of recent discussion regarding module > and package namespaces. There is a certain possible design feature > that I don't think has been mentioned yet, that I think would be very > helpful, so I thought I should at least bring it up. This idea has been raised before, but it was a while back, and we called it "grafting". Here's the start of the thread, which went on for quite some time: http://www.haskell.org/pipermail/libraries/2003-August/001310.html I suspect that various opinions raised in that thread have now changed (mine included). I'm not sure I can succinctly describe why the idea wasn't adopted - I think it is a combination of the complexity it introduces in the implementations, the feeling that the power to weight ratio is a little too low, and the fact that at the time there were many other issues to resolve in the packaging system without considering grafting. As I said, opinions may have changed, and it might be worthwhile to discuss this again. Cheers, Simon

4 4

RE: package mounting
by Simon Marlow 29 Jun '05

29 Jun '05

On 29 June 2005 12:56, Benjamin Franksen wrote: > On Tuesday 28 June 2005 11:30, Simon Marlow wrote: >> So our story for portability is that code which is intended to >> compile on more than one system must travel with its dependencies, >> where those dependencies include which packages (and versions) the >> code requires and which compiler options are required to compile it. >> All this information is stored in the .cabal file, so code is >> portable if it is a Cabal package. Grafting locations fit into this >> scheme nicely. > > Yes. Nevertheless, I agree with Frederik that the package should only > provide a default location in the module name space. I want to be able > to override this default with a compiler flag, and possibly also in > the .cabal file for the client application. Absolutely - sorry for introducing unnecessary confusion. In the paragraph you quoted above, I was referring to the grafting locations of the *dependencies*, not the package itself. Cheers, Simon

1 0

RE: package mounting
by Simon Marlow 29 Jun '05

29 Jun '05

On 28 June 2005 07:34, Frederik Eaton wrote: >> And for the same reason we have "exposed" packages, it makes sense to >> have a default set of grafting locations per user/system (this is >> debatable; indeed sometimes I think we should remove "exposed" >> completely and force non-Cabal users to write -package flags). > > I'm not sure what this "same reason" is - exposed packages are a > reason to require a faithful module namespace, and default grafting > locations would help provide that, is this it? The only reason to have "exposed" packages is so that you don't have to specify a bunch of -package options when invoking GHC or GHCi. It's convenient to be able to just import a hierarchical module without having to say which package it comes from. However, exposed packages are evil because there's no guarantee that different systems will have the same set of exposed packages, so code that compiled on one system may not compile on another. But this is no worse than the non-portability caused by different systems having different packages installed, or different versions of packages, or indeed different compilers. So our story for portability is that code which is intended to compile on more than one system must travel with its dependencies, where those dependencies include which packages (and versions) the code requires and which compiler options are required to compile it. All this information is stored in the .cabal file, so code is portable if it is a Cabal package. Grafting locations fit into this scheme nicely. Cheers, Simon

2 1