- Glasgow-haskell-users

Using packages in ghci
by Adrian Hey 01 Oct '04

01 Oct '04

Hello, Where does ghci look for .hi files from packages? (I doesn't seem to be the same place as ghc). AFAICT it expects to find them relative to the current directory, and I can only get it to work by cding to the appropriate directory *before* invoking ghci (doing this from within ghci seems to really mess things up). But I guess this isn't what's supposed to happen because this solution will only work with one package. My package entry looks like this.. Package {name = "Data.Tree.AVL", auto = True, import_dirs = ["/home/adrian/HaskellLibs/Data.Tree.AVL/pkg"], source_dirs = [], library_dirs = ["/home/adrian/HaskellLibs/Data.Tree.AVL/pkg"], hs_libraries = ["Data.Tree.AVL"], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = ["base", "Data.COrdering"], extra_ghc_opts = [], extra_cc_opts = [], extra_ld_opts = [], framework_dirs = [], extra_frameworks = []} Is there something missing here? Thanks -- Adrian Hey

1 0

Is there a non-blocking version of hGetArray?
by Peter Simons 01 Oct '04

01 Oct '04

Hi, I am a happy user of hGetBufNonBlocking, but I have come to realize that mutable arrays are nicer to work with than pointers, so I have considered using hGetArray instead. I do, however, depend on the fact that the function returns as soon as it has read data -- even if less than requested --, like hGetBufNonBlocking does. Is there currently a way to achieve this? Am I right assuming that hGetBuf and hGetArray do not differ much performance-wise? One of the reasons I am curious about using mutable arrays is because of Data.Array.Base.unsafeRead, which seems to be a *lot* faster than accessing the memory through a pointer. Is there anything comparable for pointer access? Peter

1 0

RE: constant space `minimum'
by Simon Peyton-Jones 30 Sep '04

30 Sep '04

| I meant that the implementation like | | minimum [x] = x | minimum (x:y:xs) = if x > y then minimum (y:xs) | else minimum (x:xs) It would be great if this was the defn of minimum in the Report. But it isn't. Consider data T = T1 | T2 instance Ord T where min x T2 = T2 min x y = error "urk" Now try minimum [T1,T2,T2] your defn gives "urk", but the Report gives T2. Stupid, I know, but that's what it says. So the best thing seems to be to give monomorphic instances of minimum for types where we know the instances! Simon

3 2

ghc-6.2.2-sep-26 tested
by Serge D. Mechveliani 30 Sep '04

30 Sep '04

Dear GHC team, I have tested ghc-6.2.2-september-26 under our RedHat Linux: compiling of GHC by itself, automatic test of the DoCon and prover programs, -Onot, -O, profiling with -auto-all. It looks all right. I was lazy to re-run manually the examples from the DoCon Manual: they were all right in ghc-6-2-2-branch-CVS and hope will be so in the official ghc-6.2.2. I need official and reliable ghc-6.2.2 greatly. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Haddock: how to disable the JavaScript menus?
by Simon Marlow 30 Sep '04

30 Sep '04

On 30 September 2004 10:08, Simon Marlow wrote: > On 28 September 2004 16:06, Malcolm Wallace wrote: > >> On the theme of improving Haddock, do you think it could be fixed to >> generate valid HTML? Here are some examples of the errors I get when >> running Haddock output through "validate" (the Web Design Group's >> HTML and XML validator). > > Oops! I did check the output with a validator at one point, but it > looks like I've broken it since. Thanks for pointing it out. > It appears that the current CVS Haddock sources generate valid HTML, according to the W3C validator. Cheers, Simon

1 0

RE: Haddock: how to disable the JavaScript menus?
by Simon Marlow 30 Sep '04

30 Sep '04

On 28 September 2004 16:06, Malcolm Wallace wrote: > On the theme of improving Haddock, do you think it could be fixed to > generate valid HTML? Here are some examples of the errors I get when > running Haddock output through "validate" (the Web Design Group's > HTML and XML validator). Oops! I did check the output with a validator at one point, but it looks like I've broken it since. Thanks for pointing it out. Cheers, Simon

1 0

constant space `minimum'
by Serge D. Mechveliani 29 Sep '04

29 Sep '04

Simon Marlow responds on the subject of constant space `minimum': > In 6.4, minimum & maximum will have specialised versions for Int & > Integer, which will run in constant stack space. We can't do this in > general, because minimum/maximum have the type > > (Ord a) =3D> [a] -> a > > and we can't assume that the comparison operations for any given type > are always strict. > I meant that the implementation like minimum [x] = x minimum (x:y:xs) = if x > y then minimum (y:xs) else minimum (x:xs) is correct, and on the other hand, GHC compiles it more readily into an efficient code than the version done via foldl or such. ----------------- Serge Mechveliani mechel(a)botik.ru

2 2

RE: Deforestation of literal lists
by Simon Peyton-Jones 29 Sep '04

29 Sep '04

Carsetn This, plus your earlier message about unfold, certainly make sense. But with the rules below, there's a danger that long literal lists would give rise to a huge nest of cons/build rule firings, which are ultimately all undone again. So I'm a bit cautious about building these rules in. But you can just add them yourself, by writing RULES. (Use the rules in the prelude for guidance). If you get noticeable performance wins, without obvious downside, then I'd certainly think about adding them to GHC. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Carsten Schultz | Sent: 17 September 2004 15:09 | To: glasgow-haskell-users(a)haskell.org | Subject: Deforestation of literal lists | | Hi! | | Just a thought... | | Would it be a sensible thing to not desugar | | [x, y, z] | | into | | (:) x ((:) y ((:) z [])), | | but into | | build (\ c n -> c x (c y (c z n)))? | | Alternatively, how about the following rules? | | {-# RULES | "singleton" [~1] forall x . (:) x [] = build (\c n -> c x n) | #-} | | {-# RULES | "cons/build" [~1] forall (x::a) (f:: forall b . (a->b->b) -> b -> b) . | (:) x (build f) = build (\c n -> c x (f c n)) | #-} | | This should be useful for example in conjuction with sequence_ or // | applied to short lists. Has this been discussed before? | | Greetings, | | Carsten | | -- | Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin | http://carsten.codimi.de/ | PGP/GPG key on the pgp.net key servers, | fingerprint on my home page.

1 0

RE: Haddock: how to disable the JavaScript menus?
by Simon Marlow 28 Sep '04

28 Sep '04

On 27 September 2004 21:15, Peter Simons wrote: > Simon Marlow writes: > > > This change has now been made. > > Uh ... any hints what has changed? A new command line flag? > > > > we need a way to retain the collapsed/expanded state > > between page transitions (JavaScript hackers apply > > here!). > > I am not certain whether these collapsed menus are a good > idea. Admitted, they make the page shorter at first glance. > But at the same time, they make it impossible to search in > the text! > > When I want to see the documentation for, say Data.List, I > hit CTRL-HOME in Mozilla, then type "/data.lis", and finally > press RETURN to follow the link -- and I have reached the > page. The hands never left the keyboard. With collapsed > menus, that doesn't work anymore. > > Anyway, if there was an option to enable/disable that > functionality in Haddock, all would be well. :-) The tree is expanded by default now (Sven Panne made the change a few days ago). I take your point about searching in Mozilla - I'm a big fan of Firefox's incrememtal search too. The problem I was originally trying to solve is when you have a huge number of instances for a datatype (look at the docs for Prelude, for example), which makes it hard to navigate the page. I'm not sure if we can solve this *and* have searching do the right thing. Cheers, Simon

4 4

RE: rewrite rule pragma syntax
by Simon Marlow 28 Sep '04

28 Sep '04

On 09 September 2004 16:51, Henning Thielemann wrote: > I encountered the same problem as this guy: > http://www.haskell.org/pipermail/glasgow-haskell-users/2002-May/003407.h tml > > It is still present in GHC-6.2.1. Only if you turn on -fglasgow-exts > the RULES pragma is parsed correctly. I think GHC should give a > warning like "turn -fglasgow-exts on for RULES pragma" instead of: > > Media.hs:23: Variable not in scope: `forall' > > Media.hs:23: Variable not in scope: `f' > > Media.hs:23: Variable not in scope: `f' > > Media.hs:23: Variable not in scope: `f' GHC will now ignore RULES pragmas when -fglasgow-exts is not enabled. Ideally we'd like to give a warning too, but there doesn't exist a mechanism for issueing warnings from the lexer right now, so I'll leave that until later. Cheers, Simon

1 0