Re: Fat interface files?

[Edward Z. Yang]

Hi Ben, sorry about the late response.  It looks like you've found
https://gitlab.haskell.org/ghc/ghc/-/issues/10871 which I think
pretty comprehensively discusses the issue as it is.  Given the
elapsed time it would probably make sense to reimplement from scratch;
I don't recall this being too difficult to do.  HAs anything else
come up in the meantime?

Edward

Excerpts from Ben Gamari's message of 2020-10-20 12:06:03 -0400:
> Hi Edward,
> 
> While chatting with the ghc-ide folks recently I realized that it would
> be useful to be able to preserve Core such that compilation can be
> restarted (e.g. to be pushed down the bytecode pipeline to evaluate TH
> splices).
> 
> As I recall this is precisely what you implemented in your "fat
> interface file" work. Do you recall what the state of this work was? Do
> you have a branch with last-known-good work? Do you recall any tricky
> questions that remained outstanding?
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to use Data.Compact.Serialize

[Edward Z. Yang]

Yes this looks good to me.

It is NOT necessary to statically link libc, since the only pointers
embedded in compact regions are only ever info table pointers, e.g.,
stuff that GHC generated, not arbitrary functions in libc.

Edward

Excerpts from Christopher Done's message of 2018-12-19 10:31:28 +:
> Hi,
> 
> On the docs for Data.Compact.Serialize it says:
> 
> http://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact-Serialize.html
> > Our binary representation contains direct pointers to the info tables
> > of objects in the region. This means that the info tables of the
> > receiving process must be laid out in exactly the same way as from the
> > original process; in practice, this means using static linking, using
> > the exact same binary and turning off ASLR.
> 
> It seems to me that in order to use this module in any practical way
> (i.e. write to file from one process, and then a later run of the
> process reads it), you need to know a special way to build your binary
> which isn't fully described here. What flags, for example, should be
> passed to GHC to make this viable?
> 
> * Turning off ASLR on Linux is done by writing 0 to
>   /proc/sys/kernel/randomize_va_space, which applies to all
>   programs. That's not the most isolated way to deploy an app, but I
>   discovered that you can set this per process here:
>   https://askubuntu.com/a/507954
> * To compile GHC programs statically, use -optl-static -optl-pthread.
> 
> So in total the example would be:
> 
> $ stack build compact
> compact-0.1.0.1: download
> compact-0.1.0.1: configure
> compact-0.1.0.1: build
> compact-0.1.0.1: copy/register
> 
> Example file from docs:
> 
> $ cat main.hs
> {-# LANGUAGE TypeApplications #-}
> import System.Environment
> import Data.Compact
> import Data.Compact.Serialize
> main = do
>   arg:_ <- getArgs
>   case arg of
> "write" -> do
>   orig_c <- compact ("I want to serialize this", True)
>   writeCompact @(String, Bool) "somefile" orig_c
> "read" -> do
>   res <- unsafeReadCompact @(String, Bool) "somefile"
>   case res of
> Left err -> fail err
> Right c -> print (getCompact c)
> 
> Compiling statically:
> 
> $ stack ghc -- -optl-static -optl-pthread main.hs
> [1 of 1] Compiling Main ( main.hs, main.o )
> Linking main ...
> [...hundred more warnings like this ...]
> 
> Check that it's static:
> 
> $ ldd main
> not a dynamic executable
> 
> Write the file:
> 
> $ setarch `uname -m` -R ./main write
> 
> Read the file:
> 
> $ setarch `uname -m` -R ./main read
> ("I want to serialize this",True)
> 
> Can a GHC dev confirm that this is the proper way to do this? If so,
> I'll contribute this little example as documentation to the compact package.
> 
> Cheers
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: abi-depends field

[Edward Z. Yang]

The unexpected failures are benign; they are what you'd expect
with the fix.  I recommend accepting all of the changes.

Edward

Excerpts from Ben Gamari's message of 2018-05-21 09:09:13 -0400:
> Simon Peyton Jones via ghc-devs  writes:
> 
> > Hello, anyone?
> > At the moment I am doing a manual-diff on this batch of unexpected 
> > failures, which is jolly annoying.
> > Should we just revert some patch for now?
> >
> Sigh, this is due to 1cdc14f9c014f1a520638f7c0a01799ac6d104e6, which I
> applied as a bug-fix for 8.4.3. We likely ought to revert it if it is
> causing trouble.
> 
> Edward, do you know why GHC's testsuite might be triggering this warning?
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why does the RTS run GC right before shutting down?

[Edward Z. Yang]

I believe it's so that we can run finalizers before shutdown.

Excerpts from Ömer Sinan Ağacan's message of 2018-04-06 16:49:41 +0300:
> Hi,
> 
> I'm wondering why we run GC in this line:
> 
> https://github.com/ghc/ghc/blob/master/rts/Schedule.c#L2670
> 
> I went back in commit history using git blame and found the commit that
> introduced that line (5638488ba28), but it didn't help. Does anyone know why 
> we
> need that line?
> 
> Thanks,
> 
> Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Family instance consistency

[Edward Z. Yang]

Thanks for bringing this to my attention; I'll take a look.

Excerpts from GHCindex 3a6a4070d2..0fad1da50b 100644's message of 2017-10-27 
23:14:13 +:
> Edward
> Could you possibly take a look at #14396?   It's going to bite us soon, as 
> Alan's Trees That Grow patch lands (see the branch mentioned on the ticket).
> (In fact, Alan, I don't know how you build that branch ; I can't build it.)
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is stage-1 sufficient to run nofib

[Edward Z. Yang]

Yes, but you still need to build the libraries, so the speed up
will not be as much as you might hope.

Excerpts from Joachim Breitner's message of 2017-10-22 22:19:03 -0400:
> Hi,
> 
> I guess I could just try it, but maybe someone knows it, or knows what
> would go wrong…
> 
> If I run nofib with ghc-stage1 instead of ghc-stage2, I should get
> the same results, right? (ignoring compilation times here)
> 
> My hope is that it can speed up perf.haskell.org some more.
> 
> Greetings,
> Joachim
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can I get the internal name of a package at runtime?

[Edward Z. Yang]

Hi MarLinn,

The mangling name is "z-encoded".  It is documented here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames

Edward

Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
> Hi.
> 
> I'm experimenting with plug-ins right now. I did manage to dynamically 
> load functions at runtime. The caveat: Something (cabal? ghc?) mangles 
> the package names. For example, to load a function called "theFunction" 
> from a module called "Callee" in a package "Plugin", I had to address it 
> via the name 
> "Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure". 
> O…K. Most parts of that are clear, and thanks for making my package 
> cooler by appending a "z", but who is this Ozi guy and why is he rapping 
> about modems? Without knowing Ozi, the only way I found to get at this 
> magic string is to manually look at the actual ELF-header of the 
> compiled module. While that might be a robust way, it seems neither 
> portable nor elegant.
> 
> The "plugins" library failed too, probably for the same reason. (Or it's 
> under-documented. Probably both.) The "dynamic-loader" library does 
> something via c, therefore no.
> 
> Which brings me to the question: Is there any way for a module to get at 
> its own internal package name? Or even at the internal name of an 
> external package? If not, can I somehow recreate the magic mangling at 
> runtime? At first I thought the functions in the "Module", "Name" etc 
> modules of GHC might help – but it seems I either need an existing Name 
> (that I have no idea how to get) or I have to create one (with no idea 
> what magic mangler to call).
> 
> I'm asking this question here rather than on café as I feel that if 
> there is a solution, it's probably buried in the details of GHC.
> 
> Thanks for any suggestions,
> MarLinn
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.2.1: Ord TyCon is gone?

[Edward Z. Yang]

Sorry about being late to the conversation, but if you need a map
from Type to something, go look at TypeMap in the TrieMap module.

Edward

Excerpts from Levent Erkok's message of 2017-07-28 23:12:32 -0700:
> I'm trying to port some plugin code from GHC 8.0.2 to GHC 8.2.1; alas I'm
> getting an error suggesting that TyCon is no longer an instance of Ord:
> 
> Data/SBV/Plugin/Analyze.hs:580:33: error:
> • No instance for (Ord TyCon) arising from a use of ‘M.lookup’
>   There are instances for similar types:
> instance Ord GHC.Types.TyCon -- Defined in ‘GHC.Classes’
> • In the expression: k `M.lookup` tcMap
>   In the expression:
> case k `M.lookup` tcMap of
>   Just knd -> return knd
>   Nothing -> unknown
>   In a case alternative:
>   Just k
> -> case k `M.lookup` tcMap of
>  Just knd -> return knd
>  Nothing -> unknown
> |
> 580 |  Just k -> case k `M.lookup` tcMap of
> | ^^
> 
> I was using TyCon's as a key in a map, but that code is no longer
> compiling. I've looked through the release notes but couldn't find what the
> new mechanism is.
> 
> I'd appreciate if someone can point me in the right direction regarding how
> to use TyCon as a map key..
> 
> Thanks,
> 
> -Levent.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Reinstallable lib:ghc (was: [core libraries] Upgradeable base (smallest step forward))

[Edward Z. Yang]

Reinstalled GHC should be completely ABI compatible.  This should
actually not be difficult to achieve, since we already rely on this
in the GHC build system: we assume that ghc-stage1 generated hi files
can be compatibly read and used by ghc-stage2.

Excerpts from Joachim Breitner's message of 2017-07-24 15:04:21 -0400:
> Hi,
> 
> Am Montag, den 24.07.2017, 12:24 +0200 schrieb Herbert Valerio Riedel:
> > Also, I'd like to know if you can think of reasons why or situations
> > when the reinstalled lib:ghc wouldn't work; or other reasons why this
> > is a bad idea.
> 
> I’d am mostly worried about ABI compatibility. Will the .hi files
> written by the compiler be readable by some tool that was built with an
> upgraded ghc? Which dependencies can affect the binary format (if any)?
> 
> Or will the rebuilt ghc get its own, randomly generated “GHC version”
> (similar to a development build where the build date is part of the GHC
> version) and hence never try to interact with build artifacts created
> from the host ghc?
> 
> 
> Also, if we can `cabal install ghc-the-library`, can we also `cabal
> install ghc-the-program`, possibly at a different version? (It wouldn’t
> be normally usable without bootstrapping a RTS and base library, but it
> would be a step.)
> 
> Greetings,
> Joachim
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type class instances in scope

[Edward Z. Yang]

Hi Tom,

Here is what I was thinking when I made the suggestion:

1. Determine the transitive set of 'Module' that you need to load
2. Load each one using 'loadInterface'

So, there are a few problems with your code below:

- For external packages, it's sufficient to use 'loadInterface'
  to load a module, since this will suck the module's interface
  (and instances) into the EPS.

- But you are not looking at the EPS.  You need to use something
  like tcGetInstEnvs (that is in the wrong monad; but you can
  still look at this code) to get instances from the EPS.

- But to run 'loadInterface', you need a 'Module', not a
  'ModuleName' as in your code below.  You should read off the 'Module'
  from the dependencies and usages of the module interface:
  look at 'ModIface'.

- By looking at only imports of your local modules, you will only
  get the immediate set of imports, not the transitive closure.
  So you need to recursively do this for each 'ModIface' you load.

Edward

Excerpts from Tom Sydney Kerckhove's message of 2017-05-22 05:20:37 +0200:
> Hi Edward,
> 
> I'm sorry to have to bother you with this again, but I seem to be stuck
> with this approach.
> I think I don't really understand what 'load the interfaces' means.
> 
> Here's what I tried:
> 
> ``` Haskell
> getInstancesFromTcmodule :: GhcMonad m => TypecheckedModule -> m ()
> getInstancesFromTcmodule tmod = do
> let (tcenv, md) = tm_internals_ tmod
> let insts = tcg_insts tcenv
> printO insts
> printO $ md_insts md
> printO $ tcg_inst_env tcenv
> graph <- depanal [] True
> printO graph
> forM_ graph $ \mod_ -> do
> forM_ (ms_textual_imps mod_) $ \(_, imp) -> do
> let modname = unLoc imp
> addTarget
> (Target
>  { targetId = TargetModule modname
>  , targetAllowObjCode = True
>  , targetContents = Nothing
>  })
> loadSuccessfully $ LoadUpTo modname
> getModSummary (unLoc imp) >>= printO
> tcmod <- parseModule mod_ >>= typecheckModule >>= loadModule
> let (tcenv', md') = tm_internals_ tcmod
> printO $ tcg_insts tcenv'
> printO $ md_insts md'
> printO $ tcg_inst_env tcenv'
> ```
> 
> I just wanted to see if I could find all the relevant instances.
> 
> I do find all the instances in the current `TypecheckedModle`, but none
> of the others because at `loadSuccessfully $ loadUpTo modname`, I get an
> error saying that `Test.QuickCheck a package module`.
> I think that means that it's not locally defined, but rather part of a
> package that I'm using.
> Unfortunately that means that I don't really understand how I can load
> it to find the instances.
> 
> Would you please hint me at the next step?
> 
> Thank you for your time.
> 
> On 19-05-17 23:00:41, Tom Sydney Kerckhove wrote:
> > On 19-05-17 08:35:32, Edward Z. Yang wrote:
> > > Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200:
> > > > > But if you
> > > > > really need all instances, you will have to first arrange to load
> > > > > the interfaces of ALL modules transitively imported by your module.
> > > > 
> > > > I don't really mind the time it takes to do this, but that's annoying to
> > > > write.
> > > > 
> > > > Thank you for your help! I will look into it.
> > > 
> > > Another possibility is, if you can programatically list the types that
> > > you are interested in, you can load all of those, and then the instances
> > > for those types will be ready.
> > 
> > That's probably the most feasible approach.
> > Then I'd have to find all the types in scope, and find their interfaces.
> > 
> > I know how to get all the TyThing's in scope, so it should be easy-ish
> > to get started.
> > 
> > Thanks!
> > 
> > -- 
> > Tom Sydney Kerckhove
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type class instances in scope

[Edward Z. Yang]

Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200:
> Oh, that's annoying.
> I have a feeling there is room for an optimisation here.
> ... or maybe this was already an optimisation, I don't really know.

It's an optimization. Without, we would have to eagerly load every
interface you transitively import, even if you didn't end up using them.
That would be really slow.

> > I'm not sure exactly what you are actually trying to do.
> 
> More concretely, I need to generate a line of code for every 'Arbitrary'
> instance in scope.
> 
> Later I'll also need to use other instances but this is the first part.

OK...

> > But if you
> > really need all instances, you will have to first arrange to load
> > the interfaces of ALL modules transitively imported by your module.
> 
> I don't really mind the time it takes to do this, but that's annoying to
> write.
> 
> Thank you for your help! I will look into it.

Another possibility is, if you can programatically list the types that
you are interested in, you can load all of those, and then the instances
for those types will be ready.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type class instances in scope

[Edward Z. Yang]

Hi Tom,

The problem is that GHC lazily loads non-orphan instances, so they won't
be in the environment until you load the interface which would have
caused the instance to come into scope.

I'm not sure exactly what you are actually trying to do.  But if you
really need all instances, you will have to first arrange to load
the interfaces of ALL modules transitively imported by your module.

Edward

Excerpts from Tom Sydney Kerckhove's message of 2017-05-18 14:39:38 +0200:
> Dear GHC Devs.
> 
> I am trying to use the GHC API as part of the work that I am doing for
> my thesis. Currently I am looking for a way to find all the type class
> instances that are in scope in a given module.
> 
> Here's what I've tried:
> 
> ```
> getInstancesFromTcmodule
> :: GhcMonad m
> => TypecheckedModule -> m ()
> getInstancesFromTcmodule tmod = do
> let (tcenv, md) = tm_internals_ tmod
> let insts = tcg_insts tcenv
> getInsts >>= printO
> printO $ modInfoInstances $ tm_checked_module_info tmod
> printO insts
> printO $ md_insts md
> printO $ tcg_inst_env tcenv
> 
> printO
> :: (GhcMonad m, Outputable a)
> => a -> m ()
> printO a = showGHC a >>= (liftIO . putStrLn)
> ```
> 
> Unfortunately the output that I get is empty:
> 
> ```
> ([], [])
> []
> []
> []
> []
> ```
> 
> For the record, I ran this on the following module:
> 
> ```
> {-# LANGUAGE NoImplicitPrelude #-}
> module Ints where
> 
> import Prelude (Int, (+), (-))
> 
> f :: Int -> Int
> f x = x + 1
> 
> g :: Int -> Int
> g x = x - 1
> 
> double :: Int -> Int
> double x = x + x
> 
> zero :: Int
> zero = 0
> ```
> 
> Because I'm using '+' and '-', I definitely expect the instances of
> 'Num' to be available, but I am also expecting to find ALL the other
> instances that are available for type checking.
> 
> Is there any documentation on this matter?
> Failing that, is there anyone who is willing to help me with this
> problem?
> 
> Thank you for your time.
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.2.1 status

[Edward Z. Yang]

I updated the wiki page!

Excerpts from Ben Gamari's message of 2017-03-27 12:00:19 -0400:
> George Colpitts  writes:
> 
> > Thanks Ben. When you have a chance it would be good to update the status
> > page  wrt what we
> > will be getting, specifically will Backpack be in 8.2.1
> >
> Hi George,
> 
> I just reviewed the status page and cleaned a few things up. Otherwise it 
> looks up to date.
> 
> Regarding Backpack, all of the major pieces are currently in the tree
> and will be present in 8.2. It would be great if users could play these
> bits in -rc1; there has been a steady stream of fixes from Edward in the
> past weeks, so there is no doubt more work to do here and it would be
> great to find issues before the final release if possible.
> 
> Edward: Do you think you could add some details to the Backpack entry on
> the status page?
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

[Edward Z. Yang]

We can't add Show instances for these types because many types
below them, e.g., Type, are cyclic, and would result in infinite
output.

Perhaps we can add a new type class which a) faithfully represents
the Haskell syntax, but b) can deal with cyclic data.  I think that's
something people would like (extra compilation time not withstanding).
But it sounds annoying to do since the deriving mechanism is not going
to help you.

Edward

Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> Dear GHC Devs,
> 
> I am trying to use GHC as a library but I'm having a lot of trouble with
> understanding what everything means.
> Up to now, I have been able to figure out what to do by reading the
> sources, but it ocured to me that much of my struggles could have been
> mitigated if the relevant types had Show instances.
> 
> I am specifically talking about the types concerning type checking.
> TypecheckedModule and everything below that.
> I am aware that most of the types have an Outputable instance, but
> there are two problems with that:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> - These instances are not intended to show the internal structure of a
>   value, but rather a 'human readable' representation of a value.
> 
> My questions for you:
> 
> - Is there a reason that there are no derived 'Show' instances for most
>   types?
> - Would you accept a diff that adds these?
> 
> Thank you for your time.
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Adding a module

[Edward Z. Yang]

That's correct: if you add a module which is (indirectly) imported
by DynFlags, you have to tell ghc.mk about it so that the Windows
DLL splitting hack continues to work.

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2017-03-16 17:49:43 
+:
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But 
> also ghc.mk? Otherwise I get hits
> 
> 
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But 
> also ghc.mk? Otherwise I get hits
> /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
> 
> Reachable modules from DynFlags out of date
> 
> Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
> 
> Extra modules: CoreOpt
> 
> make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
> 
> make[1]: *** Waiting for unfinished jobs
> 
> make: *** [all] Error 2
> 
> 
> Is it necessary to have two places to extend?
> 
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is there a way to avoid time limit when using travis?

[Edward Z. Yang]

Even with a paid plan, you only have 120 min to run your build.
That might be enough in your case but in Cabal's Travis project
I've started playing tricks where I upload the build products
somewhere, and then redownload them in a new job before running tests.

Edward

Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900:
> Dear devs,
> 
> Is there a way to avoid time limit when using travis?
> 
> I started using travis [1]. It is very convenient :)
> But timeout occurs [2].
> The log messages are as follows:
> 
> => InstEqContext2(normal) 1806 of 5700 [0, 0, 0]
> => InstEqContext3(normal) 1807 of 5700 [0, 0, 0]
> => InstContextNorm(normal) 1808 of 5700 [0, 0, 0]
> The job exceeded the maximum time limit for jobs, and has been
> terminated.
> 
> How do you avoid this?
> Paid plan or something?
> 
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis
> [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055
> 
> Regards,
> Takenobu
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC API 7.10 -> 8.0.1 (unusable due to missing or recursive dependencies)

[Edward Z. Yang]

Hi A.M.,

It's very possible that the list in DynFlags are accumulated in
reverse order to the flags that were provided.  The manual is
just talking about user provided flags.

You may also be interested in
https://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#frontend-plugins

Edward

Excerpts from A.M.'s message of 2017-01-07 10:54:56 -0500:
> On 01/06/2017 10:37 PM, Edward Z. Yang wrote:
> > Hello A.M.,
> > 
> > In 8.0.1 package databases must be specified in the correct order,
> > whereas in 7.10 they could be done in any order. This problem
> > was fixed in 8.0.2, give it a try.
> 
> Thanks for the tip, Edward. That was it!
> 
> Following https://ghc.haskell.org/trac/ghc/ticket/12485 to
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html#package-databases,
> I read:
> 
> "By default, the stack contains just the global and the user’s package
> databases, in that order."
> 
> However, the order that works for me is:
> 
> extraPkgConfs = const (localPkgPaths ++ [GlobalPkgConf])
> 
> so is the description flipped or is the stack head at the end of the
> list? In any case, it's rather confusing, though I recognize that the
> above sentence is not referring to the GHC API in particular.
> 
> I now see that the wrong ordering caused me to be unable to load *any*
> packages from my sandbox.
> 
> Thanks for the fix!
> 
> Cheers,
> M
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Edward Z. Yang]

