On Monday 24 September 2007 00:42, Isaac Dupree wrote:
> [...]
> This seems valid as long as Haddock can't make links to libraries that
> aren't depended upon (e.g. something in base saying "you might be
> interested in this thing that's in the 'containers' package"). (can it?
> I don't know, proba
Sun Sep 23 05:06:36 PDT 2007 [EMAIL PROTECTED]
* Fix bug #1725 (Haddock links between packages)
Resolving this bug is a bit tricky, it boils down to the question: Should the
Haddock links between packages include the package version or not?
Pro: We can differentiate between various vers
Sun Sep 23 02:43:58 PDT 2007 [EMAIL PROTECTED]
* Unbreak "dist" target for fresh trees
The previous hack to include Parser.hs in source distros broke the possibility
of doing a "make dist" in a fresh tree, i.e. one which has just been checked
out and configured, but *not* built. Of course
[ People who want to take a shortcut can immediately jump to the end and read
what has to be done to fix things. ;-) ]
On Wednesday 19 September 2007 00:41, Wolfgang Thaller wrote:
> I guess I could find some time to play around with it on the weekend.
> I don't have an x86_64-linux box available
On Monday 17 September 2007 21:56, Wolfgang Thaller wrote:
> "Something like that" is the reason. For non-PIC, ELF tries to keep
> up the illusion that there is no such thing as dynamic linking. In
> the X86_64 small code model, all addresses in the main program are
> expected to lie in the 32-bit
On Monday 17 September 2007 13:48, Simon Marlow wrote:
> When you generate a non-PIC object file, references to external functions
> will go through the PLT (a table of jump instructions, or it might be more
> complicated than that and support lazy resolution). So when you use
> dlsym() you're get
I'm currently trying to find out why a few GLUT examples work when they are
compiled by GHC, but not when they are run within GHCi (this happens e.g.
with GLUT/examples/Misc/ARBOcclude.hs). The main difference is that in the
former case libHSGLUT-XY.a is linked into the executable, and in the la
On Sunday 16 September 2007 14:13, Ian Lynagh wrote:
> Sat Sep 15 17:53:28 PDT 2007 Ian Lynagh <[EMAIL PROTECTED]>
> * Another attempt at getting bindists working everywhere
>
> M ./Makefile -1 +1
> M ./libraries/Makefile -22 +32
> M ./libraries/installPackage.hs -21 +25
Does this a
Sun Sep 16 04:19:27 PDT 2007 [EMAIL PROTECTED]
* Keep valgrind happy when calling timer_create
Fill all of the sigevent structure with zeroes before individual fields are
set. Although not strictly necessary, this keeps tools like valgrind from
complaining about passing uninitialized data,
On Sunday 16 September 2007 04:42, Ian Lynagh wrote:
> At the interface to the outside world (i.e. the configure flags) they
> have the normal semantics. We then append "/ghc-$(ProjectVersion)" to
> the internal build system variables. This seems reasonable to me - I
> don't think it would be bette
Sun Sep 16 01:43:39 PDT 2007 [EMAIL PROTECTED]
* Make DESTDIR work again
installPackage is a horror, using --force is probably not the perfect way
to make DESTDIR functionality work again, but given the current state of
affairs, I can't find a quick and clean solution.
MERGE TO STABLE
Sun Sep 16 01:41:22 PDT 2007 [EMAIL PROTECTED]
* Resurrect the "lib" subdirectory in the installation tree, it was somehow
lost
Having all package directory directly in the toplevel installation directory
would be a bad thing because of potential name clashes, and it wasn't done
this
way
Is there a deep reason why the ghc/rts packages have various files/directories
directly below the GHC installation directory? A cleaner way would be having
them below "lib/ghc" and "lib/rts", just like the other packages (Perhaps
with a version suffix? If yes, which one?).
Cheers,
S.
__
OK, after digging around the build system quite a bit, here is my first
proposal to get things back into a sane state.
The first confusing things are that "datadir", "libdir" and "libexecdir" don't
have the proposed GNU semantics. because they contain the package
name "ghc-XY". They are intende
Like every weekend when I try to build a GHC RPM, things have been broken
again, this time by ghc-pkg not taking DESTDIR into account, but the details
do not matter. Fixing the RPM build every weekend again and again and again
is extremely frustrating. What can we do to improve this? "make valid
On Sunday 09 September 2007 15:01, Sven Panne wrote:
> The current Cabal used for building GHC has a small bug, it *always*
> creates the data directory, even if there are no data files in the package.
> Simple fix:
>
> *** /tmp/Install.hs 2007-09-09 14:56:50.0 +0200
>
On Saturday 15 September 2007 10:59, Sven Panne wrote:
> Sat Sep 15 01:58:45 PDT 2007 [EMAIL PROTECTED]
> * Unbreak "clean" and "distclean" targets when there is no testsuite
>
> M ./Makefile -1 +1
Ooops, forgot a &q
Sat Sep 15 01:58:45 PDT 2007 [EMAIL PROTECTED]
* Unbreak "clean" and "distclean" targets when there is no testsuite
M ./Makefile -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Tue Sep 11 00:18:01 PDT 2007 [EMAIL PROTECTED]
* Synched documentation links with current directory layout
Somehow the "html" subdirs are gone, this change was not completely
intentional, but it is nice, anyway. Those subdirs never served any
real purpose...
MERGE TO STABLE
M ./d
On Monday 10 September 2007 18:16, Ian Lynagh wrote:
> Hi Sven,
>
> On Sun, Sep 09, 2007 at 08:42:11AM -0700, Sven Panne wrote:
> > Sun Sep 9 08:40:53 PDT 2007 [EMAIL PROTECTED]
> > * Include package documentation, n-th attempt...
>
> Am I right in thinking that
Sun Sep 9 23:57:59 PDT 2007 [EMAIL PROTECTED]
* The RTS is Haddock-less, tell make about it
MERGE TO STABLE
M ./rts/Makefile +5
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sun Sep 9 08:40:53 PDT 2007 [EMAIL PROTECTED]
* Include package documentation, n-th attempt...
MERGE TO STABLE
M ./ghc.spec.in -3 +13
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sun Sep 9 05:49:22 PDT 2007 [EMAIL PROTECTED]
* Yet another attempt to get the paths for the installed documentation correct
MERGE TO STABLE
M ./docs/index.html -1 +1
M ./libraries/Makefile -12 +8
M ./libraries/installPackage.hs -5 +6
Sun Sep 9 05:38:13 PDT 2007 [EMAIL PROTECTED]
* Add a "show" target here, too, quite useful for debugging the build process
MERGE TO STABLE
M ./libraries/Makefile -1 +4
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailma
Sun Sep 9 05:34:01 PDT 2007 [EMAIL PROTECTED]
* Never try to build Haddock docs in ghc/compiler, even with HADDOCK_DOCS=YES
MERGE TO STABLE
M ./compiler/Makefile -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman
Sun Sep 9 05:11:57 PDT 2007 [EMAIL PROTECTED]
* Removed install-dirs target, it is unnecessary and leads to stray empty
directories
MERGE TO STABLE
M ./mk/install.mk -14 +1
M ./utils/ghc-pkg/Makefile +1
___
Cvs-ghc mailing list
Cvs-ghc@ha
Sun Sep 9 03:28:15 PDT 2007 [EMAIL PROTECTED]
* Removed install-dirs from phony targets, it is unused
MERGE TO STABLE
M ./distrib/Makefile -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
The current Cabal used for building GHC has a small bug, it *always* creates
the data directory, even if there are no data files in the package. Simple
fix:
*** /tmp/Install.hs 2007-09-09 14:56:50.0 +0200
--- Distribution/Simple/Install.hs 2007-09-09 12:57:21.0 +0200
***
On Saturday 08 September 2007 19:33, Stefan O'Rear wrote:
> [...]
> $(MAKE) always includes the flags (at least with gnumake), cf "info make
> MAKE\ Variable".
Nope... Don't stop reading manuals prematurely: ;-)
http://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html
Easy
Is there a special reason why we don't pass MFLAGS (or better: MAKEFLAGS) down
to sub-makes in ghc/Makefile?
...
$(MAKE) -C libraries boot
$(MAKE) -C libraries all
...
This way, "-j" is not passed down to the library build, resulting in a
strictly sequential build. Is ghc/libraries
Just a warning: The current HEAD is not working correctly, probably some kind
of FFI problem in the interpreter. Some GLUT examples (e.g. Brick.hs,
ARBOcclude.hs) work when they are compiled, but exhibit strange behaviour
when run in GHCi (no graphics, warnings from freeglut, etc.). My platform
Sat Sep 8 07:27:12 PDT 2007 [EMAIL PROTECTED]
* We seem to use Outputable unconditionally these days
MERGE TO STABLE
M ./compiler/ghci/ByteCodeLink.lhs -3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs
Sat Sep 8 06:18:09 PDT 2007 [EMAIL PROTECTED]
* Removed setting of default values for variables which are never empty
The standard autoconf variables like prefix, exec_prefix, ... are always set
by
configure, so there is no need to provide explicit defaults in the Makefile.
The lines
Sat Sep 8 05:46:45 PDT 2007 [EMAIL PROTECTED]
* Use := for PACKAGE_TARNAME, no reason for not doing so
MERGE TO STABLE
M ./mk/config.mk.in -3 +3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Sep 8 05:44:48 PDT 2007 [EMAIL PROTECTED]
* Removed unused oldincludedir, things are already complicated enough
MERGE TO STABLE
M ./mk/config.mk.in -4
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs
Sat Sep 8 05:33:17 PDT 2007 [EMAIL PROTECTED]
* Added comment about GNU coding standards/autoconf history
MERGE TO STABLE
M ./mk/config.mk.in -4 +25
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Just a note, because it is too late for me to fix and test this: The logic in
mk/config.mk.in regarding datarootdir is wrong and leads to incorrect
directories. Autoconf 2.60 introduced datarootdir, and defines the following
defaults:
datadir = ${datarootdir}
infodir = ${datarootdir}/inf
Tue Sep 4 10:28:55 PDT 2007 [EMAIL PROTECTED]
* Don't hardwire the build path into the Haddock docs
Formerly, the ghc-pkg was called to get the HTML dirs for other packages, but
of course doing this at *build* time is totally wrong. Now we use a relative
path, just like before. This is pr
On Monday 03 September 2007 21:49, Judah Jacobson wrote:
> I was able to get make install of the haddock docs working by
> upgrading my autoconf from 2.59 to 2.61. However, I noticed that
> $prefix/share now contains three subdirectories:
>
> share/doc/ghc/libraries (contains the haddock docs)
> s
Sun Sep 2 09:43:42 PDT 2007 [EMAIL PROTECTED]
* Explicitly set "docdir" when calling make, configure's --docdir seems to be
ignored
M ./ghc.spec.in -4 +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-g
[ Not the correct mailing list, but cvs-all bounced my previous mail ]
FYI: I've just hacked the Setup scripts for Alex/Happy/Haddock to death so
these tools can now be built with a bleeding-edge GHC. But: I've done this in
a quick and dirty way which will *definitely* break things for everythin
Sat Sep 1 10:51:24 PDT 2007 [EMAIL PROTECTED]
* Use DESTDIR for installation
M ./ghc.spec.in -4 +3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Sep 1 05:46:15 PDT 2007 [EMAIL PROTECTED]
* Fixed TeX syntax
M ./compiler/prelude/primops.txt.pp -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Sunday 26 August 2007 14:38, I wrote:
> [...]
>c) "make install" gets an additional argument "prefix=/var/foo/usr"
> (where "/var/foo" is some temporary place and "/usr" is what was stated in
> the configure stage for "--prefix"), so everything gets installed
> below "/var/foo/usr". After so
On Sunday 26 August 2007 15:56, I wrote:
> GHCBIN and TOPDIROPT in the shell script wrappers for ghc and ghci contain
> the install-time prefix (not the correct build-time one) [...]
Furthermore, the package.conf is incorrect, too, as I just found out. :-(
Cheers,
S.
On Sunday 26 August 2007 15:29, Ian Lynagh wrote:
> Exactly which paths are getting baked in where?
>
> If it's the libraries causing problems then I think we need to set a
> CopyDest in installPackage.hs.
GHCBIN and TOPDIROPT in the shell script wrappers for ghc and ghci contain the
install-time
I'm currently trying to resurrect ghc.spec.in after all those build system
changes in the last few months. One thing I'm currently fighting with is the
totally obscure non-standard logic regarding the handling of build/install
prefixes. Just to recap what is needed for sane (non-relocatable) RPM
Sun Aug 26 02:30:26 PDT 2007 [EMAIL PROTECTED]
* Synched GHC's .spec file with recent changes
Fixed hsc2hs handling and added hpc binary. Explicitly generate Cabal docs.
Note that the Haddock documentation is currently not in the right place,
this needs more investigation, but at least we
Sat Aug 25 12:32:16 PDT 2007 [EMAIL PROTECTED]
* Be more flexible when trying to make scripts executable
M ./boot -1 +3
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Aug 25 06:30:52 PDT 2007 [EMAIL PROTECTED]
* Overhaul boot script
* Call autoreconf only if necessary, avoiding a strict tool dependency.
* Be a good *nix citizen and don't clutter the output when everything is fine.
* Make a few more scripts executable.
M ./boot -23 +22
Sat Aug 25 05:11:50 PDT 2007 [EMAIL PROTECTED]
* Added a few missing files to a source distribution
M ./Makefile -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Aug 25 04:55:19 PDT 2007 [EMAIL PROTECTED]
* Fixed test for pwd executable
Added a missing "test" and replaced the "-e" option of the shell-builtin
"test" with "-f". The former is not portable, see autoconf documentation.
M ./aclocal.m4 -1 +1
___
I've just once again fixed a situation in the library which looked as follows:
module Foo(Bar(..)) where
data Bar = Baz Blah
type Blah = String
Although Bar is usable, I very much doubt that it is intended that Blah is not
exported from Foo. Haddock complains about such situations, BTW.
On Monday 02 April 2007 15:44, Malcolm Wallace wrote:
> Done (although with some reluctance due to the general network slowness
> of darcs.haskell.org). In the new darcs-all, I am very keen to retain
> the ability to use package repos stored elsewhere (not at
> darcs.haskell.org).
Thanks, that wa
While we are at the darcs topic: I get problems most of the time I run
several "darcs pull" commands for the same server, but different repositories
on that server via SSH (cryptic messages about not being able to get some
patches etc.). Somehow darcs seems to share the SSH ControlPath (see
Ext
Quick question: GHC's current darcs-all adds --partial by default, and the
user has to override this with --complete if this is wanted. Given my
sometimes rather strange experiences with partial repos (darcs doesn't find a
patch, "darcs changes" is silent, etc.), I've switched to --complete for
On Monday 02 April 2007 13:51, Donald Bruce Stewart wrote:
> [...]
> nhc does use a base containing ByteString *but* it needed a couple of
> tweaks to compile. Those nhc patches are in the darcs repo, but not in
> the standard base yet.
>
> They will be on the next merge. [...]
Could you merge jus
On Monday 02 April 2007 13:23, Donald Bruce Stewart wrote:
> [...]
> The other compilers should be using a base package with fps in it, as
> hugs and ghc do.
>
> fps as a package only exists as a seperate darcs repo for those systems
> that don't have bytestrings in base. I.e. older GHC's, and nhc
I'm currently trying to unify the darcs-all scripts for GHC/Hugs/nhc, adding
a "--release" option on the way, which is inteded to retrieve fixed versions
from Hackage instead of the latest & greatest stuff from darcs repos. Looking
at nhc's package list, I found a few issues:
* Iavor's package
On Monday 02 April 2007 10:07, Simon Marlow wrote:
> Since we're all demonstrating our local darcs hacks, here's mine: I use
> HTTP for get/pull, and I have a script (attached) that grovels in
> _darcs/prefs/repos to find the right place to push to and then pushes over
> SSH.
So what I seem to rea
On Monday 02 April 2007 10:37, Simon Peyton-Jones wrote:
> Is it documented somewhere? Thorough documentation multiplies the user
> base!
I'm quite aware of that, but the script is not 100% finished yet. Anyway, we
will need *all* packages on Hackage for "release" checkouts, but there are
curre
On Sunday 01 April 2007 13:38, Donald Bruce Stewart wrote:
> Are you using master/slave connections in ssh? This will let you reuse a
> single control connection in ssh, avoiding the need to reauthenticate to
> get each patch (and there's 2 or 3 of these per patch). [...]
I don't think so: darcs u
[ Well, not exactly a GHC problem, but I think that the mailing list fits,
anyway. ]
When getting a repo via HTTP, darcs seems to be *much* faster than via SSH.
Here as an example the cpphs repo, 3.7 patches per second vs. 0.7 patches per
second (almost unusable for large/old repos):
-
On Tuesday 27 March 2007 17:34, Malcolm Wallace wrote:
> The library package is LGPL.
> The executable that uses the library is GPL.
Ah, OK...
> Really? The FSF makes it quite clear that the advertising-clause-free
> BSD licence is compatible with the GPL. They also make it clear that
> merely
On Tuesday 27 March 2007 11:48, Simon Marlow wrote:
> We distribute gcc not just for its CPP support, but also because GHC still
> supports compilation via C, and because GHC can be used as a front-end to
> the C compiler. I'd happily swap a dependency on gcc for one on cpphs, but
> that's not an
On Thursday 22 March 2007 18:01, Simon Peyton-Jones wrote:
> Each blob reported as a "cycle" is a strongly connected component. You can
> get from every module in the cycle to every other module in the cycle.
OK, but then the flag and the output should not talk about "cycles",
but "SCCs". Curren
Thu Mar 22 09:10:40 PDT 2007 [EMAIL PROTECTED]
* Warning police: Removed catch-all case which was overlapped
M ./compiler/ghci/Debugger.hs -1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On Thursday 22 March 2007 15:20, Simon Peyton-Jones wrote:
> It is topologically sorted!
Hmmm, then I don't understand the underlying partial order... What does it
mean when a module is mentioned later than another one? Or are several cycles
lumped together? Let's take the first part of the outp
On Thursday 22 March 2007 02:13, Ian Lynagh wrote:
> hugs thinks that
>
> show (0/0 :: Double)
>
> is "nan", but it will only read "NaN". I'd suggest changing the
> behaviour of show rather than that of read, so as to match GHC:
>
> Prelude> show (0/0 :: Double)
> "NaN"
> Prelude> read "nan" ::
On Thursday 22 March 2007 13:32, Simon Peyton-Jones wrote:
> I've just added a flag -ddump-mod-cycles to the behaviour of ghc -M. It's
> specialised for displaying module cycles. Here's sample output for 'base'
> [...]
Great! That was fast... One further suggestion: If it doesn't involve too much
On Wednesday 21 March 2007 17:44, Ian Lynagh wrote:
> [...] It doesn't help that the tool doesn't currently look for, and colour,
> loops (source imports are coloured red, though, so you can spot them at
> least).
Could it be modified to simply print out all loops in textual form as an
option? Th
On Friday 16 March 2007 15:45, Ian Lynagh wrote:
> The only issue I see is that Cabal calls hsc2hs when necessary, but alex
> and happy are already in the that situation. Unfortunately packages
> can't depend on tools, they just fail when asked to build. Perhaps there
> should be a cabal "Tools:" f
On Friday 16 March 2007 12:40, Malcolm Wallace wrote:
> But the very reason that cpphs and hsc2hs are distributed with hugs and
> nhc98 is for bootstrapping. If you don't already have a Haskell
> compiler on your machine, then you can't install cpphs or hsc2hs. But
> conversely, you can't install
On Thursday 15 March 2007 21:34, Ian Lynagh wrote:
> hsc2hs gives different output on different platforms, so anyone building
> from source needs it, not just those building from darcs.
I came to the same conclusion this morning while standing under the
shower... :-) So things are quite different
On Thursday 15 March 2007 21:28, Ian Lynagh wrote:
> On Thu, Mar 15, 2007 at 07:46:09PM +0100, Sven Panne wrote:
> > BTW, the toplevel directory of darcs.haskell.org needs some serious
> > cleanup,
>
> There are plans[0] to get a "community server" where anyone can
While we are at the topic: Is there a deep reason why the cpphs repo is on
www.cs.york.ac.uk and not on darcs.haskell.org? I would like to add a .spec
file etc. to make it a standalone tool, but I can't commit currently. :-(
BTW, the toplevel directory of darcs.haskell.org needs some serious cle
On Thursday 15 March 2007 17:57, Malcolm Wallace wrote:
> The only reason ghc does not ship by default with cpphs is ideological -
> the latter is GPL licensed. Of course, 3rd-party packagers (RPM,
> debian, etc) have the liberty to include cpphs anyway, and modify ghc's
> driver script accordingl
On Thursday 15 March 2007 17:43, Malcolm Wallace wrote:
> nhc98 does actually ship with hsc2hs, but it currently gets used only
> during building. It is not installed, in order to avoid conflict with
> the ghc-shipped tool of the same name.
If it's installed as hsc2hs-nhc98, then it's OK. I'll ha
Thu Mar 15 08:28:23 PDT 2007 [EMAIL PROTECTED]
* Use update-alternatives for handling generic tool names
ATTENTION: Packagers should read the following stuff carefully!
GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
one hand this is quite handy, avoiding
Thu Mar 15 05:24:57 PDT 2007 [EMAIL PROTECTED]
* Added support for parallel builds
With this patch, one can define the degree of build parallelism via a 'jobs'
rpm variable. A comfortable way to use this is having a ~/.rpmmacros file with
a line like:
%jobs 2
Alternatively,
On Thursday 01 March 2007 15:13, Ian Lynagh wrote:
> Thu Mar 1 05:17:17 PST 2007 Ian Lynagh <[EMAIL PROTECTED]>
> * MERGED: Fix #839 (Generate documentation for built-in types and
> primitve operations) Simon Marlow <[EMAIL PROTECTED]>**20070228163442
>
>This patch was originally by [EMAIL
Wed Mar 14 08:15:17 PDT 2007 [EMAIL PROTECTED]
* Unbreak Haddock markup
M ./compiler/prelude/primops.txt.pp -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 07:04:34 PDT 2007 [EMAIL PROTECTED]
* Warning police: Avoid name shadowing
M ./utils/genprimopcode/Main.hs -61 +61
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 06:43:28 PDT 2007 [EMAIL PROTECTED]
* Handle primitive types and pseudo ops when generating LaTeX
M ./utils/genprimopcode/Main.hs +15
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 06:40:44 PDT 2007 [EMAIL PROTECTED]
* Warning police: Replace patter matching failures by something more
informative
M ./utils/genprimopcode/Main.hs -1 +13
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/li
Wed Mar 14 06:27:03 PDT 2007 [EMAIL PROTECTED]
* Added LaTeX commands for primitive types and pseudo ops
M ./docs/ext-core/core.tex +8
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 06:25:21 PDT 2007 [EMAIL PROTECTED]
* Fixed LaTeX markup
M ./compiler/prelude/primops.txt.pp -5 +6
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 05:36:08 PDT 2007 [EMAIL PROTECTED]
* Warning police: Don't rely on defaulting
M ./utils/genprimopcode/Main.hs -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 05:30:21 PDT 2007 [EMAIL PROTECTED]
* Warning police: Removed "Defined but not used" warnings
M ./utils/genprimopcode/Main.hs -25 +25
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 05:22:33 PDT 2007 [EMAIL PROTECTED]
* Use -Wall for compilation of genprimopcode
M ./utils/genprimopcode/Makefile +2
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Wed Mar 14 05:23:16 PDT 2007 [EMAIL PROTECTED]
* Warning police: Added type signatures
M ./utils/genprimopcode/Main.hs -13 +64
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Sat Feb 24 10:01:23 PST 2007 [EMAIL PROTECTED]
* Don't hardwire RELEASE into configure.ac
Previously one had to edit configure.ac to build a release version. This is
evil, so one can now specify this on the configure invocation line like:
RELEASE=YES ./configure
Note that non
Wed Feb 7 08:34:04 PST 2007 [EMAIL PROTECTED]
* Improved naming of generated HTML files by using nice IDs
M ./docs/users_guide/5-00-notes.xml -5 +5
M ./docs/users_guide/5-04-notes.xml -1 +1
M ./docs/users_guide/6.6-notes.xml -2 +2
M ./docs/users_guide/ffi-chap.xml -3 +3
M .
Wed Feb 7 08:19:27 PST 2007 [EMAIL PROTECTED]
* Make the User's Guide DocBook XML 4.2 conformant again
M ./docs/users_guide/ghci.xml -21 +21
M ./docs/users_guide/glasgow_exts.xml -9 +8
M ./docs/users_guide/using.xml -8 +9
___
Cvs-ghc mai
Sat Feb 3 04:31:41 PST 2007 [EMAIL PROTECTED]
* Warning police: "%p" format expects a void*
M ./rts/Capability.c -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Thu Feb 1 07:08:39 PST 2007 [EMAIL PROTECTED]
* Warning police: Avoid warning about unused variable
M ./rts/posix/OSThreads.c -1 +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
Thu Feb 1 05:42:43 PST 2007 [EMAIL PROTECTED]
* Adhere to the new GNU Coding Standards, avoiding a warning with autoconf
2.59c and later
M ./mk/config.mk.in +1
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo
97 matches
Mail list logo
