HUnit
I've converted the literate Haskell documentation and filled in the gaps for HUnit. I've posted the darcs repository with the changes and the new documentation at http://richardg.name/ Please email me with any feedback and/or patches that you might have. In a bit, I'll submit the patches for inclusion into the GHC repository. Richard G. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HUnit
Hi Don I've made the appropriate requests, I think, and I'll upload once they are processed. Richard G. Don Stewart wrote: richardg: I've converted the literate Haskell documentation and filled in the gaps for HUnit. I've posted the darcs repository with the changes and the new documentation at http://richardg.name/ Please email me with any feedback and/or patches that you might have. In a bit, I'll submit the patches for inclusion into the GHC repository. Richard G. Would you like to move your HUnit work into code.haskell.org/hunit? We need someone to take over maintainance of this public library, and centralised hosting will ensure it isn't lost to the ages. To register an hunit project and user account, visit community.haskell.org Thanks for contributing! -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haddock, .lhs, and GHC
I never thought about that. I've been using Setup.hs with #!/usr/bin/env runhaskell and never had any problems. I guess the only thing that would be gained by using Setup.lhs is the ability to compile the setup program. Is that something that's commonly done? Richard G. Johannes Waldmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does this mean that literate source files should be discouraged? They seem to be fairly common, especially in conjunction with Cabal (i.e., Setup.lhs). I think the reason for having Setup.lhs instead of Setup.hs is that you can put #!/usr/local/bin/runhaskell in their first line. Then chmod +x Setup.lhs and you can do ./Setup.lhs configure etc. So, this has nothing to do with literate programming. Best regards, J.W. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVfxBDqiTJ5Q4dm8RAtZkAJ4r0qWQiUmQvsPhJMAFiccMvmJTQgCcCSH9 Y3Wph09j9/j2yJ2bsYYMXfQ= =NIax -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Haddock, .lhs, and GHC
Hello I did a little digging on this issue and didn't find a definitive answer. According to the Haddock page in the wiki, Haddock is the de facto way of documenting files [http://haskell.org/haskellwiki/Haddock]. Does this mean that literate source files should be discouraged? They seem to be fairly common, especially in conjunction with Cabal (i.e., Setup.lhs). They also appear in quite a few beginner tutorials, which can send new users down the wrong path (e.g., http://haskell.org/haskellwiki/How_to_write_a_Haskell_program). Is there an effort and/or intent to move the GHC sources away from .lhs entirely? --- The reason I ask is: I'm looking at the Test.HUnit modules and there are no Haddock annotations. I thought I'd help document the modules but, when I had a look at the source files, I found they were .lhs instead of .hs. There is already some documentation in the files but it's not visible to Haddock. What's the best way to proceed in a case like this? 1. Shoe-horn in the Haddock annotations by putting them in the code sections (e.g., -- | Document comment...) but this seems a little cumbersome, especially if these comments show up in the published form of the .lhs file. 2. Rename to the files to .hs and touch up the files so they compile, then add the Haddock annotations. 3. Another option? --- I get the feeling that HUnit isn't getting much attention. Is that because it's done or because it's obsolete and will soon be removed? Thanks, Richard G. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Mutually recursive modules
Hello
I've been doing some work with mutually recursive modules (MRMs). I'm
familiar with the section in the User's Guide on how to do this and have
successfully worked with MRMs with simple dependencies. However, I have
created a set of MRMs that I can't seem to get to compile because of
type issues.
I can get the code to compile by combining all of the modules into a
single, monolithic module; however, this breaks the conceptual design
that I'm going for. I may also be able to break the modules into
smaller pieces that will compile, though I'm not sure about this and it,
too, would break the conceptual design.
Does the current {-# SOURCE #-}/.hs-boot scheme allow for compilation of
arbitrary MRMs? Or are there known cases where it doesn't work? If
there are cases where it doesn't work, are there other options?
Someone in Haskell Cafe mentioned that GHC 6.2 used a different scheme
for MRMs (.hi-boot). Is it still possible to use this? Would it allow
for compilation of arbitrary MRMs?
I can create a minimal case as an example, if it would be useful.
Thanks,
Richard
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Mutually Recursive Modules
Hello
I'm using GHC 6.8.2 with mutally recursive modules. I'm familiar with
how to do simple cases in GHC ({-# SOURCE #-} and .hs-boot files) but I
can't figure out how to get it to work for a particular set of modules.
Is it known (i.e., proven) that GHC 6.8.2 can compile any set of
mutually recursive modules without refactoring? Are there known
limitations?
Thanks,
Richard G.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Fwd: Re: suggestion: add a .ehs file type]
A pre-processor is a great idea. Template Haskell and Cabal make it
possible to extend the language by adding all kinds of funky
pre-processing (via Cabal hooks) and compile-time calculations. It
wouldn't be too difficult to add a package-specific .ehs file type with
the desired behavior.
I'm currently using this combo to work around the TH limitation of not
being able to generate import statements. A Cabal hook looks in a
directory to find what .hs files are present, spits out an intermediate
file that imports all of these files, and Cabal compiles the generated
file into the final program.
I think that the biggest limitation of this setup is managing the files
if multiple stages of pre-processing are performed.
Richard
Original Message
Subject:Re: suggestion: add a .ehs file type
Date: Thu, 22 Nov 2007 10:19:57 +
From: Lennart Augustsson [EMAIL PROTECTED]
To: Simon Marlow [EMAIL PROTECTED]
CC: Alex Jacobson [EMAIL PROTECTED],
glasgow-haskell-users@haskell.org
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
Or use a preprocessor that inserts a LANGUAGE pragma. :)
On Nov 22, 2007 9:14 AM, Simon Marlow [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Alex Jacobson wrote:
In any case, I'm pretty sure the correct answer is not 50 language
pragmas with arbitrary spellings for various language features
at the
top of each source file.
You probably won't like any of these, but there are many ways to avoid
writing out all the pragmas at the top of each file.
1. Use Cabal's extensions field.
2. Use CPP
MyExtensions.h :
{-# LANGUAGE TemplateHaskell, FlexibleInstances,
OverlappingInstances, UndecidableInstances, CPP,
ScopedTypeVariables, PatternSignatures, GADTs,
PolymorphicComponents, FlexibleContexts,
MultiParamTypeClasses, DeriveDataTypeable,
PatternGuards #-}
MyModule.hs:
{-# LANGUAGE CPP #-}
#include MyExtensions.h
3. Use a shell alias
alias ghce='ghc -XTemplateHaskell -XFlexibleInstances ...'
4. use a script wrapper for GHC
#!/bin/sh
exec ghc -XTemplateHaskell -XFlexibleInstances ... $*
I'm sure there are more...
Cheers,
Simon
___
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
GHC and dynamic linking
I foggily remember previous versions of GHC being unable to create programs that use dynamic links to libraries. Is this the case and, if so, is it still an issue? Static linking is not an option due to licensing issues. I'm interested in GHC 6.6.1 and 6.8.1 on Windows, Mac (PowerPC and x86), and Linux (x86). Thanks in advance, Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Template Haskell documentation
Hello I'm trying to learn how to use Template Haskell and I'm finding that the documentation is sparse. In particular, the constructors for Dec, Exp, Con, etc. in Language.Haskell.TH.Syntax aren't explained. Would documentation patches be welcomed for this library? Thanks, Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting source code
I figured out a way to work around it. Instead of pulling all patches at once, I pulled 100 at a time. Instead of using darcs pull -a in step 3, I used darcs pull. I held down y until about 100 or so patches were accepted and then hit d to stop applying patches. After doing this 6 times, all patches were installed. It would be nice to have the issue corrected, if possible, or have it documented on the developer page. It would also be nice to have the case issue with Mac OS X document, as recent file systems have been case-insensitive for a while. Should I add this info to the page? I'm not sure what the policy is around wiki edits. Richard [EMAIL PROTECTED] wrote: Hello I'm trying to get the source code for development purposes (helping add some Haddock documentation for TH). I tried following the steps listed on http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources and ran into trouble. I downloaded ghc-HEAD-2007-08-29-ghc-corelibs-testsuite.tar.bz2 and continued through the steps. On step 3, I received an error message from darcs: $ darcs pull -a Pulling from http://darcs.haskell.org/ghc;... This is the GHC darcs repository (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ** darcs: getCurrentDirectory: resource exhausted (Too many open files) I tried using darcs get but I think I ran into the same case issue as on Windows: $ darcs get http://darcs.haskell.org/ghc This is the GHC darcs repository (HEAD branch) For more information, visit the GHC developer wiki at http://hackage.haskell.org/trac/ghc ** Copying patch 17349 of 17349... done. Applying patch 12 of 17349... Unapplicable patch: Thu Jan 11 07:26:13 MST 1996 partain * [project @ 1996-01-11 14:06:51 by partain] darcs failed: Error applying hunk to file ./ghc/includes/rtsTypes.lh I'm using GHC 6.6.1 (binary distribution) and darcs 1.0.9 (can't remember if it's binary distribution or if I compiled it myself) on Mac OS X 10.4.10 for Intel. Any help would be appreciated. Thanks, Richard ___ 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: Become a GHC build slave!
I believe that there is value in having multiple BuildBots for the same platform. More value is provided when differences are maximized between BuildBots but there is value in having similar BuildBots (particularly, if the similar BuildBots are popular). Even in the relatively monoculture world of Apple, there is a lot of variation: - The G4 and Core chips are 32-bit and the G5, Core 2, and Core 2 Xeon chips are 64-bit. - The G4 chips have some endianess instructions that are not present in the G5s. - The G5 and Core chips may have 1 or 2 cores in them. - The G5 and Core 2 Xeon chips may come in 1 or 2 CPU variations. - The Core 2 Xeon chips will soon come in 2 or 4 core versions. - The PPC chips support 2 major versions of Mac OS X (10.3 and 10.4). - Third party libraries and applications can come from from: - Apple. - darwinports. - fink. - manually installation. - The libraries may have multiple versions. Creating a bunch of similar BuildBots will help improve coverage of these differences. Wilson MacGyver wrote: You can see that here. http://darcs.haskell.org:8010/ and it looks like Thomas Davie already has both OSX PPC and OSX intel covered. there is no reason for multiple build-bot for the same platform is there? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Become a GHC build slave!
Thanks for the info; I'll set up the following: - Gentoo Linux on the G4 PPC - OpenBSD for AMD64 for the AMD box. It would be nifty to have an easy-to-view list showing which platforms are covered and which platforms are desired. Richard Wilson MacGyver wrote: I'm in the processing of setting up a OSX powerpc buildbot on my end. Maybe we can split the effort to increase powerpc coverage? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Become a GHC build slave!
Hello I have a G4 PowerPC Mac Mini and an AMD 64 bit box that I can donate to the cause. What OS would be the most useful on the G4? Mac OS X? Linux? BSD? QNX (not sure if it's supported)? What OS would be the most useful on the AMD box? BSD? QNX? Or something else? Richard Simon Marlow wrote: Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to automate nightly builds on multiple platforms. This replaces the old set of shell scripts that we used to run nightly builds; now adding new clients to the setup is relatively easy, instructions are here: http://hackage.haskell.org/trac/ghc/wiki/BuildBot So far we have various Windows builds running, and I'll be moving over the existing Linux nightly builds in due course. If you have a spare machine or a machine that is idle overnight, and you'd like to use it to run automated GHC builds, then please take a look at the above page for how to get started. We especially need platforms that we don't use regularly (i.e. not Windows or Linux/x86/x86_64). Cheers, Simon ___ 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
