June 2005 - Glasgow-haskell-users

testing current 6-4-branch
by Serge D. Mechveliani 15 Jun '05

15 Jun '05

Dear GHC supporters, I am trying to do the following. (1) to install the current GHC of 6.4 branch from CVS with ghc-6.4 for recent Debian Linux. (2) To test how ghc-current understands the field `hs-source-dirs' in a package for multiple subdirectories (is `hs-source-dirs' in the current GHC ?), and to test module name clash resolution between the packages. Could you, please, tell what is wrong here? -- (1) ----------------------------------------------------- ghc-6.4 pre-installed s in /usr/bin, /usr/lib alex, happy installed. Downloading ghc-6-4-branch of June 14, 2005. ------------------------------------------- set $CVSROOT to :pserver:anoncvs@glass.cse.ogi.edu:/cvs cd $HOME/ghc/cvs cvs login cvs co -r ghc-6-4-branch fpconfig cd fptools cvs -z3 co -r ghc-6-4-branch ghc hslibs libraries autoreconf ./configure --prefix=$HOME/ghc/cvs/instJune14 make make install ------------------------------------------------------- Among the `make' reports there occur many "Bad eta expand" messages, like this: ------------- /usr/bin/ghc -H16m -O -istage1/utils ... -Rghc-timing -H16M '-#include "hschooks.h"' -i../lib/compat -c cmm/CmmParse.hs -o stage1/cmm/CmmPars\e.o -ohi stage1/cmm/CmmParse.hi Bad eta expand 1 (__coerce <nt>CmmParse.HappyAbsSyn{tc r3Du} (zgzg{v a8rY} ... ------------- Anyway, it looks to install, and the new ghc says "version 6.4.1". I moved the ghc* files of 6.4 from /usr/bin, /usr/lib/ to `invisible' place and set the path to ghc-current. which ghc and which ghc-pkg show /home/mechvel/ghc/cvs/instJune14/bin/ghc /home/mechvel/ghc/cvs/instJune14/bin/ghc-pkg respectively. -- (2) ---------------------------------------------------------- docon.cabal is set as ---------------------------- name: docon version: 2.9 ... ... tested-with: GHC -- should be like "ghc-6.4" "Hugs-5.5" ... . build-depends: data . hs-source-dirs: "." parse -- auxil lin residue pol pol/factor -- pol/symmfunc . exposed-modules: DExport DPrelude Categs SetGroup RingModule DPair Z Fraction VecMatr LinAlg Pol GBasis Residue Permut Partition AlgSymmF ... ------------------------ and apply runhaskell Setup configure --ghc --prefix=$doconSource/inst It reports ** Exception: Line 16: Unknown field 'hs-source-dirs' I also try `hs-source-dir:', but still cannot fetch to Cabal the subdirectory list "./parse" ... where DoCon keeps the source. Also you wrote that it is fixed the feature of the module name clash in two packages, when one of them is not needed according to the package-deps field. But again, it reports DPrelude.hs:1:0: Module `DPrelude' is a member of package dumatel-1.2.6.4. To compile this module, please use -ignore-package dumatel-1.2.6.4. Please, advise, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Suggestion for hsc2hs (structures with commas)
by Dimitry Golubovsky 14 Jun '05

14 Jun '05

I came across the following issue in hsc2hs: when requesting a size of a C structure with #size (or similarly this may apply to #peek, #poke, #offset macros), and the structure is declared "anonymously", and contains multiple field declaration of the same type such as: struct {int ab,cd;} then #size(struct {int ab,cd;}) will result in hsc_size(struct {int ab,cd;}) which will fail because of the comma inside the structure makes the macro recognize 2 arguments instead of 1. GCC's preprocessor allows variadic macros defined like #define __quote__(x...) x If hsc_size is called: hsc_size(__quote__(struct {int ab,cd;})) then error does not occur. Similarly: hsc_peek(__quote__(struct {int ab,cd;}),cd) because __quote__ is scanned first, and its result is treated as a single argument. I looked through cpp.info, but could not find any other way to quote macro arguments. Is it possible to update hsc2hs (Main.hs I believe) to emit macro calls involving C types in the way described above? i. e. #size(t) becomes hsc_size(__quote__(t)), #peek(t,f) becomes hsc_peek(__quote__(t),f) etc. when hsc2hs generates the C file from a hsc source. PS I am working with hsc2hs from the GHC 6.2.2 distribution. I couldn't find such fixes in the changelog since then. I believe, the person maintaining hsc2hs might be able to implement these fixes faster than if I tried. PPS This will work with GCC, but I am not sure abouth other compilers (like Microsoft C) -- Dimitry Golubovsky Anywhere on the Web

1 0

Re: irrelevant package
by Serge D. Mechveliani 14 Jun '05

14 Jun '05

On Mon, Jun 13, 2005 at 04:06:39PM +0100, Simon Marlow wrote: > On 13 June 2005 14:34, Serge D. Mechveliani wrote: > > > I am testing packages in ghc-6.4. > > I set > > docon.cabal, > > > > which declares dependence on `data': build-depends: data > > The attempt to build docon by > > > > cd $doconSource > > runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst > > runhaskell Setup.hs build > > > > produces > > > > configuring ... > > compiling ... > > ... > > DPrelude.hs:1:0: > > Module `DPrelude' is a member of package dumatel-1.2.6.4. > > To compile this module, please use -ignore-package > > dumatel-1.2.6.4. > > > > These does exist a package dumatel-1.2.6.4, and both the above > > packages have DPrelude among the module names. > > But why does Cabal look into irrelevant package? The dependence is > > set: only `data'. > > This is "fixed" in newer versions of Cabal. > > However, you are heading for problems here. When you install a package > P that includes a module M, you prevent the user from having any modules > called M unless they say '-hide-package P' (see previous discussions on > this subject). > > For this reason, we strongly recommend using hierarchical module names. > > At the moment, Cabal "exposes" all the packages it imports. Perhaps we > should have an option to install an unexposed package, to allow > installation of packages that contain non-hierarchical module names. > Isaac - what do you think? > When you install a package > P that includes a module M, you prevent the user from having any modules > called M unless they say '-hide-package P' ? First, it is very natural to have several common module names among the installed packages. Suppose the user package P depends on P2, P3. To build P, Cabal finds the minimal needed set S of packages for P. For my particular aforementioned example, this should be sufficient. Because the packages from S occur not to have common module names, and ghc-CVS-current will find this. Right? Now, suppose, for some another example, it occurs a clash: P2 and P3 occur in S and the name DPrelude (.hs) is both in P2 and P3 (and usually these modules have different interface and implementation). Probably, the Cabal system needs to warn about this. But, of course, it is not difficult for Cabal to distinguish these two modules. Because it is visible that one is P2.DPrelude and another is P3.DPrelude. So, before compilation, the modules are resolved. Now, at the compilation stage, it all depends on the import/export set in the modules. And the user may write, for example, like this import qualified P2.DPrelude (f) import qualified P3.DPrelude (f, g) import P4.DPrelude ... Is this "using hierarchical module names" ? On ambiguious interface, the compiler reports as usual. I have impression that the compiler already resolves the module interfaces as needed, and that package processig by Cabal should not add any problem here. If the compiler cannot resolve the import, it asks: " P2.DPrelude or P3.DPrelude ?". The rest is on the user. I thought, the user has also other ways out (as above), besides writing '-hide-package P...'. Is this so? Regards, ----------------- Serge Mechveliani mechvel@botik.

1 0

When to run the garbage collector
by Robert van Herk 14 Jun '05

14 Jun '05

Hello, I noticed that it is possible to run the garbage collector explicitely... Currently, I am writing a stateful webserver, that once in a while (e.g. every 30 minutes) can discard a lot of memory (because every 30 minutes sessions time out and their state can be thrown away). Would it be wise to call the garbage collector explicitely, directly after this cleanup is done? Regards, Robert

1 0

Re: source subdirectory in package
by Serge D. Mechveliani 14 Jun '05

14 Jun '05

On Mon, Jun 13, 2005 at 02:52:09PM +0100, Simon Marlow wrote: > On 13 June 2005 14:26, Serge D. Mechveliani wrote: > > >>> Preprocessing library u1-0.0... > >>> can't find source for V1 in ["."] > > > >> The Cabal in GHC 6.4 supports source files in a single directory only > >> (although you can use hierarchical module names). To put your source > >> files in a subdirectory, add the field > >> > >> hs-source-dir: subdir > >> > >> to your .cabal file. > >> > >> The current version of Cabal allows multiple source directories, so > >> you can say > >> > >> hs-source-dirs: "." subdir > > > > My DoCon application have multiple source directories. > > I understand you so that ghc-6.4 cannot support this, but the current > > ghc-CVS supports, and ghc-6.4.1 will support. > > Right? > > No, GHC 6.4.1 will not support it (we don't make interface changes > between patchlevels). All right. ghc-6.4 has been tested with Dumatel. And ghc-6.4 was announced as very new. So, I think, 6.4 branch needs testing with DoCon (which has much more functionality). Meanwhile, I shall try to port DoCon and Dumatel applications to ghc-CVS-current. Then, I shall wait for the first official version ("ghc-after-6.4-adequate") which would treats the above features as needed, and do the above two releases for this version. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: unsafeness of unsafeInterleaveIO
by Simon Marlow 13 Jun '05

13 Jun '05

On 11 June 2005 02:23, Remi Turk wrote: > On Sat, Jun 11, 2005 at 01:55:57AM +0200, Thomas Jäger wrote: >>> Just looking at the documentation for System.IO.unsafeInterleaveIO, >>> what exactly is unsafe about it? >> >> It can create "pure values" that trigger side effects during their >> evaluation. This can be abused to do IO outside of an IO monad >> (actually, hGetContents can already be used for that purpose). >> >> In the worst case, it can even crash the RTS: >>> import Control.Concurrent.STM >>> import System.IO.Unsafe >>> >>> main :: IO () >>> main = atomically =<< unsafeInterleaveIO (atomically $ return $ >>> return ()) >> >> Thomas > > Stares at a core-dump. > I wonder whether this would be worth a bug-report, or perhaps a > warning in STM's docs about (understandable) undefined behaviour > in this case. Interestingly, Tomasz Zielonka's FakeSTM [1] > survives it. Yes, the STM implementation can't cope with nested transactions - I noticed this once before when using unsafePerformIO. I'll see if it would be possible to raise an exception when a nested atomically is detected. Cheers, Simon

1 0

unsafeness of unsafeInterleaveIO
by Andre Pang 10 Jun '05

10 Jun '05

G'day all, Just looking at the documentation for System.IO.unsafeInterleaveIO, what exactly is unsafe about it? -- % Andre Pang : trust.in.love.to.save <http://www.algorithm.com.au/>

4 6

benchmarking 6.4 vs 5.02.3
by Serge D. Mechveliani 10 Jun '05

10 Jun '05

I wrote about ghc-5.02.1 taking 13 times less memory than ghc-6.4 to compute a certain example like merge-sort. Now, I compare ghc-5.02.3 and ghc-6.4 on the same machine. The needed time and memory occur the same all right. The resources grow almost as O(n*log(n)), as expected. My error was that it was -H used for 5.03 instead of -M. With -M, they need the same time and space. Sorry for confusion. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

5.02.3 built
by Serge D. Mechveliani 10 Jun '05

10 Jun '05

I managed to install ghc-5.02.3 i86x binary on recent Debian Linux. It required libreadline.so.3, and I linked it symbolically to existing libreadline.so.4.3, Similarly, libncurses.so.4 linked to higher. My docon-2.06 looks to build and run correct under all this. Now, we shall compare 6.4 to 5.02.3 ... ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: 5.02
by Simon Marlow 10 Jun '05

10 Jun '05

On 10 June 2005 11:36, Christian Maeder wrote: > Simon Marlow wrote: >> On 10 June 2005 08:58, Serge D. Mechveliani wrote: >> >>> Now, I indeed, intend to compare 6.4 to 5.02 on several examples, >>> downloaded ghc-5.02.3 and tried to make it with ghc-6.4 >> >> Yes, that's unlikely to work. > > I was able to install the binaries from ghc-5.04.2-1.i386.rpm (with > rpm2cpio though). I did not know that ghc-5.02.3 is exceptional. Is it > really? Not that I'm aware of, but in general compiling an old compiler with a new compiler isn't guaranteed to work. Old features or libraries that we used in 5.02 may have gone away, for example. > 6.4 produces better and faster code than 6.2.2 and 5.04.2 for our > application. Great! Cheers, Simon

1 0