January 2003 - Glasgow-haskell-users

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

RE: Uninitialized UArray - feature or bug?
by Simon Marlow 13 Jan '03

13 Jan '03

> This is a little weird: > > Prelude> :m + Data.Array.Unboxed > Prelude Data.Array.Unboxed> let f () = array (1, 5) [] :: > UArray Int Int > Prelude Data.Array.Unboxed> f () == f () > False > > Are we giving away purity for efficiency? ;) > If this behaviour is intended, maybe it should be documented? > > Maybe it would be a good idea to define default values for types which > can be unboxed? That's a very good point :) Fixed now, thanks. Cheers, Simon

1 0

RE: FFI & C++ & Cygwin
by Simon Peyton-Jones 13 Jan '03

13 Jan '03

| It is possible to trick ghc into using cygwin's gcc in mingw-mode, | the following steps works for me to do that: Interesting. The only worry is that the run-time system and libraries are all pre-compiled with the mingw gcc. So it's not clear to me that the process Peter outlines will always work. Or, if it does, why doesn't it work using the mingw gcc all the time for Haskell files? Here's a guess: use g++ -mno-cygwin for the C++ files and ordinary ghc for the Haskell files. Then, linking with ghc will give linking errors, as Koen found, only because the g++ files expect to be linked with some g++ runtime system code. If that is the only problem, it can be solved by doing g++ -v to link, seeing what extra link libraries are given to ld, and giving those same libraries to the ghc link step. Or, dually, see what libraries ghc passes to ld, and give those to g++. If this works, and someone will write it up, I'll add it to the users guide. Incidentally, on the subject of building GHC to target Cygwin (rather than Mingw), I'm sure it's possible, because Sigbjorn has done it, although it's not a route we support, and I just don't know understand all the differences well enough to know what the problems are. But, if someone makes it work (which I'm sure is possible) I'd gladly apply make-system patches, and add guidance notes to the building guide, in here: http://haskell.cs.yale.edu/ghc/docs/latest/html/building/winbuild.html Simon | * compile the c++-stuff with g++ -mno-cygwin | * copy /usr/bin/gcc.exe to c:/ghc/ghc-5.04.2/gcc.exe | * rename c:/ghc/ghc-5.04.2/gcc-lib to something else | (ghc feeds a -B option to gcc, which we cannot(?) override) | * compile with "ghc -optl -mno-cygwin -lstdc++" | (add -optc -mno-cygwin if -fvia-C is used) | | (i.e. we would like to use /usr/bin/gcc -mno-cygwin as the linker) | | I think it should be possible to use -pgml instead of replacing | the binary, but that didn't work for me.. | | > However, I have tried to recompile the C++ libraries using | > the Mingwin C++ compiler but it starts throwing pages of | > error messages at me. | | However, the method above doesn't help if you really need cygwin | for your c++-library, which you seem to do? | | | /Peter | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

System.CPUTime
by Koen Claessen 13 Jan '03

13 Jan '03

Dear all, I have a question about the semantics of the function 'getCPUTime' in the module 'System.CPUTime'. Does it ever reset itself? I.e. is there a guarantee that if t1 is the result of a call to getCPUTime, any other call to getCPUTime will produce a result that is greater? It seems not to reset itself on Solaris and Linux GHC (or it has a very long period), but it seems to reset itself within 5 minutes or so on Windows GHC (version 5.04.2, binary downloaded from GHC's homepage, running Windows 2000). Regards, /Koen.

1 0