- Glasgow-haskell-users

RE: broken link
by Simon Marlow 20 Jan '03

20 Jan '03

> The page > <http://haskell.cs.yale.edu/ghc/docs/5.04.2/html/network/index.html> > links to the "CGI" library, but following that link produces the > following error: > > Forbidden > > You don't have permission to access > /ghc/docs/5.04.2/html/network/Network.CGI.html on this server. > > Looking at the download-able archive of the documentation, it appears > that the page is simply missing. The page is there, but I assume because it contains the string ".CGI" the server is mistakenly refusing to serve it. I'll see if the webmaster knows why. > On a similar notion: The "parent" link in the generated documentation > almost never works. Say, you are on the documentation for > Control.Arrow and follow the "parent" link, then the link will point > to "PATH/Control.html" -- which does not exist; the correct name would > be "PATH/index.html". I _guess_ that this can be fixed by providing > appropriate flags to Haddock, but I am not sure. Yes, this should be fixed. The idea is to take you to the parent *module*, which for many nodes in the tree doesn't exist (eg. Foreign.C has a parent, but Control.Monad doesn't). The parent button should just be removed if there isn't a parent module. Cheers, Simon

1 0

RE: comparison of execution speed of array types
by Zdenek Dvorak 20 Jan '03

20 Jan '03

Hello, >DiffArray seems to be broken :). Either that or I'm using it >incorrectly. I've attached the relevant code, but when I don't reverse >the array everything works fine; when I reverse it the program doesn't >(seem to) halt. I've tried to use DiffArray recently and it is terribly slow. I was forced to write my own version (it is a bit faster, but still nothing great). My suspicion about the result of your measuring is that it does the updates in reversing the array one by one, thus leading to quadratic behavior. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

Using --make with -odir and hierarchical modules
by Martin Norbäck 20 Jan '03

20 Jan '03