Excerpts from Matthew Pickering's message of 2017-01-03 23:32:42 +:
> The version field is not very useful as there are only two active
> branches at once. Instead we want a project which marks tickets which
> apply to the 8.0.2 branch for example. Tickets which refer to ancient
> versions of GHC should be closed if they can't be reproduced with
> HEAD. It is also not used very often, only updated on about 600
> tickets.

Echoing Richard's comment, it's a helpful reminder to the reporter
to say what version of GHC the bug was on.  If it's old, the first
thing to do is check if it still fails in HEAD.

> I'm also skeptical about how useful the component field is. I've never
> personally used it and it is not accurate for the majority of tickets.
> If someone disagrees then please say but it is really not used very
> much.

I think that there is a substantial subset of tickets that have a good
"component" characterization.  I have historically found "Runtime
system", "Linker", "Build system", "Profiling" and a number of others
very useful.  Yes, a lot of tickets get dumped in "Compiler", but many
have very good categorization!

> 2. This is a legitimate point. I will say in response that the
> majority of triaging is done by those who regularly use the bug
> tracker. These people will know the correct tags to use. There are
> occasionally people who submit tickets and ask questions about what to
> fill in these fields or fill them in incorrectly. Removing them for a
> uniform system is advantageous in my opinion.

I am a "regular user" of Cabal's GitHub bug tracker, and I find it
difficult to remember to apply all of the tags that I'm "supposed" to
for any given ticket.  It got better when I reorged all the tags
to give them a prefix for the "category" they were in, but I still
have to scroll through the list that contains ALL THE TAGS when
really I just want to select one per category.  For example, priority
in GH is a complete lost cause because none of the display mechanisms
take priority into account.

Another benefit of tags by category is in tabular views, you can ask
to group things by category, or priority, etc.  Tag based systems rarely
have this kind of UI.

> I agree with you about the default layout. I would also like a more
> compact view but I feel this style is the prevailing modern web dev
> trend.

Well, this is something we can fix with a little CSS :)

Edward

> Thanks for your comments.
> 
> Matt
> 
> On Tue, Jan 3, 2017 at 5:21 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> > Hi Matthew,
> >
> > Thanks for doing the work for setting up this prototype, it definitely
> > helps in making an informed decision about the switch.
> >
> > Some comments:
> >
> > 1. In your original email, you stated that many of the custom fields
> >were going to be replaced with Phabricator "projects" (their
> >equivalent of tags).  First, I noticed a little trouble where
> >some fields were just completely lost. Compare:
> >
> > http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095
> > https://ghc.haskell.org/trac/ghc/ticket/8095
> >
> >AFAICT, we lost version the bug was found in,
> >architecture, component.  I hope we can keep these details
> >in the real migration!  Also related tickets doesn't seem
> >to be working (see example above); migration problem?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trac to Phabricator (Maniphest) migration prototype

[Edward Z. Yang]

Hi Matthew,

Thanks for doing the work for setting up this prototype, it definitely
helps in making an informed decision about the switch.

Some comments:

1. In your original email, you stated that many of the custom fields
   were going to be replaced with Phabricator "projects" (their
   equivalent of tags).  First, I noticed a little trouble where
   some fields were just completely lost. Compare:

http://ec2-52-214-147-146.eu-west-1.compute.amazonaws.com/T8095
https://ghc.haskell.org/trac/ghc/ticket/8095

   AFAICT, we lost version the bug was found in,
   architecture, component.  I hope we can keep these details
   in the real migration!  Also related tickets doesn't seem
   to be working (see example above); migration problem?

2. Following on to this, I am actually a fan of Trac having a
   separate field per logically distinct field, rather than GitHub
   style "EVERYTHING IS A TAG".  The primary reason for this
   is during bug submission: I find that if everything is a tag,
   they all show up in a giant list of ALL THE TAGS, and I never
   bother adding all the fields I should.  Whereas in Trac, every
   relevant field is in front of me, and I remember to toggle things
   as necessary.  Sometimes they don't matter, but sometimes
   they do (e.g., arch!) and I think *seeing* every field you might
   want to field in is helpful for remembering, at least for me
   as an expert user.

3. One thing that is bad about Trac is that its built-in search
   bar is useless.  So here, Phabricator is an improvement.  However,
   it seems like Phabricator search is less good than Trac's
   advanced ticket query.  Here's what I like about Trac's version:

- It sorts by priority, and then by ticket number. There is
  a long tail of bugs that I don't really care about, and
  this sorting helps me ignore the low priority ones which
  I don't care about.  I find sort-by-relevance *particularly
  frustrating* because I find that these search engines don't
  have particularly good relevance metrics, and the chronology
  hint of sorting by ticket number is much better.
  Phabricator doesn't offer any control over search.

- Trac search devotes only one row per ticket, so it is
  really easy to scan through and find the one I'm looking for.
  Both GH and Phabricator insist on putting a useless second
  row, fluffing up the results and making it difficult to
  scan.

- It searches tickets only. In Phabricator I always have to
  type in "Maniphest Task" into document types to get into the
  bug finding view. Maybe there's a way to setup default search
  for something like this?

Thanks,
Edward

Excerpts from Matthew Pickering's message of 2016-12-21 10:12:56 +:
> Dear devs,
> 
> I have completed writing a migration which moves tickets from trac to
> phabricator. The conversion is essentially lossless. The trac
> transaction history is replayed which means all events are transferred
> with their original authors and timestamps. I welcome comments on the
> work I have done so far, especially bugs as I have definitely not
> looked at all 12000 tickets.
> 
> http://ec2-52-213-249-242.eu-west-1.compute.amazonaws.com
> 
> All the user accounts are automatically generated. If you want to see
> the tracker from your perspective then send me an email or ping me on
> IRC and I can set the password of the relevant account.
> 
> NOTE: This is not a decision, the existence of this prototype is to
> show that the migration is feasible in a satisfactory way and to
> remove hypothetical arguments from the discussion.
> 
> I must also thank Dan Palmer and Herbert who helped me along the way.
> Dan was responsible for the first implementation and setting up much
> of the infrastructure at the Haskell Exchange hackathon in October. We
> extensively used the API bindings which Herbert had been working on.
> 
> Further information below!
> 
> Matt
> 
> =
> 
> Reasons
> ==
> 
> Why this change? The main argument is consolidation. Having many
> different services is confusing for new and old contributors.
> Phabricator has proved effective as a code review tool. It is modern
> and actively developed with a powerful feature set which we currently
> only use a small fraction of.
> 
> Trac is showing signs of its age. It is old and slow, users regularly
> lose comments through accidently refreshing their browser. Further to
> this, the integration with other services is quite poor. Commits do
> not close tickets which mention them and the only link to commits is a
> comment. Querying the tickets is also quite difficult, I usually
> resort to using google search or my emails to find the relevant
> ticket.
> 
> 
> Why is Phabricator better?
> 
> 
> Through learning more about Phabricator, there are many small things
> that I think it does better which will improve the 

Re: I have Aphronted Phab

[Edward Z. Yang]

Hi Richard,

The last time this happened to me, it was because I was accessing
Phabricator on http:// rather than https://. Tkae a look.

Edward

Excerpts from Richard Eisenberg's message of 2016-12-23 21:46:10 -0500:
> Hi Austin, Ben,
> 
> In trying to write a comment on Phab, I got this:
> 
> Unhandled Exception ("AphrontCSRFException")
> You are trying to save some data to Phabricator, but the request your browser 
> made included an incorrect token. Reload the page and try again. You may need 
> to clear your cookies.
> 
> This was a Web request.
> This request had an invalid CSRF token.
> I followed the suggestions, and even tried a different browser (one I never 
> use), to no avail. This still may very well be my fault, but it seems 
> something is awry somewhere. Do you have any help you can offer?
> 
> Thanks!
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Confused about the sub-modules

[Edward Z. Yang]

I *just* pushed a Cabal submodule update, so Erik probably hadn't
gotten it.

Excerpts from Ben Gamari's message of 2016-12-21 14:14:37 -0500:
> Erik de Castro Lopo <mle...@mega-nerd.com> writes:
> 
> > Edward Z. Yang wrote:
> >
> >> Not any more. The commit just has to exist in the remote repo (that's
> >> what the lint checks.)
> >
> > So this is where I am running into trouble. Everything for process 
> > and directory is fine, but for Cabal and containers, the git repo
> > on git.haskell.org is missing the commits I need.
> >
> Hmm, what in particular is missing? Cabal seems up-to-date (both
> git.haskell.org:packages/Cabal and github.com/haskell/Cabal master
> branches point to 09865f60caa55a7b02880f2a779c9dd8e1be5ac0). As does
> containers (both point to 71c64747120c3cd1b91f06731167009b0e5b2454).
> 
> In general all of this should be reasonably automatic. However, when
> upstreams push non-fast-forward updates to their branches a bit of
> manual intervention is necessary; if in doubt just ask as you've done
> here.
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Confused about the sub-modules

[Edward Z. Yang]

Not any more. The commit just has to exist in the remote repo (that's
what the lint checks.)

Excerpts from Alan & Kim Zimmerman's message of 2016-12-21 09:20:15 +0200:
> For the utils/haddock submodule there is a ghc-head branch, and the commit
> should be on that before pushing to GHC master with a submodule update.
> 
> I do not know if that convention is followed on any of the other libraries.
> 
> Alan
> 
> On Wed, Dec 21, 2016 at 8:48 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> 
> > Once the commit is upstream, I just checkout a newer commit from
> > master and then commit it as a submodule update. Maybe it's
> > wrong but no one has ever told me otherwise.  Around release
> > time the release manager makes sure all the libraries correspond to
> > actual releases.
> >
> > Edward
> >
> > Excerpts from Erik de Castro Lopo's message of 2016-12-21 17:33:36 +1100:
> > > Hi all,
> > >
> > > I'm a bit confused about how the GHC dev tree handles submodules like
> > > libraries/Cabal, libraries/process, libraries/directory and
> > > libraries/containers.
> > >
> > > All of these libraries/submodules seem to have their own github projects
> > > where people can submit PRs, but once the commits have been made there,
> > > what is the process to get submodules updated in the GHC tree?
> > >
> > > Any light people can shed on this process would be appreciated.
> > >
> > > Erik
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Confused about the sub-modules

[Edward Z. Yang]

Once the commit is upstream, I just checkout a newer commit from
master and then commit it as a submodule update. Maybe it's
wrong but no one has ever told me otherwise.  Around release
time the release manager makes sure all the libraries correspond to
actual releases.

Edward

Excerpts from Erik de Castro Lopo's message of 2016-12-21 17:33:36 +1100:
> Hi all,
> 
> I'm a bit confused about how the GHC dev tree handles submodules like
> libraries/Cabal, libraries/process, libraries/directory and
> libraries/containers.
> 
> All of these libraries/submodules seem to have their own github projects
> where people can submit PRs, but once the commits have been made there,
> what is the process to get submodules updated in the GHC tree?
> 
> Any light people can shed on this process would be appreciated.
> 
> Erik
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: haskell.org not sending intermediate certs

[Edward Z. Yang]

curl is working now, and the SSL checker is all green. Thanks!

Edward

Excerpts from davean's message of 2016-12-18 17:49:43 -0500:
> admin@h.o is the correct list though I expect all of us are on ghc-devs@h.o
> also :)
> I at least read admin with a far higher priority though.
> 
> We've gone and added the full chain for clients that don't self-acquire
> them and also tightened up the allowed cipher list.
> Please let us know if you encounter any further issues.
> 
> -davean
> 
> On Sun, Dec 18, 2016 at 2:12 PM, Erik Hesselink <hessel...@gmail.com> wrote:
> 
> > I noticed this as well, since my work VPN does fairly strict certificate
> > checking and didn't allow me to connect to any haskell.org urls due to
> > this.
> >
> > I'm not sure about the right list, I've added ad...@haskell.org to the CC
> > list.
> >
> > Erik
> >
> > On 18 December 2016 at 07:12, Edward Z. Yang <ezy...@mit.edu> wrote:
> >
> >> See: https://www.sslshopper.com/ssl-checker.html#hostname=www.haskell.org
> >>
> >> This is causing curl to fail to download it:
> >>
> >> ezyang@sabre:~/Downloads$ curl  https://www.haskell.org/cabal/
> >> release/cabal-install-1.24.0.0/cabal-install-1.24.0.0-x86_64
> >> -unknown-mingw32.zip
> >> curl: (60) server certificate verification failed. CAfile:
> >> /etc/ssl/certs/ca-certificates.crt CRLfile: none
> >> More details here: http://curl.haxx.se/docs/sslcerts.html
> >>
> >> curl performs SSL certificate verification by default, using a "bundle"
> >>  of Certificate Authority (CA) public keys (CA certs). If the default
> >>  bundle file isn't adequate, you can specify an alternate file
> >>  using the --cacert option.
> >> If this HTTPS server uses a certificate signed by a CA represented in
> >>  the bundle, the certificate verification probably failed due to a
> >>  problem with the certificate (it might be expired, or the name might
> >>  not match the domain name in the URL).
> >> If you'd like to turn off curl's verification of the certificate, use
> >>  the -k (or --insecure) option.
> >>
> >> Apologies if this is the wrong list.
> >>
> >> Thanks,
> >> Edward
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Patch for time repository

[Edward Z. Yang]

I resolved this by just bumping our submodule to latest HEAD
in the repo (which was taken by upstream.)

Edward

Excerpts from Edward Z. Yang's message of 2016-12-17 21:45:20 -0800:
> Hi all,
> 
> I'd like to push the following patch (see bottom of email)
> to GHC's time repository, but I do not seem to have permissions.
> Upstream has already taken the fix but the version we currently
> have in the repo is quite a bit older than upstream.
> 
> Can someone do it for me / give me bits? Thanks.
> 
> Edward
> 
> commit 44c23839f964592946c889626f8acbd1f4f72e55
> Author: Edward Z. Yang <ezy...@cs.stanford.edu>
> Date:   Sat Dec 17 20:05:11 2016 -0800
> 
> Remove useless internal library version bounds.
> 
> These bounds never do anything, and in Cabal HEAD cause
> errors which cause GHC's build system to choke.
> 
> Signed-off-by: Edward Z. Yang <ezy...@cs.stanford.edu>
> 
> diff --git a/time.cabal b/time.cabal
> index 4a6eb02..28f2c21 100644
> --- a/time.cabal
> +++ b/time.cabal
> @@ -100,7 +100,7 @@ test-suite ShowDefaultTZAbbreviations
>  ghc-options: -Wall -fwarn-tabs
>  build-depends:
>  base,
> -time == 1.6.0.1
> +time
>  main-is: ShowDefaultTZAbbreviations.hs
>  
>  test-suite tests
> @@ -122,7 +122,7 @@ test-suite tests
>  build-depends:
>  base,
>  deepseq,
> -time == 1.6.0.1,
> +time,
>  QuickCheck >= 2.5.1,
>  test-framework >= 0.8,
>  test-framework-quickcheck2 >= 0.3,
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

haskell.org not sending intermediate certs

[Edward Z. Yang]

See: https://www.sslshopper.com/ssl-checker.html#hostname=www.haskell.org

This is causing curl to fail to download it:

ezyang@sabre:~/Downloads$ curl  
https://www.haskell.org/cabal/release/cabal-install-1.24.0.0/cabal-install-1.24.0.0-x86_64-unknown-mingw32.zip
curl: (60) server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Apologies if this is the wrong list.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Patch for time repository

[Edward Z. Yang]

Hi all,

I'd like to push the following patch (see bottom of email)
to GHC's time repository, but I do not seem to have permissions.
Upstream has already taken the fix but the version we currently
have in the repo is quite a bit older than upstream.

Can someone do it for me / give me bits? Thanks.

Edward

commit 44c23839f964592946c889626f8acbd1f4f72e55
Author: Edward Z. Yang <ezy...@cs.stanford.edu>
Date:   Sat Dec 17 20:05:11 2016 -0800

Remove useless internal library version bounds.

These bounds never do anything, and in Cabal HEAD cause
errors which cause GHC's build system to choke.

Signed-off-by: Edward Z. Yang <ezy...@cs.stanford.edu>

diff --git a/time.cabal b/time.cabal
index 4a6eb02..28f2c21 100644
--- a/time.cabal
+++ b/time.cabal
@@ -100,7 +100,7 @@ test-suite ShowDefaultTZAbbreviations
 ghc-options: -Wall -fwarn-tabs
 build-depends:
 base,
-time == 1.6.0.1
+time
 main-is: ShowDefaultTZAbbreviations.hs
 
 test-suite tests
@@ -122,7 +122,7 @@ test-suite tests
 build-depends:
 base,
 deepseq,
-time == 1.6.0.1,
+time,
 QuickCheck >= 2.5.1,
 test-framework >= 0.8,
 test-framework-quickcheck2 >= 0.3,
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Edward Z. Yang]

Excerpts from Shea Levy's message of 2016-11-25 10:30:25 -0500:
> > The right thing is to have a clean separation between runtime
> > imports and compile-time imports.  Perhaps we just annotate some imports to
> > say they aren't needed at compile-time for running the TH code.  but then
> > we also need compile-time vs. runtime build-depends in our .cabal files,
> > and so on.
> 
> Yes, I was just looking into this yesterday. We already have something
> similar for plugins, though of course the TH story is much more
> involved (in part because GHC has to compile haskell code, not just load
> and run a pre-existing object file).

Actually, we don't really have this for plugins either. It is true that
you can load a plugin independently of the imports of the module it is
compiling, and that you can setup an independent package database for
plugins, but the interfaces of the plugin are still all dumped in
the same interface database that GHC uses for compile-time interfaces
as well.  It's delicate and has caused bugs before 
(https://ghc.haskell.org/trac/ghc/ticket/10420)

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Making (useful subsets of) bytecode portable between targets

[Edward Z. Yang]

Excerpts from Ben Gamari's message of 2016-11-21 16:06:14 -0500:
> > 3. Teach cabal to compile dependencies and modules for the build and
> >target when cross-compiling and TH is used
> 
> You'll need to speak with the Cabal folks about this. However, it's
> probably safe to ignore this for now; there's a lot of work to done
> before you'll be in a position to start thinking about this.

Some related work that has been done for just compiling Setup scripts
with the host system: https://github.com/haskell/cabal/issues/1493
and https://github.com/haskell/cabal/issues/4047 is where we have
been going with it.

John Ericson is in charge of the effort, I've CC'ed him to this list.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Tool for minimizing examples

[Edward Z. Yang]

I asked about this on Twitter a while back
 and John
Regehr suggested that we give C-reduce a try.  I have not
yet but if you try it out I'm quite curious to see what
happens.

Edward

Excerpts from Eric Crockett's message of 2016-10-26 00:27:11 -0400:
> Devs: as I'm sure you know, the hardest part of reporting a GHC bug is
> finding a minimal example that triggers the bug. When I initially trigger a
> bug in my large code base, my workflow is something like:
> 
>  1. write a driver that triggers the bug
>  2. do manual dead code elimination by removing unused files and functions
>  3. "human required" step to figure out what can be trimmed to further
> minimize
>  4. go to step 2 until example is simple enouogh
> 
> Since I work on a large library (>60 modules) and also report a fair number
> of bugs, I spend a nontrivial amount of time on step 2, which is completely
> mechanical. It would be nice to have a tool that can help out.
> Specifically, something that takes a "driver" file, and produces a copy of
> the code contents to a new directory sans unimported files, and unused
> functions from imported files.
> 
> Ideally, this tool would make a "closed universe" assumption so that
> exported functions can also be eliminated as dead, if they are never used
> elsewhere. A bonus feature would be to remove unused imports, and even
> unused build-depends from the cabal file.
> 
> Are there any tools out there that can do any portion of this process for
> me? Perhaps it is possible to output contents after the compiler does a DCE
> pass?
> 
> Regards,
> Eric Crockett
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Edward Z. Yang]

There is another options: names from local modules (same package) shadow
names from external packages.  But it is not obvious to me that this is
a good idea.

Edward

