- Glasgow-haskell-users

RE: Haddock generated documentation for Control.Monad.Error
by Simon Marlow 05 May '05

05 May '05

On 05 May 2005 06:34, Sean Seefried wrote: > When I look in the Haddock generated code at: > http://www.haskell.org/ghc/docs/latest/html/libraries/base/ > Control.Monad.html#t%3AMonadPlus, I don't seem to find any reference > to the IO monad being an instance of the MonadPlus class. > > But when I look at the source code in > libraries/mtl/Control/Monad/Error.hs it clearly is. Why is this > happening? The instance is defined in Control.Monad.Error, that's all. (Haddock doesn't currently tell you which instances are exported via which modules, and I consider this to be a bug - though I'm not exactly sure of the best way to fix it). Cheers, Simon

1 0

Haddock generated documentation for Control.Monad.Error
by Sean Seefried 04 May '05

04 May '05

Hi, When I look in the Haddock generated code at: http://www.haskell.org/ghc/docs/latest/html/libraries/base/ Control.Monad.html#t%3AMonadPlus, I don't seem to find any reference to the IO monad being an instance of the MonadPlus class. But when I look at the source code in libraries/mtl/Control/Monad/Error.hs it clearly is. Why is this happening? Cheers, Sean

1 0

Unicode source files
by Bulat Ziganshin 04 May '05

04 May '05

Hello it is true what to support unicode source files only StringBuffer implementation must be changed? if so, then task can be simplified by converting any files read by hGetStringBuffer to UTF-32 (PackedString) representation and putting in memory array in this form. After this, we must change indexing of ByteArray to indexing of Array Int Char, and somewhat replace call to mkFastSubStringBA#. btw, why in FastString module unicode strings are saved as [Int], not as String itself? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: [ ghc-Bugs-1188785 ] panic! ... forkM Declaration for tables{v}
by Simon Marlow 04 May '05

04 May '05

On 04 May 2005 11:18, Ferenc Wagner wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Comment By: Ferenc Wágner (wferi) >> >>> Just to make sure: the "Could not find module >>> `HTMLMonadBase'..." is entirely reasonable (and my >>> package.conf is crap), it's the "ghc: panic!" I found worrying. >> >> Yes, we plan to fix the panic and emit a more helpful message. > > Fine! > >>> Anyway. Let me drift off topic: why no ghcOptions field in >>> package.conf? I'd perhaps try porting Wash if it were >>> present... >> >> The ability to specify extra GHC options in a package was >> a misfeature that we removed. It isn't reasonable for a >> package to be able to change the global GHC behaviour. > > I see. But why did hugsOptions remain, then? Hugs needs to process the source files, so it might need flags to turn on certain extensions, for example. It's not ideal either - flags should really go in the source files themselves. Cheers, Simon

1 0

RE: Problem with porting GHC
by Simon Marlow 04 May '05

04 May '05

