builders
Ian Something we didn't discuss yesterday: * 32-bit Linux build is broken (see nightly-build email that Geoff generates here at MSR) * are other buildbots working? * we are getting no snapshot builds * there are many test failures (with plain make in testsuite/) even on 64-bit Linux. Can you investigate? Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
Sounds good, but for some reason we have HscAsm as a target at the moment in GHCJS, and set it to HscNothing only after typechecking. I forgot why, might have something to do with TH. Do you have an implementation of this patch that i can test it with (even if it's not the final API or really ugly)? luite On Tue, Jun 11, 2013 at 10:43 AM, Edsko de Vries edskodevr...@gmail.comwrote: Luite, On Fri, Jun 7, 2013 at 2:08 PM, Luite Stegeman stege...@gmail.com wrote: I'd also be very happy with some plugin interface that allows us to use more GhcMake functionality from the GHC API. For GHCJS we would want to run our own (STG - JavaScript) code generator on sources that need to be recompiled instead of letting GHC run its pipeline. Do you think that's possible with your proposal? Probably; if you disable ghc's code generator (set hscTarget to HscNothing, ghcLink to NoLink) ghc will still do the dependency analysis, still process modules in the right order, and a source plugin still gets called on every module that gets typechecked correctly -- so you could potentially generate code at that point? Edsko ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Patch/feature proposal: Source plugins
On 5 June 2013 13:51, Edsko de Vries edskodevr...@gmail.com wrote: It is a little bit messy mostly because parts of the AST get lost along the way: quasi-quotes in the renamer, data type declarations and other things during type checking. A more ideal way, but also more time consuming, would be to change this so that the renamer leaves evidence of the quasi-quotes in the tree, and the type checker returns the entire tree type checked, rather than just a subset. I think that ultimately this is the better approach, at least for our purposes -- I'm not sure about other tools, but since this would be a larger change that affects larger parts of the ghc pipeline I'm not sure that I'll be able to do it. I needed something similar. In particular, I built a custom code generator, but now I need a similar feature for extracting information from a Haskell file (for IDE features). Since I needed to modify one-shot compilation mode I couldn't use the GHC API. For the IDE stuff I'm using Shake as the build manager, so that also needs a customized one-shot mode. For my current implementation I just copied and adapted the necessary parts of HscMain, DriverPipeline, etc. That's very messy, fragile and breaks on every GHC release so I'd really like to see the necessary features put into GHC. Do you have a working patch somewhere? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Patch/feature proposal: Source plugins
Guys, I'm not following the details here, but I'm open to suggestions (patches, even) that improve the GHC API. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] | On Behalf Of Thomas Schilling | Sent: 11 June 2013 12:53 | To: Edsko de Vries | Cc: ghc-devs@haskell.org | Subject: Re: Patch/feature proposal: Source plugins | | On 5 June 2013 13:51, Edsko de Vries edskodevr...@gmail.com wrote: | It is a little bit messy mostly because parts of the AST get lost | along the | way: quasi-quotes in the renamer, data type declarations and other | things | during type checking. A more ideal way, but also more time consuming, | would | be to change this so that the renamer leaves evidence of the quasi- | quotes in | the tree, and the type checker returns the entire tree type checked, | rather | than just a subset. I think that ultimately this is the better | approach, at | least for our purposes -- I'm not sure about other tools, but since | this | would be a larger change that affects larger parts of the ghc pipeline | I'm | not sure that I'll be able to do it. | | I needed something similar. In particular, I built a custom code | generator, but now I need a similar feature for extracting information | from a Haskell file (for IDE features). | | Since I needed to modify one-shot compilation mode I couldn't use the | GHC API. For the IDE stuff I'm using Shake as the build manager, so | that also needs a customized one-shot mode. For my current | implementation I just copied and adapted the necessary parts of | HscMain, DriverPipeline, etc. That's very messy, fragile and breaks | on every GHC release so I'd really like to see the necessary features | put into GHC. | | Do you have a working patch somewhere? | | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Mon, Jun 10, 2013 at 01:13:37PM +0200, Daniel Trstenjak wrote: On Mon, Jun 10, 2013 at 11:45:22AM +0100, Ian Lynagh wrote: Is this possible with subtrees?: * Initially ghc's Cabal repo is at the same commit as upstream * We make a local commit 123 in Cabal to fix some bug * Cabal upstream makes a commit 456 to fix the same bug differently * We jump to commit 456, in such a way that we don't end up merging with our 123 commit every time we pull from Cabal in the future Yes. Every repository that's added by git-subtree to your repository is represented as a separate branch. So everything that applies to the merging of branches also applies to the merging by git-subtree. I didn't follow that. Here's an example of what happens with just a plain git repo, with no branches, submodules or subrepos involved: -8--8--8--8- upstream$ git init upstream$ echo content file upstream$ git add file upstream$ git commit -a -m initial $ git clone upstream ghc $ cd ghc ghc$ echo fix1 file ghc$ git commit -a -m fix1 upstream$ echo fix2 file upstream$ git commit -a -m fix2 ghc$ git pull --no-edit -X theirs upstream$ echo feature1 file upstream$ git commit -a -m feature1 ghc$ git pull --no-edit -X theirs upstream$ echo feature2 file upstream$ git commit -a -m feature2 ghc$ git pull --no-edit -X theirs -8--8--8--8- At the end of this, you'll see that the ghc repo has a number of merge commits. I guess they may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
I suppose I could have removed those links myself, but I first thought to send this email in order to raise issue of perhaps removing that wiki user's privileges or at least trying to contact them? Who has access privileges enough to do so? Or is the Trac security porous enough that this sort of thing happens regularly at no one's fault? Thanks. On Tue, Jun 11, 2013 at 1:43 PM, Ian Lynagh i...@well-typed.com wrote: On Tue, Jun 11, 2013 at 01:32:11PM -0500, Nicolas Frisby wrote: I've yet to fully comprehend the build system, but I'm pretty sure these links are not related. http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking?action=diffversion=33old_version=32 Ta, removed. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
On Tue, Jun 11, 2013 at 01:51:54PM -0500, Nicolas Frisby wrote: I suppose I could have removed those links myself, but I first thought to send this email in order to raise issue of perhaps removing that wiki user's privileges or at least trying to contact them? Who has access privileges enough to do so? Or is the Trac security porous enough that this sort of thing happens regularly at no one's fault? You have the choice of: (a) New users can improve the wiki content without needing to request special privs (b) Spammers can't spam the wiki Currently we've chosen (a). I thinkt here's a captcha of some sort, but it doesn't fully solve the problem. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Linking to changeset on wiki
What is the magical incantation for linking to a changeset in a bug report/on the trac wiki? i can't for the life of me figure it out. Thanks, Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Build broken: urgent
Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me. Could you perhaps revert the patch (around 6 June) that caused this, until it's sorted out? Thanks Simon inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug bash-3.1$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: spam on the wiki?
I'm repasting Stefan Holdermans' mail from Haskell-cafe, because it also concerns this issue: Hi all, The last days, some spam was added to the GHC developer wiki (http://hackage.haskell.org/trac/ghc) . I have removed some of it, but I could not get rid of the bits that were added through attachments; see for example the bottom of http://hackage.haskell.org/trac/ghc/wiki/Building. Can someone with wiki admin rights have a go at it? Thanks, Stefan Jan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Build broken: urgent
If you know which commit is the cause of the problem you can try to: git revert commit SHA on your own machine and see if this fixes the problem for you. On Tue, Jun 11, 2013 at 1:09 PM, Simon Peyton-Jones simo...@microsoft.comwrote: Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me.** ** Could you perhaps revert the patch (around 6 June) that caused this, until it’s sorted out? Thanks Simon ** ** inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] ** ** Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug*** * ** ** bash-3.1$ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Build broken: urgent
Thanks. I'm busy doing exactly that. I'll push reverts shortly. From: Johan Tibell [mailto:johan.tib...@gmail.com] Sent: 11 June 2013 22:04 To: Simon Peyton-Jones Cc: Ian Lynagh (i...@well-typed.com); ghc-devs@haskell.org Subject: Re: Build broken: urgent If you know which commit is the cause of the problem you can try to: git revert commit SHA on your own machine and see if this fixes the problem for you. On Tue, Jun 11, 2013 at 1:09 PM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me. Could you perhaps revert the patch (around 6 June) that caused this, until it's sorted out? Thanks Simon inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0-package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug bash-3.1$ ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Build broken: urgent
On 06/11/2013 09:09 PM, Simon Peyton-Jones wrote: Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me. Could you perhaps revert the patch (around 6 June) that caused this, until it’s sorted out? Thanks Simon inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] Hi Simon, Could the culprit be my bswap patches that Ian pushed on the 6th ? Quickly looking at the history, doesn't look there's lots of things changing primops around this time. -- Vincent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Build broken: urgent
Yes, that's the one. I'm reverting it now -Original Message- From: Vincent Hanquez [mailto:t...@snarc.org] Sent: 11 June 2013 22:11 To: Simon Peyton-Jones Cc: Ian Lynagh (i...@well-typed.com); ghc-devs@haskell.org Subject: Re: Build broken: urgent On 06/11/2013 09:09 PM, Simon Peyton-Jones wrote: Ian This getRegister bug is killing my Windows builds too; indeed every 32-bit build is broken, and that is stalling a lot of people, now including me. Could you perhaps revert the patch (around 6 June) that caused this, until it's sorted out? Thanks Simon inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.7.20130611 for i386-unknown-mingw32): getRegister(x86) I64[Sp] Hi Simon, Could the culprit be my bswap patches that Ian pushed on the 6th ? Quickly looking at the history, doesn't look there's lots of things changing primops around this time. -- Vincent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Build broken: urgent
On 06/11/2013 10:18 PM, Simon Peyton-Jones wrote: Yes, that's the one. I'm reverting it now sorry about that. i'll have a look at the fix for the 32 bit version ASAP. -- Vincent ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Build broken: urgent
OK I've pushed reversion patches to the HEAD ghc repo and to 'base'. Attached.
Maybe Vincent can figure out what went wrong.
Simon
From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On
Behalf Of Simon Peyton-Jones
Sent: 11 June 2013 21:10
To: Ian Lynagh (i...@well-typed.com)
Cc: ghc-devs@haskell.org
Subject: Build broken: urgent
Ian
This getRegister bug is killing my Windows builds too; indeed every 32-bit
build is broken, and that is stalling a lot of people, now including me.
Could you perhaps revert the patch (around 6 June) that caused this, until it's
sorted out?
Thanks
Simon
inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O
-Werror -Wall -H64m -O0-package-name ghc-prim-0.3.1.0 -hide-all-packages -i
-ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
-ilibraries/ghc-prim/dist-install/build/autogen
-Ilibraries/ghc-prim/dist-install/build
-Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
-optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
-package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash
-XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls
-XNoImplicitPrelude -O2 -O -dcore-lint -fno-warn-deprecated-flags
-no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build
-hidir libraries/ghc-prim/dist-install/build -stubdir
libraries/ghc-prim/dist-install/build -dynamic-too -c
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o -dyno
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o
ghc-stage1.exe: panic! (the 'impossible' happened)
(GHC version 7.7.20130611 for i386-unknown-mingw32):
getRegister(x86) I64[Sp]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
bash-3.1$
---BeginMessage---
Repository : ssh://darcs.haskell.org//srv/darcs/packages/base
On branch : master
https://github.com/ghc/packages-base/commit/2f8c5bff9ccb762b34467e069f208f28538cc18e
---
commit 2f8c5bff9ccb762b34467e069f208f28538cc18e
Author: Simon Peyton Jones simo...@microsoft.com
Date: Tue Jun 11 21:50:04 2013 +0100
Revert expose new Word operation to swap endianness for Word{16,32,64}
This reverts commit 3ef0f91d4e9a3649581557ec4ba663db4306d7d5.
---
Data/Word.hs | 18 --
GHC/Word.hs | 18 +-
2 files changed, 1 insertions(+), 35 deletions(-)
diff --git a/Data/Word.hs b/Data/Word.hs
index c844c4d..39aa1a8 100644
--- a/Data/Word.hs
+++ b/Data/Word.hs
@@ -22,9 +22,6 @@ module Data.Word
Word,
Word8, Word16, Word32, Word64,
--- * byte swapping
-byteSwap16, byteSwap32, byteSwap64,
-
-- * Notes
-- $notes
@@ -36,21 +33,6 @@ import GHC.Word
#ifdef __HUGS__
import Hugs.Word
-
-byteSwap16 :: Word16 - Word16
-byteSwap16 w = (w `shift` -8) .|. (w `shift` 8)
-
-byteSwap32 :: Word32 - Word32
-byteSwap32 w =
- (w `shift` -24) .|. (w `shift` 24)
-.|. ((w `shift` -8) .. 0xff00) .|. ((w .. 0xff00) `shift` 8)
-
-byteSwap64 :: Word64 - Word64
-byteSwap64 w =
-(w `shift` -56) .|. (w `shift` 56)
-.|. ((w `shift` -40) .. 0xff00) .|. ((w .. 0xff00) `shift` 40)
-.|. ((w `shift` -24) .. 0xff) .|. ((w .. 0xff) `shift` 24)
-.|. ((w `shift` -8) .. 0xff00) .|. ((w .. 0xff00) `shift` 8)
#endif
{- $notes
diff --git a/GHC/Word.hs b/GHC/Word.hs
index 3419a24..75957df 100644
--- a/GHC/Word.hs
+++ b/GHC/Word.hs
@@ -23,10 +23,7 @@
module GHC.Word (
Word(..), Word8(..), Word16(..), Word32(..), Word64(..),
uncheckedShiftL64#,
-uncheckedShiftRL64#,
-byteSwap16,
-byteSwap32,
-byteSwap64
+uncheckedShiftRL64#
) where
import Data.Bits
@@ -303,9 +300,6 @@ instance Bits Word16 where
instance FiniteBits Word16 where
finiteBitSize _ = 16
-byteSwap16 :: Word16 - Word16
-byteSwap16 (W16# w#) = W16# (byteSwap16# w#)
-
{-# RULES
fromIntegral/Word8-Word16 fromIntegral = \(W8# x#) - W16# x#
fromIntegral/Word16-Word16 fromIntegral = id :: Word16 - Word16
@@ -530,9 +524,6 @@ instance Read Word32 where
readsPrec p s = [(fromIntegral (x::Int), r) | (x, r) - readsPrec p s]
#endif
-byteSwap32 :: Word32 - Word32
-byteSwap32 (W32# w#) = W32# (byteSwap32# w#)
-
-- type Word64
@@ -781,10 +772,3 @@ instance Ix Word64 where
instance Read Word64 where
readsPrec p s = [(fromInteger x, r) | (x, r) - readsPrec p s]
-#if WORD_SIZE_IN_BITS 64
-byteSwap64 :: Word64 - Word64
-byteSwap64 (W64# w#) = W64# (byteSwap64# w#)
-#else
-byteSwap64 :: Word64 - Word64
-byteSwap64
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
Hi Ian, I guess they may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). I don't quite understand how you should get rid of these merge commits by using submodules, because at the end every submodule is just a git repository and behaves in the same way as every other git repository for merges. You can get rid of these merge commit by using the '--rebase' option of git-pull. I put your git command lines into the attached script 'ghc_git_test'. Now you can get your version and the version using '--rebase' by calling: mkdir your_version rebase_version cd your_version ghc_git_test -X theirs cd ../rebase_version ghc_git_test --rebase -X ours You will certainly ask why it's 'ours' instead of 'theirs' for the rebase case, well, that's one of the quite counterintuitive things in the git user interface. Greetings, Daniel #!/usr/bin/env bash mkdir upstream ghc cd upstream git init echo content file git add file git commit -a -m initial cd .. git clone upstream ghc cd ghc echo fix1 file git commit -a -m fix1 cd ../upstream echo fix2 file git commit -a -m fix2 cd ../ghc git pull --no-edit $@ cd ../upstream echo feature1 file git commit -a -m feature1 cd ../ghc git pull --no-edit $@ cd ../upstream echo feature2 file git commit -a -m feature2 cd ../ghc git pull --no-edit $@ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
