Re: GHC 6.4 release candidates available
Ian Lynagh wrote: [...] Is there an equivalent of this (the no-OpenGL bit): $(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO GhcLibsWithGLUT=NO that still works or do I have to do it by hand? The OpenGL/GLUT/OpenAL packages (and a few others) are enabled automatically if the right headers/libs are found during the configuration stage, otherwise they are disabled. If you don't want these packages to be built, even if the right headers/libs are available on the build platform, just give --disable-opengl/--disable-glut/--disable-openal options to configure. Cheers, S. ___ 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 (breakage on x86-64)
Donald Bruce Stewart wrote:
bstrand:
Donald Bruce Stewart wrote:
bstrand:
Simon Marlow wrote:
Just to let you know, there are a number of open bug reports for GHC on
the x86_64 platform, which seem to indicate some kind of occasional
memory/GC problem. I'm probably not going to be able to track this down
until after the 6.4 release, but we'll put out a patch as soon as we
have one.
Here's an error building ghc-6.4.20050224ghc-6.4.20050224 via Anders'
Debian x86-64 ghc, although it doesn't look like a memory/GC problem to
my untrained eye:
==fptools== make boot - --no-print-directory -r;
in /home/bstrand/src/ghc-6.4.20050224/ghc/lib/compat
../../../glafp-utils/mkdependC/mkdependC -f .depend-I../../includes
-- -O-- cbits/directory.c cbits/rawSystem.c
/usr/bin/ghc -M -optdep-f -optdep.depend -osuf o-H16m -O -H64m -O
-I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp
Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs
Distribution/Extension.hs Distribution/GetOpt.hs
Distribution/InstalledPackageInfo.hs Distribution/License.hs
Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs
Distribution/Version.hs System/Directory/Internals.hs
<>
make all
rm -f System/Directory/Internals.o; if [ ! -d
System/Directory/Internals_split ]; then mkdir
System/Directory/Internals_split; else /usr/bin/find
System/Directory/Internals_split -name '*.o' -print | xargs rm -f
__rm_food; fi;
/usr/bin/ghc -H16m -O -H64m -O -I. -Rghc-timing -I../../../libraries
-fglasgow-exts -no-recomp -split-objs-c
System/Directory/Internals.hs-o System/Directory/Internals.o -ohi
System/Directory/Internals.hi
warning: don't know how to split object files on this architecture
<>
( cd System/Directory/Internals_split; rm -f ld.script; touch ld.script;
echo "INPUT(" *.o ")" >>ld.script; /usr/bin/ld -r -x -o
../Internals.old.script; );
/usr/bin/ld:ld.script: file format not recognized; treating as linker
script
/usr/bin/ld:ld.script:1: syntax error
make[4]: *** [System/Directory/Internals.o] Error 1
make[3]: *** [boot] Error 2
make[2]: *** [boot] Error 1
make[1]: *** [boot] Error 1
make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc'
make: *** [build] Error 1
Can you try building with SplitObjs=NO ?
Wolfgang, Ryan - that looks like a splitter problem, no?
(The splitter is more of a dark art than the evil mangler, I propose we
name it the "diabolical splitter" from now on.)
-- Don
Using SplitObjs=NO gives out many warnings then finally dies with:
../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W
-optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return
-optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel
-optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -H64m -O -O2
-static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h
-#include RtsUtils.h -#include StgRun.h -#includeSchedule.h -#include
Printer.h -#include Sanity.h -#include STM.h -#include Storage.h
-#include SchedAPI.h -#include Timer.h -#include Itimer.h-#include
ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include
Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o
In file included from ../includes/Stg.h:149,
from StgCRun.c:67:
../includes/Regs.h:213: warning: call-clobbered register used for global
register variable
../includes/Regs.h:342: warning: call-clobbered register used for global
register variable
/tmp/ghc13908.s: Assembler messages:
/tmp/ghc13908.s:20: Error: suffix or operands invalid for `jmp'
make[2]: *** [StgCRun.o] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/bstrand/src/ghc-6.4.20050224/ghc'
make: *** [build] Error 1
Are you building unregisterised? Those messages about global register
variables (I think) imply that you are not -- and we haven't yet got
x86_64 (terrible name, I much prefer amd64) registerised. Looks like you
might even have found the point where registerisation breaks.
Try building unregisterised:
GhcUnregisterised=YES
just as the .hc bootstrap compiler was built.
-- Don
Well, I don't know much about how the bootstrap compiler was built (I
just downloaded it from
http://debian-amd64.alioth.debian.org/pure64/pool/unstable/main/amd64/g/ghc6/),
but building with GhcUnregisterised=YES and SplitObjs=NO died with:
==fptools== make all -wr;
in /home/bstrand/src/ghc-6.4.20050224/libraries/base
../../ghc/compiler/ghc-inplace -H16m -O -H64m -O -fglasgow-exts -cpp
-Iinclude -"#include" HsBase.h -funbox-strict-fields -ignore-package
base -O -Rghc-timing -fgenerics -fgenerics-c GHC/Base.lhs -o
GHC/Base.o -ohi GHC/Base.hi
ghc-6.4.20050224: internal error: getMBlock: mmap: Invalid argument
Please report this as a bug to glasgow-haskell-bugs@ha
Re: GHC 6.4 release candidates available
I haven't followed this thread too closely so please excuse me if this has already been mentioned (or even fixed). After I installed the latest binary package (20050228) the documentation was not correctly linked from the main documentation page. 'Hierarchical Libraries' on the main page points to /usr/local/share/ghc-6.4.20050228/html/libraries/index.html, but in this directory there is no index.html, only subdirectories. The link named 'Cabal' is also dead: file:/usr/local/share/ghc-6.4.20050228/html/Cabal/index.html does not exist). This is clearly non-critical, but it would be nice if it could be fixed in the final version. Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
6.4 snapshot installer available
http://www.haskell.org/ghc/dist/stable/dist/ghc-6-4-20050301.msi (md5.sig: 0f3be1a0c211194415b2cb8ee579f6e1 ; size: 46M) the only known omission from the bits intended to be included in the release proper is the PDF version of the user's guide. --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: readline fun
Sorry it took me so long to reply. On Mon, Feb 07, 2005 at 11:57:58AM -, Simon Marlow wrote: > On 02 February 2005 15:51, Ian Lynagh wrote: > > I bet the old GHC will work fine with the new readline. You might be right, but I'd much rather not have to check it really does before relaxing the dependency (which would also mean it couldn't be automatically generated). > You want us to ship the readline package separately, say as a Cabal > package? That's a possibility, but we like to keep the GHC sources as > self-contained as possible, I don't necessarily want /you/ to, I just want to be able to myself without anything breaking. In fact, having thought about this a bit more I think this already is the case, as nowadays a cabal package using the readline package will have to specify it explicitly rather than GHC noticing it uses an appropriate module and pulling it in automatically. Thus an automated tool would generate a dependency on a suitably named package and it would all work fine. Well, that was easy :-) 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
On Thu, Feb 10, 2005 at 01:11:48PM -, Simon Marlow wrote:
> 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.
All the below with
2c7ed0ee7a11f2eae159d073c29b4fe6 ghc-6.4.20050228-src.tar.bz2
The following files in the tarball look like they shouldn't be there
(and should be cleaned by at least distclean):
* ghc/includes/mkGHCConstants (an x86 ELF binary)
* ghc/driver/package.conf.inplace.old
* ghc/driver/package.conf.old
* A large number of ld.script files and the _split directories they are in
* libraries/{OpenAL,X11,base,network,unix}/config.status
* libraries/config.status
After building, then doing make distclean, I'm additionally left with:
* A ghc/compiler/stage1 directory tree including a number of
.hi-boot-5 and .hi-boot-6 files.
* A ghc/compiler/stage2 directory tree including a number of
.hi-noot and .o-boot files.
* A complete libraries/html directory
* libraries/libraries.txt
* mk/config.h
* mk/config.mk
* mk/stamp-h
but "Building from source" / "Standard Targets" says:
distclean
Delete all files from the current directory that are created by
configuring or building the program. If you have unpacked the source
and built the program without creating any other files, make
distclean should leave only the files that were in the distribution.
I think you have unswapped the first two lines of
"ghc -v 2>&1 | head -2" but not changed "Reading" back to "Using", so
old hmakes are still broken (old includes the latest release, I
believe).
Is there an equivalent of this (the no-OpenGL bit):
$(MAKE) prefix=`pwd`/debian/tmp/usr install GhcLibsWithOpenGL=NO
GhcLibsWithGLUT=NO
that still works or do I have to do it by hand?
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new ghc under solaris
* Christian Maeder <[EMAIL PROTECTED]>: > I used gcc_2.95.3 until I discovered the warning: > > LdvProfile.c:43: #error Please use gcc 3.0+ to compile this file with > DEBUG; gcc < 3.0 miscompiles it This usually happens if you use build.mk.sample. Simply remove the -DDEBUG from the options (unless of course you really want a debugging RTS which you usually don't). Volker -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Scrap your boilerplate (but don't scrap them precious comments)
On 01 March 2005 10:43, Ross Paterson wrote: > On Tue, Mar 01, 2005 at 09:42:17AM -, Simon Marlow wrote: >> One thing I'm going to do for the 6.4 docs is include a link to the >> source code file (pointing to cvs.haskell.org) for each module. > > Of course this won't work when the exported names are defined > elsewhere. But I also think it would be going too far: it will > encourage users > to refer to the source code as the true documentation in all cases, > leading to both reliance on accidental features and reduced demand for > better interface documentation. That's true. I also discovered that adding the source code links isn't as easy as I thought, so it won't happen anyway. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scrap your boilerplate (but don't scrap them precious comments)
On Tue, Mar 01, 2005 at 09:42:17AM -, Simon Marlow wrote: > One thing I'm going to do for the 6.4 docs is include a link to the > source code file (pointing to cvs.haskell.org) for each module. Of course this won't work when the exported names are defined elsewhere. But I also think it would be going too far: it will encourage users to refer to the source code as the true documentation in all cases, leading to both reliance on accidental features and reduced demand for better interface documentation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Scrap your boilerplate (but don't scrap them precious comments)
Including the source code in Haddock output is a good idea. Retaining
the original indentation would be tricky (but possible, the HaRe folks
have to solve a similar problem).
Marking up the source code with hyperlinks requires applying Haskell's
static scoping rules to the source code - currently Haddock doesn't have
to do this, it only deals with type signatures and type declarations.
One thing I'm going to do for the 6.4 docs is include a link to the
source code file (pointing to cvs.haskell.org) for each module.
Cheers,
Simon
On 01 March 2005 01:20, Ralf Lammel wrote:
> That's a very good point.
> Me too, I would often wish to see some principled
> code details when entering documentation. For instance
> what is the point of _explaining_ that "inc" aliases
> "add 1", why not just show that equation! I agree that
> gmap?? are a bit of this kind. It is so much easier to
> explain them, while showing code. It is so much of a
> hassle to explain them while not showing code. The
> implementations of gmap?? are almost like algebraic
> properties ... I mean these are rather principled
> implementations. A documentation tool should support
> algebraic laws _and_ such principled implementations.
>
> It would really help to link the function signatures
> with the function definitions in the sense of a limited
> code browsing functionality.
>
> I am sure this is not a new discussion topic,
> but we really need this IMHO.
>
> Ralf
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:glasgow-haskell- [EMAIL PROTECTED] On Behalf Of
>> Benjamin Franksen
>> Sent: Monday, February 28, 2005 4:11 PM
>> To: glasgow-haskell-users@haskell.org
>> Subject: Scrap your boilerplate (but don't scrap them precious
>> comments)
>>
>> Hi,
>>
>> I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
>> combinators. (Yes, I have read the papers). What finally made me
>> understand how they worked was reading the code: first the
>> implementation of the gmap functions (Data/Generics/Basics.hs), then
>> the long and detailed comments in the same file, and finally the
>> instance definitions for the built-in types (in
>> Data/Generics/Instances.hs).
>>
>> IMHO, a lot of this could and should be part of the
>> (haddock-generated) documentation.
>>
>> It is such a waste: all these wonderful comments in the source file,
>> that could be added to the docs with a keystroke! Instead, they
>> simply say
>>
>> "Left-associative fold operation for constructor applications"
>>
>> which is really a bit terse for gfoldl, of which the source file
>> comment (rightly) states that its type is a "headache".
>>
>> Furthermore, (example) implementations can sometimes be extremely
>> helpful to understand things; this is especially true for a language
>> like Haskell, in which the implementation is often already the
>> shortest (or at least a very short) and most precise way to specify
>> a functions semantics.
>>
>> In this case, the implementations of gfoldl helped me to understand
>> what the function itself does. However, how and why these extremely
>> abstract combinators can serve as the basic building blocks of all
>> the more concrete and better understandable variants is best
>> documented by the implementation of just these variants gmapXX and
>> friends. (Maybe one or two examples implementations would suffice).
>> At least, it should be stated in the docs what the type constructor
>> ('c') is in each case.
>>
>> I don't know if haddock can add the implementation of a function to
>> the documentation. If not, such a feature should be considered.
>>
>> SYB is a wonderful piece of work and deserves to be documented as
>> well as it is programmed.
>>
>> Ben
>> ___
>> 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: Scrap your boilerplate (but don't scrap them precious comments)
John Meacham wrote: On Mon, Feb 28, 2005 at 05:20:18PM -0800, Ralf Lammel wrote: It would really help to link the function signatures with the function definitions in the sense of a limited code browsing functionality. I am sure this is not a new discussion topic, but we really need this IMHO. Yeah, I have wanted some special haddock identifier which means 'include the body of the function here'. Since often, this can be the best documentation. I think haddock could be a lot more useful if it could extract more information from unprepared input. Just argument names in addition to types could be helpful, sometimes they are meaningful and not just "x" or "xs" ;) I remember, more than once, having looked up the code to getProcessStatus to find out which boolean argument meant what, for example.. Or, being able to link to and "export" source code as well, pretty printed and crosslinked. (like doxygen[1]) Then you could use haddock to familiarize yourself with unknown, non-haddockized, haskell code. Or, thinking of it, one should perhaps just write a haskell frontend to doxygen... Peter [1] http://www.doxygen.org ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