On 04 May 2005 07:46, Thomas Schwinge wrote: > On Tue, May 03, 2005 at 06:57:23PM -0400, Liwen Huang wrote: >> However, when I execute the last command of cross-compilation, I get >> another problem. >> >> $make hc-file-bundle Project=Ghc >> I have following error msg. >> ------------------------------------------------------------- >> echo ghc-6.4/libraries/base/GHC/PrimopWrappers.hs >> hc-files-to-go >> echo ghc-6.4/ghc/compiler/parser/Parser.hs >> hc-files-to-go >> echo ghc-6.4/ghc/compiler/parser/ParserCore.hs >> hc-files-to-go >> echo ghc-6.4/ghc/compiler/main/ParsePkgConf.hs >> hc-files-to-go >> echo ghc-6.4/libraries/haskell-src/Language/Haskell/Parser.hs >> >> hc-files-to-go tar czf ghc-6.4-i386-pc-nto-qnx6.2.0-hc.tar.gz `cat >> hc-files-to-go` >> tar: ghc-6.4/ghc/rts/AutoApply_thr.hc: Cannot stat: No such file or >> directory tar: ghc-6.4/ghc/rts/AutoApply_thr_p.hc: Cannot stat: No >> such file or directory tar: ghc-6.4/ghc/rts/AutoApply_debug.hc: >> Cannot stat: No such file or directory tar: Error exit delayed from >> previous errors >> make: *** [hc-file-bundle] Error 2 >> ------------------------------------------------------------- > > I was getting the following while porting ghc-6.4-branch to GNU/Hurd: > #v+ > $ make hc-file-bundle Project=Ghc > [...] > echo ghc-6.4/ghc/compiler/main/ParsePkgConf.hs >> hc-files-to-go > echo ghc-6.4/libraries/haskell-src/Language/Haskell/Parser.hs >> > hc-files-to-go > tar czf ghc-6.4-i386-unknown-gnu-hc.tar.gz `cat hc-files-to-go` > tar: ghc-6.4/ghc/rts/AutoApply_thr_p.hc: Cannot stat: No such file or > directory > tar: ghc-6.4/ghc/rts/AutoApply_thr.hc: Cannot stat: No such file or > directory > tar: ghc-6.4/ghc/rts/AutoApply_debug.hc: Cannot stat: No such file or > directory > tar: ghc-6.4/libraries/haskell-src/Language/Haskell/Parser.hs: Cannot > stat: No such file or directory tar: Error exit delayed from previous > errors > make: *** [hc-file-bundle] Error 2 > #v- > >> Since it is mentioned in the documentation, that we can ignore "rts >> error", >> and the gz file is successfully generated. I decide to try the next >> step. It it safe to do so? > > I continued with the incomplete tarball of .hc files and didn't have > any > problems related to that (AFAICT), apart from having to unpack > happy-1.15/happy into the build tree and run 'make -C happy boot all' > before continuing the build. Yes, the lack of those files isn't fatal. Cheers, Simon

1 0

RE: Haddock's -s switch is broken
by Simon Marlow 04 May '05

04 May '05

On 03 May 2005 15:24, Peter Simons wrote: > Simon Marlow writes: > > > Anyway, in CVS, the argument to -s is transformed as follows: > > > > - the string %M is replaced by the module name > > (with '.' replaced by '/') > > > > - the string %F is replaced by the source file name > > > > so to get the behaviour of Haddock 0.6, you say 'haddock -s > <url>/%F'. > > Very cool. Adding the '%F' did fix the problem; thanks for > the pointer. > > I am all for having links to the source code wherever > possible, by the way, I think that's the right direction to > go. IMHO, the best solution would be generate the pages with > the source along with the documentation. This approach gets > rid of most file-name-guessing problems, and it allows for > nifty features to be added (such as adding hyperlinks in the > source code, too). Opinions were divided on whether we should link to the source code at all. Some people thought that doing so would reduce the incentive for us to provide good documentation. There are good arguments on both sides - I don't have a strong opinion either way. Cheers, Simon

1 0

RE: [ ghc-Bugs-1188785 ] panic! ... forkM Declaration for tables{v}
by Simon Marlow 04 May '05

04 May '05

On 03 May 2005 17:20, SourceForge.net wrote: > ---------------------------------------------------------------------- > > Comment By: Ferenc Wágner (wferi) > Date: 2005-05-03 18:19 > > Message: > Logged In: YES > user_id=142529 > > Just to make sure: the "Could not find module > `HTMLMonadBase'..." is entirely reasonable (and my > package.conf is crap), it's the "ghc: panic!" I found worrying. Yes, we plan to fix the panic and emit a more helpful message. > Anyway. Let me drift off topic: why no ghcOptions field in > package.conf? I'd perhaps try porting Wash if it were > present... The ability to specify extra GHC options in a package was a misfeature that we removed. It isn't reasonable for a package to be able to change the global GHC behaviour. Cheers, Simon

2 1

RE: [Haskell] GHC: Setting default +RTS options at compile time?
by Simon Marlow 04 May '05

04 May '05

