2014-07-24 16:24 GMT+02:00 Mark Lentczner :
> On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne wrote:
>> The source tarball is missing a few files for hptool:
> I'll try to catch them the next round... or pull requests on github welcome!
The structure on GitHub is a bit confusing: It took me some time
OK I have made extensive edits to
https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
You might want to check it through.
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Philip
You are right: there are some missing pieces.
* First you need to ask where your plugin's special library module "Foo" is in
the file system. This is what findImportedModule is for, and it seems quite
reasonable. However, it (or some variant) should be available to you in CoreM.
* Next
By the way, I would be happy to attempt this task, if the concept is viable.
On Thu, Jul 24, 2014 at 11:23 PM, Alan & Kim Zimmerman
wrote:
> While we are talking about fixing traversals, how about getting rid of the
> phase specific panic initialisers for placeHolderType, placeHolderKind and
>
Thanks a lot Simon.
Re top-level bindings:
I agree. There's no good time to force CAFs so they'll need to be
forced on first use.
Re newtypes:
I agree. Pattern matching on newtypes should be strict.
Implementation:
Where do I get started? I think we looked at some code together during
t
I suggest starting with the proposed improvements to
let !pat = rhs
* Remove the stuff in TcBinds that forces such things to be non-recursive and
monomorphic -- ie bangs no longer affect type checking.
* In DsBinds, add the appropriate seqs. Take a look at DsExpr.ds_val_bind and
see
On Fri, Jul 25, 2014 at 12:32 AM, Sven Panne wrote:
> The structure on GitHub is a bit confusing
As with past releases, we generally work on a branch until release.
> With 2013.2.0.0 one could
>
easily specify a --prefix in the configure step, and everything worked
> as expected.
I didn't rea
On July 24, 2014 at 23:49:10, Simon Peyton Jones (simo...@microsoft.com) wrote:
> | I think part of the confusion is coming from the fact that we don’t
> | process each module individually, resolve all of the types, and
> | serialize them to disk somewhere. Rather, when we check a module, we
> | p
Hi,
just fixing few warning issues on Solaris/x86. The changes spread over
main ghc tree and libraries/primitive and libraries/unix. I already
commited changes and pushed to my github.com's forks of
libraries/primitive and libraries/unix. The git status looks then:
$ git status
On branch ma
Indeed! Thanks for the fast help. Updating to 1.8.5 solved this issue.
Karel
On 07/20/14 08:31 PM, Edward Z. Yang wrote:
Hello Karel,
You should blow away your copy (well, preserve the patches), upgrade
your version of Git and then check out again. You've run into
this bug:
http://comm
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
11 matches
Mail list logo
