On 7 Mar 2011, at 09:35, Sean Leather wrote:
I have been getting the following message from cvs-ghc-ow...@haskell.org
repeatedly since December: "Your membership in the mailing list Cvs-
ghc has been disabled due to excessive bounces."Lately, it's been
every four days. I then have to re-ena
On 10 Jan 2011, at 14:02, Gregory Collins wrote:
+1. I don't have a lot of skin in this particular game (I'm not
currently a GHC contributor and am unlikely to become one in the near
future), but I can offer some anecdotal evidence:
As another non-GHC contributor, my opinion should probably als
The most interesting observation seems to be that the results are
largely inconsistent (look at 'atom', for example). Even wheel-
sieve1, where our numbers go in the same direction, varies between
+10% and +22.7%. My numbers are from an older HEAD (as I had nofib
handy there), but I'm stil
tags is the vim equivalent of TAGS.
Unfortunately, on a case-insensitive filesystem, such as the defaults
on Windows and MacOS, there is no way to have both a 'tags' and a
'TAGS' file.
Regards,
Malcolm
___
Cvs-ghc mailing list
Cvs-ghc@has
2. The back-end has a LLVM binding of sorts, ... Should this
binding be split out into a separate library?
There is already a published Haskell binding for LLVM on Hackage.
Does your new binding cover the same territory? Or different
aspects? Could it be converted to use the existing bin
Out of interest, without trying it, what do you think this program
should print (the only difference between the 3 functions is the
indentation of the "where" line)?:
main = do print $ f1 1
print $ f2 1
print $ f3 1
I reckon it would be "layout error" at line 2. :-)
f1 x = x
If you are using msys, then you can get a wget program by ...
Just wanted to point out that MacOS X does not by default supply wget
either (although it does have curl).
Regards,
Malcolm
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.h
Would you say that the nofib benchmarks are the best available for
measuring the effectiveness of compiler optimizations, or is there a
better benchmarking suite for that purpose?
I don't know about "better", but the nobench suite (which is largely
based on nofib, but goes further) automate
Interesting. This could be the cause of a weird floating point bug
that has been showing up in the ghc testsuite recently, specifically
affecting MacOS/Intel (but not MacOS/ppc).
http://darcs.haskell.org/testsuite/tests/ghc-regress/lib/Numeric/num009.hs
That test compares the result of t
Any idea why the buildbot collator (for stable only) does not include
results for the buildbot called "malcolm"? (The collator for HEAD does.)
> Build results:
> macgyver PPC OSX stable: fail (failed darcs)
> tnaur x86 Linux stable: pass
> x86 Linux stable:fail (failed srcdist) fail (fai
> So I'm asking for comments: if you find these changes useful, and
> they work for you, perhaps they get included;
I don't build ghc much (but nhc98 has a darcs-all script too...), so
take my opinion with a pinch of salt. However, I do think both of these
changes are likely to be improvements: t
"Claus Reinke" <[EMAIL PROTECTED]> wrote:
> | Starting from a fresh tree everytime or searching for files manually
> | don't sound realistic
>
> >Perhaps the easiest thing is to start with a fresh link-tree.
> >That's easy and fast -- but does not work on Windows.
>
> So your recommendation fo
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> I'm not against this, but I urge that we postpone it until after 6.10.
> There'll be quite a bit of settling down to do, I predict.
Actually, since the module namespace is one of the few extensions that
is purely lexical, I think it is easy to guar
> As I've said before regarding (2), it's feasible to make the .hi
> format stable across minor releases of GHC, but not major releases.
Here is an idea that might help solve some of the "need exact version of
ghc to build haddock" style of problem.
Why not develop a _small_ stand-alone tool th
Nobody answered the question that I (implicitly) raised a few times:
how do you branch ghc with a mixed use of git and darcs? (I don't
know too much of git, but AFAIK, it's notion of branches is pretty
different of that of darcs).
As far as I can tell, you do it in much the same way as the
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Bother! I did not mean to push the patch below.
> Can someone who knows what they are doing expunge it from the HEAD
> repo and tell me what actions I need to take at this end?
Although the usual policy is not to permit "unpull"s on the main repo,
Simon Marlow <[EMAIL PROTECTED]> wrote:
> This means we still get to use 'make', we still get to use the .cabal
> files as metadata, but the build system is more private to GHC, more
> extensible, and hopefully more understandable and modifiable.
This is essentially the same approach that nhc98
"Claus Reinke" <[EMAIL PROTECTED]> wrote:
> > - changing nhc98-corelibs (which are?) can break nhc98
Currently, building the nhc98 compiler itself depends on:
haskell98, base, containers, filepath, packedstring
Regards,
Malcolm
___
Cvs-ghc ma
Ian Lynagh <[EMAIL PROTECTED]> wrote:
> I'm hoping that once GHC's view of base is saner (and in particular,
> most modules are not in a recursive import loop) we can look at making
> ghc, nhc, hugs, etc, have a more consistent view, with imports and
> code mostly shared. Then it should be a lot l
1. whatever I check in, the _whole_ thing has to build ok
2. if _my_ changes break someone else's code, _I_ have to fix that
I'd suggest to interpret GHC+corelibs as a unit, and to apply rules
1 and 2.
To put it crudely, I don't see why the Hugs and nhc98 developers
should be forced to
> > | Would it be useful if I tried to get hold of such a thing,
>
> I think it's safe to say that support like this would make many people happy
I have an x86 Mac (running Leopard) available 24/7 which I have offered
as a buildbot. Just waiting for all the buildbot admin stuff to be
sorted out
> I don't think that's right. The HP maintainers are not (and cannot be)
> the maintainers of each individual package. That just does not scale.
Oh absolutely, but I was imagining that (at least part of) the purpose
of the Platform is to generate automatic notifications to package
owners, when a c
> FYI: Haskell's OpenGL binding has just been dropped from GHC's
> extralibs, which means that it will no longer be kept in sync with GHC
> development, at least not by GHC HQ.
>
> GHC HQ has its hands full and -generally speaking - extralibs are to
> be replaced by H(L)P, the Haskell (Library) Pl
[been on holiday - just catching up]
> | So the point of this analogy is that the releases of ghc and the
> | haskell platform should not be synchronised.
>
> Does that make sense? ... we do need to release a HLP that works, say,
> with GHC 6.10, at the same time that 6.10 comes out.
I disagre
Isaac Dupree <[EMAIL PROTECTED]> wrote:
> Do you think it's plausible to apply for this as haskell.org Summer of
> Code project (I'm a U.S. college student now, which explains why I've
> been too busy to work on GHC stuff, and in the fall) ; I don't know
> much about the process, and of course t
Isaac Dupree <[EMAIL PROTECTED]> wrote:
... lots of questions about the nhc98 .hi file format.
I think the easiest way to answer is just "have a look at an example
file". There are plenty supplied with the source distribution of nhc98:
you don't even need to build it. Look in the include/ direc
> > Module cycles have supported in nhc98 since forever, by simply
> > providing a bootstrapping .hi file.
>
> yay! Is the format of this .hi file documented somewhere?
It simply contains type signatures for exported functions, together with
datatype, class, and instance decls. A signature for f
Isaac Dupree <[EMAIL PROTECTED]> wrote:
> extension matrix, am I right? (did the tabs work to format it?)
The tabs worked, but the extension matrix is not exactly right.
> [1] supported in darcs but not a released version? or was there a
> recent nhc release supporting pattern-guards?
Patt
Simon Peyton-Jones <[EMAIL PROTECTED]> writes:
> | So in this hypothetical system, haddock uses the GHC API to get at the
> | comments in the AST, it somehow figures out which comments are in
> | locations that are legal for haddock markup, parses them. It extracts
> | the names from the markup an
I'm still on holiday, but saw this and thought I'd join in.
> Malcolm, how do you feel about this? Are we able to link cpphs as a
> library statically to GHC?
Sure, I'll happily add a static-linking exception to the LGPL for cpphs,
so you can use it directly within ghc as a library, rather than
Isaac Dupree <[EMAIL PROTECTED]> wrote:
> * remove #if branches for pre-ghc-6.0
> I skipped utils/hsc2hs/Main.hs since its ifs also involved
> checking for old versions of nhc98
It's worth noting that hsc2hs was forked by ghc HQ, so the version in
ghc/utils/hsc2hs is ghc-only, and no longer
Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > We want ideally a simple call like
> > Xtract -n "//patch[0]/name/-" -
OK, in my home directory on darcs.haskell.org, there is a new binary of
Xtract, which implements the -n flag as shown in the example above, to
squash entity references to their tex
Ian Lynagh <[EMAIL PROTECTED]> writes:
> > How about removing --xml-output and:
> > | grep '^ \* ' | head -n 1 | sed 's| \* ||'
> > (`head` just in case the detailed text has a line starting with "* ")
Note that in the textual output of 'darcs changes', inverted patches
(i.e. made with 'da
Ian Lynagh <[EMAIL PROTECTED]> wrote:
> > It would be nice if whatever generates these "patch applied" e-mails
> > wouldn't replace perfectly fine characters in the e-mail subjects
> > with the XML entity "equivalents" & gt; & apos; , etc.
>
> If someone (you?) wants to track down what's causing
Isaac Dupree <[EMAIL PROTECTED]> wrote:
> know how close GHC's stage1 code
> is to compilability with other compilers?
AFAIK, ghc's source code primarily uses only two main extensions beyond
the Haskell language - unboxed values, and pattern guards. To a large
extent, GHCi will also rely on havi
Sven Panne <[EMAIL PROTECTED]> wrote:
> * Malcolm: Could you move the polyparse repository from
> http://www.cs.york.ac.uk/fp/darcs/polyparse to
> darcs.haskell.org/packages, please? This would make things more
> consistent.
Done (although with some reluctance due to the general network slowne
Sven Panne <[EMAIL PROTECTED]> wrote:
> I am not very radical about licenses, but a lot of distros are, so the
> problem still remains: cpphs' LGPL (why the initial "L" for a
> program, BTW?)
The library package is LGPL.
The executable that uses the library is GPL.
> is incompatible with Hugs'
Sven Panne <[EMAIL PROTECTED]> wrote:
> What's even worse: I've just seen that neither Hugs nor nhc98
> implement isNaN, isInfinte, isDenormalized, isNegativeZero and
> isIEEE. :-( GHC does it via some bit-fiddling in StgPrimFloat.c, but
> it is unclear to me why the stuff from (isnan() etc.)
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Module cycles found:
> -- Cycle 1 --
> GHC.Base {-# SOURCE #-} imports GHC.Err
> Data.Either imports GHC.Base
> Data.Tuple imports GHC.Base
> ...
FWIW, hmake reports the same cycles for me:
Sven Panne <[EMAIL PROTECTED]> wrote:
> GHC/Hugs/nhc
> should fetch these tools via their darcs-all script and use it for
> bootstrapping themselves,
At least nhc98 already does this. :-)
> but they should *not* install these tools
> along with the compiler/interpreter in question.
Well, per
Sven Panne <[EMAIL PROTECTED]> wrote:
> 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?
No deep reason, just historical. cpphs was converted to darcs at a time
when I had no write access on darcs.haskell.org.
I have n
Sven Panne <[EMAIL PROTECTED]> wrote:
> OK, now I remember. :-) Hmmm, that seems to indicate that splitting
> off at least cpphs from the Hugs/nhc98 distributions is the right
> way. And because of a similar reasoning, hsc2hs should not be
> distributed with nhc98.
But the very reason that cpph
Sven Panne <[EMAIL PROTECTED]> wrote:
>they come with different sets of tools:
>
> GHC: hsc2hs
> Hugs: hsc2hs, cpphs
> nhc: cpphs
The only reason ghc does not ship by default with cpphs is ideological -
the latter is GPL licensed. Of course, 3rd-party pack
Sven Panne <[EMAIL PROTECTED]> wrote:
>Alas, this doesn't work well with the Haskell
>implementations yet, because they come with different sets of
>tools (in addition to runFOO):
>
> GHC: hsc2hs
> Hugs: hsc2hs, cpphs
> nhc: cpphs
nhc98 does
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> | > Here's the complete record wildcard patch.
> |
> | Just to clarify, does ghc still accept the traditional record puns
> | (in both expressions and patterns) from Haskell 1.3, and this patch
> | merely augments puns to include wildcards? Or are w
Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Here's the complete record wildcard patch.
Just to clarify, does ghc still accept the traditional record puns (in
both expressions and patterns) from Haskell 1.3, and this patch merely
augments puns to include wildcards? Or are wildcarded-puns the
46 matches
Mail list logo
