- Glasgow-haskell-users

interpreter in 5.04.3
by Serge D. Mechveliani 08 May '03

08 May '03

Dear GHC team, * Is it possible to build ghc-5.04.3 with interpreter? For we have installed it from RPM, and it reports that ghci would not work. * Concerning my previous question on packages: Makefile prepares docon.conf by packDocon = Package {name = "\"docon\"", \ import_dirs = ["\"$(e)\""], \ source_dirs = ["\"$(e)\""], \ library_dirs = ["\"$(e)\""], \ hs_libraries = ["\"HSdocon\""], \ ... } , ... echo $(packDocon) | ghc-pkg -f $(s)/docon.conf -a ... With ghc-5.04.3, this leads to Reading package info from stdin... done. Expanding embedded variables...done. cannot find `libHSdocon.a' on library path Simon Marlow writes > The error is self-explanatory: it can't find libHSdocon.a on the path > given in the package specification. It looks like you might have some > extra quotation marks in there. This DoCon installation aims at the following meaning: initially, HSdocon.o, libHSdocon.a are absent, compile DoCon modules making libraries $(e)/HSdocon.o, $(e)/libHSdocon.a, and these libraries have to link when using the package docon. It works in ghc-5.02 (see haskell.org/docon, version 2.06, Makefile), and quotations look all right, because it is in Makefile and it issues `echo' ... But in ghc-5.04.3, Makefile needs to skip "HSdocon", and someone has to set it to docon.conf after the installation. Maybe, it is a trivial question, but still I wonder how to improve Makefile in a proper way. With kind regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Naming and subexpressions
by Simon Marlow 08 May '03

08 May '03

> I have a program, structured approximately like so > > main = do > let stage1 = e1... > let stage2 = e2...stage1... > stage3 <- e3...stage2 > case something of > foo -> output stage1 > bar -> output stage2 > baz -> output stage3 > > I think this is an improvement from using multiple main functions, > since it reveals the pipeline structure of the program and the > modularity of the stages. > > It appears¹, however, that naming the result of stage1 > prevents it from > being garbage collected when subsequent stages are produced. Since > stage1 is a huge list, this leads to a space leak. Hard to tell, but from the code above it looks like stage1 would be retained because it might need to be output after stage3. Could you perhaps move the output of stage1 up the pipeline? If you suspect there's a bug and something is being retained when it shouldn't be, then send us the code and we'll happily investigate. > So, is there any way to avoid this? Do I need to restructure my > program? I could conceivably do > > main = do > let stage1 = e1... > let stage2 = e2...(e1...)... > : > > and so on, but an aggressive (but slightly dumb) compiler might > rediscover the similarity and CSE it. > > Suggestions more than welcome. > > -kzm > > ¹ Memory retainer profiling shows the product being retained by > SYSTEM, so I *think* this is the right interpretation. A SYSTEM retainer is usually the stack. Cheers, Simon

2 1

RE: Histogram-building code (was: Re: Yet another weakly defined bug report)
by Simon Marlow 08 May '03

08 May '03

