RE: Download stats
On 09 February 2005 20:03, Tomasz Zielonka wrote: > On Wed, Feb 09, 2005 at 01:11:34PM -, Simon Marlow wrote: >> Hi folks, >> >> For the forthcoming 6.4 release, we'd like to get a rough idea of >> download statistics, at least from haskell.org. Both Simon & I are >> too busy/lazy (delete as applicable) to do this ourselves, and we >> don't know the best tools to use (grep|wc on the access_log is a bit >> too crude - we want to exclude things like partial downloads except >> when the download was completed later, etc.). Of course, if we can >> get or estimate download statistics for other sources of GHC too, >> that would be great. >> >> Any volunteers? > > Why not ask GHC users to fill some web form with additional > information, like how they use GHC, where they use it, for what, etc? > > I can make a suitable web form in WASH, if you want. That would be nice. There's no way I'm putting a web form in the way of the download link, but having it a separate "survey" on the site would perhaps be useful. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc sensitive to struct layout
Good morning, gcc uses a different convention from the Microsoft environment when it comes to laying out fields in C structs, in particular bit fields. Can I pass the -optc--mms-bitfields to ghc when it compiles via C without negative effect? This flag is not implicit at the moment which I assume means that ghc itself is not compiled with --mms-bitfields on Windows. ghc surely includes struct declarations when it compiles the generated C files, so the question is whether all its structs are laid out the same regardless of which layout option one chooses. Thank, Axel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC 6.4 release candidates available
We are finally at the release candidate stage for GHC 6.4. Snapshots with versions 6.4.20050209 and later should be considered release candidates for 6.4. Source and Linux binary distributions are avaiable here: http://www.haskell.org/ghc/dist/stable/dist/ Please test if you're able to, and give us feedback. Thanks! Simons & the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc sensitive to struct layout
On 09 February 2005 08:53, Axel Simon wrote: > gcc uses a different convention from the Microsoft environment when it > comes to laying out fields in C structs, in particular bit fields. > Can I pass the -optc--mms-bitfields to ghc when it compiles via C > without negative effect? > > This flag is not implicit at the moment which I assume means that ghc > itself is not compiled with --mms-bitfields on Windows. ghc surely > includes struct declarations when it compiles the generated C files, > so the question is whether all its structs are laid out the same > regardless of which layout option one chooses. The answer is I don't know, but we could probably make it true if necessary. In GHC 6.4, the generated HC code doesn't use any structs, all the field offests are precomputed, which will no doubt make your life easier. One thing you could do (in 6.4) is to compile ghc/include/mkDerivedConstants.c with and without -mms-bitfields and see if it generates the same output. If it does, then we have some confidence that -mms-bitfields won't cause any grief. If it doesn't, then we have some clue about what needs fixing. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
"Simon Marlow" <[EMAIL PROTECTED]> writes: > We are finally at the release candidate stage for GHC 6.4. Snapshots > with versions 6.4.20050209 and later should be considered release > candidates for 6.4. Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 $ cat hello.hs main = putStrLn "hello world" $ ghc--6.4.20050209 -o hello hello.hs ld: cannot find -lHSbase_cbits collect2: ld returned 1 exit status $ Pretty much a show-stopper. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 10 February 2005 13:31, Malcolm Wallace wrote: > "Simon Marlow" <[EMAIL PROTECTED]> writes: > >> We are finally at the release candidate stage for GHC 6.4. Snapshots >> with versions 6.4.20050209 and later should be considered release >> candidates for 6.4. > > Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 > > $ cat hello.hs > main = putStrLn "hello world" > $ ghc--6.4.20050209 -o hello hello.hs > ld: cannot find -lHSbase_cbits > collect2: ld returned 1 exit status > $ > > Pretty much a show-stopper. Yes, I'm fixing this right now. Please hold off downloading until I can get a fixed distribution up... Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 10 February 2005 13:40, Simon Marlow wrote: > On 10 February 2005 13:31, Malcolm Wallace wrote: > >> "Simon Marlow" <[EMAIL PROTECTED]> writes: >> >>> We are finally at the release candidate stage for GHC 6.4. >>> Snapshots with versions 6.4.20050209 and later should be considered >>> release candidates for 6.4. >> >> Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2 >> >> $ cat hello.hs >> main = putStrLn "hello world" >> $ ghc--6.4.20050209 -o hello hello.hs >> ld: cannot find -lHSbase_cbits >> collect2: ld returned 1 exit status >> $ >> >> Pretty much a show-stopper. > > Yes, I'm fixing this right now. Please hold off downloading until I > can get a fixed distribution up... New distributions are up now. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Unregistering a package
On 09 February 2005 13:32, Peter Simons wrote: > I have an interesting problem. There are two versions of the > HsDNS package installed right now: > > $ ghc-pkg list > | /usr/local/ghc-current/lib/ghc-6.5/package.conf: > | rts-1.0, [...] (hsdns-2005-02-04), > | hsdns-2005-02-08 > > Now how can I unregister them? I have tried everything I > could think of, but no luck: > > $ ghc-pkg unregister hsdns > | ghc-pkg: package hsdns matches multiple packages: > | hsdns-2005-02-04, hsdns-2005-02-08 > > $ ghc-pkg unregister hsdns-2005-02-08 > | ghc-pkg: cannot parse 'hsdns-2005-02-08' as a package identifier > > Can someone give me a pointer how to remedy this situation? The problem is not really that "hsdns-2005-02-08" isn't a legal package identifier, actually it is an ambiguous package identifier. I suggest you remove that package by hand from the package.conf file, and instead use "hsdns-2005.02.08". The general syntax of package ids is: pkgid ::= pkg ('-' version)? pkg ::= (alphanum|'-')+ version ::= (digit+) ('.' digit+)* ('-' alphanum+)* This syntax means that package ids which have numeric component(s) at the end and no '.' will be ambiguous. I've added a test to ghc-pkg to prevent you from registering a package with a problematic package id for now. Perhaps we should change the syntax of package ids though? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
"Simon Marlow" <[EMAIL PROTECTED]> writes: > We are finally at the release candidate stage for GHC 6.4. > Please test if you're able to, and give us feedback. In versions 5.00 <= ghc <= 6.2.2, the result of ghc -v 2>&1 | head -2 was something like Glasgow Haskell Compiler, Version 6.2.2, Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf whereas with 6.4, these two lines have been swapped: Reading package config file: /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow Haskell Compiler, Version 6.4.20050209, and the "Using package config" message has become "Reading package config". These changes are minor and unnecessary: in particular they make the detection of configuration information (by hmake) rather more complicated than it ought to be. I know this is a pretty trivial complaint, but the -v behaviour has been stable for a few years now, so why change it arbitrarily? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 10 February 2005 15:13, Malcolm Wallace wrote: > "Simon Marlow" <[EMAIL PROTECTED]> writes: > >> We are finally at the release candidate stage for GHC 6.4. >> Please test if you're able to, and give us feedback. > > In versions 5.00 <= ghc <= 6.2.2, the result of > > ghc -v 2>&1 | head -2 > > was something like > > Glasgow Haskell Compiler, Version 6.2.2, > Using package config file: /grp/haskell/lib/ghc-6.2.2/package.conf > > whereas with 6.4, these two lines have been swapped: > > Reading package config file: > /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf Glasgow > Haskell Compiler, Version 6.4.20050209, > > and the "Using package config" message has become "Reading package > config". These changes are minor and unnecessary: in particular they > make the detection of configuration information (by hmake) rather > more complicated than it ought to be. I know this is a pretty trivial > complaint, but the -v behaviour has been stable for a few years now, > so why change it arbitrarily? Ok, fixed. The right way to get the location of the package.conf file is to ask ghc-pkg, BTW. In fact, the right way is not to know the location of package.conf at all, but to use ghc-pkg to query its contents. The contents of package.conf is proprietary :-) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
"Simon Marlow" <[EMAIL PROTECTED]> writes: > Ok, fixed. The right way to get the location of the package.conf file > is to ask ghc-pkg, BTW. In fact, the right way is not to know the > location of package.conf at all, but to use ghc-pkg to query its > contents. The contents of package.conf is proprietary :-) And indeed hmake does use ghc-pkg, when it needs to find import directories etc. But the thing is, previous versions of ghc-pkg reported such directories as e.g. "$libdir/base", and how do you find out what $libdir refers to...? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 6.4 release candidates available
On 10 February 2005 15:36, Malcolm Wallace wrote: > "Simon Marlow" <[EMAIL PROTECTED]> writes: > >> Ok, fixed. The right way to get the location of the package.conf >> file is to ask ghc-pkg, BTW. In fact, the right way is not to know >> the location of package.conf at all, but to use ghc-pkg to query its >> contents. The contents of package.conf is proprietary :-) > > And indeed hmake does use ghc-pkg, when it needs to find import > directories etc. But the thing is, previous versions of ghc-pkg > reported such directories as e.g. "$libdir/base", and how do you find > out what $libdir refers to...? ghc --print-libdir Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
"Simon Marlow" <[EMAIL PROTECTED]> writes: > > and how do you find out what $libdir refers to...? > > ghc --print-libdir Cool. Will fix hmake to use it. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote: > Package: ghc6 > Version: 6.2.2-2 > > /usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU > linker script, not a shared object. This breaks ghci. Known problem: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html What is your particular problem? CCing glasgow-haskell-users@haskell.org as someone there may have an answer, or be interested to know the problem exists if not. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
$ ghc-pkg-6.4.20050209 --show-package=base --field=import_dirs ["/usr/malcolm/local/lib/ghc-6.4.20050209/imports"] yet $ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs ghc-pkg: cannot find package base-1.0 $ ghc-pkg-6.4.20050209 --list-packages /usr/malcolm/local/lib/ghc-6.4.20050209/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, ... Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
On Thu, 2005-02-10 at 13:11 +, Simon Marlow wrote: > Please test if you're able to, and give us feedback. I've noticed that running main of the attached code, using Proxy data-types to simulate context parameters (see previous email) still sends something into an infinite loop; is this my fault or GHCs? -Si. -- Simon David Foster <[EMAIL PROTECTED]> {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances #-} module Test where import Data.Typeable -- Skeleton of the Data class class (Typeable a, Sat (ctx a)) => Data ctx a -- Our main class with 2 parameters class (Data (DictClassA a) b, ClassB b) => ClassA a b where func :: b -> a -> String -- The class which contrains ClassA class ClassB a where func2 :: a -> String data DictClassA a b = DictClassA { funcD :: b -> a -> String, classBD :: DictClassB b, func2D' :: b -> a -> String } data DictClassB a = DictClassB { func2D :: a -> String } class Sat a where dict :: a instance Sat (ctx String) => Data ctx String instance Sat (ctx Int) => Data ctx Int --instance ClassA a b => (Data (DictClassA a) b) -- Trying to access any of functions in ClassA works fine, but trying to get at anything in ClassB causes and infinite loop. instance (Data (DictClassA a) b, ClassA a b) => Sat (DictClassA a b) where dict = DictClassA { funcD = func, classBD = dict, func2D' = func2' } func2' :: ClassA a b => b -> a -> String func2' x ctx = func2 x instance ClassB a => Sat (DictClassB a) where dict = DictClassB { func2D = func2 } instance ClassA a String where func _ _ = "hello" instance ClassA Int Int where func _ _ = "hello" instance ClassB String where func2 _ = "bye" instance ClassB Int where func2 _ = "bye" main = do print $ func "hello" (5::Int) print $ func2D' ((dict::DictClassA Int String)) "hello" 5 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Thu, 2005-02-10 at 16:58 +, Ian Lynagh wrote: > On Wed, Feb 09, 2005 at 11:13:36PM +0100, Juliusz Chroboczek wrote: > > Package: ghc6 > > Version: 6.2.2-2 > > > > /usr/lib/libpthread.so (comes from libc6-dev 2.3.2.ds1-20) is a GNU > > linker script, not a shared object. This breaks ghci. > > Known problem: > > http://www.haskell.org/pipermail/glasgow-haskell-users/2004-May/006671.html > > What is your particular problem? > > CCing glasgow-haskell-users@haskell.org as someone there may have an > answer, or be interested to know the problem exists if not. There are two workarounds that I know of: * simply omit -lpthread. This often works since pthread is a dependency of other libs so it will just work automatically. * use -pthread instead of -lpthread. This is valid option to gcc and tells it to link in the pthreads library. However ghci does not recognise the option so ghci will not load pthread itself (but hopefully it will be pulled in as a dependency by the dynamic linker) but when doing ordinary linking with ghc the program will be linked to the pthreads shared library. The -pthread option has to go in "extra_ld_opts" in the package file. You cannot just stick -lpthread in the extra_ld_opts since ghci will notice any options which look like -l* and load the libs anyway. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unregistering a package
Simon Marlow writes: > The general syntax of package ids is: >pkgid ::= pkg ('-' version)? >pkg ::= (alphanum|'-')+ >version ::= (digit+) ('.' digit+)* ('-' alphanum+)* Thanks. I gave my package the version "hsdns-0.0-2005-02-10" and that fixed the problem. > Perhaps we should change the syntax of package ids > though? In my humble opinion, GHC shouldn't try to guess what version identifiers mean; I would treat them as a literal strings without any parsing. But that's probably just me. Anyway, thanks for the clarification. Peter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bug#294481: ghci -lpthread fails
On Thu, Feb 10, 2005 at 07:00:47PM +0100, Juliusz Chroboczek wrote: > Hi Ian, > > > What is your particular problem? > > Running Darcs under ghci. This seems to work for me (at least in as much as ghci loads and FastPackedString.lengthPS (FastPackedString.packString "Foo") says 3): rm -rf .libs rm *ghcidarcsfoo* touch ghcidarcsfoo.c libtool --mode=compile gcc -g -O -c ghcidarcsfoo.c libtool --mode=link gcc -g -O -o libghcidarcsfoo.la ghcidarcsfoo.lo -lpthread -rpath /usr/lib libtool --mode=install cp libghcidarcsfoo.la `pwd`/libghcidarcsfoo.la libtool --finish /usr/lib ghci -cpp -package unix -package parsec -O -funbox-strict-fields -Werror -package util -I. -DHAVE_CURSES -optl-lcurses -optl-lz -L`pwd` -optl-lghcidarcsfoo darcs.lhs compat.o fpstring.o zlib_helper.o c_context.o Is there a problem with this? Could something along these lines be done when -lfoo (as opposed to -optl-lfoo, which for consistency should probably be left alone) is given on the ghci command-line? I'm no library expert, so there may be a cleaner/simpler/more portable equivalent to the above. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
When -fglasgow-exts is on, (#) no longer seems to be recognized. (I get a parse error.) however # works fine as an infix operator. John -- John Meacham - ârepetae.netâjohnâ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
There seems to have been a change in how packages are found which is biting me. I have a module called PackedString, which used to be fine, as ghc's packedstring was called Data.PackedString. however with ghc 6.4 I am getting the error: Atom.hs:3:0: Failed to load interface for `PackedString': Could not find module `PackedString': it is a member of package lang-1.0, which is hidden If not using -package foo doesn't allow you to reuse the names in foo then I must wonder what the point is of hiding the package in the first place :) John -- John Meacham - ârepetae.netâjohnâ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users