Re: more fixups for GHC docs
Hi Bulat, Thanks for the suggestions! On Tue, Sep 19, 2006 at 05:52:53PM +0400, Bulat Ziganshin wrote: > > in GHC library paragraph - add a link to the API documentation. btw, > my download > (http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unknown-mingw32.tar.gz) > don't includes any library docs nor $(GHC)/doc/html/libraries/index.html > can you please fix this? I'll probably look into this as part of the move to buildbot. In the meantime, the most recent docs should be available at http://www.haskell.org/ghc/dist/current/docs/ > also, it will be great to use each library section heading as URL to > the docs of corresponding library: > > 1.4.4.1 [[url://libraries/base/index.html base]] We don't have this, do we? All the library docs are combined in libraries/index.html. > "GHC.Exts now provides a function lazy which forces GHC to think that > its argument is lazy in its first argument. " - a copy-paste typo? Do you mean the double "argument"? If so, then no: In lazy f f is "its argument", and f is lazy in f's "first argument". This is a pain to explain clearly and concisely. Is this better?: GHC.Exts now provides a magic function /lazy/ such that GHC is forced to think that /lazy f/ is lazy in its first argument. Or am I misunderstanding your point completely? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Year 2038 problem in GHC 6.4.2 runtime
Bulat, I am afraid I would need the new Time library a little earlier than 2038, because I am working on financial software where it is not uncommon to have contracts over 30 years long. Is the new Time library available for download? Regards, Cyril ___ Bulat Ziganshin wrote: there is new Time library, which is supposed to replace old System.Time. we hope that it will happen before 2038 :D ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: more extra-libs for ghc 6.6
On Tue, Sep 19, 2006 at 08:45:30PM +0400, Bulat Ziganshin wrote: > Hello glasgow-haskell-users, > > how about adding to the list of extra libs the following very useful ones: I think we're too late in the release process to be adding libraries. Also, I think we would like to move towards distributing fewer libraries, not more. For 6.8 I hope we can do something like drop the extra-libs tarball, but have the build process do a topological sort of everything in libraries/ and build the lot. That way if you want to bundle a given set of libs in the Windows installer, or whatever, then you just instruct cabal-get to give you the source tarballs for those libs, and anything they depend on (would need to tell it you have the core libraries already somehow), put them in libraries/ and build in the normal way. This would neatly sidestep any arguments about what packages are important/common/small/... enough that they should go in extralibs. > regex-* I'm not sure if you are refering to other packages, but regex-base, regex-compat and regex-posix are already core libraries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: TArray
It wasn't in the list of exposed modules for the STM package. Thanks for spotting this. [Ian: pls push patch to the 6.6 branch] Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Josef Svenningsson | Sent: 20 September 2006 11:19 | To: Bulat Ziganshin | Cc: glasgow-haskell-users@haskell.org | Subject: Re: TArray | | Hi, | | I get the exact same thing with ghc-6.5.20060914. | | Weird. | | Josef | | On 9/20/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: | > Hello glasgow-haskell-users, | > | > can someone try to compile this one-line module: | > | > import Control.Concurrent.STM.TArray | > | > with a recent 6.5 builds, preferably mingw32 ones? | > | > it doesn't work for me, although TVar and other modules import | > without any problems; and i see TArray.hi module along with TVar.hi | > and so on. the message is: | > | > Failed to load interface for `Control.Concurrent.STM.TArray': | > locations searched: | > Control/Concurrent/STM/TArray.hi | > Control/Concurrent/STM/TArray.hi-boot | > | > compiler is, again, | > http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20060901-i386-unkno wn-mingw32.tar.gz | > | > | > -- | > Best regards, | > Bulat mailto:[EMAIL PROTECTED] | > | > ___ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: internal error: asyncRead#, ghci and fps (windows) (trac 806)
On Tue, Sep 19, 2006 at 09:20:45PM +0200, Rene de Visser wrote: > Is there anyway to turn off that ghci runs in threaded mode on windows? Only by recompiling, I'm afraid (for 6.4.2 comment out the line "SRC_HC_OPTS += -threaded" in ghc/compiler/Makefile; for 6.5 you need to also do so in ghc/compiler/Makefile.ghcbin). > fps 0.8 (and software that uses fps) triggers trac error #806. > This means that I cannot run such things interactively :-( I'll add a note about this to the bug. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Year 2038 problem in GHC 6.4.2 runtime
On Fri, Sep 22, 2006 at 04:16:44PM +0200, Cyril Schmidt wrote: > As far as I can see, the current (6.4.2) GHC runtime > suffers the year 2038 problem; that is, the System.Time > module does not support dates from 2038 onwards > (the code below reproduces the problem). We inherit the problem from C's mktime, which returns a time_t, so this is not trivial to fix. As Bulat says, I don't think the new time package will suffer from this problem. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: threadDelay not ending
Hi Rich, On Mon, Sep 18, 2006 at 09:23:52AM -0500, Rich Fought wrote: > I've got some unit test code that forks off test processes using the > 'system' function and then delays using 'threadDelay' to synchronize > with the test process. > > This has worked fine until I upgraded to 6.4.2, now some of the > 'threadDelay' calls never return - it's like they are stuck in limbo. Are you compiling with -threaded? Are you able to send us a small example demonstrating the problem? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Help with unregisterised build
On Wed, Sep 13, 2006 at 09:43:03PM +1000, Jeremy Wazny wrote: > > I've attempted to build an installation of GHC which uses > unregisterised libraries, but have not had much success. I am new to > GHC's build system and would be grateful for some advice. > > I'm trying to build the 6.4.2 source distribution on an x86 linux > machine, using GHC 6.4.2 (the "Generic Linux with glibc2.3" version on > the download page.) The target is the same machine. > > I've created a mk/build.mk file containing just the line: > > GhcUnregisterised = YES > > which, according to the comment in mk/config.mk, ought to build the > unregisterised libraries that I'm after (and use them by default.) For my unregisterised builds I use: GhcUnregisterised=YES GhcWithNativeCodeGen=NO GhcWithInterpreter=NO SplitObjs=NO The "SplitObjs=NO" will solve the problem you are seeing. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance overlap in 6.6 candidate
Simon Peyton-Jones schrieb: > | instance Show [Equation] > | where > | showsPrec _ eqs = | in a `nicer' way than by the default list [...] > Perhaps. That's what I'd like feedback about. What do others think? Overlapping Show instances are desirable for debugging purposes or quick and dirty code (not for "nicer" ways). Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Deferred instance declarations (serialization ofexistential boxes)
[redirecting to GHC users, since it's a GHC-specific question] Misha | I asked this question on haskell-cafe once, but my post didn't get any | responses, so I try once again here explaining a bit more where my | problem comes from. I was at ICFP. | Suppose I have a monomorphic datatype, say T and want to do something | with it, which depends on an instance of class C being defined for T. | However I can only provide this instance later, in a different module. | So I would like to write something like | | > f :: C T => T -> T | or | > instance C T => C T' where | > -- a body that uses functions from C T There is no reason in principle why this isn't ok. But there is a practical reason why things are the way they are. Generally, GHC tries to share constraints as much as possible, so that a (C T) constraint in one function right hand side is satisfied by the same binding as another (C T) constraint from another right hand side. So in general, GHC "floats" constraints outwards if they don't mention any type variables bound by the forall's of the type signature. The whole question of the interaction of type signatures and constraints is quite delicate, and I rather doubt I'll change this behaviour soon. (And no one else has asked for it before, I think.) But I think the case is stronger for top-level constraints, and I will bear it in mind. If you would like to open a Trac feature request, please do so. Concerning your application | I am having a box like | > data Box = forall a. Cxt a => Box a | and want to write a Read instances for it. I don’t see how it helps to defer the Read instance. Reading existentials is bound to be difficult, or even impossible. I guess it depends what is in Cxt. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: compiler change
| Last question, is using "fst/snd" really a problem as I suspected by | using the constant twice? (I actually didn't explicitly inline the | constant by two calls of unsafePerfromIO.) Using a constant twice should not duplicate the work of computing it, if that's what you mean S ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
