RE: A question about GHC-5.03
Title: Message First thing to do is to read the manual (comes with the snapshot, I hope), where I tried to document it. Mark and I are writing the paper! You could try "Putting type annotations to work" by Odersky and Laufer for some useful background Simon -Original Message-From: Sean Seefried [mailto:[EMAIL PROTECTED]] Sent: 14 February 2002 00:52To: [EMAIL PROTECTED]Subject: A question about GHC-5.03 One of the new features of the latest snapshot of GHC is that : "The type system now supports arbitrary rank polymorphism, given appropriate type annotations." Could you point me to some literature on this feature and how it is used? I'm familiar with rank-2 polymorphic types. I am not however familiar with what an "appropriate type annotation" is. Sean Seefried
RE: problem with source 5.03
| There seems to be a problem with the source tar.bz2 | distribution of the | 5.03 snapshot. The web page claims it's 5.3M, but the actualy file is | only 4117517 bytes and doesn't untar properly: | | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed Files, 0 | bytes, 0 tape blocks | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed | Files/Language Independent, 0 bytes, 0 tape blocks | tar: directory checksum error | | I was able to grab a CVS image, but someone should probably fix this. The web page is wrong. The file is OK. haskell:~/website/dist/5.03.20020204$ ls -l ghc-5.03.20020204-src.tar.bz2 -rw-rw-r--1 sewardj sewardj 4117517 Feb 5 09:17 ghc-5.03.20020204-src.tar.bz2 haskell:~/website/dist/5.03.20020204$ bzip2 -tv ghc-5.03.20020204-src.tar.bz2 ghc-5.03.20020204-src.tar.bz2: ok and I guess you are untarring it on solaris, using the solaris tar? If so try GNU tar? J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The size of things
While waiting for the gurus to bestow upon me fragments of their wisdom, I've stumbled further on my path to enligthenment: [EMAIL PROTECTED] (Ketil Z. Malde) writes: E.g. how much [space] for [...] a data type with only nullary data constructors -- should I use Word8s instead? From my superficial testing data Alphabet = A | B | C | D is no worse than using Word8. Is this a correct observation? Would it change if I somehow managed to get things to work with Word8# instead, or will the compiler automatically unbox things when I stuff them in tuples, lists or arrays anyway? The GHC docs seem to discourage using unboxed types. (BTW, it took me a while to discover that Word8 hides in PrelWord. I may have missed some obvious place to look, but perhaps it could be better documented?) I realize I can use profiling to determine heap use, Actually, I can't. Binaries created with ghc -prof -auto-all segmentation fault on startup. This is GHC 5.02.1 installed from an RPM on a RH7.2 box. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Weird symbol prevents GHCi from loading my package.
I built quite a big library and turned it into a package. It works fine if use ghc -package gtk2 Blah.hs to compile things. But when I convert all the libraries to object files as described in the documentation, GHCi refuses to load the whole machinery: ~/source/mogul/fpDemo:$ ghci -package gtk2 Arabic.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Loading package gtk2 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol gcc2_compiled. whilst processing object file /home/as49/local/lib/gtk2hs/gtk2hs.o I think this is due to a bug in GHCi's linker, which has been fixed post 5.02.2. I tripped over it recently while trying to use Gtk+HS in GHCi on my RedHat 7.2 box. There are two bugs tickled by gcc 2.96: our linker wasn't dealing with sections with names other than the standard ones (.text, .data, .rodata) properly, and there was also some infelicities in the local-symbol handling (Julian S. can tell you more). The workaround I used is to compile up any .c files in your package *without* -O, and without -g if you were also using that. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: CVS Build problem
If you're building the CVS version of GHC, it usually helps to keep an eye on [EMAIL PROTECTED] where these kind of things are generally announced (in this case, I mentioned it in the commit message). The building guide tends to lag a little, but it will get updated. Cheers, Simon -Original Message- From: Hal Daume III [mailto:[EMAIL PROTECTED]] Sent: 13 February 2002 22:41 To: Nicholas Nethercote Cc: GHC users list Subject: RE: CVS Build problem Ah, thanks. I was having the same problem but was too shy to ask about it, figuring it must be my bad. This should probably be mentioend in the build documentation (hint, hint). - Hal -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Wed, 13 Feb 2002, Nicholas Nethercote wrote: On Wed, 13 Feb 2002, Nicholas Nethercote wrote: That's what I did. It made ghc ok, but then when it tries the 'make boot' in hslibs it falls over. The same happens if I change into $(BUILD)/hslibs and do 'make boot'... Ok, I've worked out the problem: I just checked out the modules ghc and hslibs. It seems that the standard library has just been moved into a new separate module libraries. So my build was missing the standard library which was causing the problem. -- Nick Nethercote [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: The size of things
I'm building some stuff here that is basically a glorified and specialized version of quicksort. It is very quick, and works like a charm for my purposes, except that it consumes way too much space, about 100 bytes times the size of the input list. Which means that, for my data sets, the program exceeds available RAM and uses swap, which in turn kills performance. Is there any guideline how much space the various constructs use? E.g. how much for cons cells (or whatever that make up lists), how much for a data type with only nullary data constructors -- should I use Word8s instead? -- how much for tuples, and so on. I realize I can (and I do somewhat) use profiling to determine heap use, but it'd be nice to be able to do back-of-envelope calculations and have some idea of what's the right approach. Ok, roughly speaking, in GHC every object requires one word plus one word for each field (a word is 4 bytes on a 32-bit machine). In other words, a cons cell will require 3 words. An Int requires two words. A Char usually requires no words (chars up to 256 are cached in the RTS). Nullary constructors require no dynamic storage. The smallest dynamic object is 2 words: ie. a Word8 requires 2 words, even though the useful data it contains is only a single byte. Of course, all of this just applies to fully-evaluated structures - any suspensions (thunks) will screw up the calculations, and certainly the amount of temporary allocation required to *generate* a particular structure is very rarely predictable. You can save storage by using strict constructor fields and using the -funbox-strict-fields flag. eg. data FloatList = FloatNil | FloatCons !Float FloatList requires 3 words for each float in the list, because its actual representation is data FloatList = FloatNil | FloatCons Float# FloatList (Float# is an unboxed float). We heartily recommend strict constructor fields: apart from saving space and time, they help avoid space leaks. Using -funbox-strict-fields is a good way to get the benefits of unboxed types without digging around in GHC's low-level primitive types operations. Does that help? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: problem with source 5.03
Ah, yes, that's it. Thanks :) -- Hal Daume III Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes. -Dijkstra | www.isi.edu/~hdaume On Thu, 14 Feb 2002, Julian Seward (Intl Vendor) wrote: | There seems to be a problem with the source tar.bz2 | distribution of the | 5.03 snapshot. The web page claims it's 5.3M, but the actualy file is | only 4117517 bytes and doesn't untar properly: | | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed Files, 0 | bytes, 0 tape blocks | x ghc-5.03.20020204/ghc/InstallShield/Setup Files/Compressed | Files/Language Independent, 0 bytes, 0 tape blocks | tar: directory checksum error | | I was able to grab a CVS image, but someone should probably fix this. The web page is wrong. The file is OK. haskell:~/website/dist/5.03.20020204$ ls -l ghc-5.03.20020204-src.tar.bz2 -rw-rw-r--1 sewardj sewardj 4117517 Feb 5 09:17 ghc-5.03.20020204-src.tar.bz2 haskell:~/website/dist/5.03.20020204$ bzip2 -tv ghc-5.03.20020204-src.tar.bz2 ghc-5.03.20020204-src.tar.bz2: ok and I guess you are untarring it on solaris, using the solaris tar? If so try GNU tar? J ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
strange behavior with ghci version 5.02.2
I just noticed this behavior with ghci After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Regards, Martin -- Martin Norbäck Safelogic AB [EMAIL PROTECTED]Stena Center 1C +46 (0)31 772 81 70S-412 92 GÖTEBORG http://www.safelogic.seSWEDEN ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: strange behavior with ghci version 5.02.2
After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Yes, for some modules it happens for others it doesn't. Kind of strange. SuSE 7.3 rpms here, v. 5.02.2 J.A. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
scope in ghci. Reply
Martin Norb [EMAIL PROTECTED] writes I just noticed this behavior with ghci After loading a module with :l Module you can't use the Prelude functions unqualified, you just get things like interactive:1: Variable not in scope: `show' I am pretty sure that this worked some days ago, and I was using the same version then. I feel totally confused. Has this happened to anyone else? Even if Prelude is visible, still the library items are not. (List.sort, Ratio ...). Maybe, this is natural, I do not know. But I believe, it is possible to control the scope. For example, create a module Universe.hs which re-exports Prelude, libraries and user programs. Then, :l Universe should bring to scope all these items. - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
