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'
Ex
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* you
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:
http://parfunk.blogspot.com/2013/08/ze
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 th
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 ver
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 see
On 16/08/2013, at 16:58 , Simon Peyton-Jones wrote:
> Ben, would you be able to look at the failing tests and see what's going on?
> There isn't much point in running them if they fail anyway -- then we aren't
> checking that the vectoriser is working.
Yes, I will when I can build the head
On 22/08/13 12:32, Austin Seipp wrote:
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
Jan
Four things:
| •Six primops are an exception to the rules above: sameMutableArray#,
| sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar#
| and sameTVar#. Their names have remained the same as before and new
| wrappers created for them lack # at the end of their name. We mad
>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
er
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 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 init
> == r
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
> 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 p
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
- Ory
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 want
Hi Ben. I get similar linker errors, also on Mac OS X.
Adding
SplitObjs = NO
DYNAMIC_BY_DEFAULT = NO
DYNAMIC_GHC_PROGRAMS = NO
to my build.mk avoids the problem for me — I haven't narrowed it further
than that.
On Thu, Aug 22, 2013 at 7:48 AM, Ben Lippmeier wrote:
>
> From a fres
| 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
You said that before, but *why* does the "naming feel better" to you?
We now have
ltFloatI# :: Float# -> Fl
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 GH
> But you don't say what you want to do with that observation.
> Could you list the API changes you want to make?
Sure, I'll write down the exact changes I'm thinking of, but probably next week
- I'll let you know that I updated the wiki page.
Janek
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 ur
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"
Do: "Jan Stolarek"
DW: ghc-devs@haskell.org, "Gabor Greif"
Wysłane: czwartek, 22 sierpień 2013 15:31:32
Temat: RE: Changes to pri
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.
G
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 task
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
sa
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 weeks
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 prob
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
|
| H
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: Geof
Sure. I considered that idea at some point but it seemed a bit to drastic.
Janek
- Oryginalna wiadomość -
Od: "Simon Peyton-Jones"
Do: "Geoffrey Mainland" , "Jan Stolarek"
DW: ghc-devs@haskell.org
Wysłane: czwartek, 22 sierpień 2013 17:57:48
Temat: RE: Changes to primops break librarie
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 demons
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 (unlik
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:
>
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] (n
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 see
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 pl
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,
While
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
---
comm
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 anyt
Great, thanks!
On Thu, Aug 22, 2013 at 2:09 PM, Simon Marlow wrote:
> 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'l
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 wrote:
> On 22/08/13 19:24, g...@git.haskell.org wrote:
>
>> Repository :
>>
On Thu, Aug 22, 2013 at 6:13 PM, Simon Peyton-Jones
wrote:
> 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
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 August
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?
http://ghc.haskell.or
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 moving
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 wrote:
> On 21/08/13 15:44, Ryan Newton wrote:
>
>> Hi all,
>>
>> Returning to the topic discussed by Simon M. and others here:
>>
>> http://project
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
___
ghc-d
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 b
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 ca
Hi!
The check for Windows in sync-all is failing (line 790). On a mingw/msys
system $OSNAME contains 'msys' and not MSWin32 or Cygwin that it is
checking for.
Niklas
2013/8/23 Simon Peyton-Jones
> I’ve got a new Windows laptop, and have being having a torrid time
> getting GHC to build on it
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 lat
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.
>
55 matches
Mail list logo