- Glasgow-haskell-users

ghc 6.4 without libreadline4
by Geoffrey Alan Washburn 16 Jun '05

16 Jun '05

Does anyone have a prebuilt version of ghc 6.4 that works with libreadline5? The generic Linux version on http://www.haskell.org/ghc/download_ghc_64.html requires libreadline4, but the system I am using does not have it installed. Nor am I the administrator, so I can't go installing libraries willy-nilly sadly. Or is really the best solution here to get my administrator to do so? Will building my own version and setting my LD_LIBRARY_PATH work reasonably well too? Thanks.

2 5

RE: testing current 6-4-branch
by Simon Marlow 16 Jun '05

16 Jun '05

On 15 June 2005 11:23, Serge D. Mechveliani wrote: > 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. The GHC 6.4 branch does not have hs-source-dirs. You need to checkout the HEAD to get it (but bear in mind that the HEAD is likely to be more unstable than the 6.4 branch). Cheers, Simon

2 1

Generating unique random numbers
by Robert van Herk 15 Jun '05

15 Jun '05

Hello all, Is it possible to generate random numbers that are "unique" in O(1) in Haskell? I mean something like the GUID-thingy Windows uses. Of course, I could create unique numbers by incrementing a global value, but for security reasons I need random numbers. Also, I could use a list of numbers already in use, but this would mean that I'd not be able to generate a new number in O(1). Any ideas? Regards, Robert

4 4

RE: irrelevant package
by Simon Marlow 15 Jun '05

15 Jun '05

On 14 June 2005 10:55, Serge D. Mechveliani wrote: >> 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. No, Cabal does not do this. > 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? I'm not sure what you mean - we don't find the minimal set of depended-upon packages at all. You are required to explicitly list dependencies in the build-depends field. > 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. It's more than just a warning: it's an error. GHC will issue an error message in this case. > 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. I don't know what P2.DPrelude means. Is it a module name, or are you proposing to prefix module names with package names? You should read recent discussions on the libraries(a)haskell.org mailing list, where this issue has been dissected at some length. Cheers, Simon

1 0

RE: When to run the garbage collector
by Simon Marlow 15 Jun '05

15 Jun '05

On 14 June 2005 10:35, Robert van Herk wrote: > 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? Sounds reasonable, otherwise it might be a while before a major GC runs. In CVS we have a new idle GC feature: the GC is run automatically after a specified amount of idle time. This might be useful in your case, too. (it is only activated in -threaded mode right now). Cheers, Simon

1 0

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