On 14/08/2008, at 18:01, Simon Marlow wrote:
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is
really unnecessary and could be done by Cabal since it only or
mostly depends on the package information. Instead, it is
implemented somewhere in Distributi
On 15/08/2008, at 07:11, Tim Chevalier wrote:
While reading some Core code, I noticed a function whose return type
was (# State# RealWorld #). I was curious why unboxed tuples of arity
1 would exist, so I dug around in the GHC sources and found that they
are used when desugaring foreign calls, a
This was a taste of the insanity of trying to run a project on two
vcs...
Manuel
Thomas Schilling:
Ok, my solution was actually not so correct. If Simon would push his
amended patch, this would have led to a conflict in darcs. I now
unpulled both the manual UNDO patch and the original patc
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/simonmar/nightly/HEAD
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Thu Aug 14 18:02:05 BST 2008.
checking out
Ok, my solution was actually not so correct. If Simon would push his
amended patch, this would have led to a conflict in darcs. I now
unpulled both the manual UNDO patch and the original patch.
On Thu, Aug 14, 2008 at 7:40 PM, Thomas Schilling
<[EMAIL PROTECTED]> wrote:
> Ok, naturally, unpullin
catamorphism:
> While reading some Core code, I noticed a function whose return type
> was (# State# RealWorld #). I was curious why unboxed tuples of arity
> 1 would exist, so I dug around in the GHC sources and found that they
> are used when desugaring foreign calls, as per the comment at the
>
While reading some Core code, I noticed a function whose return type
was (# State# RealWorld #). I was curious why unboxed tuples of arity
1 would exist, so I dug around in the GHC sources and found that they
are used when desugaring foreign calls, as per the comment at the
beginning of boxResult i
Ok, naturally, unpulling from darcs doesn't unpull from the git repo
and the darcs repo it is based on.
In case we ever have to do this again (hopefully not), here's what i did:
$ git log# to find out the commit id
$ git revert # create an invert commit
$ git status # should report
I wonder if that broke the Git mirror...
On Thu, Aug 14, 2008 at 6:17 PM, Malcolm Wallace
<[EMAIL PROTECTED]> wrote:
> Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
>> Bother! I did not mean to push the patch below.
>> Can someone who knows what they are doing expunge it from the HEAD
>> repo a
| Here's an example of using darcs rollback:
|
| $ darcs rollback
| Fri Jul 11 19:07:23 BST 2008 Duncan Coutts <[EMAIL PROTECTED]>
| * Merge StateTrans into State and simplify
| Shall I rollback this patch? [yNvpq], or ? for help: y
| Finished rolling back.
|
| $ darcs changes --last=2
| Fri Jul
On Thu, 2008-08-14 at 17:25 +0100, Simon Peyton-Jones wrote:
> | Although the usual policy is not to permit "unpull"s on the main repo, I
> | have unpulled this patch anyway. If anyone (or any buildbot) has pulled
> | this patch in the meantime, they should unpull it manually from their
> | own re
| Although the usual policy is not to permit "unpull"s on the main repo, I
| have unpulled this patch anyway. If anyone (or any buildbot) has pulled
| this patch in the meantime, they should unpull it manually from their
| own repo. I hope this does not inconvenience anyone too much.
Thanks Malc
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Bother! I did not mean to push the patch below.
> Can someone who knows what they are doing expunge it from the HEAD
> repo and tell me what actions I need to take at this end?
Although the usual policy is not to permit "unpull"s on the main repo,
Bother! I did not mean to push the patch below. I have not fully validated
etc... somehow I did this by mistake. (I was pushing a documentation patch.)
I don't know how to undo it though! Obliterate in the main repo? A reverse
patch? Sadly Ian is out and Simon has gone home.
Can someone w
Thu Aug 14 08:26:48 PDT 2008 [EMAIL PROTECTED]
* Improve -fwarn-orphans documentation (thanks to Tim)
M ./docs/users_guide/separate_compilation.xml -1 +7
M ./docs/users_guide/using.xml -1 +2
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080814152648-1287e-9eb29053268
Thu Aug 14 07:53:55 PDT 2008 [EMAIL PROTECTED]
* Make dictionary functions small
This patch makes an important change to the way that dictionary
functions are handled. Before, they were unconditionally marked
INLIINE, but all the code written by the user in the instance
was inside th
On 14/08/2008, at 06:32, Duncan Coutts wrote:
On Wed, 2008-08-13 at 22:47 +1000, Roman Leshchinskiy wrote:
Again, I'm not arguing against a build system written in Haskell. I'd
just like it to be completely separated from Haskell's packaging
system. In particular, "polluting" a package descrip
I think what SimonPJ suggested, that the build system just gives an appropriate error message if a
component is missing, would be much easier to realise.
That test already exists (Makefile check-packages:) but doesn't
seem to have followed the changes in packages file format, so it
doesn't tri
I think what SimonPJ suggested, that the build system just gives an
appropriate error message if a component is missing, would be much
easier to realise.
Manuel
Claus Reinke:
"darcs-all get; darcs-all pull -a; sh validate" instead of just the
latter two.
actually, since pull might change
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is really
unnecessary and could be done by Cabal since it only or mostly depends
on the package information. Instead, it is implemented somewhere in
Distribution.Simple and not really usable from the outside.
Thu Aug 14 05:52:23 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* update
M ./tests/ghc-regress/ghci/scripts/ghci024.py +1
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080814125223-12142-84065ac25545704a6b2731ddf4bfd6e246385f52.gz
___
Wed Aug 13 07:03:33 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add test for #2491
M ./tests/ghc-regress/cabal/Makefile +4
M ./tests/ghc-regress/cabal/ghcpkg01.stderr +1
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080813140333-12142-73e5943eccfad8c55af13eec51
Thu Aug 14 05:14:29 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add test for #2441, and stacking of package.confs
M ./tests/ghc-regress/cabal/Makefile +20
M ./tests/ghc-regress/cabal/all.T +7
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20080814121429-12142-02d7
Wed Aug 13 06:54:00 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* update these tests
M ./tests/ghc-regress/cabal/Makefile -4 +3
M ./tests/ghc-regress/cabal/all.T -2 +1
M ./tests/ghc-regress/cabal/cabal01/cabal01.stdout -2
A ./tests/ghc-regress/cabal/ghcpkg01.stderr
A ./tests/g
Build results:
x86-64 Linux head:fail (failed getsubrepos)
x86 Windows head: fail (failed getsubrepos)
x86 Windows head fast:lost fail (failed boottestsuite runtestsuite)
fail (failed getsubrepos) fail (failed darcs) fail (failed boottestsuite
runtestsuite) fail (f
Build results:
fast486 stable: fail (failed darcs)
kgardas stable: fail (failed stage1)
malcolm stable: fail (failed darcs)
mnemosyne x86-64 Gentoo stable: pass
tnaur PPC OSX stable 2: pass
x86 Windows stable: fail (failed getsubre
My perl is very rusty, so I'll only sketch what I had in mind,
and leave it to someone with more recent perl exposure to
see whether this (completely untested!) code can be adapted
into working code for darcs-all:
argh, I hadn't quite realized how rusty. While haskell.org is
gone, here's an upd
Thu Aug 14 05:53:48 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* Fix #2441 (unregister/expose/hide packages in non-first package databases)
M ./utils/ghc-pkg/Main.hs -36 +51
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080814125348-12142-a07ac6077b40923376da5302116ac8cf8
Thu Aug 14 05:53:12 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* add --no-user-package-conf
M ./utils/ghc-pkg/Main.hs +6
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080814125312-12142-c6b3c71c6a4879d538a6d953de85ed31217bffc4.gz
_
Wed Aug 13 07:47:07 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* move INPLACE_DATA_DIR into mk/config.mk and share it
M ./driver/Makefile -1
M ./ghc/Makefile -3
M ./mk/config.mk.in +2
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080813144707-12142-63e5de6004e3a23
Wed Aug 13 07:37:38 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* FIX #1963: use Cabal's writeFileAtomic to write the new package.conf
This depends on #2298 also being fixed, which I'll do shortly
M ./utils/ghc-pkg/Main.hs -35 +44
View patch online:
http://darcs.haskell.org/ghc/_darcs/patc
Wed Aug 13 07:34:36 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* FIX #2492: ghc-pkg insists on having HOME environment variable set
M ./utils/ghc-pkg/Main.hs -8 +16
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080813143436-12142-ba670f5a670b247bd9ba8d981d23807893331ae1.g
Wed Aug 13 07:25:55 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* FIX #2491 (ghc-pkg unregister should complain about breaking dependent
packages)
M ./utils/ghc-pkg/Main.hs -35 +46
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20080813142555-12142-d17a3fb6b425a3dbcde6f2698f
Tue Aug 12 07:16:06 PDT 2008 Simon Marlow <[EMAIL PROTECTED]>
* put back -fwarn-depcrecations
It was replaced by -fwarn-warnings-deprecations, but I think we want
to keep it for backwards compatibility. I'm not sure we want to
deprecate it either...
M ./compiler/main/DynFlags.hs +1
34 matches
Mail list logo