Excerpts from Herbert Valerio Riedel's message of 2016-10-04 13:50:58 +0200:
> Hi,
> 
> On 2016-10-04 at 13:12:54 +0200, Yuras Shumovich wrote:
> > On Tue, 2016-10-04 at 04:48 -0400, Edward Kmett wrote:
> >
> >> It makes additions of names to libraries far less brittle. You can
> >> add a
> >> new export with a mere minor version bump, and many of the situations
> >> where
> >> that causes breakage can be fixed by this simple rule change.
> >
> > It would be true only if we also allow imports to shadow each other.
> > Otherwise there will be a big chance for name clash yet.
> >
> > Can we generalize the proposal such that subsequent imports shadow
> > preceding ones?
> 
> IMO, that would be lead to fragile situations with hard to detect/debug
> problems unless you take warnings serious.
> 
> With the original proposal, the semantics of your code doesn't change if
> a library starts exposing a name it didn't before. There is a clear
> priority of what shadows what.
> 
> However, when we allow the ordering of import statements to affect
> shadowing, it gets more brittle and surprising imho:
> 
> For one, we have tooling which happily reorders/reformats import
> statements which would need to be made aware that the reordering
> symmetry has been broken.
> 
> Moreover, now we get into the situation that if in
> 
>   import Foo -- exports performCreditCardTransaction
>   import Bar
> 
>   main = do
>  -- ..
>  performCreditCardTransaction ccNumber
>  --
> 
> 'Bar' suddenly starts exporting performCreditCardTransaction as well
> (and doing something sinister with the ccNumber before handing it over
> to the real performCreditCardTransaction...), it can effectively change
> the semantics of a program and this would merely emit a warning which
> imho rather deserves to be a hard error.
> 
> However, iirc there is a different idea to address this without breaking
> reordering-symmetry, e.g. by allowing explicitly enumerated names as in
> 
>   import Foo (performCreditCardTransaction)
>   import Bar
> 
> to shadow imports from other modules which didn't explicitly name the
> same import; effectively introducing a higher-priority scope for names
> imported explicitly.
> 
> > In that case you may e.g. list local modules after libraries' modules,
> > and be sure new identifies in libraries will not clash with local
> > ones. Obviously shadowing should be a warning still.
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Allow top-level shadowing for imported names?

[Edward Z. Yang]

I don't see why not. (But then again I wasn't around for Haskell98!)

Edward

Excerpts from Herbert Valerio Riedel's message of 2016-10-03 10:29:06 +0200:
> Hi *,
> 
> I seem to recall this was already suggested in the past, but I can't
> seem to find it in the archives. For simplicity I'll restate the idea:
> 
> 
> foo :: Int -> Int -> (Int,Int)
> foo x y = (bar x, bar y)
>   where
> bar x = x+x
> 
> results merely in a name-shadowing warning (for -Wall):
> 
> foo.hs:4:9: warning: [-Wname-shadowing]
> This binding for ‘x’ shadows the existing binding
>   bound at foo.hs:2:5
> 
> 
> However,
> 
> import Data.Monoid
>  
> (<>) :: String -> String -> String
> (<>) = (++)
>  
> main :: IO ()
> main = putStrLn ("Hi" <> "There")
> 
> doesn't allow to shadow (<>), but rather complains about ambiguity:
> 
> bar.hs:7:23: error:
> Ambiguous occurrence ‘<>’
> It could refer to either ‘Data.Monoid.<>’,
>  imported from ‘Data.Monoid’ at bar.hs:1:1-18
>   or ‘Main.<>’, defined at bar.hs:4:1
> 
> 
> This is of course in line with the Haskell Report, which says in
> https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1010005.3
> 
> | The entities exported by a module may be brought into scope in another
> | module with an import declaration at the beginning of the module. The
> | import declaration names the module to be imported and optionally
> | specifies the entities to be imported. A single module may be imported
> | by more than one import declaration. Imported names serve as top level
> | declarations: they scope over the entire body of the module but may be
> | shadowed by *local non-top-level bindings.*
> 
> 
> However, why don't we allow this to be relaxed via a new language
> extensions, to allow top-level bindings to shadow imported names (and
> of course emit a warning)?
> 
> Unless I'm missing something, this would help to keep existing and
> working code compiling if new versions of libraries start exporting new
> symbols (which happen to clash with local top-level defs), rather than
> resulting in a fatal name-clash; and have no major downsides.
> 
> If this sounds like a good idea, I'll happily promote this into a proper
> proposal over at https://github.com/ghc-proposals/ghc-proposals; I
> mostly wanted to get early feedback here (and possibly find out if and
> where this was proposed before), before investing more time turning
> this into a fully fledged GHC proposal.
> 
> Cheers,
>   HVR
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Getting rid of -XImpredicativeTypes

[Edward Z. Yang]

A ghc-proposals is a good way to solicit feedback and publicize more
widely.  At least a proposal is worth it (and I am in favor of removing
ImpredicativeTypes, FWIW).

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-25 18:05:38 
+:
> Friends
> 
> GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to 
> support impredicative polymorphism.  But it is vestigial if it works, 
> it's really a fluke.  We don't really have a systematic story here at all.
> 
> I propose, therefore, to remove it entirely.  That is, if you use 
> -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete 
> no-op) and you should remove it.
> 
> Before I pull the trigger, does anyone think they are using it in a 
> mission-critical way?
> 
> Now that we have Visible Type Application there is a workaround: if you want 
> to call a polymorphic function at a polymorphic type, you can explicitly 
> apply it to that type.  For example:
> 
> 
> {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
> 
> module Vta where
> 
>   f x = id @(forall a. a->a) id @Int x
> 
> You can also leave out the @Int part of course.
> 
> Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). 
>Is that sensible?  Or should we allow it regardless?   I rather think the 
> latter... if you have Visible Type Application (i.e. -XTypeApplications) then 
> applying to a polytype is nothing special.   So I propose to lift that 
> restriction.
> 
> I should go through the GHC Proposals Process for this, but I'm on a plane, 
> so I'm going to at least start with an email.
> 
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: building ghc-8.0 branch on Win10

[Edward Z. Yang]

This is a dumb build system problem.  One way to hack around
it is edit libraries/Cabal/Cabal/Cabal.cabal and remove
the spaces before 1.25.0.0.

I thought I fixed this in HEAD so there may be a patch you
could backport too.

Edward