> One question though, about hFlush. I print out the status by > repeatedly putStr'ing "blah blah \r". With NoBuffering set, it works, > but when following the putStr with 'hFlush stdout', it doesn't (only > outputs very sporadically. I guess I'm misunderstanding the function > of hFlush, anybody care to elaborate?) It could be a bug. Can you provide us with a cut-down example? Cheers, Simon

3 2

RE: -package data in ghc-5.04.3
by Simon Marlow 07 May '03

07 May '03

> This refers the issues of `data' package (FiniteMap), > user package setting > > The Manual tells about `base' to replace `data'. > > 1. > If I put to Main.hs > > import FiniteMap > main = putStr $ shows (fmToList $ listToFM $ zip "abc" "abc") "\n" > > , then ghc -package data --make Main > works. > And ghc -package base --make Main > reports > ghc-5.04.3: chasing modules from: Main > ghc-5.04.3: can't find module `FiniteMap' ... The FiniteMap module from package 'data' is now available as Data.FiniteMap from package 'base' (there's no need to explicitly request 'base', it's always available). > 2. > Makefile sets my user package as it was with 5.02 : > ... > packDocon = Package {name = "\"docon\"", \ > import_dirs = ["\"$(e)\""], \ > source_dirs = ["\"$(e)\""], \ > library_dirs = ["\"$(e)\""], \ > hs_libraries = ["\"HSdocon\""], \ > extra_libraries = [], \ > include_dirs = [], \ > c_includes = [], \ > package_deps = [\"data\"], \ > extra_ghc_opts = [$(extraPackageOpts)], \ > extra_cc_opts = [], \ > extra_ld_opts = [] } > ... > > ghc-5.04.3 reports: dependency `data' doesn't exist This is a problem that will be fixed in the next release. For now, just omit the dependency. > Renaming data <- base gives similar report. > After changing it to package_deps = [], > > it reports: > > --------------------------------- > if [ ! -d /home/mechvel/docon/2.06/docon/source/export ]; > then mkdir /home/mechvel/docon/2.06/docon/source/export; fi > ghc-pkg -f /home/mechvel/docon/2.06/docon/source/docon.conf -l > > echo Package {name = "\"docon\"", > import_dirs = > ["\"/home/mechvel/docon/2.06/docon/source/export\""], > source_dirs = > ["\"/home/mechvel/docon/2.06/docon/source/export\""], > library_dirs = > ["\"/home/mechvel/docon/2.06/docon/source/export\""], > hs_libraries = ["\"HSdocon\""], extra_libraries = [], > include_dirs = [], c_includes = [], package_deps = [], > extra_ghc_opts = ["\"-package data\"", > "\"-fno-warn-overlapping-patterns\"", "\"-fwarn-unused-binds\"", > "\"-fwarn-unused-matches\"", "\"-fwarn-unused-imports\"", > "\"-fglasgow-exts\"", "\"-fallow-overlapping-instances\"", > "\"-fallow-undecidable-instances\"" ], extra_cc_opts = [], > extra_ld_opts = [] } > | > ghc-pkg -f /home/mechvel/docon/2.06/docon/source/docon.conf -a > > Reading package info from stdin... done. > Expanding embedded variables...done. > cannot find `libHSdocon.a' on library path The error is self-explanatory: it can't find libHSdocon.a on the path given in the package specification. It looks like you might have some extra quotation marks in there. Also, I wouldn't put '-package data' in extra_ghc_opts. I think that is unlikely to work. Cheers, Simon

1 0

-package data in ghc-5.04.3
by Serge D. Mechveliani 07 May '03

07 May '03

Dear GHC team, I am trying to build my DoCon program under ghc-5.04.3, built from RPM And the installation Makefile for ghc-5.02 does not work for 5.04.3. Could you, please, tell me how to correct it? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru ----------------------------------------------------------------- This refers the issues of `data' package (FiniteMap), user package setting The Manual tells about `base' to replace `data'. 1. If I put to Main.hs import FiniteMap main = putStr $ shows (fmToList $ listToFM $ zip "abc" "abc") "\n" , then ghc -package data --make Main works. And ghc -package base --make Main reports ghc-5.04.3: chasing modules from: Main ghc-5.04.3: can't find module `FiniteMap' ... 2. Makefile sets my user package as it was with 5.02 : ... packDocon = Package {name = "\"docon\"", \ import_dirs = ["\"$(e)\""], \ source_dirs = ["\"$(e)\""], \ library_dirs = ["\"$(e)\""], \ hs_libraries = ["\"HSdocon\""], \ extra_libraries = [], \ include_dirs = [], \ c_includes = [], \ package_deps = [\"data\"], \ extra_ghc_opts = [$(extraPackageOpts)], \ extra_cc_opts = [], \ extra_ld_opts = [] } ... ghc-5.04.3 reports: dependency `data' doesn't exist Renaming data <- base gives similar report. After changing it to package_deps = [], it reports: --------------------------------- if [ ! -d /home/mechvel/docon/2.06/docon/source/export ]; then mkdir /home/mechvel/docon/2.06/docon/source/export; fi ghc-pkg -f /home/mechvel/docon/2.06/docon/source/docon.conf -l echo Package {name = "\"docon\"", import_dirs = ["\"/home/mechvel/docon/2.06/docon/source/export\""], source_dirs = ["\"/home/mechvel/docon/2.06/docon/source/export\""], library_dirs = ["\"/home/mechvel/docon/2.06/docon/source/export\""], hs_libraries = ["\"HSdocon\""], extra_libraries = [], include_dirs = [], c_includes = [], package_deps = [], extra_ghc_opts = ["\"-package data\"", "\"-fno-warn-overlapping-patterns\"", "\"-fwarn-unused-binds\"", "\"-fwarn-unused-matches\"", "\"-fwarn-unused-imports\"", "\"-fglasgow-exts\"", "\"-fallow-overlapping-instances\"", "\"-fallow-undecidable-instances\"" ], extra_cc_opts = [], extra_ld_opts = [] } | ghc-pkg -f /home/mechvel/docon/2.06/docon/source/docon.conf -a Reading package info from stdin... done. Expanding embedded variables...done. cannot find `libHSdocon.a' on library path make: *** [init] Error 1

1 0

RE: import PrelAddr
by Simon Marlow 06 May '03

06 May '03

> I'm rewriting some old code,originally written for ghc-4.08.2 . > > 1)Now, when I compile with ghc-5.02 , fails: > > ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c > foo.hs > > foo.hs:47: > failed to load interface for `PrelAddr': > Could not find interface file for `PrelAddr' > gmake: *** [foo.o] Error 1 > > > 2)if commented, > --import PerlAddr > > ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c > foo.hs > > foo.hs:112: Type constructor or class not in scope: `Addr' > > foo.hs:514: Data constructor not in scope: `A#' > > gmake: *** [foo.o] Error 1 > > > 3)In doc available I'm recommended to import Foreign > > import Foreign > > ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c > foo.hs > > foo.hs:511: Data constructor not in scope: `A#' > > gmake: *** [foo.o] Error 1 The Addr type is now deprecated, and has been replaced by the Ptr type. The 'A#' constructor belonged to the Addr type - the code shouldn't have been using the internal representation. I suggest you change it to use published interfaces instead because it will end up being more portable to future versions of GHC. Also, the -syslib option will be removed at some point; nowadays -package is the right option to use. Cheers, Simon

1 0

import PrelAddr
by Rafael Martinez Torres 06 May '03

06 May '03

I'm rewriting some old code,originally written for ghc-4.08.2 . 1)Now, when I compile with ghc-5.02 , fails: ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c foo.hs foo.hs:47: failed to load interface for `PrelAddr': Could not find interface file for `PrelAddr' gmake: *** [foo.o] Error 1 2)if commented, --import PerlAddr ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c foo.hs foo.hs:112: Type constructor or class not in scope: `Addr' foo.hs:514: Data constructor not in scope: `A#' gmake: *** [foo.o] Error 1 3)In doc available I'm recommended to import Foreign import Foreign ghc -cpp -fglasgow-exts -O -fvia-C -syslib lang -syslib concurrent -c foo.hs foo.hs:511: Data constructor not in scope: `A#' gmake: *** [foo.o] Error 1 What should I import to use unboxed types and constructors ? You see the "-fglasgow-exts" .

