Re: Hadrian failure after worktree update
Hi Bryan,
Could you try to run ./configure before hadrian/build.sh?
Best regards,
Artem Pyanykh
> On 5 Oct 2019, at 19:30, Bryan Richter wrote:
>
> Below is an error message I have seen a number of times after
> rebasing my git worktree, i.e. this is how to "reproduce":
>
>git fetch origin
>git rebase origin/master
>git submodule update
>./hadrian/build.sh
>
> (Obviously some details are elided, and this is not a complete reproduction.)
>
> I don't have many copies of the error, but I do remember seeing the
> complaint about "No generator for .../PmOracle.hs" on other occasions.
>
> Any idea what this comes from?
>
> -Bryan
>
> --- 8< ---
>
> Error when running Shake build system:
> at action, called at src/Rules.hs:71:19 in main:Rules
> at need, called at src/Rules.hs:93:5 in main:Rules
> * Depends on: _build/stage0/lib/package.conf.d/ghc-8.9.0.20190929.conf
> at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register
> * Depends on: _build/stage0/compiler/build/libHSghc-8.9.0.20190929.a
> * Depends on: _build/stage0/compiler/build/GHCi.o
> * Depends on: _build/stage0/compiler/build/GHCi.o
> _build/stage0/compiler/build/GHCi.hi
> * Depends on: OracleQ (KeyValues
> ("_build/stage0/compiler/.dependencies","_build/stage0/compiler/build/GHCi.o"))
> * Depends on: _build/stage0/compiler/.dependencies
> * Depends on: _build/stage0/compiler/.dependencies.mk
> at need, called at src/Rules/Dependencies.hs:26:9 in main:Rules.Dependencies
> * Depends on: _build/stage0/compiler/build/PmOracle.hs
> at error, called at src/Rules/Generate.hs:105:34 in main:Rules.Generate
> * Raised the exception:
> No generator for _build/stage0/compiler/build/PmOracle.hs.
>
> ___
> 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
Hadrian failure after worktree update
Below is an error message I have seen a number of times after
rebasing my git worktree, i.e. this is how to "reproduce":
git fetch origin
git rebase origin/master
git submodule update
./hadrian/build.sh
(Obviously some details are elided, and this is not a complete reproduction.)
I don't have many copies of the error, but I do remember seeing the
complaint about "No generator for .../PmOracle.hs" on other occasions.
Any idea what this comes from?
-Bryan
--- 8< ---
Error when running Shake build system:
at action, called at src/Rules.hs:71:19 in main:Rules
at need, called at src/Rules.hs:93:5 in main:Rules
* Depends on: _build/stage0/lib/package.conf.d/ghc-8.9.0.20190929.conf
at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register
* Depends on: _build/stage0/compiler/build/libHSghc-8.9.0.20190929.a
* Depends on: _build/stage0/compiler/build/GHCi.o
* Depends on: _build/stage0/compiler/build/GHCi.o
_build/stage0/compiler/build/GHCi.hi
* Depends on: OracleQ (KeyValues
("_build/stage0/compiler/.dependencies","_build/stage0/compiler/build/GHCi.o"))
* Depends on: _build/stage0/compiler/.dependencies
* Depends on: _build/stage0/compiler/.dependencies.mk
at need, called at src/Rules/Dependencies.hs:26:9 in main:Rules.Dependencies
* Depends on: _build/stage0/compiler/build/PmOracle.hs
at error, called at src/Rules/Generate.hs:105:34 in main:Rules.Generate
* Raised the exception:
No generator for _build/stage0/compiler/build/PmOracle.hs.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Coercible questions
I think there's some work going on to expose the representations, which would enable some ability to coerce. But possibly not this much, as they're separate RuntimeReps so you don't combine signed and unsigned numbers inadvertently; currently that's a little magical inside ghc iirc, with the RuntimeRep the only way to distinguish at all and that vanishing post-typechecking. On Sat, Oct 5, 2019 at 12:30 PM Michal Terepeta wrote: > Adding +ghc-devs to continue the thread > > Hi Sandy, > > Thanks for the answer! Do you think there is some fundamental reason for > this? Or just a matter of implementing this in GHC? It seems to me that > this should work just fine as long as the runtime representation is the > same. > > And a related question--is it safe to `unsafeCoerce` an `Int` to a `Word`? > The only reason for why this could be problematic that comes to my mind is > that there could be an assumption that different `data`s do not alias each > other (although `newtype`s can due to `Coercible` functionality). But I'm > not sure this is ever used by GHC? Are there any other reasons why this > could be problematic? > > Thanks! > > - Michal > > > > On Sat, Oct 5, 2019 at 5:27 PM Sandy Maguire > wrote: > >> Hi Michal, >> >> Datas aren't coercible, only newtypes. This is why you can't coerce Ints >> and Words, and why Foo and Bar don't work. >> >> Sandy >> >> On Sat, Oct 5, 2019 at 4:17 PM Michal Terepeta >> wrote: >> >>> Hi, >>> >>> I've started looking into using `Data.Coerce` (and the `Coercible` >>> type-class) for a personal project and was wondering why coercing between >>> `Int` and `Word` is not allowed? I don't see any fundamental reason why >>> this shouldn't work... >>> >>> Perhaps, it's just a matter of GHC's implementation details leaking out? >>> IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and >>> for an `Int#`. If that's the case, would it make sense to unify these? >>> Their actual runtime representation should be the same and I'd expect most >>> (all?) of their differences should be attached to `PrimOp`s. >>> >>> And that leads me to another question--what exactly goes wrong here: >>> ``` >>> data Foo = Foo Int# >>> data Bar = Bar Int# >>> >>> test :: Bar >>> test = coerce (Foo 42#) >>> ``` >>> Which fails with: "Couldn't match representation of type ‘Foo’ with >>> that of ‘Bar’ arising from a use of ‘coerce’" >>> >>> Perhaps I'm just misunderstanding exactly how `Coercible` works? >>> >>> Thanks in advance! >>> >>> - Michal >>> >>> PS. The ability to coerce through things like lists is amazing :) >>> ___ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> >> >> -- >> I'm currently travelling the world, sleeping on people's couches and >> doing full-time collaboration on Haskell projects. If this seems >> interesting to you, please consider signing up as a host! >> https://isovector.github.io/erdos/ >> > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allber...@gmail.com ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Coercible questions
Adding +ghc-devs to continue the thread Hi Sandy, Thanks for the answer! Do you think there is some fundamental reason for this? Or just a matter of implementing this in GHC? It seems to me that this should work just fine as long as the runtime representation is the same. And a related question--is it safe to `unsafeCoerce` an `Int` to a `Word`? The only reason for why this could be problematic that comes to my mind is that there could be an assumption that different `data`s do not alias each other (although `newtype`s can due to `Coercible` functionality). But I'm not sure this is ever used by GHC? Are there any other reasons why this could be problematic? Thanks! - Michal On Sat, Oct 5, 2019 at 5:27 PM Sandy Maguire wrote: > Hi Michal, > > Datas aren't coercible, only newtypes. This is why you can't coerce Ints > and Words, and why Foo and Bar don't work. > > Sandy > > On Sat, Oct 5, 2019 at 4:17 PM Michal Terepeta > wrote: > >> Hi, >> >> I've started looking into using `Data.Coerce` (and the `Coercible` >> type-class) for a personal project and was wondering why coercing between >> `Int` and `Word` is not allowed? I don't see any fundamental reason why >> this shouldn't work... >> >> Perhaps, it's just a matter of GHC's implementation details leaking out? >> IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and >> for an `Int#`. If that's the case, would it make sense to unify these? >> Their actual runtime representation should be the same and I'd expect most >> (all?) of their differences should be attached to `PrimOp`s. >> >> And that leads me to another question--what exactly goes wrong here: >> ``` >> data Foo = Foo Int# >> data Bar = Bar Int# >> >> test :: Bar >> test = coerce (Foo 42#) >> ``` >> Which fails with: "Couldn't match representation of type ‘Foo’ with that >> of ‘Bar’ arising from a use of ‘coerce’" >> >> Perhaps I'm just misunderstanding exactly how `Coercible` works? >> >> Thanks in advance! >> >> - Michal >> >> PS. The ability to coerce through things like lists is amazing :) >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > I'm currently travelling the world, sleeping on people's couches and doing > full-time collaboration on Haskell projects. If this seems interesting to > you, please consider signing up as a host! > https://isovector.github.io/erdos/ > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Coercible questions
Hi, I've started looking into using `Data.Coerce` (and the `Coercible` type-class) for a personal project and was wondering why coercing between `Int` and `Word` is not allowed? I don't see any fundamental reason why this shouldn't work... Perhaps, it's just a matter of GHC's implementation details leaking out? IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and for an `Int#`. If that's the case, would it make sense to unify these? Their actual runtime representation should be the same and I'd expect most (all?) of their differences should be attached to `PrimOp`s. And that leads me to another question--what exactly goes wrong here: ``` data Foo = Foo Int# data Bar = Bar Int# test :: Bar test = coerce (Foo 42#) ``` Which fails with: "Couldn't match representation of type ‘Foo’ with that of ‘Bar’ arising from a use of ‘coerce’" Perhaps I'm just misunderstanding exactly how `Coercible` works? Thanks in advance! - Michal PS. The ability to coerce through things like lists is amazing :) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
