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 Tue Oct 14 18:02:05 BST 2008.
checking out
Build description = HEAD on x86_64-unknown-linux
(cam-04-unx.europe.corp.microsoft.com)
Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx
Nightly build started on cam-04-unx at Tue Oct 14 19:00:01 BST 2008.
**
2008/10/14 Thomas Schilling <[EMAIL PROTECTED]>:
> So, I've been thinking. How do plugins get used by GHC? Maybe it's
> possible to have a ghc-plugin-api package that exports binary and ghc.
> IIUC, the plugin need not be part of the compiled program, so we
> could expose binary only to the plu
So, I've been thinking. How do plugins get used by GHC? Maybe it's
possible to have a ghc-plugin-api package that exports binary and ghc.
IIUC, the plugin need not be part of the compiled program, so we
could expose binary only to the plugins. This way at least only
plugin-writers would be bo
2008/10/14 Thomas Schilling <[EMAIL PROTECTED]>:
> How does this help? The problem is that a compiler plugin (which is
> effectively a GHC API client) might see two different versions of
> binary and would have to choose the one bundled with GHC.
Right. Basically, we /have/ to expose Binary becau
How does this help? The problem is that a compiler plugin (which is
effectively a GHC API client) might see two different versions of
binary and would have to choose the one bundled with GHC.
2008/10/14 Don Stewart <[EMAIL PROTECTED]>:
> omega.theta:
>> 2008/10/14 Ian Lynagh <[EMAIL PROTECTED]>:
Tue Oct 14 14:12:36 PDT 2008 Thomas Schilling <[EMAIL PROTECTED]>
* Make tags work on Unices, too.
M ./compiler/Makefile -2 +5
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081014211236-7c5c6-b330ead01b932a634c4c434b8e0f643a4893fd8e.gz
__
omega.theta:
> 2008/10/14 Ian Lynagh <[EMAIL PROTECTED]>:
> > On Mon, Oct 13, 2008 at 06:06:03PM +0100, Max Bolingbroke wrote:
> >>
> >> (http://hackage.haskell.org/trac/ghc/wiki/Annotations).
> >
> > When you say
> >{-# ANN f id 1 #-}
> > this means you are attaching (id 1) to f, right?
> >
>
2008/10/14 Ian Lynagh <[EMAIL PROTECTED]>:
> On Mon, Oct 13, 2008 at 06:06:03PM +0100, Max Bolingbroke wrote:
>>
>> (http://hackage.haskell.org/trac/ghc/wiki/Annotations).
>
> When you say
>{-# ANN f id 1 #-}
> this means you are attaching (id 1) to f, right?
>
> I think that that syntax is ver
On Mon, Oct 13, 2008 at 06:06:03PM +0100, Max Bolingbroke wrote:
>
> (http://hackage.haskell.org/trac/ghc/wiki/Annotations).
When you say
{-# ANN f id 1 #-}
this means you are attaching (id 1) to f, right?
I think that that syntax is very confusing. I'm not sure what I'd prefer
though. Maybe
Hi
> Right, this is another interesting alternative. But since it
> requires users to define their own instances all over the
> place anyway I would almost be happier to provide our own
> version of the binary package to
> users: they would be free to define their (de)serialization
> methods u
2008/10/14 Mitchell, Neil <[EMAIL PROTECTED]>:
> One way round both issues you raise is to have a GhcTransform class,
> with two transform methods, one which is applied to the data before
> writing and the other after reading - giving the type a chance to
> "change" into another type supporting Dat
Tue Oct 14 04:47:14 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Fix the name of prologue.txt when making bindists
M ./libraries/Makefile -1 +1
View patch online:
http://darcs.haskell.org/ghc-6.10/ghc/_darcs/patches/20081014114714-3fd76-9925302e8b3dbc708bd964d457023763eeedbee3.gz
___
Mon Oct 13 16:58:17 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Fill out the ghc package's cabal file
M ./compiler/ghc.cabal.in -6 +10
View patch online:
http://darcs.haskell.org/ghc-6.10/ghc/_darcs/patches/20081013235817-3fd76-6ce92bf5a602460f16f3875e5cfab9e8eac163ab.gz
___
Tue Oct 14 07:32:06 PDT 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Undefine __PIC__ before defining it to work around "multiple definitions of
__PIC__" warnings
M ./compiler/main/DynFlags.hs -4 +4
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081014143206-ed0c4-f81a9d
Tue Oct 14 05:51:23 PDT 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Add "dyn" to GhcRTSWays when compiling --enable-shared
M ./mk/config.mk.in -1 +1
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081014125123-ed0c4-7fbb8dd80a7377b40d12e71bce0b7f128025fd96.gz
___
Mon Oct 13 16:58:17 PDT 2008 Ian Lynagh <[EMAIL PROTECTED]>
* Fill out the ghc package's cabal file
M ./compiler/ghc.cabal.in -6 +10
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081013235817-3fd76-6ce92bf5a602460f16f3875e5cfab9e8eac163ab.gz
Hi
Both are valid problems. Indeed, Data /= Binary, but does provide handy
serialisation in a lot of cases.
One way round both issues you raise is to have a GhcTransform class,
with two transform methods, one which is applied to the data before
writing and the other after reading - giving the typ
Tue Oct 14 03:34:59 PDT 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Patching libffi so it can be built as DLL
libffi-dllize-3.0.6.patch should be pushed upstream
M ./libffi/Makefile -7 +29
A ./libffi/libffi-autotools-update.patch
A ./libffi/libffi-dllize-3.0.6.patch
View patc
2008/10/14 Mitchell, Neil <[EMAIL PROTECTED]>:
> Hi,
>
> There is an alternative 4:
>
> Require Data/Typeable instances for all items, then using runtime
> reflection provided by Data serialise the values into binary (or however
> else you want them).
Yes, we did consider this, and should have men
Mon Oct 13 10:09:27 PDT 2008 Thomas Schilling <[EMAIL PROTECTED]>
* Add 'etags' makefile target.
This only works with stage2 since `ghctags' is built against stage1
but not against the bootstrapping compiler. Also note that all of GHC
must typecheck for this target to succeed. Perhaps
Mon Oct 13 10:06:58 PDT 2008 Thomas Schilling <[EMAIL PROTECTED]>
* Use cabal information to get GHC's flags to `ghctags'.
By giving the dist-directory to ghctags we can get all the GHC API
flags we need in order to load the required modules. The flag name
could perhaps be improved, bu
2008/10/14 Mitchell, Neil <[EMAIL PROTECTED]>:
> * You don't get any additional dependencies (other than perhaps SYB,
> which I hope you are going to add for the GHC API data types anyway).
I took Claus Reinke's code and put it in a package. I will upload it
as soon as I have tested it with GHC
Tue Oct 14 01:13:00 PDT 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Version bump for libffi to 3.0.6
R ./libffi/libffi-3.0.4.tar.gz
A ./libffi/libffi-3.0.6.tar.gz
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081014081300-ed0c4-853138834732d678b5600d5f05625f346b2714
Mon Oct 13 15:15:30 PDT 2008 Clemens Fruhwirth <[EMAIL PROTECTED]>
* Encode shared/static configuration into stamps to do the right thing when
rebuilding
M ./libffi/Makefile -5 +14
View patch online:
http://darcs.haskell.org/ghc/_darcs/patches/20081013221530-ed0c4-88c910ac3065bc788181e9d7
Hi,
There is an alternative 4:
Require Data/Typeable instances for all items, then using runtime
reflection provided by Data serialise the values into binary (or however
else you want them).
* You don't get any additional dependencies (other than perhaps SYB,
which I hope you are going to add fo
| > Simon M mentioned this. However, the unique problem with Binary is
| > that ghc will exports an API that mentions the Binary class:
| >
| > """
| > -- For normal GHC API users:
| > getAnnotations :: (Typeable a, Binary a) => Name -> GHCM [a]
| >
| > -- Only for plugins adding their own annotati
Build results:
x86-64 Linux head: fail (failed bindisttest)
x86 Windows head:fail (failed getsubrepos)
x86 Windows head fast: pass pass pass pass pass
macgyver PPC OSX head: fail (failed darcs)
tnaur PPC OSX head 2:fail (failed stage2)
tnaur x86 Linux head:pass
x86-64 Linu
28 matches
Mail list logo