Excerpts from Josh Berman's message of 2016-09-19 15:39:15 +0300:
> Sorry to pester - now 'make' is failing:
> 
> ===--- building phase 0
> > make --no-print-directory -f ghc.mk phase=0 phase_0_builds
> > "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \
> >-optc-Wall -optc-Werror -optc-fno-stack-protector \
> > \
> >-hide-all-packages \
> >-package base -package array -package time -package containers
> > -package bytestring -package deepseq -package process -package pretty
> > -package directory -package Win32 \
> >--make utils/ghc-cabal/Main.hs -o
> > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \
> >-no-user-package-db \
> >-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
> >-DCABAL_VERSION=  1,25,0,0 \
> >-DMIN_VERSION_binary_0_8_0 \
> >-DBOOTSTRAPPING \
> >-optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \
> >-odir  bootstrapping \
> >-hidir bootstrapping \
> >-ilibraries/Cabal/Cabal \
> >-ilibraries/binary/src -DGENERICS \
> >-ilibraries/filepath \
> >-ilibraries/hpc \
> > target `1,25,0,0' is not a module name or a source file
> > ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory
> > make[1]: *** [utils/ghc-cabal/ghc.mk:48:
> > utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
> > make: *** [Makefile:130: all] Error 2
> 
> 
> I updated my cabal to be 1.25, thinking that might be the issue, but now I
> realize that was probably irrelevant.
> 
> Any further ideas? (This time, I searched trac before emailing... but
> didn't find anything).
> 
> Thanks,
> - Josh
> 
> On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman  wrote:
> 
> > Yeah, I just saw that bug report, too. Thanks.
> >
> > On Mon, Sep 19, 2016 at 2:37 PM, Phyx  wrote:
> >
> >> Hi Josh,
> >>
> >> Yes you are hitting a bug in configure that was exposed due to changes in
> >> msys.
> >>
> >> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g
> >> hc/ticket/12487
> >>
> >> Tamar
> >>
> >> On Mon, Sep 19, 2016, 12:24 Josh Berman  wrote:
> >>
> >>> Hi,
> >>>
> >>> I was able to build the "master" branch of ghc 8.0.1 using the
> >>> instructions found here:
> >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> >>>
> >>> When I switched to the "ghc-8.0" branch, though, I get the following
> >>> error:
> >>>
> >>> configure: error:
>  You've selected:
>    BUILD:  x86_64-w64-mingw32   (the architecture we're building on)
>    HOST:   x86_64-unknown-mingw32(the architecture the compiler
>  we're building will execute on)
>    TARGET: x86_64-unknown-mingw32  (the architecture the compiler we're
>  building will produce code for)
>  BUILD must equal HOST; that is, we do not support building GHC itself
>  with a cross-compiler.  To cross-compile GHC itself, set TARGET: stage
>  1 will be a cross-compiler, and stage 2 will be the cross-compiled
>  GHC.
> >>>
> >>>
> >>>
> >>> Anyone know off the top of their heads what the issue is?
> >>>
> >>> Thanks,
> >>> - Josh Berman
> >>> ___
> >>> ghc-devs mailing list
> >>> ghc-devs@haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>
> >>
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Tooling-friendly ModSummary

[Edward Z. Yang]

Hello Alan,

SPJ and I both think that GhcMake is well overdue for a rewrite.
But it's not altogether obvious what the rewrite should look like.
I've made some remarks here: 
https://gist.github.com/ezyang/50004e0f842eec5848acad5cf1c22240

I'm OK with small, incremental changes that make tooling's life better.
But adding renamed/typechecked ASTs is almost certainly the wrong
thing to do.  The ModSummary is produced by looking at an hs file
and doing the bare minimum processing to get the import graph.

The way the pipeline works is a ModSummary is eventually turned into a
HomeModInfo by the typechecking process. So one possibility is that
if it is requested (retaining renamed, typechecked ASTs increases
memory consumption for clients that don't need it) the things you want
could be stashed in HomeModInfo.  So you'd probably augment
FrontendResult to return the information you need, and then
hscIncrementalCompile to stick it in HomeModInfo.

Things to be careful about:

- You will NOT get this info if you load the HomeModInfo from
  disk rather than compile it directly.  I am assuming that you
  have a way to convince 'load' to rebuild; I don't actually
  know how to do this.

- We don't want to save this info by default; it will increase
  memory usage for anyone who doesn't need it (e.g., ghc --make)

Hope that helps,
Edward

Excerpts from Alan & Kim Zimmerman's message of 2016-09-05 20:27:26 +0200:
> At the moment the standard way to use the GHC API is something like
> 
> _ <- load LoadAllTargets
> modSum <- getModSummary mn
> p <- parseModule modSum
> 
> And likewise if renamed or typechecked ASTs are needed.
> 
> But the `load` step already does all those phases.
> 
> So, would there be any objection to modifying the ModSummary to possibly
> retain those artifacts, configurable via a DynFlag?
> 
> I would expect the flag would default to retaining none, but could then
> either provide for returning all artifacts, or just for the targets
> explicitly listed in the `setTargets` call (i.e. not the full `depanal`
> result).
> 
> Regards
>   Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Build GHC on Windows using Hadrian and Stack

[Edward Z. Yang]

Nice work!

Edward

Excerpts from Andrey Mokhov's message of 2016-09-02 02:45:58 +:
> Hi all,
> 
> Summary: Building GHC on Windows using Hadrian and Stack got even simpler - 
> see https://github.com/snowleopard/hadrian/blob/master/doc/windows.md.
> 
> 
> To build GHC on Windows you usually need to jump through a lot of hoops [1], 
> which may be confusing even for experienced GHC developers [2].
> 
> Hadrian to the rescue!
> 
> Hadrian, a new build system for GHC that I've been developing [3], is written 
> in Haskell and can therefore be built and run via Stack that can install 
> appropriate bootstrapping GHC and MSYS2 environment in an automated and 
> robust way. This was first pointed out by Neil Mitchell [4], and I've 
> recently simplified build instructions even further. Here are all the steps:
> 
> git clone --recursive git://git.haskell.org/ghc.git
> cd ghc
> git clone git://github.com/snowleopard/hadrian
> cd hadrian
> stack setup
> stack exec -- pacman -S autoconf automake-wrapper make patch tar --noconfirm
> stack build
> stack exec hadrian -- --directory ".." -j --flavour=quickest
> 
> See more details here: 
> https://github.com/snowleopard/hadrian/blob/master/doc/windows.md.
> 
> NB: Hadrian can build Stage2 GHC, but there are still many limitations [5]. 
> Help make it better!
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012340.html
> [3] https://github.com/snowleopard/hadrian
> [4] http://neilmitchell.blogspot.co.uk/2016/03/compiling-ghc-on-windows.html
> [5] https://github.com/snowleopard/hadrian#current-limitations
> 
> Cheers,
> Andrey
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phabricator diffs not viewable by non-logged in users

[Edward Z. Yang]

For example, if I am not logged in (try an incognito/private
browsing session), https://phabricator.haskell.org/D2501 reports
an error.

Is this intentional? Seems poor, and also the diff is labeled as Public
in the UI. I found this quite surprising.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rewrapping with simple bidirectional pattern synonyms

[Edward Z. Yang]

I filed a ticket for precisely this:

https://ghc.haskell.org/trac/ghc/ticket/12203

Edward

Excerpts from David Feuer's message of 2016-08-24 18:11:16 -0400:
> I'm trying to write a bidirectional pattern synonym which is morally
> simple, but as far as I can tell there's no way to write it as a
> simple bidirectional pattern synonym.
> 
> What I want to say is
> 
> pattern TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs)
> 
> (where TSnocList and Dual are both newtype constructors)
> 
> But I don't see a way to do it without being explicitly bidirectional:
> 
> pattern TSnoc xs x <- (tsViewR -> ViewR xs x) where
>   TSnoc (TSnocList xs) x = TSnocList (CL.TCons (Dual x) xs)
> 
> tsViewR :: TSnocList c x y -> ViewR c (TSnocList c) x y
> tsViewR (TSnocList CL.TNil) = EmptyR
> tsViewR (TSnocList (CL.TCons (Dual x) xs)) = ViewR (TSnocList xs) x
> 
> Would it be possible to make this simple thing simple?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Question about initializing the run-time system

[Edward Z. Yang]

I looked at RtsStartup.c but I didn't see any code that was
obviously enforcing this (have you tried it?)rts/RtsStartup.c

However, at a guess, I bet the reason is related to the reason
why we can't have multiple copies of the RTS in the same
memory address space: the way we handle CAFs scribbles over
data pages that we loaded in from objects. I last looked
at this when working on
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced#Method2:copystaticclosuresintoaspecialareaatstartup

Edward

Excerpts from Iavor Diatchki's message of 2016-08-15 11:02:54 -0700:
> Hello,
> 
> GHC's user guide says that the run-time system cannot re-initialize itself,
> after it was shut-down (i.e., you can't call `hs_init` after calling
> `hs_exit`).
> 
> Could anyone shed some light on why that is?
> 
> -Iavor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Landing Backpack in HEAD

[Edward Z. Yang]

Hello friends,

I'm hoping to land Backpack (the patch is two years in the making now!)
for GHC 8.2, even though 8.2 is intended to be a stabilization and
performance release.  In this email, I will make the case that the
Backpack patch is relatively self-contained and will not affect
non-Backpack users, and explain how you might be affected by the
patch.  The most recent patchset can be found at 
https://github.com/ezyang/ghc/tree/ghc-backpack ; look for "The Backpack patch" 
in the commit log, since I plan
on squashing these commits before committing.

OK, here is what is in the patchset that affects non-Backpack users:

- The primary, overarching change is that there is now
  a distinction between "semantic" and "identity" modules.
  This solves a problem with hsig files:  suppose
  you have A.hsig which defines data T in package p.
  The resulting A.hi is most accurately identified
  as p[A=]:A; however, the Name for T should be .T,
  not p[A=]:A.T.  The former is an identity module
  (it *identifies* interfaces), whereas the latter is a semantic
  module (it is what is used in names).  Without Backpack,
  these two identities are always the same.  There are a number
  of places in the existing codepaths where we have to
  distinguish between the two concepts (sometimes you
  want semantic, sometimes you want identity); we DEFAULT
  to the identity module but I fix a few cases where
  semantic modules were desired instead.

- UnitId is generalized to also record how a component
  is instantiated (a mapping from module names to modules.)
  Without Backpack this is blank and equivalent to the
  existing UnitId.

- Packages has been refactored to also handle Backpack `-unit-id`
  flags, since we have to do some extra work to determine
  what inherited signatures merge where.

- The patch REVERTS all of the old support we had for hsig
  files; -sig-of is no more.  spinda had mentioned that
  Liquid Haskell used this in some cases, and I'm looking
  at supporting *just* their particular use-case.

- A new driver mode --backpack, which process test.bkp files.
  This mode is used PURELY for testing, and end users
  are not supposed to use it.  These all live in their own
  modules (BkpSyn, DriverBkp) except for some modest,
  convenient extensions to the lexer and parser to parse
  multiple modules at once.

The patch also comes with rewritten typechecking support for hsig
files, and instantiating indefinite packages on the fly, but these
are all standalone pieces of functionality which are not tied
to any existing compiler infrastructure.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Edward Z. Yang]

If you can execute subprocesses, you could always spawn gdb to
attach via ptrace() to the parent process and then poke around
memory.

Yes this is a "dumb" example but I think it goes to show how
important it is to correctly characterize what the threat model
is.  A "no-segfault" fragment of Haskell doesn't seem so much
as a security feature as it is a "good practices" lint pass.

Edward

Excerpts from Ryan Newton's message of 2016-08-09 10:41:44 -0400:
> On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov  glushen...@gmail.com> wrote:
> >
> > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using
> > sun.misc.Unsafe [2], one can cause segfaults even from pure Java.
> > [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf
> > [2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf
> 
> 
> Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with
> pure Java code.  Good to know about the unsafe interface.
> 
> On Mon, Aug 8, 2016 at 7:32 PM, David Terei  wrote:
> >
> > If you have the energy, it'd be great to put some of this thinking
> > into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell)
> > and flesh out a first approximation of what IO API's cause issues. Is
> > it just Ptr not carrying bounds around with it? Maybe, but then we
> > need to secure how Ptr's can be created, which excludes FFI returning
> > Ptr's.
> >
> 
> Yes, we can add a Wiki page.
> 
> Btw I was thinking more of kicking FFI/peek/poke outside of the Safe
> bubble, not changing their operational behavior.  First of all, it's nigh
> impossible to lock down FFI calls.
> 
> When someone, e.g. Bob Harper
> ,
> points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell*
> is the real objet d'art!  It's a safe language."  Yet it isn't really a
> full *language* if people cannot write and run programs in it!  (Because
> every program must be ultimately be `main::IO()`.)  Kicking out segfaulty
> features would still leave a safe language that people can write complete
> programs in.
> 
> Best,
>   -Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Edward Z. Yang]

I think what you are proposing is reasonable.  I wasn't present
when Safe Haskell's design was originally fleshed out so I don't
know why this route wasn't taken.

Edward

Excerpts from Ryan Newton's message of 2016-08-08 16:00:38 -0400:
> Hi Ed,
> 
> Thanks, I went back to the paper and read those sections.
> 
> It sounds like this design heavily reflects the untrusted-code use case.  I
> believe ceding the entire IO monad is too pessimistic, and it's also
> against the *spirit* of the type safety guarantee mentioned in the paper:
> 
> "Type safety. In Milner’s famous phrase, well-typed programs do not go
> wrong. "
> There's not really very much discussion of this "punting on IO" decision in
> the paper.  The paper mentions not deleting users files as an example of a
> higher level security policy -- and a reason not  to try to lock down IO --
> but that's not really the issue here.
> 
> Sure, there are many use cases that require an RIO newtype, but the memory
> model and memory protection are really internal to the language.  My
> interest is in a type safe language with a memory model *in the IO monad*.
> I think it's quite *reasonable to expect Safe Haskell to be as safe as
> Java! * There are hundreds of thousands or millions of lines of code
> written in the IO monad [1], and a lot of that code could probably be
> memory safe by construction.
> 
> One question I have for people is which of the following they would favor:
> 
>1. Redefine -XSafe to guarantee something about IO and its memory safety
>(and even its memory model)
>2. Add a fourth safety level, "SafeExceptIO", that corresponds to the
>current guarantees, while extending "Safe" to say something about IO.
>3. Leave safe Haskell as it is.
> 
> (2) sounds a bit clunky to me, and I favor (1) most of all.
> 
> Best,
>   -Ryan
> 
> [1] 17M lines on hackage total, hard to count how much is in an IO monad or
> related monad.
> 
> On Mon, Aug 8, 2016 at 2:05 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> 
> > Hello Ryan,
> >
> > The guarantee that Safe Haskell gives with regards to IO is a little
> > subtle and is mentioned in Section 3.1 of the paper, and detailed
> > in Section 5.1. Essentially, to use Safe Haskell, you are responsible
> > for defining the type at which untrusted code is to be called.
> > Using an untrusted value at type IO a in main imposes no safety
> > restrictions by design--it's up to the user of Safe Haskell to
> > decide what kind of security properties it needs out of user code.
> >
> > Edward
> >
> > Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400:
> > > We're trying to spend some cycles pushing on Safe Haskell within the
> > > stackage packages.  (It's looking like a slog.)
> > >
> > > But we're running up against some basic questions regarding the core
> > > packages and Safe Haskell guarantees.  The manual currently says:
> > > <https://downloads.haskell.org/~ghc/latest/docs/html/
> > users_guide/safe_haskell.html#safe-language>
> > >
> > >
> > > *Functions in the IO monad are still allowed and behave as usual. *
> > > As usual?  So it is ok to segfault GHC?  Elsewhere it says "in the safe
> > > language you can trust the types", and I'd always assumed that meant Safe
> > > Haskell is a type safe language, even in the IO fragment.
> > >
> > > Was there an explicit decision to allow segfaults and memory corruption?
> > > This can happen not just with FFI calls but with uses of Ptrs within
> > > Haskell, for example the following:
> > >
> > >
> > > ```
> > >
> > > {-# LANGUAGE Safe #-}
> > >
> > > module Main where
> > >
> > > import Foreign.Marshal.Alloc
> > >
> > > import Foreign.Storable
> > >
> > > import Foreign.Ptr
> > >
> > > import System.Random
> > >
> > >
> > > fn :: Ptr Int -> IO ()
> > >
> > > fn p = do
> > >
> > >   -- This is kosher:
> > >
> > >   poke p 3
> > >
> > >   print =<< peek p
> > >
> > >   -- This should crash the system:
> > >
> > >   ix <- randomIO
> > >
> > >   pokeElemOff p ix 0xcc
> > >
> > >
> > >
> > > main = alloca fn
> > >
> > > ```
> > >
> > >
> > >   -Ryan
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving cost center reports to show residency?

[Edward Z. Yang]

Hello Omer,

I don't quite understand; is +RTS -hc what you want?  That will output
a heap profile per cost center, which will give you residency.  Is the
problem that you need a heap profile every minor GC rather than major
GC (e.g. something like https://ghc.haskell.org/trac/ghc/ticket/8504 ?)

Edward

Excerpts from Ömer Sinan Ağacan's message of 2016-08-08 11:28:48 +:
> One thing that we can't currently see in cost center reports is the residency
> and because of that cost centers can't be used for fixing memory leaks or
> reducing max. memory residency. For example, I can have a function that 
> returns
> an `Int` but allocates lots of intermediate data on the way. In the reports I
> see this function as allocates a lot, but it has no effect on my program's
> residency (especially if it runs fast).
> 
> So I'm thinking of somehow using cost centers for reasoning about memory
> residency. One idea is to print a summary after every major GC, by doing 
> another
> pass on the whole heap and recording attributions. This can be used for 
> plotting
> live data of cost centers over time. (like hp2ps but for cost centers)
> 
> Another idea is to add "residency" column in the profiling reports. Not sure 
> how
> to update this column in runtime though.
> 
> The main use case for me is fixing T1969, but of course this is a very general
> solution.
> 
> Does anyone have any other ideas?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Is Safe Haskell intended to allow segfaults?

[Edward Z. Yang]

Hello Ryan,

The guarantee that Safe Haskell gives with regards to IO is a little
subtle and is mentioned in Section 3.1 of the paper, and detailed
in Section 5.1. Essentially, to use Safe Haskell, you are responsible
for defining the type at which untrusted code is to be called.
Using an untrusted value at type IO a in main imposes no safety
restrictions by design--it's up to the user of Safe Haskell to
decide what kind of security properties it needs out of user code.

Edward

Excerpts from Ryan Newton's message of 2016-08-08 13:27:16 -0400:
> We're trying to spend some cycles pushing on Safe Haskell within the
> stackage packages.  (It's looking like a slog.)
> 
> But we're running up against some basic questions regarding the core
> packages and Safe Haskell guarantees.  The manual currently says:
> 
> 
> 
> *Functions in the IO monad are still allowed and behave as usual. *
> As usual?  So it is ok to segfault GHC?  Elsewhere it says "in the safe
> language you can trust the types", and I'd always assumed that meant Safe
> Haskell is a type safe language, even in the IO fragment.
> 
> Was there an explicit decision to allow segfaults and memory corruption?
> This can happen not just with FFI calls but with uses of Ptrs within
> Haskell, for example the following:
> 
> 
> ```
> 
> {-# LANGUAGE Safe #-}
> 
> module Main where
> 
> import Foreign.Marshal.Alloc
> 
> import Foreign.Storable
> 
> import Foreign.Ptr
> 
> import System.Random
> 
> 
> fn :: Ptr Int -> IO ()
> 
> fn p = do
> 
>   -- This is kosher:
> 
>   poke p 3
> 
>   print =<< peek p
> 
>   -- This should crash the system:
> 
>   ix <- randomIO
> 
>   pokeElemOff p ix 0xcc
> 
> 
> 
> main = alloca fn
> 
> ```
> 
> 
>   -Ryan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FINAL CALL FOR TALKS (Aug 8 deadline): Haskell Implementors Workshop 2016, Sep 24, Nara

[Edward Z. Yang]

Deadline is in a week!  Submit your talks!

Call for Contributions
   ACM SIGPLAN Haskell Implementors' Workshop

http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
Nara, Japan, 24 September, 2016

Co-located with ICFP 2016
   http://www.icfpconference.org/icfp2016/

Important dates
---
Proposal Deadline:  Monday, 8 August, 2016
Notification:   Monday, 22 August, 2016
Workshop:   Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
--- End forwarded message ---
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: T11758 testcase help needed

[Edward Z. Yang]

I am not sure if this will work, but how about dumping the assembly and
looking for sign extension?  C-- might be easier!

Excerpts from Alex Dzyoba's message of 2016-07-09 08:25:39 -0400:
> Hi, all!
> 
> I was working on #11758, which is about dropping binutils<2.17 hack, and while
> it was relatively easy to remove the hack itself, I'm not sure how to add a
> test case for it.
> 
> As I understand, after removing the aforementioned hack, native codegen now
> shouldn't generate sign extension. So my question is how to test it? Should it
> be Cmm file that will be tested with `compile_cmp_asm` like memcpy in
> "codeGen/should_gen_asm/memcpy.cmm"? Or should I stick to
> the Haskell test?
> 
> Thanks,
> Alex Dzyoba
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interruptible exception wormholes kill modularity

[Edward Z. Yang]

Excerpts from Yuras Shumovich's message of 2016-07-02 09:06:59 -0400:
> On Sat, 2016-07-02 at 00:49 -0400, Edward Z. Yang wrote:
> > 
> > P.P.S. I have some speculations about using uninterruptibleMask more
> > frequently: it seems to me that there ought to be a variant of
> > uninterruptibleMask that immediately raises an exception if
> > the "uninterruptible" action blocks.  This would probably of
> > great assistance of noticing and eliminating blocking in
> > uninterruptible code.
> 
> 
> Could you please elaborate where it is useful. Any particular example?

You would use it in any situation you use an uninterruptibleMask.
The point is that uninterruptible code is not supposed to take
too long (the program is unresponsive in the meantime), so it's
fairly bad news if inside uninterruptible code you block.  The
block = exception variant would help you find out when this occurred.

Arguably, it would be more Haskelly if there was a static type
discipline for distinguishing blocking and non-blocking IO operations.
But some operations are only known to be (non-)blocking at runtime,
e.g., takeMVar/putMVar, so a dynamic discipline is necessary.

> I'm interested because few years ago I proposed similar function, but
> in a bit different context. I needed it to make interruptible cleanup
> actions safe to use.

Could you elaborate more / post a link?

Cheers,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interruptible exception wormholes kill modularity

[Edward Z. Yang]

Excerpts from Simon Marlow's message of 2016-07-02 05:58:14 -0400:
> > Claim 1: Here is some code which reimplements 'unblock':
> >
> > import Control.Exception
> > import Control.Concurrent
> > import Control.Concurrent.MVar
> >
> > unblock :: IO a -> IO a
> > unblock io = do
> > m <- newEmptyMVar
> > _ <- forkIO (io >>= putMVar m)
> > takeMVar m
> >
> >
> This isn't really an implementation of unblock, because it doesn't enable
> fully-asynchronous exceptions inside io.  If a stack overflow occurs, it
> won't be thrown, for example.  Also, io will not be interrupted by an
> asynchronous exception thrown to the current thread.

Oh, that's true. I suppose you could work around this by passing
on an asynchronous exception to a child thread that is unmasked
using forkIOWithUnmask, although maybe you would consider that
cheating?

> We already have a way to allow asynchronous exceptions to be thrown within
> a mask, it's called allowInterrupt:
> http://hackage.haskell.org/package/base-4.9.0.0/docs/Control-Exception.html#v:allowInterrupt

Well, it's different, right?  allowInterrupt allows asynchronous exceptions to
be thrown at a specific point of execution; unblock allows asynchronous
exceptions to be thrown at any point while the inner IO action is
executing.  I don't see why you would allow the former without the
latter.

> I don't buy the claim that this breaks "modularity".  The way to think
> about mask is that it disables fully-asynchronous exceptions, only allowing
> them to be thrown at certain well-defined points.  This makes them
> tractable, it means you can write code without worrying that an async
> exception will pop up at any point.  Inside a mask, the only way to get
> back to the state of fully asynchronous exceptions is to use the unblock
> action that mask gives you (provided you weren't already inside a mask).

I suppose what I don't understand, then, is that if interruptible
points are modular, I don't see why unblock isn't modular either;
it's just a more convenient way of inserting allowInterrupt between
every indivisible IO operation in user code.

> > You could very well argue that interruptible actions are a design flaw.
> >
> 
> I disagree - it's impossible to define withMVar without interruptible mask.

What about this version of withMVar using uninterruptible? (Assume
no other producers.)

withMVarUninterruptible :: MVar a -> (a -> IO b) -> IO b
withMVarUninterruptible m io =
  uninterruptibleMask $ \restore -> do
a <- restore (takeMVar m)
b <- restore (io a) `onException` putMVar m a
putMVar m a
return b

I don't think it is quite right, as there is race between when
takeMVar unblocks, and when the uninterruptible mask is restored.
But perhaps the primary utility of interruptible masks is to
let you eliminate this race.

> > Then you should use 'uninterruptibleMask' instead, which effectively
> > removes the concept of interruptibility--and is thus modular.  Indeed,
> > Eyal Lotem proposed [2] that 'bracket' should instead use
> > 'uninterruptibleMask', for precisely the reason that it is too easy to
> > reenable asynchronous exceptions in 'mask'.
> 
> 
> The problem he was talking about was to do with the interruptibility of the
> cleanup action in bracket, not the acquire, which really needs
> interruptible mask. The interruptibility of the cleanup is a complex issue
> with arguments on both sides.  Michael Snoyman recently brought it up again
> in the context of his safe-exceptions library.  We might yet change that -
> perhaps at the very least we should implement a catchUninterruptible# that
> behaves like catch# but applies uninterruptibleMask to the handler, and
> appropriate user-level wrappers.

Yes, it is complex, and I won't claim to know the right answer here.

> > But assuming that
> > interruptible masks are a good idea (Simon Marlow has defended them
> > as "a way avoid reasoning about asynchronous exceptions except
> > at specific points, i.e., where you might block"), there should
> > be an 'unblock' for this type of mask.
> >
> > It should be said that the absence of 'unblock' for
> > 'uninterruptibleMask' only implies that a passed in IO action (e.g., the
> > cleanup action in bracket) does not have access to the exceptions thrown
> > to the current thread; it doesn't actually guarantee uninterruptibility,
> > since the passed in IO action could always raise a normal exception.
> > Haskell's type system is not up to the task of enforcing such
> > invariants.
> >
> > Cheers,
> > Edward
> >
> > [1]
> > https://mail.haskell.org/pipermail/libraries/2010-March/013310.html
> > https://mail.haskell.org/pipermail/libraries/2010-April/013420.html
> >
> > [2]
> > https://mail.haskell.org/pipermail/libraries/2014-September/0
> > 
> > Cheers,
> > Simon
> >
> > 23675.html
> > 

Interruptible exception wormholes kill modularity

[Edward Z. Yang]

In 2010, in the thread "Asynchronous exception wormholes kill modularity" [1],
Bas van Dijk observed that 'unblock :: IO a -> IO a' broke modularity,
as the sequence of calls 'block . block . unblock $ io' would result in
'io' being run with asynchronous exceptions unblocked, despite the outer
'block' "expecting" that asynchronous exceptions cannot be thrown.

I would like to make two claims:

1. The new mask/restore interface is insufficient to "solve"
this modularity problem, as *interruptible* operations can
still be used to catch asynchronous exceptions.

2. Thus, we should provide an unblock combinator which
can be used to catch asynchronous exceptions from a 'mask'
(though not an 'uninterruptibleMask')--though it is
doubtful if anyone should ever use 'mask' in the first
place.

Claim 1: Here is some code which reimplements 'unblock':

import Control.Exception
import Control.Concurrent
import Control.Concurrent.MVar

unblock :: IO a -> IO a
unblock io = do
m <- newEmptyMVar
_ <- forkIO (io >>= putMVar m)
takeMVar m

The main idea is that 'takeMVar' is an interruptible operation:
when it blocks, the thread can now receive asynchronous exceptions.
In general, a thread can unmask exceptions by blocking.  Here
is a simple test-case:

main = do
let x = 1000 -- Just do a bit of work
tid <- myThreadId
forkIO $ (threadDelay 1 >> killThread tid)
r <- mask $ \restore -> do
-- restore $ do
-- unblock $ do
-- do something non-blocking
evaluate (f x [])
-- If the exception is delivered in a timely manner,
-- shouldn't get here.
print r

f 0 r = r
f n r = f (n-1) (n:r)

With both restore and unblock commented, the ThreadKilled
exception is delayed; uncommenting either restore or unblock
causes the exception to be delivered.

This admonition does not apply to uninterruptibleMask, for
which there are no interruptible exceptions.

Claim 2:  Thus, I come to the conclusion that we were wrong
to remove 'unblock', and that it is no worse than the
ability for interruptible actions to catch asynchronous
exceptions.

You could very well argue that interruptible actions are a design flaw.
Then you should use 'uninterruptibleMask' instead, which effectively
removes the concept of interruptibility--and is thus modular.  Indeed,
Eyal Lotem proposed [2] that 'bracket' should instead use
'uninterruptibleMask', for precisely the reason that it is too easy to
reenable asynchronous exceptions in 'mask'.  But assuming that
interruptible masks are a good idea (Simon Marlow has defended them
as "a way avoid reasoning about asynchronous exceptions except
at specific points, i.e., where you might block"), there should
be an 'unblock' for this type of mask.

It should be said that the absence of 'unblock' for
'uninterruptibleMask' only implies that a passed in IO action (e.g., the
cleanup action in bracket) does not have access to the exceptions thrown
to the current thread; it doesn't actually guarantee uninterruptibility,
since the passed in IO action could always raise a normal exception.
Haskell's type system is not up to the task of enforcing such
invariants.

Cheers,
Edward

[1]
https://mail.haskell.org/pipermail/libraries/2010-March/013310.html
https://mail.haskell.org/pipermail/libraries/2010-April/013420.html

[2]
https://mail.haskell.org/pipermail/libraries/2014-September/023675.html

P.S. You were CC'ed to this mail because you participated in the original
"Asynchronous exception wormholes kill modularity" discussion.

P.P.S. I have some speculations about using uninterruptibleMask more
frequently: it seems to me that there ought to be a variant of
uninterruptibleMask that immediately raises an exception if
the "uninterruptible" action blocks.  This would probably of
great assistance of noticing and eliminating blocking in
uninterruptible code.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Template Haskell determinism

[Edward Z. Yang]

Oh drat, that's right, local names don't get given a package
key / package id, and externally visible local names aren't given a
deterministic name until we tidy (which is too late to help
Template Haskell.)  So I suppose there is not much we can do here.

Edward

Excerpts from Michael Sloan's message of 2016-06-29 13:41:13 -0400:
> No, NameU and NameL both lack package key / package id.
> 
> -Michael
> 
> On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> > No, nameBase is not the right thing to use here; you also need the
> > unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
> > in GHC 7.8 and before).  If you have that information, then
> > GHC establishes an invariant that if two names compare stably equal,
> > then the uniques associated with them are the same.
> >
> > Edward
> >
> > Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
> >> Hey, sorry for not getting back to this sooner!
> >>
> >> Perhaps I should have added the following to my list of goals in 
> >> contention:
> >>
> >> (3) (==) shouldn't yield True for Names that have different unique ids.
> >>
> >> We can only have stable comparisons if goal (3) isn't met, and two
> >> different unique Names would be considered to be equivalent based on the
> >> nameBase.  This is because Ord is a total order, not a partial order.  As
> >> described in my prior email, PartialOrd could be added, but it'd be
> >> inconvenient to use with existing Ord based containers.
> >>
> >> -Michael
> >>
> >> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> >>
> >> > I must admit, I am a bit confused by this discussion.
> >> >
> >> > It is true that every Name is associated with a Unique.  But you don't
> >> > need the Unique to equality/ordering tests; the names also contain
> >> > enough (stable) information for stable comparisons of that sort.  So
> >> > why don't we expose that instead of the Unique?
> >> >
> >> > Edward
> >> >
> >> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> >> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
> >> > simo...@microsoft.com>
> >> > > wrote:
> >> > >
> >> > > > If names get different ordering keys when reified from different
> >> > modules
> >> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
> >> > end up
> >> > > > with an unpleasant circumstance where these do not compare as equal
> >> > > >
> >> > > >
> >> > > >
> >> > > > The I believe that global, top level names (NameG) are not subject to
> >> > this
> >> > > > ordering stuff, so I don’t think this problem can occur.
> >> > > >
> >> > >
> >> > > True, top level names are NameG.  The reified Info for a top level Dec
> >> > may
> >> > > include NameU, though.  For example, the type variables in 'Maybe' are
> >> > > NameU:
> >> > >
> >> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
> >> > >  lift (show nf))
> >> > >
> >> > > The resulting expression is something like "NameU 822083586"
> >> > >
> >> > > > This is a breaking change and it doesn't fix the problem that
> >> > NameFlavour
> >> > > > is
> >> > > >
> >> > > > not abstract and leaks the Uniques. It would break at least:
> >> > > >
> >> > > >
> >> > > >
> >> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
> >> > > > don’t.  What use are these packages making of it?
> >> > > >
> >> > >
> >> > > It's being leaked in the public inteface via Ord.  The Eq instance is
> >> > fine,
> >> > > because these are Uniques, so the results should be consistent.
> >> > >
> >> > > There are two goals in contention here:
> >> > >
> >> > > 1) Having some ordering on Names so that they can be used in Map or Set
> >> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> >> > > really handle th

Re: Linker.c broken

[Edward Z. Yang]

I'm guessing it's:

commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7
Author: Simon Marlow 
Date:   Wed Jun 29 21:50:18 2016 +0100

Linker: some extra debugging / logging

which added ghci_find.

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-07-01 18:51:20 
-0400:
> Aargh!  Windows is broken /again/.   Some mess-up in Linker.c.
> I have not yet tried reverting recent patches.  Might someone fix please?
> It’s really helpful to validate on Windows when making RTS changes.
> Simon
> 
> 
> 
> rts\Linker.c: In function 'ghci_find':
> 
> 
> 
> rts\Linker.c:1482:52: error:
> 
>  error: pointer type mismatch in conditional expression [-Werror]
> 
>   oc->archiveMemberName : oc->fileName);
> 
> ^
> 
> 
> 
> rts\Linker.c:1480:28: error:
> 
>  error: format '%ls' expects argument of type 'wchar_t *', but argument 3 
> has type 'void *' [-Werror=format=]
> 
>  debugBelch("%p is in %" PATH_FMT, addr,
> 
> ^
> 
> "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall 
> -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes 
> -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline 
> -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn 
> -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes 
> -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header 
> -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build 
> -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common 
> -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 
> -optc-fomit-frame-pointer -optc-g -optc-fno-omit-frame-pointer -optc-g 
> -optc-O0 -optc-DRtsWay=\"rts_debug\" -optc-DWINVER=0x06000100 -static 
> -optc-DDEBUG -ticky -DTICKY_TICKY  -O0 -H64m -Wall 
> -fllvm-fill-undef-with-garbage-Werror -Iincludes -Iincludes/dist 
> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header 
> -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint  -i 
> -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen 
> -Irts/dist/build/./autogen   -O2 -O0
> -Wnoncanonical-monad-instances  -c rts/RaiseAsync.c -o 
> rts/dist/build/RaiseAsync.debug_o
> 
> 
> 
> rts\Linker.c:1483:28: error:
> 
>  error: format '%lx' expects argument of type 'long unsigned int', but 
> argument 3 has type 'long long unsigned int' [-Werror=format=]
> 
>  debugBelch(", section %d, offset %lx\n", i,
> 
> ^
> 
> 
> 
> In file included from rts\Linker.c:13:0: error:
> 
> rts\Linker.c: In function 'ocTryLoad':
> 
> 
> 
> rts\Linker.c:2563:55: error:
> 
>  error: pointer type mismatch in conditional expression [-Werror]
> 
>  oc->archiveMemberName : oc->fileName));
> 
>^
> 
> 
> 
> includes\Rts.h:300:53: error:
> 
>  note: in definition of macro 'IF_DEBUG'
> 
>  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
> 
>  ^
> 
> 
> 
> rts\Linker.c:2561:33: error:
> 
>  error: format '%ls' expects argument of type 'wchar_t *', but argument 2 
> has type 'void *' [-Werror=format=]
> 
>  IF_DEBUG(linker, debugBelch("Resolving %" PATH_FMT "\n",
> 
>  ^
> 
> 
> 
> includes\Rts.h:300:53: error:
> 
>  note: in definition of macro 'IF_DEBUG'
> 
>  #define IF_DEBUG(c,s)  if (RtsFlags.DebugFlags.c) { s; }
> 
>  ^
> 
> cc1.exe: all warnings being treated as errors
> 
> `gcc.exe' failed in phase `C Compiler'. (Exit code: 1)
> 
> rts/ghc.mk:255: recipe for target 'rts/dist/build/Linker.debug_o' failed
> 
> make[1]: *** [rts/dist/build/Linker.debug_o] Error 1
> 
> make[1]: *** Waiting for unfinished jobs
> 
> Makefile:129: recipe for target 'all' failed
> 
> make: *** [all] Error 2
> 
> /cygdrive/c/code/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

topHandler03 failing now

[Edward Z. Yang]

Hey thomie,

You recently changed topHandler03 to not ignore output.
Unfortunately, on my Arch Linux box this causes the
test to fail:

--- ./topHandler03.run/topHandler03.stderr.normalised   2016-06-30 
10:30:56.423442132 -0700
+++ ./topHandler03.run/topHandler03.run.stderr.normalised   2016-06-30 
10:30:56.423442132 -0700
@@ -1 +1 @@
-Terminated
+/bin/sh: line 1:  7193 Terminated  ./topHandler03

It seems the shell output behavior here varies.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Template Haskell determinism

[Edward Z. Yang]

No, nameBase is not the right thing to use here; you also need the
unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
in GHC 7.8 and before).  If you have that information, then
GHC establishes an invariant that if two names compare stably equal,
then the uniques associated with them are the same.

Edward

Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
> Hey, sorry for not getting back to this sooner!
> 
> Perhaps I should have added the following to my list of goals in contention:
> 
> (3) (==) shouldn't yield True for Names that have different unique ids.
> 
> We can only have stable comparisons if goal (3) isn't met, and two
> different unique Names would be considered to be equivalent based on the
> nameBase.  This is because Ord is a total order, not a partial order.  As
> described in my prior email, PartialOrd could be added, but it'd be
> inconvenient to use with existing Ord based containers.
> 
> -Michael
> 
> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang <ezy...@mit.edu> wrote:
> 
> > I must admit, I am a bit confused by this discussion.
> >
> > It is true that every Name is associated with a Unique.  But you don't
> > need the Unique to equality/ordering tests; the names also contain
> > enough (stable) information for stable comparisons of that sort.  So
> > why don't we expose that instead of the Unique?
> >
> > Edward
> >
> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
> > simo...@microsoft.com>
> > > wrote:
> > >
> > > > If names get different ordering keys when reified from different
> > modules
> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
> > end up
> > > > with an unpleasant circumstance where these do not compare as equal
> > > >
> > > >
> > > >
> > > > The I believe that global, top level names (NameG) are not subject to
> > this
> > > > ordering stuff, so I don’t think this problem can occur.
> > > >
> > >
> > > True, top level names are NameG.  The reified Info for a top level Dec
> > may
> > > include NameU, though.  For example, the type variables in 'Maybe' are
> > > NameU:
> > >
> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
> > >  lift (show nf))
> > >
> > > The resulting expression is something like "NameU 822083586"
> > >
> > > > This is a breaking change and it doesn't fix the problem that
> > NameFlavour
> > > > is
> > > >
> > > > not abstract and leaks the Uniques. It would break at least:
> > > >
> > > >
> > > >
> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
> > > > don’t.  What use are these packages making of it?
> > > >
> > >
> > > It's being leaked in the public inteface via Ord.  The Eq instance is
> > fine,
> > > because these are Uniques, so the results should be consistent.
> > >
> > > There are two goals in contention here:
> > >
> > > 1) Having some ordering on Names so that they can be used in Map or Set
> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> > > really handle these well.  In that case, the ordering would be based on
> > > everything but the NameU int, but 'Eq' would still follow it
> > >
> > > A few ideas for different approaches to resolving this:
> > >
> > > 1) Document it.  Less appealing than fixing it in the API, but still
> > would
> > > be good.
> > >
> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
> > newtype
> > > (current behavior).  A trickyness of this approach is that you'd need
> > > containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
> > > people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> > > this would break a lot of code that was already deterministic.
> > >
> > > 3) Some approaches like this ordering key, but I'm not sure how it will
> > > help when comparing NameUs from different modules?
> > >
> > > > S
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *From:* ghc-devs [mailto:ghc-devs-boun...@ha

Re: Using the GHC API to write an interpreter

[Edward Z. Yang]

I am not sure I entirely understand your proposal, but a good
way of finding out if it works is giving it a try.

Excerpts from Christopher Done's message of 2016-06-26 06:28:55 -0400:
> I've been pondering how feasible it would be to:
> 
> * Compile in stages a module with the byte code linker
> * Keep hold of the Core source
> * Interpret the Core AST within Haskell
> * When encountering built-in/primitives (or things from other libraries),
> we compile that Core term and link it as an HValue and then run it with the
> arguments expected. So () would be such a HValue, as would be "show" which
> in interpretable unoptimized Core would take an extra argument for the Show
> instance. When passing in values to such "foreign" functions it would wrap
> them up in an interpretive way.

I don't understand what the bytecode format has to do here. Since
your suggestion is to just store Core you can just compile to object
code.

I prototyped "fat interface" files https://ghc.haskell.org/trac/ghc/ticket/10871
which store core into interface files, so they could be compiled later.
The patchset was here: https://github.com/ezyang/ghc/tree/ghc-fat-interface

> This is the hypothetical idea, it seems like it would yield a really
> trivial way to write a new and interesting interpreter for GHC Haskell
> without having to re-implement any prim ops, ready to work on regular
> Haskell code.
> 
> In my case, I would use this to write an interpreter which:
> 
> * is not tagless, so we preserve type info
> * allows top-level names to be redefined
> * when a function is applied, it checks the type of its arguments
> 
> Both of these are pretty much necessary for being able to do in-place
> update of a running program while developing (a la Emacs or Smalltalk), and
> type tags let us throw a regular Haskell exception of type error, a la
> deferred type errors. It means in your running program, if you make a
> mistake or forget to update one part, it doesn't bring the whole program
> down with an RTS error or a segfault, maybe a handler in a thread (like a
> server or a video game) throws an exception and the developer just updates
> their code and tries again.
> 
> I'd love support for something like this, but I'd rather not have to
> re-create the world just to add this capability. Because it's really just
> conceptually regular interpreted GHC Haskell plus type tags and updating,
> it seems like it should be a small diff.
> 
> Any input into this? How far away is GHC's current architecture from
> supporting such a concept?

Well, if you are going to support update you need to make sure that the
tag information is more elaborate than what GHC currently supports
(a type would just be a Name, which is going to get reused when you
recompile.)

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Require -fexternal-interpreter support for future TH changes?

[Edward Z. Yang]

Hello Simon,

I have no exception to having it be default and dropping the special
case support for building profiled/dynamic so that TH works.  But
I don't think support for loading code in-process for GHC should be dropped,
c.f. Manuel's email
https://mail.haskell.org/pipermail/ghc-devs/2015-November/010491.html
and also the necessity to run code in-process for typechecking plugins,
etc.

Edward

Excerpts from Simon Marlow's message of 2016-06-22 04:51:12 -0400:
> *Background*
> 
> A few months ago I added -fexternal-interpreter to GHC:
> 
>- docs:
>
> http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter
>- wiki, rationale: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
> 
> When -fexternal-interpreter is used, GHC runs interpreted code in a
> separate subprocess, and communicates with it using binary messages over a
> pipe.
> 
> -fexternal-interpreter currently implements all of TH, quasi-quoting,
> annotations, and all the GHCi features except for some features of the
> debugger.  It is also now implemented on Windows, thanks to Tamar Christina.
> 
> *Proposal*
> 
> I'd like to propose that going forward we commit to maintaining full
> support for -fexternal-interpreter, with a view to making it the default.
> 
> Why?
> 
>- -fexternal-interpreter will be a prerequisite for GHCJS support, so
>maintaining full support for TH in -fexternal-interpreter will ensure that
>everything that works with GHC works with GHCJS.
>- We will be able to make simplifications in GHC and the build system
>once -fexternal-interpreter is the default, because when compiling with
>-prof or -dynamic we won't have to compile things twice any more.
>- Ultimately we don't want to have two ways of doing everything, because
>that's harder to maintain.
> 
> How?
> 
>- I'll make all the TH and quasi-quoting tests run with and without
>-fexternal-interpreter, so it will break validate if one of these fails.
> 
> *Why now?*
> 
> There are some TH changes in the pipeline that will need special attention
> to work with -fexternal-interpreter.  e.g.
> https://phabricator.haskell.org/D2286 and
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective, so I'd
> like to raise it now so we can keep the issue in mind.
> 
> 
> Cheers
> 
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Optimizing "counting" GADTs

[Edward Z. Yang]

Excerpts from David Feuer's message of 2016-06-18 19:47:54 -0700:
> I would think the provided equalities could be constructed in a view
> pattern, possibly using unsafeCoerce.

Yes, this does work.

{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PatternSynonyms #-}
{-# LANGUAGE ViewPatterns #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE GADTs #-}
{-# OPTIONS_GHC -fwarn-incomplete-patterns #-}
module GhostBuster where

import GHC.TypeLits
import Unsafe.Coerce

newtype Vec a (n :: Nat) = Vec { unVec :: [a] }

-- "Almost" Vec GADT, but the inside is a Vec
-- (so only the top-level is unfolded.)
data Vec' a (n :: Nat) where
VNil'  :: Vec' a 0
VCons' :: a -> Vec a n -> Vec' a (n + 1)

upVec :: Vec a n -> Vec' a n
upVec (Vec []) = unsafeCoerce VNil'
upVec (Vec (x:xs)) = unsafeCoerce (VCons' x (Vec xs))

pattern VNil :: () => (n ~ 0) => Vec a n
pattern VNil <- (upVec -> VNil') where
VNil = Vec []

pattern VCons :: () => ((n + 1) ~ n') => a -> Vec a n -> Vec a n'
pattern VCons x xs <- (upVec -> VCons' x xs) where
VCons x (Vec xs) = Vec (x : xs)

headVec :: Vec a (n + 1) -> a
headVec (VCons x _) = x

mapVec :: (a -> b) -> Vec a n -> Vec b n
mapVec f VNil = (VNil :: Vec a 0)
mapVec f (VCons x xs) = VCons (f x) (mapVec f xs)

> Dictionaries are harder to come by,
> but reflection might be an option.

If I understand correctly, even if you have a Typeable dictionary you
don't necessarily have a way of constructing the other dictionaries
that are available at that type.  Maybe that is something worth fixing.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara

[Edward Z. Yang]

(...and now with the right date in the subject line!)

Call for Contributions
   ACM SIGPLAN Haskell Implementors' Workshop

http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
Nara, Japan, 24 September, 2016

Co-located with ICFP 2016
   http://www.icfpconference.org/icfp2016/

Important dates
---
Proposal Deadline:  Monday, 8 August, 2016
Notification:   Monday, 22 August, 2016
Workshop:   Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
--

  * Joachim Breitner(Karlsruhe Institut für Technologie)
  * Duncan Coutts   (Well Typed)
  * Michael Snoyman (FP Complete)
  * Luite Stegeman  (ghcjs)
  * Niki Vazou  (UCSD)
  * Stephanie Weirich   (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Call for talks: Haskell Implementors Workshop 2016, Aug 24, Nara

[Edward Z. Yang]

Call for Contributions
   ACM SIGPLAN Haskell Implementors' Workshop

http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016
Nara, Japan, 24 September, 2016

Co-located with ICFP 2016
   http://www.icfpconference.org/icfp2016/

Important dates
---
Proposal Deadline:  Monday, 8 August, 2016
Notification:   Monday, 22 August, 2016
Workshop:   Saturday, 24 September, 2016

The 8th Haskell Implementors' Workshop is to be held alongside ICFP
2016 this year in Nara. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings; the workshop will be informal and interactive, with a
flexible timetable and plenty of room for ad-hoc discussion, demos,
and impromptu short talks.

Scope and target audience
-

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2016. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides and presented data
available with the consent of the speakers.

In the Haskell Implementors' Workshop, we hope to study the underlying
technology. We want to bring together anyone interested in the
nitty-gritty details behind turning plain-text source code into a
deployed product. Having said that, members of the wider Haskell
community are more than welcome to attend the workshop -- we need your
feedback to keep the Haskell ecosystem thriving.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment

Talks
-

At this stage we would like to invite proposals from potential speakers
for talks and demonstrations. We are aiming for 20 minute talks with 10
minutes for questions and changeovers. We want to hear from people
writing compilers, tools, or libraries, people with cool ideas for
directions in which we should take the platform, proposals for new
features to be implemented, and half-baked crazy ideas. Please submit a
talk title and abstract of no more than 300 words.

Submissions should be made via HotCRP. The website is:
  https://icfp-hiw16.hotcrp.com/

We will also have a lightning talks session which will be organised on
the day. These talks will be 5-10 minutes, depending on available time.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Organisers
--

  * Joachim Breitner(Karlsruhe Institut für Technologie)
  * Duncan Coutts   (Well Typed)
  * Michael Snoyman (FP Complete)
  * Luite Stegeman  (ghcjs)
  * Niki Vazou  (UCSD)
  * Stephanie Weirich   (University of Pennsylvania) 
  * Edward Z. Yang - chair  (Stanford University)
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Template Haskell determinism

[Edward Z. Yang]

I must admit, I am a bit confused by this discussion.

It is true that every Name is associated with a Unique.  But you don't
need the Unique to equality/ordering tests; the names also contain
enough (stable) information for stable comparisons of that sort.  So
why don't we expose that instead of the Unique?

Edward

Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones 
> wrote:
> 
> > If names get different ordering keys when reified from different modules
> > (seems like they'd have to, particularly given ghc's "-j"), then we end up
> > with an unpleasant circumstance where these do not compare as equal
> >
> >
> >
> > The I believe that global, top level names (NameG) are not subject to this
> > ordering stuff, so I don’t think this problem can occur.
> >
> 
> True, top level names are NameG.  The reified Info for a top level Dec may
> include NameU, though.  For example, the type variables in 'Maybe' are
> NameU:
> 
> $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>  lift (show nf))
> 
> The resulting expression is something like "NameU 822083586"
> 
> > This is a breaking change and it doesn't fix the problem that NameFlavour
> > is
> >
> > not abstract and leaks the Uniques. It would break at least:
> >
> >
> >
> > But why is NameU exposed to clients?   GHC needs to know, but clients
> > don’t.  What use are these packages making of it?
> >
> 
> It's being leaked in the public inteface via Ord.  The Eq instance is fine,
> because these are Uniques, so the results should be consistent.
> 
> There are two goals in contention here:
> 
> 1) Having some ordering on Names so that they can be used in Map or Set
> 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> really handle these well.  In that case, the ordering would be based on
> everything but the NameU int, but 'Eq' would still follow it
> 
> A few ideas for different approaches to resolving this:
> 
> 1) Document it.  Less appealing than fixing it in the API, but still would
> be good.
> 
> 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> newtype (partial ord on the non-unique info), or 'UnstableNameOrd' newtype
> (current behavior).  A trickyness of this approach is that you'd need
> containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
> people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> this would break a lot of code that was already deterministic.
> 
> 3) Some approaches like this ordering key, but I'm not sure how it will
> help when comparing NameUs from different modules?
> 
> > S
> >
> >
> >
> >
> >
> > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of 
> > *Michael
> > Sloan
> > *Sent:* 02 June 2016 02:07
> > *To:* Bartosz Nitka 
> > *Cc:* ghc-devs Devs 
> > *Subject:* Re: Template Haskell determinism
> >
> >
> >
> > +1 to solving this.  Not sure about the approach, but assuming the
> > following concerns are addressed, I'm (+1) on it too:
> >
> >
> >
> > This solution is clever!  However, I think there is some difficulty to
> > determining this ordering key.  Namely, what happens when I construct the
> > (Set Name) using results from multiple reifies?
> >
> >
> >
> > One solution is to have the ordering key be a consecutive supply that's
> > initialized on a per-module basis.  There is still an issue there, though,
> > which is that you might store one of these names in a global IORef that's
> > used by a later TH splice.  Or, similarly, serialize the names to a file
> > and later load them.  At least in those cases you need to use 'runIO' to
> > break determinism.
> >
> >
> >
> > If names get different ordering keys when reified from different modules
> > (seems like they'd have to, particularly given ghc's "-j"), then we end up
> > with an unpleasant circumstance where these do not compare as equal.  How
> > about having the Eq instance ignore the ordering key?  I think that mostly
> > resolves this concern.  This implies that the Ord instance should also
> > yield EQ and ignore the ordering key, when the unique key matches.
> >
> >
> >
> > One issue with this is that switching the order of reify could
> > unexpectedly vary the behavior.
> >
> >
> >
> > Does the map in TcGblEnv imply that a reify from a later module will get
> > the same ordering key?  So does this mean that the keys used in a given
> > reify depend on which things have already been reified?  In that case, then
> > this is also an issue with your solution.  Now, it's not a big problem at
> > all, just surprising to the user.
> >
> >
> >
> >
> >
> > If the internal API for Name does change, may as well address
> > https://ghc.haskell.org/trac/ghc/ticket/10311 too.  I agree with SPJ's
> > suggested solution of having both the traditional package identifier and
> > package keys in 'Name'.
> >
> >
> >
> > 

Re: HEADS UP: running tests in /tmp and the `extra_files` setup function

[Edward Z. Yang]

Hello Thomas,

Is there a way to change where the temporary directory is made?  The
test suite can take a lot of disk space and some of us would prefer
to store the test output on a different partition.

Thanks,
Edward

Excerpts from Thomas Miedema's message of 2016-05-17 09:11:53 -0700:
> Hello GHC developers,
> 
> the testsuite driver now runs each test in a temporary directory in /tmp,
> after first linking/copying all files that the test requires to that
> directory.
> 
> When adding a new test:
> 
> ** if your test requires source files that don't start with the name of
> your test, then you *have to* specify those files using the `extra_files`
> setup function. [1]*
> 
> * you no longer have to specify files to cleanup (`clean_files` and
> `clean_cmd` are deprecated)
> 
> * you no longer have to add generated files to `testsuite/.gitignore`
> 
> * you no longer have to worry about two tests possibly overwriting each
> others intermediate (.o, .hi) files, and you no longer have to
> specify `-outputdir` if you want to let multiple tests use the same source
> files.
> 
> Example:
> 
> *BEFORE:*
> test('driver011',
>  extra_clean(['A011.hi', 'A011.o']),
>  run_command,
>  ['$MAKE -s --no-print-directory test011'])
> 
> *AFTER:*
> test('driver011',
>  extra_files(['A011.hs']),
>  run_command,
>  ['$MAKE -s --no-print-directory test011'])
> 
> See https://ghc.haskell.org/trac/ghc/ticket/11980 and
> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding for more
> information.
> 
> Cheers,
> Thomas
> 
> [1] Extra files for existing tests are currently listed in
> `testsuite/driver/extra_files.py`.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New wiki page about tying the knot in GHC

[Edward Z. Yang]

Yep, updated, thanks.

Edward

Excerpts from Ben Gamari's message of 2016-05-17 00:16:55 -0700:
> "Edward Z. Yang" <ezy...@mit.edu> writes:
> 
> > Hello all,
> >
> > I've written a new wiki page about how knot tying works in
> > GHC:
> >
> > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot
> >
> This is quite useful! Thanks for writing it down. A few points:
> 
> It might be nice if it defined HPT and EPS a bit more concretely (at
> least expand the acronyms, ideally including a bit of text defining
> their roles in the compiler and why there is two of them).
> 
> You say "we produce TyCons and another type checking entities for them".
> Should this read "other type checking entities for them"?
> 
> Otherwise it looks good to me.
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

New wiki page about tying the knot in GHC

[Edward Z. Yang]

Hello all,

I've written a new wiki page about how knot tying works in
GHC:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot

Please let me know if anything is unclear and I'll try to
revise it for more clarity.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Phabricator not sending emails

[Edward Z. Yang]

As far as I can tell, Phabricator is not sending emails.
I noticed when some of my diffs updated but I didn't get
any emails, and doublechecked by asking for a password
reset email.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Stop rejecting Summary: Signed-off-by: ... OR patch Phabricator

[Edward Z. Yang]

Hey guys,

Currently the commit hooks reject commit messages that look like:

Summary: Signed-off-by: Edward Z. Yang <ezy...@cs.stanford.edu>

Unfortunately, if I do a one line commit message with -s, Phabricator
will automatically reformat my message to have this.

This is dumb. Either:

1) You should stop rejecting these commit messages, or

2) You should patch Phabricator to stop munging the messages
this way.  The message formatting is done server-side so as
a client I have no way of changing it, you need to fix it.
This URL has some guidance on how to do it:
https://secure.phabricator.com/T6055

I'd offer to edit the hook myself but there does not seem to be
any canonical location where the hooks are versioned.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Harbourmaster is failing

[Edward Z. Yang]

260a5648c299636a94b12b9b97bf9743b0a1496d introduced
the #import.  Probably should be an #include.

Edward

Excerpts from Simon Peyton Jones's message of 2016-05-10 01:50:41 -0700:
> Bother. This is killing my build.   I had to switch of –Werror.
> Anyone know what is going on?
> Simon
> 
> 
> make --no-print-directory -f ghc.mk phase=1 phase_1_builds
> 
> inplace/bin/deriveConstants --gen-header -o 
> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir 
> includes/dist-derivedconstants/header/ --gcc-program "gcc" --gcc-flag -Wall 
> --gcc-flag -Werror --gcc-flag -Werror=unused-but-set-variable --gcc-flag 
> -Wno-error=inline --gcc-flag -std=gnu99 --gcc-flag -fno-stack-protector 
> --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag 
> -Iincludes/dist-derivedconstants/header --gcc-flag 
> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon 
> --nm-program "/usr/bin/nm" --objdump-program "/usr/bin/objdump" --target-os 
> "linux"
> 
> In file included from includes/Stg.h:213:0,
> 
>  from includes/Rts.h:30,
> 
>  from includes/dist-derivedconstants/header/tmp.c:13:
> 
> includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension 
> [-Werror=deprecated]
> 
> cc1: all warnings being treated as errors
> 
> Executing "gcc" failed
> 
> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 
> 1
> 
> make: *** [all] Error 2
> 
> 
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon 
> Peyton Jones
> Sent: 10 May 2016 09:44
> To: ghc-devs 
> Subject: Harbourmaster is failing
> 
> Lots of early Harbourmaster fails
> https://phabricator.haskell.org/harbormaster/build/11545/
> 
> Simon
> 
> In file included from includes/Stg.h:213:0,
> 
> 
> 
> from includes/Rts.h:30,
> 
> 
> 
> from includes/dist-derivedconstants/header/tmp.c:13:
> 
> 
> 
> includes/stg/Types.h:31:2: error: #import is a deprecated GCC extension 
> [-Werror=deprecated]
> 
> 
> 
> #import 
> 
> 
> 
> ^
> 
> 
> 
> cc1: all warnings being treated as errors
> 
> 
> Executing "gcc" failed
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Determining if an instance is provided by the environment

[Edward Z. Yang]

Well, I have to write the new variant of this function :)

Simon, I ran into a minor complication: if my instance is
something like:

instance Show a => Show [a]

I think I need to pass in a 'CtGiven' for 'Show a'.  However,
I don't know what to pass as the evidence to the 'CtGiven'
constraints.  My guess is that it doesn't matter?

Edward

Excerpts from David Fox's message of 2016-05-06 17:06:41 -0700:
> Is there a way to connect this to template-haskell or haskell-src-exts code?
> 
> On Fri, May 6, 2016 at 4:40 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> 
> > Thanks Simon, that has all the ingredients I need.
> >
> > I wrote some more docs for the function:
> > https://phabricator.haskell.org/D2180
> >
> > Edward
> >
> > Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -0700:
> > > You probably want a variant on TcDeriv.simplifyDeriv, shorn of its
> > complex error reporting.
> > >
> > > Simon
> > >
> > > |  -Original Message-
> > > |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> > > |  Edward Z. Yang
> > > |  Sent: 06 May 2016 00:21
> > > |  To: ghc-devs <ghc-devs@haskell.org>
> > > |  Subject: Determining if an instance is provided by the environment
> > > |
> > > |  Hello all,
> > > |
> > > |  Suppose I have a ClsInst from typechecking the following instance
> > > |  declaration:
> > > |
> > > |  instance Show [Char] -- i.e. String
> > > |
> > > |  I'd now like to answer the question: "Is this instance 'provided'
> > > |  by the instance environment?"  For example, this instance is provided
> > > |  given that I have these two instances in the environment:
> > > |
> > > |  instance Show a => Show [a] -- (1)
> > > |  instance Show Char  -- (2)
> > > |
> > > |  However, if I have just instance (1) in the environment, it's not
> > > |  provided (and if you tried to use show "foo", you'd get the error that
> > > |  Char is not an instance of Show.)
> > > |
> > > |  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
> > > |  and I can easily test if there is some instance in the environment
> > > |  which *matches* my instance head (e.g., Show [a] matches Show [Char])
> > > |  but this doesn't tell me if all the resulting constraints are
> > solvable.
> > > |
> > > |  Thanks,
> > > |  Edward
> > > |  ___
> > > |  ghc-devs mailing list
> > > |  ghc-devs@haskell.org
> > > |
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> > > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> > > |  devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com
> > %7c8c304d9b355244c6
> > > |
> > ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1=iWdrnb6hC
> > > |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Determining if an instance is provided by the environment

[Edward Z. Yang]

Thanks Simon, that has all the ingredients I need.

I wrote some more docs for the function: https://phabricator.haskell.org/D2180

Edward

Excerpts from Simon Peyton Jones's message of 2016-05-06 02:05:31 -0700:
> You probably want a variant on TcDeriv.simplifyDeriv, shorn of its complex 
> error reporting.
> 
> Simon
> 
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 06 May 2016 00:21
> |  To: ghc-devs <ghc-devs@haskell.org>
> |  Subject: Determining if an instance is provided by the environment
> |  
> |  Hello all,
> |  
> |  Suppose I have a ClsInst from typechecking the following instance
> |  declaration:
> |  
> |  instance Show [Char] -- i.e. String
> |  
> |  I'd now like to answer the question: "Is this instance 'provided'
> |  by the instance environment?"  For example, this instance is provided
> |  given that I have these two instances in the environment:
> |  
> |  instance Show a => Show [a] -- (1)
> |  instance Show Char  -- (2)
> |  
> |  However, if I have just instance (1) in the environment, it's not
> |  provided (and if you tried to use show "foo", you'd get the error that
> |  Char is not an instance of Show.)
> |  
> |  Is there are convenient way to do this from TcM?  With 'tcMatchTys'
> |  and I can easily test if there is some instance in the environment
> |  which *matches* my instance head (e.g., Show [a] matches Show [Char])
> |  but this doesn't tell me if all the resulting constraints are solvable.
> |  
> |  Thanks,
> |  Edward
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8c304d9b355244c6
> |  ee7208d3753be740%7c72f988bf86f141af91ab2d7cd011db47%7c1=iWdrnb6hC
> |  8pexyVkWNG22G%2fgdO10tCBy8nuCxhnO0M8%3d
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Determining if an instance is provided by the environment

[Edward Z. Yang]

Hello all,

Suppose I have a ClsInst from typechecking the following instance
declaration:

instance Show [Char] -- i.e. String

I'd now like to answer the question: "Is this instance 'provided'
by the instance environment?"  For example, this instance is provided
given that I have these two instances in the environment:

instance Show a => Show [a] -- (1)
instance Show Char  -- (2)

However, if I have just instance (1) in the environment, it's not
provided (and if you tried to use show "foo", you'd get the error
that Char is not an instance of Show.)

Is there are convenient way to do this from TcM?  With 'tcMatchTys'
and I can easily test if there is some instance in the environment
which *matches* my instance head (e.g., Show [a] matches Show [Char])
but this doesn't tell me if all the resulting constraints are
solvable.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"

[Edward Z. Yang]

Don't forget to "git submodule update"

Edward

Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700:
> I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD,
> and "make" keeps dying at ghctags:
> 
> Configuring ghctags-0.1...
> ghc-cabal: At least the following dependencies are missing:
> Cabal >=1.25 && <1.27
> 
> According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly
> git-pulled git clone).
> 
> Any ideas what's going on and how I can fix it?
> 
> Thanks.  - Conal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Initial compile time benchmarks

[Edward Z. Yang]

This ticket may be of interest:

https://ghc.haskell.org/trac/ghc/ticket/9630

Deriving costs a lot and we just need someone to figure out what's
going on.

Edward

Excerpts from Michael Sloan's message of 2016-03-29 15:23:50 -0700:
> Great! Thanks for y'all putting effort towards performance. It really is
> crucial
> for developer productivity.
> 
> In the particular case of haskell-src-exts, I found that removing many of
> the
> more complicated typeclasses from deriving (Data, Generics, etc) brought the
> compilation time way down. IIRC it was pretty drastic, like 40 seconds vs 10
> seconds (that could be just the timing for that one types module though, I
> don't recall).  Could be valuable to investigate exactly what's going on
> there.
> 
> -Michael
> 
> On Tue, Mar 29, 2016 at 2:00 PM, Ömer Sinan Ağacan 
> wrote:
> 
> > Hi all,
> >
> > Using Ben's timing patch [^1], Cabal, and a Haskell program to parse
> > generated
> > logs [^2], I generated some tables that show compile times of modules in
> > hxt,
> > haskell-src-exts, lens, and all of their dependencies:
> >
> >
> > https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt
> >
> > Some notes:
> >
> > - Modules and passes in modules are sorted.
> >
> > - At the end of the file you can see the cumulative numbers for the
> > passes. In
> >   fact, that's a small table so I'm just going to paste it here:
> >
> > ==Total==
> > CodeGen41.32%
> > Simplifier 34.83%
> > Renamer/typechecker12.22%
> > Desugar 2.11%
> > CorePrep1.90%
> > Demand analysis 1.44%
> > CoreTidy1.35%
> > Called arity analysis   1.10%
> > Float inwards   0.96%
> > Common sub-expression   0.87%
> > Parser  0.75%
> > SpecConstr  0.57%
> > Specialise  0.30%
> > Worker Wrapper binds0.17%
> > Liberate case   0.12%
> > ByteCodeGen 0.00%
> > Simplify0.00%
> >
> > I don't know how to make use of this yet, but I thought ghc-devs may find
> > it
> > useful.
> >
> > As a next thing I'm hoping to add some more `withTiming` calls. The analyze
> > program can handle nested `withTiming` calls and renders passes as a tree
> > (GHC
> > HEAD doesn't have nested `withTiming`s so we don't see it in the file
> > above),
> > so we can benchmark things in more details. I also want to experiment a
> > little
> > bit with different `force` parameters to `withTiming`. If anyone has any
> > other
> > ideas I can also try those.
> >
> > ---
> >
> > [^1]: https://phabricator.haskell.org/D1959
> > [^2]: https://github.com/osa1/analyze-ghc-timings
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Compiling Core Haskell using GHC API

[Edward Z. Yang]

What version of GHC are you working with? I don't see any
compileCoreToObj function in HEAD.

Edward

Excerpts from Marek Wawrzos's message of 2016-02-20 00:39:55 -0800:
> Hello,
> 
> I am bringing back that thread to life after a while.
> 
> I've spent some time on studding GHC source code related with that topic.
> There are some conclusions I have made:
> 
>- In my first email, I thought that execution of function
>*compileCoreToObj *in my program produced some *.o file. I was wrong.
>That file was produced by earlier step, that is execution of
> *compileToCoreModule
>*function. *compileCoreToObj *has generated only *.hi file because
>exception has been raised.
>- I have found a way to produce valid interface file
>- I have discovered, why *compileCoreToObj *raises exceptions. It was
>because *stubDir* field in *DynFlags *structure has to be set for proper
>execution.
>- Artifacts produced by *compileCoreToObj *for a non-executable module are:
>interface file and assembly output.
> 
> The last point is my main problem for now. I supposed that object file will
> be generated, as it is generated by GHC executed on haskell module.
> Code used for my tests is as follows:
> 
> A.hs:
> 
> import GHC
> > import DynFlags
> > import GHC.Paths
> > import qualified Debug.Trace as T
> > import Panic
> > import HscMain
> > import HscTypes
> > import Name
> > import UniqFM
> > main = do
> > core <- getCore
> > getLine
> > compile HscAsm "foo" core
> > getCore = defaultErrorHandler defaultFatalMessager defaultFlushOut
> > $ runGhc (Just libdir) $ do
> > df <- getSessionDynFlags
> > setSessionDynFlags df
> > core <- compileToCoreModule "B.hs"
> > return core
> > compile target output_fn core = defaultErrorHandler defaultFatalMessager
> > defaultFlushOut
> > $ runGhc (Just libdir) $ do
> > df <- getSessionDynFlags
> > setSessionDynFlags df { hscTarget = target , stubDir = Just
> > "./stub" }
> 
> compileCoreToObj False core output_fn "bar"
> 
> B.hs:
> 
> > module B (foo) where
> > foo ::  a -> a
> > foo = id
> > bar :: Eq a => a -> a -> Bool
> > bar = (==)
> 
> 
> *getCore *and *compile* are separated to make sure, no flags set by the
> first function were used by the second  one.
> *getLine *is used here to stop an execution of test for cleaning output
> directory form files generated by *getCore*.
> 
> Is there a way to get an object file as a result of *compileCoreToObj*?
> 
> Regards,
> MWawrzos
> 
> 2015-10-08 19:02 GMT+02:00 Edward Z. Yang <ezy...@mit.edu>:
> 
> > If we look at the source code for hscCompileCore, it would seem that it
> > creates a ModGuts with mkModGuts which has an empty mg_exports, which
> > means that in all cases there will be no exported items.  So it's not
> > very useful!  You should file a bug.
> >
> > We should fix this, but in the mean time, you could simply copypaste the
> > definition of hscCompileCore, and modify it so that you do set up
> > the ModGuts correctly with a real mg_exports field.
> >
> > Edward
> >
> > Excerpts from Marek Wawrzos's message of 2015-10-08 07:22:01 -0700:
> > > Hello,
> > >
> > > I'm trying to compile some module with GHC API. I'm going to feed GHC
> > with
> > > Core generated by me.
> > >
> > > So far is noticed, that function compileCoreToObj ends with an runtime
> > > error on each call. In spide of this function produces some *.o and *.hi
> > > files. However, produced interface file does not contain any item in
> > > exports field, what makes compiled module unusable.
> > >
> > > Because of this problem, I tried to achieve my goal by using steps
> > > described here: https://wiki.haskell.org/GHC/As_a_library (the second
> > > example)
> > > I was able to print out Core produced form file. If I'm not wrong,
> > > modifying structures passing on between sequent calls does not effect on
> > > produced *.hi and *.o files. Both files are generated by `load
> > > LoadAllTargets' call, and further calls (parseModule, loadModule, ...)
> > does
> > > not effect on generated files.
> > >
> > > Could You give me any advices in that topic? Am I right about
> > > compileCoreToObj and functions mentioned above?
> > >
> > > Best Regards,
> > > Marek
> >
> 
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fwd: Is anything being done to remedy the soul crushing compile times of GHC?

[Edward Z. Yang]

Another large culprit for performance is that the fact that ghc --make
must preprocess and parse the header of every local Haskell file:
https://ghc.haskell.org/trac/ghc/ticket/618 (as well
as https://ghc.haskell.org/trac/ghc/ticket/1290).  Neil and I
have observed that when you use something better (like Shake)
recompilation performance gets a lot better, esp. when you
have a lot of modules.

Edward

Excerpts from Ben Gamari's message of 2016-02-17 00:58:43 -0800:
> Evan Laforge  writes:
> 
> > On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari  wrote:
> >> Multiple modules aren't a problem. It is dependencies on Hackage
> >> packages that complicate matters.
> >
> > I guess the problem is when ghc breaks a bunch of hackage packages,
> > you can't build with it anymore until those packages are updated,
> > which won't happen until after the release?
> >
> This is one issue, although perhaps not the largest. Here are some of
> the issues I can think of off the top of my head,
> 
>  * The issue you point out: Hackage packages need to be updated
> 
>  * Hackage dependencies mean that the performance of the testcase is now
>dependent upon code over which we have no control. If a test's
>performance improves is this because the compiler improved or merely
>because a dependency of the testcase was optimized?
> 
>Of course, you could maintain a stable fork of the dependency, but
>at this point you might as well just take the pieces you need and
>fold them into the testcase.
> 
>  * Hackage dependencies greatly complicate packaging. You need to
>somehow download and install them. The obvious approach here is to
>use cabal-install but it is unavailable during a GHC build
> 
>  * Hackage dependencies make it much harder to determine what the
>compiler is doing. If I have a directory of modules, I can rebuild
>all of them with `ghc --make -fforce-recomp`. Things are quite a bit
>trickier when packages enter the picture.
> 
> In short, the whole packaging system really acts as nothing more than a
> confounding factor for performance analysis, in addition to making
> implementation quite a bit trickier.
> 
> That being said, developing another performance testsuite consisting of
> a set of larger, dependency-ful applications may be useful at some
> point. I think the first priority, however, should be nofib.
> 
> > From a certain point of view, this could be motivation to either break
> > fewer things, or to patch breaking dependents as soon as the breaking
> > patch goes into ghc.  Which doesn't sound so bad in theory.  Of course
> > someone would need to spend time doing boring maintenance, but it
> > seems that will be required regardless.  And ultimately someone has to
> > do it eventually.
> >
> Much of the effort necessary to bring Hackage up to speed with a new GHC
> release isn't due to breakage; it's just bumping version bounds. I'm
> afraid the GHC project really doesn't have the man-power to do this work
> consistently. We already owe hvr a significant amount of gratitude for
> handling so many of these issues leading up to the release.
> 
> > Of course, said person's boring time might be better spent directly
> > addressing known performance problems.
> >
> Indeed.
> 
> > My impression from the reddit thread is that three things are going on:
> >
> > 1 - cabal has quite a bit of startup overhead
> 
> Yes, it would be great if someone could step up to look at Cabal's
> performance. Running `cabal build` on an up-to-date tree of a
> moderately-sized (10 kLoC, 8 components, 60 modules) Haskell project I
> have laying around takes over 5 seconds from start-to-finish.
> 
> `cabal build`ing just a single executable component takes 4 seconds.
> This same executable takes 48 seconds for GHC to build from scratch with
> optimization and 12 seconds without.
> 
> > 2 - ghc takes a long time on certain inputs, e.g. long list literals.
> > There are probably already tickets for these.
> >
> Indeed, there are plenty of pathological cases. For better or worse,
> these are generally the "easier" performance problems to tackle.
> 
> > 3 - and of course, ghc can be just generally slow, in the million tiny
> > cuts sense.
> >
> And this is the tricky one. Beginning to tackle this will require that
> someone perform some very careful measurements on current and previous
> releases.
> 
> Performance issues are always on my and Austin's to-do list, but we are
> unfortunately rather limited in the amount of time we can spend on these
> due to funding considerations. As Simon mentioned, if someone would like
> to see this fixed and has money to put towards the cause, we would love
> to hear from you.
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: New type of ($) operator in GHC 8.0 is problematic

[Edward Z. Yang]

I'm not really sure how you would change the type of 'id' based on
a language pragma.

How do people feel about a cosmetic fix, where we introduce a new
pragma, {-# LANGUAGE ShowLevity #-} which controls the display of levity
arguments/TYPE.  It's off by default but gets turned on by some
extensions like MagicHash (i.e. we only show levity if you have
enabled extensions where the distinction matters).

Edward

Excerpts from Christopher Allen's message of 2016-02-04 15:20:34 -0800:
> This seems worse than FTP IMO. It's considerably noisier, considerably
> rarer a concern for Haskell programmers, and is wa beyond the scope of
> most learning resources.
> 
> Is there a reason this isn't behind a pragma?
> 
> On Thu, Feb 4, 2016 at 5:02 PM, Manuel M T Chakravarty  > wrote:
> 
> > To be honest, I think, it is quite problematic if an obscure and untested
> > language extension (sorry, but that’s what it is right now) bleeds through
> > into supposedly simple standard functionality. The beauty of most of GHC’s
> > language extensions is that you can ignore them until you need them.
> >
> > Has this ever been discussed more widely? I expect that every single
> > person teaching Haskell is going to be unhappy about it.
> >
> > Manuel
> >
> >
> > > Richard Eisenberg :
> > >
> > > I agree with everything that's been said in this thread, including the
> > unstated "that type for ($) is sure ugly".
> > >
> > > Currently, saturated (a -> b) is like a language construct, and it has
> > its own typing rule, independent of the type of the type constructor (->).
> > But reading the comment that Ben linked to, I think that comment is out of
> > date. Now that we have levity polymorphism, we can probably to the Right
> > Thing and make the kind of (->) more flexible.
> > >
> > > Richard
> > >
> > > On Feb 4, 2016, at 3:27 PM, Ryan Scott  wrote:
> > >
> > >>> My understanding was that the implicitly polymorphic levity, did (->)
> > not change because it's a type constructor?
> > >>
> > >> The kind of (->) as GHCi reports it is technically correct. As a kind
> > >> constructor, (->) has precisely the kind * -> * -> *. What's special
> > >> about (->) is that when you have a saturated application of it, it
> > >> takes on a levity-polymorphic kind. For example, this:
> > >>
> > >>   :k (->) Int# Int#
> > >>
> > >> would yield a kind error, but
> > >>
> > >>   :k Int# -> Int#
> > >>
> > >> is okay. Now, if you want an explanation as to WHY that's the case, I
> > >> don't think I could give one, as I simply got this information from
> > >> [1] (see the fourth bullet point, for OpenKind). Perhaps SPJ or
> > >> Richard Eisenberg could give a little insight here.
> > >>
> > >>> Also does this encapsulate the implicit impredicativity of ($) for
> > making runST $ work? I don't presently see how it would.
> > >>
> > >> You're right, the impredicativity hack is a completely different
> > >> thing. So while you won't be able to define your own ($) and be able
> > >> to (runST $ do ...), you can at least define your own ($) and have it
> > >> work with unlifted return types. :)
> > >>
> > >> Ryan S.
> > >> -
> > >> [1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
> > >>
> > >> On Thu, Feb 4, 2016 at 2:53 PM, Christopher Allen 
> > wrote:
> > >>> My understanding was that the implicitly polymorphic levity, did (->)
> > not
> > >>> change because it's a type constructor?
> > >>>
> > >>> Prelude> :info (->)
> > >>> data (->) a b -- Defined in ‘GHC.Prim’
> > >>> Prelude> :k (->)
> > >>> (->) :: * -> * -> *
> > >>>
> > >>> Basically I'm asking why ($) changed and (->) did not when (->) had
> > similar
> > >>> properties WRT * and #.
> > >>>
> > >>> Also does this encapsulate the implicit impredicativity of ($) for
> > making
> > >>> runST $ work? I don't presently see how it would.
> > >>>
> > >>> Worry not about the book, we already hand-wave FTP effectively. One
> > more
> > >>> type shouldn't change much.
> > >>>
> > >>> Thank you very much for answering, this has been very helpful already
> > :)
> > >>>
> > >>> --- Chris
> > >>>
> > >>>
> > >>> On Thu, Feb 4, 2016 at 12:52 PM, Ryan Scott 
> > wrote:
> > 
> >  Hi Chris,
> > 
> >  The change to ($)'s type is indeed intentional. The short answer is
> >  that ($)'s type prior to GHC 8.0 was lying a little bit. If you
> >  defined something like this:
> > 
> >    unwrapInt :: Int -> Int#
> >    unwrapInt (I# i) = i
> > 
> >  You could write an expression like (unwrapInt $ 42), and it would
> >  typecheck. But that technically shouldn't be happening, since ($) ::
> >  (a -> b) -> a -> b, and we all know that polymorphic types have to
> >  live in kind *. But if you look at unwrapInt :: Int -> Int#, the type
> >  Int# certainly doesn't live in *. So why is this happening?
> > 
> >  The long answer is that 

GHC build time graphs

[Edward Z. Yang]

Joachim,

Anthony Cowley was recently complaining on Twitter that
building GHC takes 39.5% longer now than it did for 7.10.1:
https://twitter.com/a_cowley/status/692481516744634368

Do we have graphs for these metrics, e.g. can we see the breakdown
of which commits increased the build time?

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] Shaking up GHC

[Edward Z. Yang]

I mean, it would be nice if ghc --make was reimplemented using
Shake, but there are a few problems (most notably the use of
.shake metadata store) which make it hard to be bug-for-bug
compatible with the old make.

Edward

Excerpts from Ben Gamari's message of 2016-01-23 10:45:50 -0800:
> Tuncer Ayaz  writes:
> 
> > On 23 January 2016 at 18:16, Herbert Valerio Riedel wrote:
> >
> >> On 2016-01-23 at 17:58:12 +0100, Tuncer Ayaz wrote:
> >>
> >> [...]
> >>
> >> > My suggestion, and what I'd expect, is to make Shake part of GHC's
> >> > included lib, just like process or xhtml.
> >>
> >> please don't; the only reason we include process and xhtml because
> >> we *have* to. The less we *have* to bundle, the better.
> >
> > If there's a good way in 8.x (with new Cabal and Shake) to avoid
> > bundling, while using Shake for ghc --make, then I'm all for it. My
> > concern is that it has to be as simple as it's currently to install
> > ghc on a random Linux distro, in order for someone to use a Shakefile.
> > I want more Shakefile users :).
> 
> I'm not sure I follow. Edward's --make support is a front-end plugin;
> as far as I know there has been no discussion of shipping it with
> GHC-proper. It merely makes use of the new front-end plugin facility.
> Perhaps I'm misunderstanding something here?
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Host-Oriented Template Haskell

[Edward Z. Yang]

I've filed a Trac ticket for this: 
https://ghc.haskell.org/trac/ghc/ticket/11470#ticket

Edward

Excerpts from Moritz Angermann's message of 2016-01-20 22:55:36 -0800:
> Colour me an interested party!  For iOS one currently builds two
> different ghc compiler.  One for the simulator (i386) and one for the
> actual device (arm).  My initial work on bringing ghcjs’s TH support,
> (which basically ships the TH out to a process on the target to compile
> and brings back the compiled TH into the cross compiler) to ghc, was
> based on the idea of having a TH handler plugin, which would handle the
> TH parts, and could then be adapted for different TH situations.  This
> of course could only work if the plugin was compiled with the same version
> of ghc, that the cross compiler was.
> 
> I wonder if the multi-target pipeline might be simpler to achieve with
> the llvm backend.
> 
> If someone is taking a shot at this, I’d like to help!
> 
> Cheers,
>  Moritz
> 
> > On Jan 21, 2016, at 2:44 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> > 
> > Yes, in principle, a compiler that supports cross-compiling to many
> > targets without needing to be configured (at build time) which
> > target it should support is ideal.  Unfortunately, currently GHC
> > relies on autoconf to determine all of the necessary parameters
> > for a cross-compile.  I am not sure how feasible it would be to
> > allow these parameters to be configured at runtime: it might be
> > easy, it might be hard!  (And of course you have to arrange
> > to have cross-compiled all the boot libraries too...)
> > 
> > In any case, I think that a GHC that permits changing cross-compilation
> > targets at runtime is a fine goal, and if it is supported, then we
> > would only have to make adjustments to GHC internally to distinguish
> > between the interfaces/objects for various targets (including itself.)
> > 
> > Edward
> > 
> > Excerpts from Ericson, John's message of 2016-01-20 21:23:28 -0800:
> >> Oops, Sent just to Edward by mistake.
> >> 
> >> 
> >> 
> >> That all sounds good to me---I think what I was thinking all along in
> >> fact, unless I am still missing some nuance :).
> >> 
> >> My idea of using a multi-target compiler was to avoid needing stage0
> >> to be the same version as stage1 (or adding a new stage, stage1 as in
> >> your alternative). The cross compiler is multi-target so it doesn't
> >> need to link another compiler to load plugins / run "host-oriented
> >> Template Haskell". I mentioned the usecase of trying to build a stage2
> >> which needs plugins / Host-Oriented Template Haskell, but it could
> >> well apply to building anything else with the need for those to things
> >> (and not normal TH, which cannot be built with a cross compiler)
> >> 
> >> In diagrams, rather than:
> >> 
> >>> stage0 (version foo, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> platform-y)
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> or
> >> 
> >>> stage0 (version bar, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> platform-x) ->
> >>> ==> stage2 (version foo, platform-x -> platform-y) ->
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> do just
> >> 
> >>> stage0 (version bar, platform-x -> platform-x)
> >>> ==> stage1 (version foo, platform-x -> {platform-x, platform-y})
> >>> ==> some program (with plugins, with host-oriented TH, without normal TH)
> >> 
> >> Now it may be that building such a multi-target compiler today is just
> >> as arduous as making sure one has a native compiler of the same
> >> version before building the cross compiler, so my idea is of no
> >> practical value. But if so, I hope in the long term that could be
> >> fixed.
> >> 
> >> John
> >> 
> >> On Wed, Jan 20, 2016 at 8:37 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> >>> Hello John,
> >>> 
> >>> Almost!
> >>> 
> >>> As you point out, if you just want a cross-compiler, you don't
> >>> need to build stage2.  The real problem is that we want stage0
> >>> to be *the same version* as stage1, so that stage0 has the correct
> >>> API in order to load stage0 libraries which are going to be used
&

Re: Fwd: Host-Oriented Template Haskell

[Edward Z. Yang]

Hello John

You may find this implementation ticket of interest:
https://ghc.haskell.org/trac/ghc/ticket/11378

Edward

Excerpts from Ericson, John's message of 2016-01-19 15:15:15 -0800:
> Cross-posting this as was suggested on the Haskell-Cafe list. While I
> envision this as normal feature that anyone can use, in practice its
> biggest consumers would be GHC devs.
> 
> John
> 
> -- Forwarded message --
> From: Ericson, John 
> Date: Tue, Jan 19, 2016 at 1:17 PM
> Subject: Host-Oriented Template Haskell
> To: Haskell-Cafe 
> 
> 
> As is well known, TH and cross-compiling do not get along. There are
> various proposals on how to make this interaction less annoying, and I
> am not against them. But as I see it, the problem is largely inherent
> to the design of TH itself: since values can (usually) be lifted from
> compile-time to run-time, and normal definitions from upstream modules
> to downstream modules' TH, TH and normal code must "live in the same
> world".
> 
> Now this restriction in turn bequeaths TH with much expressive power,
> and I wouldn't advocate getting rid of it. But many tasks do not need
> it, and in some cases, say in bootstrapping compilers[1] themselves,
> it is impossible to use TH because of it, even were all the current
> proposals implemented.
> 
> For these reason, I propose a new TH variant which has much harsher
> phase separation. Normal definitions from upstream modules can not be
> used, lifting values is either not permitted or is allowed to fail
> (because of missing/incompatible definitions), and IO is defined to
> match the behavior of the host, not target, platform (in the cross
> compiling case). The only interaction between the two phases is that
> quoted syntax is resolved against the the run-time phase's definitions
> (just like today).
> 
> Some of you may find this a shoddy substitute for defining a subset of
> Haskell which behaves identically on all platforms, and optionally
> constraining TH to it. But the big feature that my proposal offers and
> that one doesn't is to be able to independently specify compile-time
> dependencies for the host-oriented TH---this is analogous to the
> newish `Setup.hs` dependencies. That in turns leads to what I think is
> the "killer app" for Host-Oriented TH: exposing the various
> prepossessors we use (alex, happy, hsc2hs, even CPP) into libraries,
> and side-stepping any need for "executable dependencies" in Cabal.
> Note also that at least hsc2hs additionally requires host-IO---there
> may not even exist a C compiler on the target platform at all.
> 
> Finally, forgive me if this has been brought up before. I've been
> thinking about this a while, and did a final pass over the GHC wiki to
> make sure it wasn't already proposed, but I could have missed
> something (this is also my first post to the list).
> 
> John
> 
> [1]: 
> https://github.com/ghcjs/ghcjs/blob/master/lib/ghcjs-prim/GHCJS/Prim/Internal/Build.hs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghci and unfoldings?

[Edward Z. Yang]

Does passing -fobject-code solve your problem?

Edward

Excerpts from Conal Elliott's message of 2016-01-17 22:18:49 -0800:
> Hi Brandon. Thanks for the reply. I’m not sure that it addresses what I was
> trying to ask. GHCi *does* invoke plugins and even reloads those plugins
> dynamically when their source code changes. So in this sense ghci does
> enable optimization, even if it doesn’t perform much optimization on its
> own. And of course plugins and unfolding are not just about optimization.
> 
> I’m not looking for ghci to do optimization, but rather to enable me to
> more easily develop my GHC plugins. It’s *almost* there already. I just
> need access to unfoldings from other modules for my plugin’s use.
> 
> For context, I’m rebuilding my Haskell-to-hardware compiler
> , which relies on
> giving a non-standard but principled interpretation of Haskell programs via
> a conversion through the language of cartesian closed categories (CCCs).
> The first back-end is hardware generation (e.g., via Verilog), and I have
> plans for several other CCC-based interpretations.
> 
> In addition to facilitating my plugin development, hosting in ghci will
> make it much more pleasant for others to *use* the plugin during
> exploratory programming, just as with ghci use in general. With access to
> unfoldings, users will be able to generate circuit diagrams and Verilog
> like those in my compiler talk immediately and directly from within ghci. I
> also intend to make a GPU back-end for fast interactive graphics etc, which
> would be much more fun in ghci than with batch compilation.
> I hope this explanation clarifies my goals and motivation. I hope there’s a
> way to access unfoldings from ghci currently or with a small amount of
> effort.
> 
> Regards, - Conal
> 
> On Sun, Jan 17, 2016 at 7:00 PM, Brandon Allbery 
> wrote:
> 
> > On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott  wrote:
> >
> >> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
> >> speed up development. I'm able to do so, except that my plugin critically
> >> needs access to unfoldings, which appear to be unavailable in ghci. A
> >> little experimenting with ghc shows me that "-O" is the key, but "-O" is
> >> incompatible with "--interactive" (as in ghci). Is there any way to
> >> persuade ghci to make unfoldings available?
> >
> >
> > I think unfoldings are only done as part of optimization, and the bytecode
> > backend doesn't support optimization at all.
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> > associates
> > allber...@gmail.com
> > ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> > http://sinenomine.net
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Trac internal error

[Edward Z. Yang]

When I posted the (attached) POST request to newticket, I got the
following error.  It did correctly add the ticket to the
database.  I've elided the form token from this.

Trac detected an internal error:

AttributeError: 'NoneType' object has no attribute 'split'

Here's the contents of the POST request (my guess is that I put
something bad in the CC field):

field_summary=Turn+on+SplitSections+by+default
field_reporter=ezyang
field_description=This+is+a+general+tracking+bug+for+what+is+blocking+us+from+turning+on+`SplitSections`+by+default,+implemented+in+#8405.+Fixing+this,+and+mandating+use+of+the+gold+linker,+will+help+solve+#11285+(split+objects+make+linking+slow),+and+will+make+ghc-split+unnecessary,+mooting+#9832.

I+encountered+some+misinformation+while+talking+to+people+about+this+feature,+regarding+whether+or+not+this+feature+only+supported+by+Apple-style+linkers+(i.e.+on+Mac+OS+X)?+On+IRC+I+heard+a+claim+made+that+`--split-sections`+was+only+supported+by+Mac+OS+X.+However,+olsner+pointed+out+that+`-split-sections`+on+GHC+was+OUR+reimplementation+of+the+feature,+and+likely+does+not+work+on+Mac+OS+X.+https://github.com/snowleopard/shaking-up-ghc/issues/153#issuecomment-171078800++A+later+comment+mentioned+that+

So,+can+we+turn+on+this+feature+by+default?+Does+it+subsume+split-objs?+Does+it+work+on+all+the+tier-1+platforms?+It+would+be+nice+if+bgamari,+olsner+and+co+could+weigh+in+here.+Thanks!
field_type=task
field_priority=normal
field_milestone=8.2.1
field_component=Build+System
field_version=8.0.1-rc1
field_keywords
field_cc=bgamari,+olsner
field_os=Unknown/Multiple
field_architecture=Unknown/Multiple
field_failure=None/Unknown
field_testcase
field_blockedby
field_blocking=#11285
field_related
field_differential
field_wikipage
field_owner=<+default+>
sfp_email
sfph_mail
submit=Create+ticket
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reify and separating renamer+TH from type-checking

[Edward Z. Yang]

I implemented the refactoring to run the renamer and TH splices all
first before doing any type-checking, but actually there's a problem:
Template Haskell splices can call 'reify', which needs the type
information in order to supply the information about the identifiers
in question.  I can't think of any good way around this problem.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How does TH know to load non-profiled object code when compiling profiled?

[Edward Z. Yang]

I've been looking for the code that implements this logic, but I can't
seem to find it.  (For what it's worth, compiler plugins *incorrectly*
load the profiling interface when compiling profiled, which is wrong
and something I'd like to fix.)  Simon Marlow, do you happen to know?

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How does TH know to load non-profiled object code when compiling profiled?

[Edward Z. Yang]

Thanks!

In fact, I have just realized that Template Haskell does something
very dodgy when it is loading profiled code: it will use the
*profiled* interface files (things that are used in splices
are brought into scope with import) to figure out what is going on with
the *non-profiled* object files.  I'm a bit surprised that we haven't
had any terrifying bugs related to this.  (It should be relatively
easy to trigger horrible brokenness; just compile hi and p_hi with
different code so that they are inconsistent.)

Edward

Excerpts from Simon Marlow's message of 2016-01-07 09:42:27 -0800:
> On 07/01/2016 16:28, Edward Z. Yang wrote:
> > I've been looking for the code that implements this logic, but I can't
> > seem to find it.  (For what it's worth, compiler plugins *incorrectly*
> > load the profiling interface when compiling profiled, which is wrong
> > and something I'd like to fix.)  Simon Marlow, do you happen to know?
> 
> Yeah, I've been fiddling with this lately.  It's this function here: 
> https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/ghci/Linker.hs;c78fedde7055490ca6f6210ada797190f3c35d87$520-539
> 
> Cheers,
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remote GHCi

[Edward Z. Yang]

I was reviewing some history here, and I realized
that the GHCJS folks had previous implemented this:

https://mail.haskell.org/pipermail/ghc-devs/2015-November/010478.html

What ever happened to this line of work?  Does remote GHCi
subsume it?

Edward

Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800:
> Hi folks - I've been thinking about changing the way we run interpreted 
> code so that it would be run in a separate process.  It turns out this 
> has quite a few benefits, and would let us kill some of the really 
> awkward hacks we have in GHC to work around problems that arise because 
> we're running interpreted code and the compiler on the same runtime.
> 
> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
> 
> I'd be interested to hear if anyone has any thoughts around this, 
> particularly if doing this would make your life difficult in some way. 
> Are people relying on dynCompileExpr for anything?
> 
> Cheers,
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: uniqAway and collisions

[Edward Z. Yang]

Hello Bartosz,

The principle between uniqAway is described in the "Secrets of the GHC
Inliner" paper

http://research.microsoft.com/en-us/um/people/simonpj/Papers/inlining/

I doubt there's a bug in uniqAway; it's more likely the in scope set is
not correct.

Edward

Excerpts from Bartosz Nitka's message of 2016-01-05 09:39:54 -0800:
> Hi,
> 
> I'm running into core lint issues [1] with my determinism patch [2] and
> they appear to come down to uniqAway coming up with a Unique that's already
> used in the expression. That creates a collision, making next substitution
> substitute more than it needs.
> 
> I have 2 questions:
> 
> 1. When is it safe to use uniqAway?
> 
> 2. Is my conclusion reasonable given this trace: (full trace here [3])?
> 
> I. We start out with (line 123):
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/coreSyn/CoreLint.hs:659:12 in ghc:CoreLint
>   e: EqConstr
>@ (s_Xpw a_Xpz)
>@ (s_Xpw b_Xpy)
>@ s_Xpw
>@ b_Xpy
>@ a_Xpz
>@~ (_N :: s_Xpw a_Xpz ~# s_Xpw a_Xpz)
>@~ (_N :: s_Xpw b_Xpy ~# s_Xpw b_Xpy)
>dt_aq3
>   fun: EqConstr
>   args: [TYPE: s_Xpw a_Xpz, TYPE: s_Xpw b_Xpy, TYPE: s_Xpw,
>  TYPE: b_Xpy, TYPE: a_Xpz, CO: _N, CO: _N,
>  dt_aq3]
>   fun_ty: forall a_apr b_aps (s_Xpw :: * -> *) b_Xpy a_Xpz.
>   (a_apr ~# s_Xpw a_Xpz, b_aps ~# s_Xpw b_Xpy) =>
>   EqTypes a_Xpz b_Xpy -> EqTypes a_apr b_aps
> 
> II. Then we create s_Xpz with uniqAway (line 499) which has the same unique
> as a_Xpz above
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/types/TyCoRep.hs:1947:5 in ghc:TyCoRep
>   old_var: s_Xpy
>   new_var: s_Xpz
> 
> III. Which causes trouble when we want to substitute s_Xpw for s_Xpz and we
> substitute a_Xpz as well (line 733):
> 
> CallStack (from ImplicitParams):
>   pprSTrace, called at compiler/coreSyn/CoreLint.hs:813:11 in ghc:CoreLint
>   substTyWith [tv] [arg_ty] body_ty forall b_XpB a_XpD.
> (s_Xpw s_Xpw ~# s_Xpw a_XpD, s_Xpw
> b_Xpy ~# s_Xpw b_XpB) =>
> EqTypes a_XpD b_XpB -> EqTypes (s_Xpw
> s_Xpw) (s_Xpw b_Xpy)
> 
> The uniqAway comes from substTyVarBndrCallback which blames to nokinds
> patch.
> 
> Thanks,
> Bartosz
> [1] https://phabricator.haskell.org/P77
> [2] https://phabricator.haskell.org/P76
> [3] https://phabricator.haskell.org/P78
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: arcanist-external-json-linter missing commits

[Edward Z. Yang]

It does not, but I have discovered that the problem is related to
my git-new-workdir setup, so I think I'll just fix it myself.

(New submodule went into global .git but git-new-workdir can't deal
with that.)

Edward

Excerpts from Alan & Kim Zimmerman's message of 2015-12-10 13:50:25 -0800:
> I was advised to
> 
> git submodule update --init
> 
> and it did solve the problem
> 
> Alan
> 
> On Thu, Dec 10, 2015 at 11:48 PM, Edward Z. Yang <ezy...@mit.edu> wrote:
> > On a git submodule update on HEAD, I get:
> >
> > fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
> > Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in 
> > submodule path '.arc-linters/arcanist-external-json-linter'
> >
> > Edward
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

arcanist-external-json-linter missing commits

[Edward Z. Yang]

On a git submodule update on HEAD, I get:

fatal: reference is not a tree: 85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9
Unable to checkout '85ece0f8653e7b1e7de6024d372cfeaf36ab5fa9' in submodule 
path '.arc-linters/arcanist-external-json-linter'

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Plugins: Accessing unexported bindings

[Edward Z. Yang]

If you have control over the Ids for the properties, if you can
arrange for them to be marked "local exported" that should solve
your problem.

Edward

Excerpts from Levent Erkok's message of 2015-12-05 23:01:29 -0800:
> Hello,
> 
> The mg_binds field of the ModGuts seem to only contain the bindings that
> are exported from the module being compiled.
> 
> I guess GHC must be running user-plugins after it drops the bindings that
> are not exported, which makes perfect sense for most use cases. However,
> I'm working on a plugin where the end-programmer embeds "properties" in the
> form of functions inside his/her code, which are not necessarily exported
> from the module under consideration.
> 
> Is there a way to access all top-level bindings in a module from a plugin,
> even if those bindings are not exported?
> 
> Thanks,
> 
> -Levent.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: The GHC 8.0 feature freeze is coming

[Edward Z. Yang]

Based on my cursory look at the patch, I think it's unlikely to
break existing functionality in subtle ways.  So I'm OK with
trying to ship it in 8.0

Edward

Excerpts from Simon Marlow's message of 2015-12-03 09:50:37 -0800:
> On 03/12/2015 13:50, Ben Gamari wrote:
> > Luite Stegeman  writes:
> >
> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
> >> working on upgrading GHCJS to work with the master branch, but I haven't
> >> quite finished yet. This change would clearly require some restructuring of
> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
> >> to test the changes. Also the recent removal of boot file merging
> >> reintroduces a problem with that I'm not sure can be fixed without adding a
> >> new hook.
> >>
> > Simon, what do you think about this?
> >
> > I'm a bit worried that this patch is quite late and breaks users like
> > Luite. Nevertheless, I am willing to hear arguments for merging.
> 
> It doesn't have to go in, but I think it would be nice.  I'd like to 
> have it out for at least one major release in a disabled-by-default 
> state so that we can experiment with it.  But as far as my particular 
> goals for this feature are concerned, I'll backport the patch to 7.10 
> and use it in our local GHC build at Facebook regardless.
> 
> Luite - the hooks you use are still intact, so I don't think you have to 
> do any major restructuring in GHCJS until you're ready.  What I've 
> implemented will almost certainly need work to be usable or shareable 
> with GHCJS, and it's not clear to me exactly what the changes will look 
> like, but for the time being I thought the changes should not impact 
> GHCJS's implementation of TH & GHCi.  I could be wrong though, if so 
> please let me know how it breaks you.
> 
> Cheers,
> Simon
> 
> >> What's the policy on adding hooks or GHC API tweaks after the freeze?
> >>
> > We'll need to work that out when we get to that point. It largely
> > depends upon how confined and "safe" a change appears to be. That being
> > said, given how much other churn has happened for this release, I don't
> > think we want to be sloppy with merge discipline this time around.
> >
> > Austin, what do you think?
> >
> > Cheers,
> >
> > - Ben
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: spj-wildcard-refactor

[Edward Z. Yang]

IMO, reset is a fine way to do this if you don't care about any of this
history.  But Simon, you should use 'git reset --soft master' so that
you don't have to re-add any new files (if you have any!).

Edward

Excerpts from Alan & Kim Zimmerman's message of 2015-11-20 09:42:26 -0800:
> I would imagine
> 
> git pull # Get master up to date
> git checkout wip/spj-wildcard-refactor
> git rebase -i master
> 
> The -i will let you flatten commits
> 
> See
> https://robots.thoughtbot.com/git-interactive-rebase-squash-amend-rewriting-history
> 
> Alan
> 
> On Fri, Nov 20, 2015 at 7:14 PM, Simon Peyton Jones 
> wrote:
> 
> > Status on my spj-wildcard-refactor patch
> >
> > · I’m down to one test failure a modest perf regression on T3064.
> >   This is really a test of type family reduction which is nothing to do
> > with my changes, so I have no idea what’s happening there.  I’m waiting
> > till I can build a profiled compiler to test.
> >
> >
> >
> > What’s the best workflow for to take my branch with tons of wibble-ish
> > patches, and commit to HEAD with a small number of sensible patches.
> >
> >
> >
> > I was thinking:
> >
> > · Git checkout wip/spj-wildcard-refactor
> >
> > · Git merge master
> >
> > · Git reset master   (leaves working files alone)
> >
> > · Now commit patches
> >
> > Is that right?
> >
> >
> >
> > Simon
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Feature status for GHC 8.0

[Edward Z. Yang]

Excerpts from Ben Gamari's message of 2015-11-17 07:22:22 -0800:
>  * Backpack work    Edward Z. Yang
>   How is this coming along?

Had a chat with SPJ about this and we've decided that Backpack still
needs stabilizing, and there is not much gain to be had shipping it
until it is very nearly done, so we are not going to be targeting
this patch for GHC 8.0

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Remote GHCi

[Edward Z. Yang]

I like it.

Let me make sure that I've understand this correctly:

- While GHC doesn't need to be built with profiling if you
  want to use profiling in the interpeter, you will need
  multiple versions of the "server binary" for each way
  you want to implement.  This should be pretty reasonable,
  because the server binary is a lot smaller than GHC.

- It seems that GHC will ship bytecode and object code
  to the server binary.  In this case, the interpeted
  code and compiled code CAN share data among each other;
  it is just when you want to share data with GHC that
  you must implement serialization.  (Also, external
  bytecode format?!)

- Many people have commented that their extensions use
  dynCompileExpr.  I think these cases can be accommodated,
  by making the server binary not a standalone application,
  but a LIBRARY which can be linked against a custom
  application (e.g. IHaskell).  The messages to be sent
  should not be the values/file descriptors, but the
  invocations that are being requested of GHC. Unfortunately,
  this does seem to imply that most things would have to
  be rewritten from scratch to not use the ghc-api, but
  use whatever this new library's interface over the message
  passing is.

Honestly, it seems like the hard part is defining the message-passing
protocol, esp. since the GHC API is as overgrown as it is today.

Edward

Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800:
> Hi folks - I've been thinking about changing the way we run interpreted 
> code so that it would be run in a separate process.  It turns out this 
> has quite a few benefits, and would let us kill some of the really 
> awkward hacks we have in GHC to work around problems that arise because 
> we're running interpreted code and the compiler on the same runtime.
> 
> I summarised the idea here: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
> 
> I'd be interested to hear if anyone has any thoughts around this, 
> particularly if doing this would make your life difficult in some way. 
> Are people relying on dynCompileExpr for anything?
> 
> Cheers,
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On the record pattern synonyms patch

[Edward Z. Yang]

Hello Matthew,

I have a question about the record pattern synonyms patch
which you landed in the last month (2a74a64e8329ab9e0c74bec47198cb492d25affb).

In IfaceSyn, you made the following change:

 data IfaceIdDetails
   = IfVanillaId
-  | IfRecSelId IfaceTyCon Bool
+  | IfRecSelId (Either IfaceTyCon IfaceDecl) Bool
   | IfDFunId

I don't understand why IfRecSelIds can now store IfaceDecls.  Why aren't
these declarations stored at the *top level* list of declarations in an
interface file?  If they are, you shouldn't be storing the entire
IfaceDecl structure when serializing to disk.  If they are not, I
am afraid I don't understand this code.

I also noticed that the commit message is quite long, and many of the
comments I see are not replicated anywhere in the source.  Is there any
reason why they should not be written down as proper notes, with
cross-references from the appropriate code?

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: too many lines too long

[Edward Z. Yang]

For me, a huge reason why the line length errors are annoying
is because there will often be some existing line which is 80+,
and I just need to change one word in it.  Well, now that's
a line length error.

Now, I *could* refactor the line so that it's less than 80.
But this (1) fluffs up the diffs with non-semantic noise, and
(2) makes merge conflicts a lot more likely.

I think the counts thing could help for this case.  But now
suppose there's an existing line which is just barely under
80, and you need to do a mechanical substitution which pushes
it over. Yes, I /could/ reindent it, but it's a huge timesink
for no very good reason.  Usually the best way to eliminate
a long line is to refactor the entire region of code, e.g.
splitting out helper functions or whatnot.

Edward

Excerpts from Richard Eisenberg's message of 2015-11-09 13:02:48 -0800:
> Hi devs,
> 
> We seem to be uncommitted to the ideal of 80-character lines. Almost every 
> patch on Phab I look through has a bunch of "line too long" lint errors. No 
> one seems to do much about these. And Phab's very very loud indication of a 
> lint error makes reviewing the code harder.
> 
> I like the ideal of 80-character lines. I aim for this ideal in my patches, 
> falling short sometimes, of course. But I think the current setting of 
> requiring everyone to "explain" away their overlong lines during `arc diff` 
> and then trying hard to ignore the lint errors during code review is wrong. 
> And it makes us all inured to more serious lint errors.
> 
> How about this: after `arc diff` is run, it will count the number of overlong 
> lines before and after the patch. If there are more after, have the last 
> thing `arc diff` outputs be a stern telling-off of the dev, along the lines of
> 
> > Before your patch, 15 of the edited lines were over 80 characters.
> > Now, a whopping 28 of them are. Can't you do better? Please?
> 
> Would this be ignored more or followed more? Who knows. But it would sure be 
> less annoying. :)
> 
> What do others think?
> 
> Thanks,
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Questions on the RTS C API regarding threads and tasks

[Edward Z. Yang]

Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800:
> We don't have measurements, but we ruled out this possibility for
> performance reasons. Our idea is to make a thin Haskell wrapper 
> around a tiny bit of highly optimized C code. What's the performance
> of locking on MVars?

I still don't know what it is you're trying to do.  If you have a tiny
bit of optimized C code that runs quickly, then you should just make
an unsafe FFI call to it (as for as Haskell's runtime is concerned,
it's just a "fat instruction").

> While we are at it: are primops callable directly from C? I suppose
> calling conventions are different.

Anything is "callable" from C, but yes, you have to do the right
calling convention.  Primops are not easily callable from C.

> A question comes to mind: you mentioned "safe" calls. 
> Are unsafe calls different regarding the detaching of the capability?

An unsafe call does not detach the capability.

> Also: would a patch to make this possible be accepted?
> In particular:
> - add a way to make a "ultraunsafe" foreign call that do not loose the
>   ownership of the calling thread. 

I don't see what the difference between this and an unsafe foreign call
is.

> - add a BlockedOnExplicitSleep flag for tso->why_blocked
>   (And in turn this means managing a different blocking queue, right?)
> - export something to reliably put in sleep and resume threads
>   in this way.
> 
> Is this feasible? Would it be a good idea?

I still don't see why you can't just block the thread on an MVar
(removing it from the main run queues), and then when you want to
resume it write to the MVar.  It'll have an added bonus that you'll
automatically handle masking/async exceptions correctly.

If you find the MVar implementation is too slow, then maybe you
can think about making an optimized implementation which doesn't
use any synchronization / is inline in the TSO so no allocation
is necessary.  But in my opinion this is putting the cart before
the horse.

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Questions on the RTS C API regarding threads and tasks

[Edward Z. Yang]

Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800:
> I’ve started delving into the ghc runtime API to understand
> if everything we need is exposed to the world or if we
> have to modify the runtime itself (which I would avoid if possible).

I agree with this goal in principle, but:

(1) Depending on what you want to do, it may be quite difficult to
do this, and

(2) The RTS is actually quite hackable (as long as you are not
changing any of the interfaces with generated Haskell code, you
could even build your own RTS and have users link against that.)

Something to keep in mind.

> I have a few questions about the functions that the runtime
> exports to the C world regarding the manipulation of tasks:
> 
> - Fundamentally, is there a way for a C function called by a foreign call
>   to suspend the haskell thread that called it, to be resumed later
>   when appropriate? I see that the runtime has a concept of
>   “blocking queue”, but I also see that the functions that work on
>   blocking queues are not exported. I can manage a queue of TSOs myself,
>   but then I need a way to put in sleep the task indefinitely up to a wake 
> signal.
>   In other words, can I sleep and awake haskell threads from a C function
>   called by a foreign call?

Not easily.  If you make a safe foreign call, the capability is given up
before the C code executes, so you actually lose ownership of the
capability and TSO by the time you're running C code.  The only
way to write a foreign call to properly suspend the thread that called
it is a primop function (e.g. stg_putMVar), and the operation is quite
delicate and you will probably want to use some existing (internal)
code in the RTS to do it.

But if you just need to sleep/awake threads, why not just use an MVar?

Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: New error on linux

[Edward Z. Yang]

That's simple, we can just use ifdef to test for macro appearance.
I'll commit a fix.

Edward

Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700:
> Simon Peyton Jones  writes:
> 
> > gcc 4.6.3
> >
> Alright, we'll need to figure out what to do about these differences.
> 
> Cheers,
> 
> - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: New error on linux

[Edward Z. Yang]

OK fixed.

Edward

Excerpts from Edward Z. Yang's message of 2015-10-27 10:36:36 -0700:
> That's simple, we can just use ifdef to test for macro appearance.
> I'll commit a fix.
> 
> Edward
> 
> Excerpts from Ben Gamari's message of 2015-10-27 04:04:42 -0700:
> > Simon Peyton Jones  writes:
> > 
> > > gcc 4.6.3
> > >
> > Alright, we'll need to figure out what to do about these differences.
> > 
> > Cheers,
> > 
> > - Ben
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: recomp013

[Edward Z. Yang]

I couldn't repro on a devel2 build.

Edward

Excerpts from Simon Peyton Jones's message of 2015-10-26 08:24:00 -0700:
> driver/recomp013 is failing, on Linux, on HEAD for me:
> 
> Actual stdout output differs from expected:
> 
> --- ./driver/recomp013/recomp013.stdout.normalised2015-10-26 
> 14:26:51.920153558 +
> 
> +++ ./driver/recomp013/recomp013.run.stdout.normalised  2015-10-26 
> 14:26:51.920153558 +
> 
> @@ -3,5 +3,3 @@
> 
> [2 of 3] Compiling B( B.hs, B.o )
> 
> [3 of 3] Compiling C( C.hs, C.o )
> 
> second run
> 
> -[2 of 3] Compiling B( B.hs, B.o )
> 
> -[3 of 3] Compiling C( C.hs, C.o ) [B changed]
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can't build on Windows

[Edward Z. Yang]

Same here, can't reproduce on 64bit Windows 10.

Edward

Excerpts from Thomas Miedema's message of 2015-10-26 17:54:35 -0700:
> I can not reproduce this on 64bit
> Windows, a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 builds succesfully with
> flavour devel2.
> 
> * Which build flavour are you using? Any other mk/build.mk settings?
> * 32bit or 64bit?
> * Output of `git status` (i.e. did you 'git submodule update'? In case that
> fixes it, I suggest you use git pullall
> 
> for
> all your pulling needs)
> * Try `make maintainer-clean`.
> * In case you use llvm, note that HEAD needs llvm-3.7 now.
> 
> 
> 
> On Mon, Oct 26, 2015 at 10:19 PM, Simon Peyton Jones 
> wrote:
> 
> > Gurgah.   GHC is broken on my windows laptop.  See below.  Anyone have any
> > ideas?  Frustrating.
> >
> > Oddly the symbol is defined in the .exe
> >
> > bash$ nm inplace/bin/ghc-stage2.exe | grep stg_upd_frame
> >
> > 02c248e0 T _stg_upd_frame_info
> >
> > This is admittedly on a branch that I have modified; but I have only
> > modified stuff in the front end, nothing in the RTS etc.  I suppose I will
> > try to build a unmodified HEAD too.
> >
> > can anyone help?  Thanks!
> >
> > Simon
> >
> >
> >
> > bash$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive
> >
> > GHCi, version 7.11.20151026: http://www.haskell.org/ghc/  :? for help
> >
> > ghc-stage2.exe: unable to load package `ghc-prim-0.4.0.0'
> >
> > ghc-stage2.exe:
> > C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.4.0.0.o:
> > unknown symbol `_stg_upd_frame_info'
> >
> > HEAD $
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building HEAD with HEAD fails

[Edward Z. Yang]

Phab here: https://phabricator.haskell.org/D1355

Excerpts from Edward Z. Yang's message of 2015-10-22 13:09:25 -0700:
> Scratch that, I managed to reproduced. (As you said, it occurs only when
> you do the bindist.)  I'll debug.
> 
> Edward
> 
> Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700:
> > I did not use an inplace-stage2 but had a 'make install' before and
> > did a boot/reconfigure.
> > 
> > Not sure whether this detail is relevant.
> > 
> > How can I debug this problem? What does the error message say precisely?
> > 
> > Cheers,
> > 
> > Gabor
> > 
> > On 10/22/15, Edward Z. Yang <ezy...@mit.edu> wrote:
> > > So... I can't reproduce this.  I validated a copy of GHC HEAD,
> > > and then used the inplace ghc-stage2 to build another using
> > > ./configure --with-ghc=... and it built fine.
> > >
> > > Maybe, do you have some more details?
> > >
> > > Edward
> > >
> > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700:
> > >> This is likely my fault, w.r.t. to the recent Cabal submodule update.
> > >> I'm a bit confused why there are things in the DB that don't have ABI
> > >> hashes though...
> > >>
> > >> Edward
> > >>
> > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700:
> > >> > Hi devs,
> > >> >
> > >> > just a heads-up (pun intended...)
> > >> >
> > >> > (After updating to TOT, boot and configure with a freshly installed
> > >> > TOT ghc as bootstrap compiler. Then 'make clean'.)
> > >> >
> > >> > Running 'make' gives:
> > >> >
> > >> > ...
> > >> > Creating includes/ghcplatform.h...
> > >> > Done.
> > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
> > >> > "/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
> > >> > libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
> > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
> > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
> > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
> > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id
> > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
> > >> > process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts  -odir
> > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
> > >> > utils/hsc2hs/dist/build -dep-makefile
> > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
> > >> > -include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
> > >> > utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
> > >> > utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
> > >> > utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
> > >> > : package db: duplicate packages with incompatible ABIs:
> > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
> > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
> > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
> > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
> > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
> > >> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33
> > >> > template-haskell-2.11.0.0 has ABIs: ,
> > >> > 0ef51476100e9bdf96d1bf59696b98a1
> > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467
> > >> >
> > >> >
> > >> > The only solution I could come up for now is
> > >> >
> > >> > cd libraries
> > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d
> > >> > bootstrapping.conf
> > >> >
> > >> > then resuming 'make' leads to success.
> > >> >
> > >> > What could this be? Has somebody seen such an error?
> > >> >
> > >> > Cheers and thanks,
> > >> >
> > >> > Gabor
> > >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs