September 2004 - Glasgow-haskell-users

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

RE: constant space `minimum'
by Simon Marlow 28 Sep '04

28 Sep '04

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) => [a] -> a and we can't assume that the comparison operations for any given type are always strict. Cheers, Simon On 10 September 2004 12:17, Serge D. Mechveliani wrote: > See my next letter -- about compiling of > minimum [1 .. (10^6)] > with -O. > Because, I think, [1 .. (10^6)] is a program which interferes with > `minimum', and it depends much on how cleverly this whole expression > is complied, for example, `minimum' is in-lined or not. > > Probably, `minimum' can be rewritten so, that the whole thing will > reliably perform in a constant space in the interpreter mode too. > > And maybe it is, generally, hard to optimize reliably foldl. > > ----------------- > Serge Mechveliani > mechel(a)botik.ru > > > > On Fri, Sep 10, 2004 at 12:29:01PM +0200, Jerzy Karczmarczuk wrote: >> Serge D. Mechveliani wrote: >> >>> The library functions like minimum, maximum, >>> should perform in a constant space: probably, it is easy to write >>> them his way. And ghc-6.2.2-pre shows >>> >>> Prelude> minimum [1 .. (10^4)] >>> 1 >>> >>> Prelude> minimum [1 .. (10^6)] >>> >>> *** Exception: stack overflow >>> Prelude> >>> >>> What do you think of this, please? >>> >>> >> Strange, I thought that foldl or foldl1 don't produce such garbage >> here. I tested with Hugs, you are right also here, this is not >> specific to GHC. >> >> minim (x:l) = mi x l where >> mi x (y:q) |x<y = mi x q >> |otherwise = mi y q >> mi x [] = x >> >> This one works. But it is brutal, not so exquisite... >> >> >> Jerzy Karczmarczuk >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

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

27 Sep '04

On 27 September 2004 14:22, Peter Simons wrote: > Is there any way to tell Haddock (the version from CVS HEAD) > to _not_ generate those JavaScript menus on the contents > page? I'd rather have plain and simple HTML here. > > Or, if that isn't possible, is there any way make Haddock > generate those menus so that they are all _open_ when one > loads the page? This change has now been made. The JavaScript stuff is still experimental - I'm certainly not going to release a new Haddock version in its current state - we need a way to retain the collapsed/expanded state between page transitions (JavaScript hackers apply here!). Cheers, Simon

2 1

RE: Compiling faster
by Simon Marlow 27 Sep '04

27 Sep '04

On 23 September 2004 12:42, George Russell wrote: > I think therefore the section "Sooner: producing a program more > quickly" > > > http://www.haskell.org/ghc/docs/latest/html/users_guide/sooner-faster-qu icker.html#SOONER > > should recommend using --make to compile lots of files at a time. > And by the way, that might not be a bad idea for GHC itself ... --make might also need a lot more memory (.hi files are cleverly demand-loaded when compiling a single module), and it also leaves you rather exposed to space leaks in GHC itself. It can also be slower when only re-compiling a small number of modules in a large program. However, nevertheless it *is* better in many cases. I'll add something to that section of the docs. Cheers, Simon

1 0

newCString -- to 'free' or not?
by Peter Simons 27 Sep '04

27 Sep '04

When I create a CString with Foreign.C.String.newCString, do I have to 'free' it after I don't need it anymore? Or is there some RTS magic taking place? How about Foreign.Marshal.Utils.new and all those other newXYZ functions? Peter

3 3

Haddock: how to disable the JavaScript menus?
by Peter Simons 27 Sep '04

27 Sep '04

Is there any way to tell Haddock (the version from CVS HEAD) to _not_ generate those JavaScript menus on the contents page? I'd rather have plain and simple HTML here. Or, if that isn't possible, is there any way make Haddock generate those menus so that they are all _open_ when one loads the page? Peter

1 0

RE: newCString -- to 'free' or not?
by Bayley, Alistair 27 Sep '04

27 Sep '04

> And Alistair Reid answers a similar question I asked: Sorry... s/Alistair/Alastair/ > -----Original Message----- > From: Bayley, Alistair [mailto:Alistair_Bayley@ldn.invesco.com] > Sent: 27 September 2004 08:37 > To: 'Peter Simons'; glasgow-haskell-users(a)haskell.org > Subject: RE: newCString -- to 'free' or not? > > There are some useful guidelines hidden in section 8.2.3 of > the GHC user's > guide: > > http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ff > i-ghc.html#AEN > 10578 > > And Alistair Reid answers a similar question I asked: > http://www.reid-consulting-uk.ltd.uk/docs/ffi-Common_Problems.html > (Common Problems: Are Ptr values deallocated?) > > > In the current CVS code newCString redirects to newCAString, > which uses > mallocArray (or newArray), and which also states that storage > must be freed: > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ba > se/Foreign/C/S > tring.hs?rev=1.14 > > You can also see that Foreign.Marshal.Utils.new uses malloc: > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ba > se/Foreign/Mar > shal/Utils.hs?rev=1.12 > > > > > -----Original Message----- > > From: Peter Simons [mailto:simons@cryp.to] > > Sent: 25 September 2004 21:38 > > To: glasgow-haskell-users(a)haskell.org > > Subject: newCString -- to 'free' or not? > > > > When I create a CString with Foreign.C.String.newCString, do > > I have to 'free' it after I don't need it anymore? Or is > > there some RTS magic taking place? > > > > How about Foreign.Marshal.Utils.new and all those other > > newXYZ functions? > > > > Peter ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

RE: newCString -- to 'free' or not?
by Bayley, Alistair 27 Sep '04

27 Sep '04

There are some useful guidelines hidden in section 8.2.3 of the GHC user's guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ffi-ghc.html#AEN 10578 And Alistair Reid answers a similar question I asked: http://www.reid-consulting-uk.ltd.uk/docs/ffi-Common_Problems.html (Common Problems: Are Ptr values deallocated?) In the current CVS code newCString redirects to newCAString, which uses mallocArray (or newArray), and which also states that storage must be freed: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/C/S tring.hs?rev=1.14 You can also see that Foreign.Marshal.Utils.new uses malloc: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/Mar shal/Utils.hs?rev=1.12 > -----Original Message----- > From: Peter Simons [mailto:simons@cryp.to] > Sent: 25 September 2004 21:38 > To: glasgow-haskell-users(a)haskell.org > Subject: newCString -- to 'free' or not? > > When I create a CString with Foreign.C.String.newCString, do > I have to 'free' it after I don't need it anymore? Or is > there some RTS magic taking place? > > How about Foreign.Marshal.Utils.new and all those other > newXYZ functions? > > Peter ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Compiling faster
by George Russell 23 Sep '04

23 Sep '04

I am responsible for a large project containing 577 Haskell library modules, with almost 120 KLOC. These modules are divided into packages. They can be compiled either (1) the old way, using ghc -M to generate dependency files, and then using make to call GHC once for each file. (2) the new way, compiling each package in one GHC invocation using --make. There is a big difference in speed between the two. The new way takes 4 minutes 16 seconds; the old way 6 minutes 55 seconds, both measured in wallclock time. (This is, admittedly, with -Onot.) My guess is that a lot of this is due to initialisation, particularly the need to read and parse lots of .hi files. This takes a lot of time, even though in fact all the .hi files during this test were on local disks. I think therefore the section "Sooner: producing a program more quickly" http://www.haskell.org/ghc/docs/latest/html/users_guide/sooner-faster-quick… should recommend using --make to compile lots of files at a time. And by the way, that might not be a bad idea for GHC itself ...

1 0