1 0

RE: Haddock code block problems
by Simon Marlow 06 May '03

06 May '03

> I'm using the latest Haddock release (0.4) and seem to > be having a lot of trouble getting line breaks to appear > in code blocks. I've tried it so many ways that if I > were to enumerate them all this would be a very long email. > I can't find any consistency in when it decides to work > (occasionally) and when it doesn't (usually). Here's > some examples.. > > This gives no line breaks: > {-$CStuff > @ > test f [] = 0 > test f (x:xs) = 0 > @ > -} > > Neither does this: > {-$CStuff > >test f [] = 0 > >test f (x:xs) = 0 > -} This is a result of the fact that Haddock removes the <p>..</p> around single paragraphs to eliminate extra whitespace around short documentation comments. In the same vein it turns a single code paragraph, normally <pre>..</pre>, into <tt>..</tt>, which has the side effect of removing line breaks. On reflection that seems to be the wrong thing to do, so I'll change the behaviour for the next release. > This gives a parse error:-( > {-$CStuff > @ > test f [] = 0 > test f (x:xs) = 0 > @ > >test f [] = 0 > >test f (x:xs) = 0 > -} because there's no paragraph break between these paragraphs. A paragraph break is two consecutive newlines. > This doesn't, but still no line breaks. > {-$CStuff > >test f [] = 0 > >test f (x:xs) = 0 > @ > test f [] = 0 > test f (x:xs) = 0 > @ > -} That's a bug (one that I'm aware of). I'm planning to rewrite Haddock's lexer using Alex and get rid of this strange behaviour at the same time. > This gives me line breaks at the end of each birdtracked > line (only). > {-$CStuff > >test f [] = 0 > >test f (x:xs) = 0 > > @ > test f [] = 0 > test f (x:xs) = 0 > @ > -} Urk, that's just a bug. Thanks! Cheers, Simon

1 0

I/O Question
by Seth Kurtzberg 06 May '03

06 May '03

I need to find a way to determine whether data is available, for reading, on a socket connection, without blocking a thread. The equivalent of select() or poll() would do the trick. I don't need to get the information for all open files, as you can in select and poll, so a way to find out if there is data available on a single socket (or handle) is sufficient. TIA, -- Seth Kurtzberg MIS Corp 480-661-1849 seth(a)cql.com

2 1

Haddock code block problems
by Adrian Hey 04 May '03

04 May '03

Hello I'm using the latest Haddock release (0.4) and seem to be having a lot of trouble getting line breaks to appear in code blocks. I've tried it so many ways that if I were to enumerate them all this would be a very long email. I can't find any consistency in when it decides to work (occasionally) and when it doesn't (usually). Here's some examples.. This gives no line breaks: {-$CStuff @ test f [] = 0 test f (x:xs) = 0 @ -} Neither does this: {-$CStuff >test f [] = 0 >test f (x:xs) = 0 -} This gives a parse error:-( {-$CStuff @ test f [] = 0 test f (x:xs) = 0 @ >test f [] = 0 >test f (x:xs) = 0 -} This doesn't, but still no line breaks. {-$CStuff >test f [] = 0 >test f (x:xs) = 0 @ test f [] = 0 test f (x:xs) = 0 @ -} This gives me line breaks at the end of each birdtracked line (only). {-$CStuff >test f [] = 0 >test f (x:xs) = 0 @ test f [] = 0 test f (x:xs) = 0 @ -} But this gives me line breaks for both (as I would expect from the Haddock docs): {-$CStuff @ test f [] = 0 test f (x:xs) = 0 @ >test f [] = 0 >test f (x:xs) = 0 -} Strangely this works too (no parse error this time): {-$CStuff >test f [] = 0 >test f (x:xs) = 0 @ test f [] = 0 test f (x:xs) = 0 @ -} So is this possibly a bug in Haddock? Perhaps there's some syntactic requirement I'm failing to observe? Thanks -- Adrian Hey

1 0