On 19/08/13 21:16, Carter Schonwald wrote:
hey all,
i'm trying to build head to test out some stuff, and i'm hitting the
following error message (http://ghc.haskell.org/trac/ghc/ticket/8143 )
compiler/stage1/build/Parser.hs:1:1:
File name does not match module name:
Saw: `Main'
On 20/08/13 12:21, Geoffrey Mainland wrote:
Would be nice to have. How about a third hook that disallows commits
that include whitespace-only changes unless *all* changes are
whitespace-only? ;)
The problem with these kind of commit-time checks is that you only find
out the problem *after*
On 21/08/13 15:44, Ryan Newton wrote:
Hi all,
Returning to the topic discussed by Simon M. and others here:
http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html
This is my attempt at a script for bootstrapping a GHC-validating VM:
On 21/08/13 16:11, Ryan Newton wrote:
Hi all,
It is not merged into master presently but I would like to propose the
three new primops that are on the atomics branch for inclusion in 7.8.
These are pretty much completely apart from everything else and don't
break any existing code.
For the
This seems acceptable IMO. The general working conventions already are to
separate whitespace and/or tab changes from a commit containing actual
content. If you ./validate cleanly, but the server rejects the push for
whitespace, adding an extra commit on top to clean up the affected files
seems
Carter is building with the new XCode, which only has Clang on OS X. This
error is a result of clang preprocessing Parser.y.pp, since it uses a
'double pass' CPP trick to pass -fcmm-sink to the stage2 compiler. I could
never fully come to understand the behavior of why this was an error, and
it
From a fresh ghc-head checkout.
On OSX Lion
$ ./sync-all get
...
== libraries/dph: running git config --local core.ignorecase true
== running git config --local core.ignorecase true
== running git submodule init
== running git submodule update
Me and Simon PJ had some discussion about modifying Hoopl. I summarized that
discussion on a wiki page:
http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup
I'd like to implement changes once there's a consensus on which changes exactly
do we want in Hoopl.
Janek
On 22/08/2013, at 22:48 , Ben Lippmeier b...@ouroborus.net wrote:
On OSX Lion
$ ./sync-all get
...
== libraries/dph: running git config --local core.ignorecase true
== running git config --local core.ignorecase true
== running git submodule
Hey Janek,
as a remark, Hoopl is the only library in GHC that defines its own *
operation, which will clash with the AMP. Hoopl's * is conceptually
just `mappend`, so if you're doing a large-scale refactoring of the
module maybe consider adding a suitable Monoid instance to replace *
with before
1. Why do you say this naming feels more consistent? Consistent with what?
Convention is that functions ending with # operate on unboxed values and return
unboxed values (usually), so to me it seemed consistent that sameTVar# returns
an unboxed value, while sameTVar does not. I raised that
Oh, and I think that using sameTVar# for primop and sameTVar for wrapper is a
good choice, even if we make transition slightly more difficult. This naming
feels better to me and I think there are few libraries that will need to
adjust. So I vote to keep these names as they are.
Janek
-
Hi Jan,
On 22/08/13 14:01, Jan Stolarek wrote:
Me and Simon PJ had some discussion about modifying Hoopl. I summarized that
discussion on a wiki page:
http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup
I'd like to implement changes once there's a consensus on which changes exactly
do we
I created a wiki page that describes the upgrade process in two easy steps:
http://ghc.haskell.org/trac/ghc/wiki/NewPrimopsInGHC7.8
I also added link to this page in the release notes. Simon, does this address
points 3 4 of your mail? Of course aside from the fact that if we change name
of
On 2013-08-22 at 15:35:29 +0200, Ben Lippmeier wrote:
[...]
I was confused because the ./sync-all script gets most of the repos
with git:// style URLs, but then switches to http:// style URLs for
sub modules.
well, that's because the 'sync-all' script is not clever enough to
rewrite the urls
You're right Simon - I didn't thought about ltFloat and that my idea of
consistency breaks there.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Jan Stolarek jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org, Gabor Greif ggr...@gmail.com
Wysłane: czwartek,
This is not a completely serious suggestions, but... If we moved the
magic GHC.Prim module to GHC.Prim.Base or something, then we could move
GHC.PrimWrappers to GHC.Prim, have it import GHC.Prim.Base, and,
assuming that we use Simon PJ's naming convention, (I think) no code
would have to change.
There's a ticket that describes the design here:
http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1
It is a fairly simple extension of the casMutVar# that has been in since
7.2. The implementation is on the `atomics` branch currently.
Feel free to add your views either here or on that
In addition to the Hooks patch (see other mail on this post) I have a few
minor updates to support GHCJS that I think are pretty uncontroversial:
1. Add a WayCustom to the Ways type in DynFlags to make custom tags. We use
this to generate native code (.o, .hi) and JS code (.js_o, .js_hi) in the
Luite, Edsko, Thomas, Nicolas
You have all variously proposed improvements to the GHC API and/or the plug-in
mechanism. I have been so swamped in the last few months that I have not had a
chance to look carefully at your proposals, nor how they relate to each other.
We are now only three
On Thu, Aug 22, 2013 at 05:01:45PM +0200, Herbert Valerio Riedel wrote:
Btw, the implementation in sync-all at
https://github.com/ghc/ghc/blob/master/sync-all#L897-L912
seems a bit confusing; the submodule init in the if ($command eq
get or $command eq pull) branch is probably never
GHC already has -fwarn-tabs; we could have -fwarn-trailing-whitespace
and turn it on by default, so that validate errors on it but you also
notice it when you're doing a build (if you're paying attention to
warnings).
Edward
Excerpts from Simon Marlow's message of Thu Aug 22 05:04:50 -0700 2013:
I have elaborated (more clearly I hope)
S
| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 22 August 2013 15:14
| To: Jan Stolarek
| Cc: ghc-devs; Simon Peyton-Jones; n...@cs.tufts.edu; d...@cs.tufts.edu;
| Edward Z. Yang
| Subject: Re: Changes in Hoopl
|
|
I think that's a pretty good idea. It's not just a hack... it makes sense even
if you ignore the issues of managing the transition.
Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell
operations.
Jan would you like to try it?
Simon
| -Original Message-
| From:
Sure. I considered that idea at some point but it seemed a bit to drastic.
Janek
- Oryginalna wiadomość -
Od: Simon Peyton-Jones simo...@microsoft.com
Do: Geoffrey Mainland mainl...@apeiron.net, Jan Stolarek
jan.stola...@p.lodz.pl
DW: ghc-devs@haskell.org
Wysłane: czwartek, 22 sierpień
Simon, you give this example:
L1: ...blah blah...
CondBranch e L1 L2
L2: blah blah
and say that (...) on the first iteration, we don't have any fact from L1. So
for backwards analysis the client really must give us a bottom element. I
think this example does not actually
Hey Ryan,
you raise some very good points.
The most important point you raise (I think) is this:
it would be very very nice to (where feasible) to add analogous machinery
to the native code gen, so that its not falling behind the llvm one quite
as much.
at least for these atomic operations
Well, what's the long term plan? Is the LLVM backend going to become the
only backend at some point?
On Thu, Aug 22, 2013 at 1:43 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
Hey Ryan,
you raise some very good points.
The most important point you raise (I think) is this:
it
All,
A while back, Nicolas Frisby compiled a small list of the currently active
branches in the GHC tree. I would like to clean up a lot of the existing
branches which are effectively dead (by deleting them.) At the same time,
it's nice to take inventory and see what's currently out there, or 'in
Simon,
While validating the changes for #8144, I noticed there were several
failures that seem like a result of your recent commits (amd64/Linux):
Unexpected failures:
. T4059 [bad stderr] (normal)
. T4850 [bad stderr] (normal)
. T5423 [bad stderr] (normal)
. T7037 [bad stderr]
Sorry! Just pushed the fix. atomicinc was also failing for me, I
assumed it was nothing to do with me. Perhaps not. I'll look into it.
Cheers,
Simon
On 22/08/13 19:35, Austin Seipp wrote:
Simon,
While validating the changes for #8144, I noticed there were several
failures that
Hi all,
I just reread this thread again. Is this one of these situations where *almost
everyone agrees, but the fix just didn't happen*?
In particular, there is still no formal relationship between versions of
the compiler and versions of the testsuite that tests it -- that seems odd!
Can we
On 20/08/13 11:55, Mateusz Kowalczyk wrote:
Trying to build HEAD I get.
inplace/bin/ghc-stage1@exeext_host@ -fPIC -dynamic -H32m -O -Werror
-Wall -H64m -O0 -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
Fixed atomicinc too.
Cheers,
Simon
On 22/08/13 19:58, Simon Marlow wrote:
Sorry! Just pushed the fix. atomicinc was also failing for me, I
assumed it was nothing to do with me. Perhaps not. I'll look into it.
Cheers,
Simon
On 22/08/13 19:35, Austin Seipp wrote:
Simon,
On 22/08/13 19:24, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/testsuite
On branch : master
Link :
http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516adf6a77f/testsuite
---
Simon and I discussed this a little today. I think there are several
legitimate points made throughout the threads here, but the problem is
clear: consistent builds are difficult, if not legitimately impossible.
That's a very big problem.
Right now, it is far too late into release cycle to do
Thanks. When I followed the ticket, it gave me the impression failure for
dynamic GHCi seems relatively reasonable, so I assumed this was acceptable.
Should've just asked!
On Thu, Aug 22, 2013 at 2:16 PM, Simon Marlow marlo...@gmail.com wrote:
On 22/08/13 19:24, g...@git.haskell.org wrote:
There was a long discussion about this a couple of months ago. It did not
reach a conclusion, but it is merely parked, not abandoned. I hope that you can
all pick it up again after the release.
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin Seipp
Sent: 22
I made the necessary adjustments.
Just some more observations...
Cardinality: merged, someone should close this:
http://ghc.haskell.org/trac/ghc/ticket/7520
but Simon wanted to look at this one:
http://ghc.haskell.org/trac/ghc/ticket/8036
Gitolyte, can this be closed?
Ok, resuming after release makes sense.
Regarding whether it reached a conclusion:
What struck me about this particular discussion was the *lack* of
disagreement (relative to say, the records debate). It seemed like no one
was arguing for the status quo and just about everyone agreed that
Oh, good question. It was Ubuntu 12.04 LTS so I just assumed it would be
too old without checking.
On Thu, Aug 22, 2013 at 3:38 AM, Simon Marlow marlo...@gmail.com wrote:
On 21/08/13 15:44, Ryan Newton wrote:
Hi all,
Returning to the topic discussed by Simon M. and others here:
Hi all,
I merged patches from #8144 into HEAD to fix nasty recompilation-checking
behavior. As a result, the interface format has changed, so you'll need to
clean your tree the next time you sync up.
--
Regards,
Austin - PGP: 4096R/0x91384671
___
Urk. The Haskell Platform claims to include Happy and Alex.
http://www.haskell.org/platform/contents.html
But 2013.2.0.0 doesn't. Is that intentional?
That's a big problem for people using HP to build GHC. I'm installing
2012.4.0.0 in the hope that it does. No, nor does 2012.2
Am I just
I've got a new Windows laptop, and have being having a torrid time getting GHC
to build on it.
1. Build falls over with
checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe
checking whether the C compiler works... no
configure: error: in `/c/code/HEAD':
configure: error: C compiler
Additionally, if you're using the latest MinGW it ships with GCC 4.7 and
fails with an error I reported and thoughtpolice replied here;
http://ghc.haskell.org/trac/ghc/ticket/7056#comment:9
There's a patch that (with some hacking, namely, fixing the missing
bracket) will bring GHC to build. It
Huh. What OS?
Could this be an issue wth your path?
Failing that
Try
cabal update ; cabal install happy ; cabal alex
Unless there's some reason you can't use cabal-install?
On Thursday, August 22, 2013, Simon Peyton-Jones wrote:
Urk. The Haskell Platform claims to include Happy and Alex.
46 matches
Mail list logo
