Hey guys,
HP Mac users have identified the non-standard Perl location in the GHC
installer creates an extra dependency on MacPorts. Perl is already on
the Mac, so we can use that path, and avoid pain.
We've tried to work around this in the Mac installers, but it would be
better to fix it upstream
Applied, thanks!
simonpj:
> Don
>
> Would you consider applying this patch to package 'binary' please?
>
> * Replaces deprecated -fglasgow-exts with the right language flags
> * Removes an UNPACK pragma that does nothing and now elicits a warning
> * Adds a type signature on a local binding
>
>
kili:
> ghc-stage2: panic! (the 'impossible' happened)
> (GHC version 6.13.20100314 for x86_64-unknown-openbsd):
> Cant do annotations without GHCi
> {59:20-31}ghc-6.13.20100314:SpecConstr.NoSpecConstr{d rap}
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
davidterei:
> On 24 February 2010 12:38, Don Stewart wrote:
> > David,
> >
> > Did you see my patch to fix the parsing of -optlo and friends?
> >
> > http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch
> >
> > Order of the flag
David,
Did you see my patch to fix the parsing of -optlo and friends?
http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch
Order of the flags appears to matter to GetOpt.
-- Don
davidterei:
> David Peixotto wrote:
>> I "deprecated" the LlvmBackend page in favor of Comment
heinlein:
> On Sun, 25 Oct 2009, Ian Lynagh wrote:
>
>> On Mon, Oct 19, 2009 at 01:35:33PM -0700, Paul Heinlein wrote:
>>>
>>> In the meantime, /srv on monk is getting quite crowded. I deleted a
>>> ton of old web logs before I brought monk into multi-user mode --
>>> reducing disk usage on /sr
David Himmelstrup has been working on nobench as well, for LHC,
http://darcs.haskell.org/~lemmih/nobench/x86_64/results.html
dmp:
> Thanks for the input. I'll take a look at the nobench suite. I might be
> interested in working to improve nobench. Is there some obvious
> improvements that
kili:
> And here's a little rant...
>
> On Tue, Sep 15, 2009 at 11:40:50PM +0200, Matthias Kilian wrote:
> > Tue Sep 15 22:42:54 CEST 2009 Matthias Kilian
> > * Follow the builtin:rts vs. builtin_rts renaming
> >
> > This unbreaks make install again.
>
> Why are some parts of the build c
marlowsd:
> Here's what's left on my list before we can put out the 6.12.1 RC:
>
> - fix the name of the binary package
> - RTS options for parallel GC (#3340, currently validating)
> - install/bindist issues (#3481, #3493) (Igloo)
> - #3486: bytestring bug
> - release notes (Igloo)
> - some
igloo:
> > In the worst case you can just bundle a copy of the binary code
> > privately since I presume it's not exposed in the ghc package's API.
>
> Well, it exposes Binary instances of various types. And AFAIK the only
> reason it isn't yet used more in GHC is concerns over performance.
>
I'
Re. locality, and affinity, and the complexity of it, have you see the
work on Chapel for programmable locality 'strategies' (in the Haskell
sense) they've done? I think there's some interesting overlaps there in
with what GHC needs to do, and how it's envisaged for Chapel on Cray
machines.
Brad
kili:
> On Mon, Mar 02, 2009 at 08:45:42PM +0100, Matthias Kilian wrote:
> > > kili stable: fail (failed stage1)
> > > tnaur PPC OSX stable 2: fail (failed stage1)
> >
> > This happens when building from ghc-6.6:
> [...]
> > Patch attached.
>
> Now that poor stupid guy named "kili" n
dias:
> >How's your defence preparation going?
>
> The defense is finished and went well. I expect to wrap up my revisions
> next week.
>
> >What's the flag to switch on the new path?
>
> For reasons that are no long obvious to me, there used to be two flags,
> but after I submit my next patch
chak:
> Current HEAD on Mac OS X 10.5.5 (Intel):
>
> /Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -optc-Wall -optc-W -
> optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-
> declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -
> optc-I. -optc-Iparallel -opt
simonmarhaskell:
> Thu Nov 6 03:36:39 PST 2008 Simon Marlow <[EMAIL PROTECTED]>
> * Run sparks in batches, instead of creating a new thread for each one
> Signficantly reduces the overhead for par, which means that we can
> make use of paralellism at a much finer granularity.
>
> M ./c
marlowsd:
> Duncan Coutts wrote:
> >I was about to bump and release the parallel library because it has
> >changed since the last release, and needs to be released with
> >ghc-6.10.1.
> >
> >I was looking at what changed and thus what the new version number
> >should be. What has changed is that pa
I'm keen to work on them. This weekend is open, so will try to get to
them then. I don't think they should be blockers for the release, but
any patches should be ok to merge back into the stable branch when done.
simonpj:
> Hi Don
>
> You generously offered to deal with these bugs. I know you ar
omega.theta:
> 2008/10/14 Ian Lynagh <[EMAIL PROTECTED]>:
> > On Mon, Oct 13, 2008 at 06:06:03PM +0100, Max Bolingbroke wrote:
> >>
> >> (http://hackage.haskell.org/trac/ghc/wiki/Annotations).
> >
> > When you say
> >{-# ANN f id 1 #-}
> > this means you are attaching (id 1) to f, right?
> >
>
So results taking today's cabal-install (with soft dependencies),
ghc 6.10, and some bumped extralibs (network, in particular),
The results are:
1 UnpackFailed
yeganesh-2.1, --> odd looking tar.gz
2 DownloadFailed
child, monadenv --> probably due to illegal
dons:
> Hey guys,
>
> Here's a summary of what builds out of the box, and what doesn't, from
> hackage, with today's amd64 GHC RC. The initial system was just GHC
> 6.10, with cabal-install from darcs (the upcoming cabal-install
> release).
My next attempt was again, 6.10, cabal-install from darc
Hey guys,
Here's a summary of what builds out of the box, and what doesn't, from
hackage, with today's amd64 GHC RC. The initial system was just GHC
6.10, with cabal-install from darcs (the upcoming cabal-install
release).
The initial package list was based on the 700 or so packages
in http://has
igloo:
> On Sat, Oct 04, 2008 at 04:00:57PM -0700, Duncan Coutts wrote:
> > On Sat, 2008-10-04 at 15:50 -0700, Don Stewart wrote:
> > > BTW, this is why we cannot ship with the old bytestring fork of 0.9
> > > bumping around in GHC.
> >
> > That and t
quot;Duncan Coutts" <[EMAIL PROTECTED]>,
"Don Stewart" <[EMAIL PROTECTED]>
Cc: "Ketil Malde" <[EMAIL PROTECTED]>
Subject: Nasty (but fixed) complexity-changing bug thingy in bytestring
Hi, gents -
Ketil and I were mystified by a huge performance discrepancy
duncan.coutts:
> On Sat, 2008-10-04 at 13:32 -0700, Duncan Coutts wrote:
> > All,
> >
> > We've got an unfortunate situation with the bytestring repo. It got
> > accidentally forked after the ghc-6.8 release and is now about 7
> > releases behind and contains many known bugs and performance proble
marlowsd:
> Don Stewart wrote:
>
> >Here's a summary of why this is non-trivial,
> >
> >* We're trying to compose packages on the users machine to yield new
> > type correct programs.
> >
> >* We're using cabal dependencies to decide wh
duncan.coutts:
> Hi,
>
> We're getting pretty close to a final ghc-6.10.1 release. We would like
> of course for the transition this time to be less painful than last
> time. We all got a lot of flack last time for having no plan in place
> and making everyone change all their .cabal files etc.
>
I'll just pipe up here that Galois is interested in any effort
put into refactoring tools.
If you ever want beta testers, or advice on real world refactoring
issues, yell.
simonpj:
> Hi Chris
>
> | If you can remember a few months ago we discused porting HaRe over to GHC,
> | and at the time I
Thanks, I've forward this to Paul.
catamorphism:
> Hi, Don/others --
>
> The bandwidth problems with darcs.haskell.org seem to have returned,
> at least for today. I'm currently getting between 10-40K/s downloading
> a HEAD tarball via wget. By comparison, I get upwards of 1 M/s
> downloading a
ied and, we think, fixed.
>
> On Wed, 2008-09-03 at 23:28 +0200, Matthias Kilian wrote:
> > On Wed, Aug 27, 2008 at 11:22:33PM -0700, Don Stewart wrote:
> > > > - darcs.haskell.org is very slow, and sometimes not reachable at all, at
> > > > least wheneve
duncan.coutts:
> On Wed, 2008-08-27 at 12:53 -0700, Don Stewart wrote:
>
> > A draft "meta package" for the platform is here,
> >
> > http://code.haskell.org/haskell-platform/haskell-platform.cabal
> >
> > This would allow us to:
> >
>
simonpj:
> Don, Duncan
>
> As you know, we're planning to produce GHC 6.10 with "batteries not
> included", relying on the Haskell Platform for the batteries. We are
> working v hard to get 6.10 ready for release-candidate on 19 Sept.
>
> But http://www.haskell.org/haskellwiki/Haskell_Platform s
t-jodias:
>Before merging a large batch of codegen changes, I wanted to make it
>available for testing. These patches do not turn on the new code generator
>(still a buggy work in progress), but there were some representation
>changes that affected the old code generator, as well as
catamorphism:
> While reading some Core code, I noticed a function whose return type
> was (# State# RealWorld #). I was curious why unboxed tuples of arity
> 1 would exist, so I dug around in the GHC sources and found that they
> are used when desugaring foreign calls, as per the comment at the
>
marlowsd:
> Following lots of useful discussion and evaluation of the available DVCSs
> out there, the GHC team have made a decision: we're going to switch to git.
Hooray, this will generate a lot of open source good will, and help make
GHC more accessible to the outside world.
Just see the comm
igloo:
> Sun Aug 3 07:11:46 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
> * Follow the move of assertError from Control.Exception to GHC.IOBase
>
> M ./compiler/prelude/PrelNames.lhs -1 +1
>
Do we have good assurances end-user behaviour isn't changing with these
patches? Control.Exception ch
igloo:
> On Mon, Jul 21, 2008 at 04:20:29PM -0700, Donald Bruce Stewart wrote:
> >
> > We should decide what the next step for the HLP is now
>
> I think the next step is to get some infrastructure up, e.g.:
>
> * A bug tracker for HLP (even if only for bugs like "library foo should
> be added
Malcolm.Wallace:
> [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
simonpj:
> | > We probably don't want "extralibs" and the HLP.
> | >
> | > Are you willing to lead on this?
> |
> | We'd want other things not in extralibs too (e.g. binary, json, feed,
> | tagsoup..)
>
> Absolutely! I wasn't suggesting that HLP = current extralibs. Rather,
> we were thinking that
simonpj:
> Don, Duncan
>
> | We need to do something about the Haskell library platform around the
> | 6.10 release too. At least a list of libraries considered the
> | an minimal platform for support by the distros.
>
> Simon and Ian and I were discussing this yesterday. Could the
> "Haskell L
duncan.coutts:
>
> On Thu, 2008-06-19 at 11:38 +0100, Simon Marlow wrote:
> > Neil Mitchell wrote:
> >
> > >> While I was away last week I jotted down a list of priorities for 6.10.
> > >> Some of these are in the bug tracker and some aren't, but I think it'd
> > >> be a good idea for us to f
david.waern:
> Hi,
>
> I'm going to add Type Families support to the Haddock HTML backend.
> What would be the best way to do it? I'm thinking it could work
> similar to how classes and instances are currently rendered, so that
> type/data/newtype instances are collected and attached to type famil
isaacdupree:
> Neil Mitchell wrote:
> >Hi
> >
> >> While I was away last week I jotted down a list of priorities for 6.10.
> >> Some of these are in the bug tracker and some aren't, but I think it'd
> >> be a good idea for us to first discuss what we really want to see
> >> happen in the 6.10 ti
marlowsd:
> Neil Mitchell wrote:
>
> >> While I was away last week I jotted down a list of priorities for 6.10.
> >> Some of these are in the bug tracker and some aren't, but I think it'd
> >> be a good idea for us to first discuss what we really want to see
> >> happen in the 6.10 time frame a
duncan.coutts:
>
> On Fri, 2008-05-23 at 21:24 +0200, Henning Thielemann wrote:
> > On Fri, 23 May 2008, Bulat Ziganshin wrote:
> >
> > > Hello Henning,
> > >
> > > Friday, May 23, 2008, 8:31:24 PM, you wrote:
> > >
> > >> would guarantee speed in every case. Or I can SPECIALISE the function,
> >
igloo:
> On Fri, May 23, 2008 at 05:54:36PM +0200, Henning Thielemann wrote:
> >
> > An even more advanced tool could show differences between two Core
> > listings.
>
> That would be great. In the meantime, from GHC 6.10,
> -ddump-simpl -dsuppress-uniques
> can be good enough to get by (it
lemming:
>
> On Fri, 23 May 2008, Henning Thielemann wrote:
>
> >An even more advanced tool could show differences between two Core
> >listings. Say I have a program which runs too slow. But if I change a
> >small detail it runs significantly faster - I want to know, how did my
> >change in th
et !x2 = x in ...x2...
>
> rather than
>
> x `seq` ...x
>
> With the latter, if you have
> let x = e
> enclosing, then substituting e for x can defeat the seq. And what humans can
> do, compilers may too!
>
> The former doesn't let you do this
simonpj:
> Fri May 16 01:51:49 PDT 2008 [EMAIL PROTECTED]
> * Improve the treatment of 'seq' (Trac #2273)
>
> Trac #2273 showed a case in which 'seq' didn't cure the space leak
> it was supposed to. This patch does two things to help
>
> a) It removes a now-redundant special case in
Mon May 12 11:24:35 PDT 2008 Don Stewart <[EMAIL PROTECTED]>
* typo in rules example. spotted by [EMAIL PROTECTED]
M ./docs/users_guide/glasgow_exts.xml -1 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080512182435-cba2c-b5ea174b016153f31d2eb3a6230c44d9d5ee4
Just a quick announcement, I've uploaded to hackage 'ghc-core' , a
wrapper over ghc for displaying the optimised core and assembly language
ghc produces from your programs.
The code is colourised by hscolour, and displayed in a pager, git-log style.
This will be useful for those who like looking
oops. fixed.
-- Don
keller:
> validate breaks on the latest head with the following warning:
>
>
> ../compiler/ghc-inplace -optc-Werror -optc-Wall -optc-W -optc-Wstrict-
> prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-
> Winline -optc-Waggregate-return -optc-I../inclu
Wed Apr 30 17:05:17 PDT 2008 Don Stewart <[EMAIL PROTECTED]>
* Missing .0 on float constant.
M ./rts/StgPrimFloat.c -1 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080501000517-cba2c-2320295b83bb30e9ebe1f457c56099b9200c8
Wed Apr 30 14:48:27 PDT 2008 Don Stewart <[EMAIL PROTECTED]>
* Replace C99 exp2f(32) call in __2Int_encodeDouble
with constant 4294967296.
exp2f is a C99-ism not availabl everywhere. Replace it
with its result. Helps building on OpenBSD>
M ./rts/StgPrimFloat.c -1 +1
V
gavelino:
>Which optimizations are presented just in the STG, not being observed in
>the Core? Are there any documentation about these optimizations?
>
>Thanks in advance.
There's very little optimisation done on the STG representation these
days -- its effectively just a normal form
catamorphism:
> On 3/25/08, Don Stewart <[EMAIL PROTECTED]> wrote:
> > The integer package is needed to build base now.
>
> Are you saying that I need to do something other than running
> darcs-all get and darcs-all pull (as well as sh boot, configure,
> make)? If so
catamorphism:
> Hi all,
>
> After pulling patches in the HEAD, I get the following while building
> the libraries (after doing ./darcs-all get, ./darcs-all pull, sh
> validate):
>
> GHC/Word.hs:577:38: Not in scope: `word2Integer'
>
> GHC/Word.hs:668:17: Not in scope: data constructor `S#'
>
>
igloo:
>
> Hi all,
>
> I've just pushed a patch to make the HEAD use editline rather than
> readline. You'll have to do a "./darcs-all get" after pulling in order
> to get the editline package.
>
> Please let me know if you hit any problems!
Good work on getting this into place guys!
-- Don
_
This is a darcs bug, it seems. Roman and Manuel also noticed it.
Roman sez:
"just do a darcs revert/ darcs pull"
and it should be fine again.
claus.reinke:
> i just tried to bring my ghc repo up to date and got:
>
> == running darcs pull -av --repodir libraries/base
> Pulling from "http:/
rl:
> I get:
>
> Actual stdout output differs from expected:
> --- ./ghci/scripts/ghci008.stdout.normalised 2008-03-10
> 10:49:59.0 +1100
> +++ ./ghci/scripts/ghci008.run.stdout.normalised 2008-03-10
> 10:49:59.0 +1100
> @@ -8,10 +8,12 @@
>...
> -- Defined in GHC.
gavelino:
>Hi,
>
>I'm using the flag -fext-core to obtain the core of a program. But,
>rewrite rules not changed this code. Are there any way to observe the
>changes cause by rewrite rules on Core language?
>
Yeah, -ddump-simpl-iterations -ddump-simpl-stats
will show each iterat
simonmarhaskell:
> Simon Peyton-Jones wrote:
> >I'm all for this, if Roman and/or Don care to help -- thank you! A
> >little readme to explain how to add a new test would be good.
>
> The testsuite is well documented on the wiki:
>
> http://hackage.haskell.org/trac/ghc/wiki/Building/RunningTest
rl:
> Simon Peyton Jones wrote:
> >Thu Feb 7 08:22:44 PST 2008 [EMAIL PROTECTED]
> > * Add a new category of "eyeball" tests
> >
> > These tests are hard to do automatically, but they record examples that
> > provoked changes to the optimiser. Each one has notes that says what
> > you
>
simonmarhaskell:
> Don Stewart wrote:
> >This is a rather fun patch (imo) that lets runghc read from stdin (into
> >a temp file) if no filename is provided.
> >
> >It means this works,
> >
> >$ cat A.hs | runghc | python2.4| ruby | runghc | python2
third-order-quine-in-three-languages.html
-- Don
New patches:
[Have runghc read from stdin, if no filename provided
Don Stewart <[EMAIL PROTECTED]>**20080206041851
As for ruby, perl, python, read from stdin (into a temp file), if no
filename provided. Let's cute meta-quines work:
duncan.coutts:
> On Tue, 2007-11-27 at 23:07 -0800, Stefan O'Rear wrote:
> > On Tue, Nov 27, 2007 at 10:23:40PM -0800, Don Stewart wrote:
> > > SO very little fix up of the Stream structures the library translated
> > > the list code into.. probably not good..
** This is a plea to release ghc 6.8.2 soon, since the SpecConstr
breakage in ghc 6.8.1 is killing the stream-fusion library **
I was handed some code by Eric Mertens used in a competition, and he
wondered if it would go any faster with some stream fusion. It is quite
list heavy, so I was hopeful.
ndmitchell:
> > What should we consider as alternatives? At least Mercurial and git, I
> > would think.
>
> git's first Windows port came out last week, and because of its
> origins is always likely to be Linux/Unix centric. If Windows is an
> important criteria this may rule out git.
We're usin
stefanor:
> On Fri, Nov 16, 2007 at 05:14:08PM -0300, Guilherme Avelino wrote:
> > Hi,
> >
> > I want to use the stg code generated by the ghc with a frontend for my
> > compiler. I´m using the flags -ddump-stg and -dppr-debug to obtain the STG
> > informations. However there are some things tha
The hsc2hs include and lib flags aren't being propagated
through to the hpc package, which fails to build in last night's
snapshot, on OpenBSD, at:
Configuring hpc-0.5.0.0...
rm -f hpc/GNUmakefile
cp Makefile.local hpc
if ifBuildable/ifBuildable hpc; then \
cd hpc && setup/
dons:
>
> The change to use remap in Linker.c has broken the mmap Linker.c
> implementation on OpenBSD, and other BSDs.
>
> #ifndef linux_HOST_OS /* mremap is a linux extension */
> #error ocAllocateSymbolExtras doesnt want USE_MMAP to be defined
> #endif
>
> Do we know why this
The change to use remap in Linker.c has broken the mmap Linker.c
implementation on OpenBSD, and other BSDs.
#ifndef linux_HOST_OS /* mremap is a linux extension */
#error ocAllocateSymbolExtras doesnt want USE_MMAP to be defined
#endif
Do we know why this was done? USE_MMAP worke
atomb:
> This patch fixes the preprocessor directives surrounding the Darwin/
> i386 portion of freeHaskellFunctionPtr, which had used the wrong
> symbol (x86_HOST_ARCH instead of i386_HOST_ARCH), causing occasional
> FFI problems. This patch is against the 6.8 branch, but will probably
> ap
duncan.coutts:
> On Wed, 2007-10-17 at 08:50 -0700, Don Stewart wrote:
>
> > > Don, what do you think? How about we keep bytestring on darcs.h.o and
> > > only move binary etc to code.h.o.
> >
> > As long as we have a head and stable branch. I don't want
duncan.coutts:
> On Tue, 2007-10-16 at 14:14 +0100, Simon Marlow wrote:
>
> > > If we're doing this we should be consistent about it. ie where the head
> > > should
> > > go, where the other branches should go. Here's Cabal's layout at the
> > > moment:
> > >
> > > Cabal HEAD: d.h.o/cabal
> > >
duncan.coutts:
> In message <[EMAIL PROTECTED]> Don Stewart
> <[EMAIL PROTECTED]> writes:
> > simonmarhaskell:
> > > Don Stewart wrote:
> > > >dons:
> > > >>simonpj:
> > > >>> In bytestring package, Data.Char8
simonmarhaskell:
> Don Stewart wrote:
> >dons:
> >>simonpj:
> >>> In bytestring package, Data.Char8 doesn't even get past the parser.
> >>> What's going on with bytestring?
> >>>
> >>Looks like the last patch added a
chak:
> Simon Peyton-Jones wrote,
> >Unpulling up to and including this patch seems to make bytestring build
> >again
> [..]
> >Fri Sep 28 23:33:56 GMT Daylight Time 2007 Duncan Coutts
> ><[EMAIL PROTECTED]>
> >
> > * Use new style syntax in .cabal file and use configurations for
> > ghc-6.4.
dons:
> simonpj:
> >In bytestring package, Data.Char8 doesn't even get past the parser.
> >What's going on with bytestring?
> >
>
> Looks like the last patch added a ',' to the end of a line, which was
> silently accepted by 6.6.1 which Duncan uses, but failed with the head
> (which I us
simonpj:
>In bytestring package, Data.Char8 doesn't even get past the parser.
>What's going on with bytestring?
>
Looks like the last patch added a ',' to the end of a line, which was
silently accepted by 6.6.1 which Duncan uses, but failed with the head
(which I use).
Patch applied.
-
Sun Sep 16 16:37:35 PDT 2007 Don Stewart <[EMAIL PROTECTED]>
* Different output expected for this test on x86_64-unknown-openbsd
A
./tests/ghc-regress/lib/Directory/getPermissions001.stdout-x86_64-unknown-openbsd
___
Cvs-ghc mailing li
Sun Sep 16 17:29:56 PDT 2007 Don Stewart <[EMAIL PROTECTED]>
* some expected outputs on openbsd
R
./tests/ghc-regress/numeric/should_run/arith003.stdout-x86_64-unknown-openbsd
R
./tests/ghc-regress/numeric/should_run/arith011.stdout-x86_64-unknown-openbsd
A ./tests/ghc-r
I've sent some patches to Ian to get the head building on amd64/openbsd,
including GHCI (not sure if that has worked previously).
make fast for the testsuite produces,
OVERALL SUMMARY for test run started at Sat Sep 15 23:23:41 PDT 2007
1941 total tests, which gave rise to
10101 test cases
82 matches
Mail list logo