[ replying to old mail which ended up in my spam folder... ] On 18 March 2005 17:00, Simon Peyton-Jones wrote: >> Is there any way to specify at compile/link time default options for >> GHC program +RTS options? > > No. This is a long-standing feature request. It makes perfect sense, > but needs someone to design and implement it. So far not enough > people have yelled loudly enough for us to do it. Any volunteers? But there *is* a way to do this, and it's documented: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control. html#rts-hooks Cheers, Simon

1 0

RE: Problem with porting GHC
by Simon Marlow 03 May '05

03 May '05

On 29 April 2005 22:49, Liwen Huang wrote: > I am trying to port GHC to QNX machines. I followed the instructions > in the document of porting GHC strictly. > > Everything went well until I came to the step > $cd H/ghc/lib > $make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > > I was given following error messages > ------------------------------------- > System/Directory/Internals.hs:1:0: > Module `System.Directory.Internals' is a member of package > base-1.0. To compile this module, please use -ignore-package > base-1.0. ------------------------------------- > > I have tried to add the option, but then the compiler can not find > Prelude. > > My host machine is running redhat9.0. It also has ghc-6.4 > installed. Will that be the reason why I got this problem when > creating a unregisterised GHC. This error message shouldn't occur, but looking at the build system, it might if you were bootstrapping using an older version of GHC (6.2.x?). Could you send me the complete output from the command that failed? Cheers, Simon

3 2

RE: installing ghc without already having ghc
by Simon Marlow 03 May '05

03 May '05

On 11 April 2005 16:44, Jessica Brennan wrote: > cd H/ghc && make boot && make > in section 10.2.1 of the build guide. > > Actually I just double checked and I don't get those lines of the > error when doing cross-compiling. > Sorry grabbed the first set of errors I saw. It is the same minus > those test messages for the cross-compiling: > > ------------------------------------------------------------------------ > ==fptools== gmake all -r; > in /devel/build/NetBSD/ghc/ghc-6.4-host/ghc/compiler > ------------------------------------------------------------------------ > > /usr/local/bin/ghc -H16m -O -H32m -istage1/utils -istage1/basicTypes > -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename > -istage1/typecheck -istage1/deSugar -istage1/coreSyn > -istage1/specialise -istage1/simplCore -istage1/stranal > -istage1/stgSyn > -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling > -istage1/parser -istage1/cprAnalysis -istage1/compMan > -istage1/ndpFlatten -istage1/iface -istage1/cmm -Istage1 > -DOMIT_NATIVE_CODEGEN -cpp -fglasgow-exts -fno-generics -Rghc-timing > -I. > -IcodeGen -InativeGen -Iparser -package unix -recomp -Rghc-timing -O > -fasm > -H16M '-#include "hschooks.h"' -i../lib/compat -c > utils/PrimPacked.lhs > -o stage1/utils/PrimPacked.o -ohi stage1/utils/PrimPacked.hi > > utils/PrimPacked.lhs:244: > Warning: foreign declaration uses deprecated non-standard syntax > > utils/PrimPacked.lhs:248: > Warning: foreign declaration uses deprecated non-standard syntax > > utils/PrimPacked.lhs:251: > Warning: foreign declaration uses deprecated non-standard syntax > > utils/PrimPacked.lhs:254: > Warning: foreign declaration uses deprecated non-standard syntax > > utils/PrimPacked.lhs:257: > Warning: foreign declaration uses deprecated non-standard syntax > ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): > This compiler was built without a native code generator > Use -fvia-C instead > > Please report it as a compiler bug to > glasgow-haskell-bugs(a)haskell.org, or > http://sourceforge.net/projects/ghc/. Ok, the instructions have a slight mistake, we shouldn't be using the -fasm flag to build stage 1. I'm not sure how that crept in, sorry. Just remove -fasm from GhcStage1HcOpts in mk/build.mk, that should fix it. By the way, I'm guessing you're on a Sparc box, is that right? If so, others have reported problems on Sparc with 6.4, so you might run into difficulties. We're lacking a Sparc guru at the moment. Cheers, Simon

2 3