The GHC manual needs to specify what happens when you use -odir and hierarchical modules with --make. I posted to the list about this before but it was not resolved: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-October/004178.… Here is an example: . |-- Library | |-- Bar | | `-- Module.hs | `-- Foo | `-- Module.hs `-- Program |-- Program.hs `-- output Program.hs uses Bar.Module and Foo.Module. Then, doing cd to Program # ghc -i../Library --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, ../Library/Bar/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, ../Library/Foo/Module.o ) Compiling Main ( Program.hs, ./Program.o ) ghc: linking ... everything works fine. Using -odir: # ghc -i../Library -odir output --make Program ghc-5.04.2: chasing modules from: Program Compiling Bar.Module ( ../Library/Bar/Module.hs, output/Module.o ) Compiling Foo.Module ( ../Library/Foo/Module.hs, output/Module.o ) Compiling Main ( Program.hs, output/Program.o ) ghc: linking ... <LONG LINKER ERROR> Error, since both modules are compiled to the same file. This should not happen. What should be done about it? Solution 1: -odir is relative to the source directory (files will end up in Library/Bar/output/Module.o and Library/Foo/output/Module.o). This is a change of semantics from the earlier behaviour of -odir (files are put in another place). On the other hand, it may be more natural to put files relative to their source, like --make without -odir does. The question remains what to do if -odir is an absolute path. Solution 2: files put in -odir are put in directories (files will end up in Program/output/Bar/Module.o and Program/output/Foo/Module.o) This is also a slight change in semantics, since files are put in directories. May affect Makefiles that does "ar output/*.o" or similar. Solution 3: files put in -odir will have their full module name (files will end up in Program/Output/Bar.Module.o and Program/Output/Foo.Module.o) This is an ever lesser change in semantics, and is better than solution 2 in my opinion. I would recommend using solution 1 if the path name is relative and solution 3 if it's absolute. Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

5 4

broken link
by Peter Simons 16 Jan '03

16 Jan '03

The page <http://haskell.cs.yale.edu/ghc/docs/5.04.2/html/network/index.html> links to the "CGI" library, but following that link produces the following error: Forbidden You don't have permission to access /ghc/docs/5.04.2/html/network/Network.CGI.html on this server. Looking at the download-able archive of the documentation, it appears that the page is simply missing. On a similar notion: The "parent" link in the generated documentation almost never works. Say, you are on the documentation for Control.Arrow and follow the "parent" link, then the link will point to "PATH/Control.html" -- which does not exist; the correct name would be "PATH/index.html". I _guess_ that this can be fixed by providing appropriate flags to Haddock, but I am not sure. -peter

1 0

ADV: Chipworks Inside Technology - Just Released Circuit Analysis Reports
by Chipworks 15 Jan '03

15 Jan '03

1 0

Feature Request: ghci source file monitoring
by Sengan.Baring-Gould＠nsc.com 15 Jan '03

15 Jan '03

It would be nice if ghci had a mode which made it monitor the loaded source files, and recompile them as soon as one of the files change. jikes (IBM's opensource java compiler) does this, and it's very useful when fixing compile errors since you don't need to switch to and from the editor. I assume the new native threads stuff could be used here. Sengan

1 0

RE: Question about literals in the core-language
by Simon Marlow 14 Jan '03

14 Jan '03

> I'm working at comparing the ghc-core-language with another > lambda-calculus. > This calculus has no unboxed values, but normal constructors > are available. > My problem is now: How can I represent the unboxed values in > my calculus. > More precisely: Can I represent the unboxed values by a finite set of > constants, > or include the literals also integers, which can be infinite? > If that is the > case, > how are the (unboxed) integers represented in the ghc-core-language? First, there is a distinction between unboxed and unlifted types. An unlifted type is one who's domain of values does not include _|_. All of GHC's primitive types(*) are unlifted. An unboxed type is unlifted, but also it is not represented by a pointer. Its representation depends on the type (eg. Int# is a 32- or 64-bit signed integral value). Integers do not have associated primitive types. An Integer in GHC is defined as data Integer = S# Int# -- small integers | J# Int# ByteArray# -- large integers Cheers, Simon (*) well, except for RealWorld, but that is Deeply Special anyway.

1 0

Question about literals in the core-language
by David Sabel 13 Jan '03

13 Jan '03

Hello, I'm working at comparing the ghc-core-language with another lambda-calculus. This calculus has no unboxed values, but normal constructors are available. My problem is now: How can I represent the unboxed values in my calculus. More precisely: Can I represent the unboxed values by a finite set of constants, or include the literals also integers, which can be infinite? If that is the case, how are the (unboxed) integers represented in the ghc-core-language? Thanks for your comments! David Sabel ----------------- JWGU Frankfurt

1 0

RE: openFile and threads
by Simon Marlow 13 Jan '03

13 Jan '03

> > Haskell Strings are a common performance bottleneck; for > example when > > serving files in the Haskell web server I avoided the conversion to > > Haskell Strings altogether by reading/writing arrays of > bytes (see the > > paper for details). > > I was curious to see if this is also the case here. Therefore I just > pasted the GHC implementation of openFile into Peter's suspicious > module ('openFile' obtained from > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ba > se/GHC/Handle.hs---I > hope this was the right one?) to be able to also profile the GHC > internal openfile code. Here are the relevant parts of the resulting > output of the profiler: > > COST CENTRE MODULE %time %alloc > > withCString' MailStore 39.1 19.7 Interesting - I just looked at the code for withCString and it is being poorly optimised. There are several layers of FFI abstraction which aren't being inlined/deforested away. Thanks for the pointer, I'll take a look at this. Cheers, Simon

1 0

RE: openFile and threads
by Simon Marlow 13 Jan '03

13 Jan '03

> > You might consider bypassing the Handle interface and going > to the bare > > metal using the Posix library, which will cut down on the > overhead in > > openFile. > > That's what I was fearing. Is the conversion from Haskell Strings to > C strings a performance problem? Haskell Strings are a common performance bottleneck; for example when serving files in the Haskell web server I avoided the conversion to Haskell Strings altogether by reading/writing arrays of bytes (see the paper for details). But it sounds like in your case you need to open lots of (small?) files. What do you do with the contents of the files? Cheers, Simon

2 1