git-annex (written in Haskell!) is designed specifically for this purpose.
might be worth a look.
-E
On Tue, Jun 10, 2014 at 4:02 PM, Simon Peyton Jones
wrote:
> | Right now, cloning the ghc-tarballs.git repo requires to fetch ~130MiB.
> |
> | Can't we simply put the tarballs in a plain HTTP f
Hi guys,
I have been trying to compile a 32-bit version ghc, versions 7.8 as well as
HEAD, in a myriad of ways, bootstrapping with the 32-bit binary of 7.4
(which is the latest 32-bit binary available from haskell.org), but no
matter which way I try, it always fails somewhere.
I was trying this m
Yes, this is a nuisance, esp because ghc can most of the time see perfectly
well that if you *do* write down the "missing" cases that they are
inaccessible. There are a bunch of open tickets about it. I too use
Richard's trick; I tend to use
foo _ _ = error "inaccessible"
Fixing ghc so that i
Possibly I did something wrong (certainly when I tried to build something
very close to RC1 at Austin's request it worked fine), but now I am getting
In file included from rts/sm/Evac.c:21:0:
rts/sm/GCTDecl.h:71:0:
error: thread-local storage not supported for this target
(Host compiler: gh
Ok, created a ticket: https://ghc.haskell.org/trac/ghc/ticket/8563 .
Thanks,
Edsko
On Mon, Nov 25, 2013 at 5:18 PM, Joachim Breitner
wrote:
> Hi Edsko,
>
> Am Montag, den 25.11.2013, 16:47 + schrieb Edsko de Vries:
> > I'm getting the errors below if I try to bu
I'm getting the errors below if I try to build tagged with head:
src/Data/Tagged.hs:57:5:
'Tagged' is applied to too many type arguments
In an expression type signature:
Tagged k s b -> Tagged k s b -> Bool
In the expression:
ghc-prim:GHC.Prim.coerce ((==) :: b -> b -> Bo
Hmmm, a completely clean build seems to have resolved the issue.
Indicative of a Makefile problem somewhere?
-E
On Tue, Nov 12, 2013 at 10:36 AM, Edsko de Vries wrote:
> Hi guys,
>
> I'm trying to add a new primop; as a starting point I just copied the
> definiti
Hi Arash,
On Tue, Nov 12, 2013 at 10:44 AM, Arash Rouhani
wrote:
> I'm really curious why you want a "catchRethrow". I'm tempted to add such
> a primop myself since I'm working on problems with stack traces. I'm really
> interested in what use-case you had in mind.
>
I'm working on dealing wit
Hi guys,
I'm trying to add a new primop; as a starting point I just copied the
definition of "catch#" in primops.txt.pp and renamed "catch#" to
"catchRethrow#", and added the corresponding declarations following
https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp
; however, w
if we come across any problems.
Edsko
On Tue, Nov 5, 2013 at 8:51 AM, Simon Marlow wrote:
> On 31/10/2013 18:06, Edsko de Vries wrote:
>>
>> Hi guys,
>>
>> We started experimenting with dynamically loading and unloading C
>> object files (using the GHC API). I h
Hi guys,
We started experimenting with dynamically loading and unloading C
object files (using the GHC API). I have a simple example with an
object file exporting a single symbol "f"; I have two versions of the
object file; in the first one, f is defined
int f() {
return 1234;
}
The second one
Hi all,
I'm still trying to get a Windows build (Win 7, tried both 32-bit and
64-bit, same result) -- using THREADS=1. When running 'sh validate',
compilation eventually stops with
"inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static
-H32m -O -Werror -Wall -H64m -O0-package-name
Hi all,
Trying to get a build going on Win 7. On both the 32-bit and the
64-bit version running 'sh validate' stalls at
"inplace/bin/mkdirhier" utils/touchy/dist/build/tmp//.
At this point nothing happens, other than that I seem to have 100% CPU
usage; 'ps' only shows two make processes, but no
t clear to me why exactly those are the right places. But I suppose
> they are simply driven by what has been needed.
>
>
>
> Anyway if you two are happy (no one else seems to mind either way) then go
> ahead.
>
>
>
> Simon
>
>
>
>
>
> From: L
ion. And then you two, with Thomas
> and other interested parties, work together to evolve a design that everyone
> is happy with.
>
>
>
> Does that sound ok?
>
>
>
> Simon
>
>
>
> From: Luite Stegeman [mailto:stege...@gmail.com]
> Sent: 07 September 2013 22:
Note that I opened a ticket about this (but with less information than
in this thread):
http://ghc.haskell.org/trac/ghc/ticket/8102
-E
On Tue, Aug 6, 2013 at 12:59 PM, Kazu Yamamoto wrote:
> Hi Nicolas,
>
> My guess is here: libraries/integer-gmp/configure generates "gmp.h".
> Building mkGmpDer
It might well be hsenv, which modifies your environment in a number of
ways. I recommend using my approach to sandboxes, which works fine
with ghc (http://www.edsko.net/2013/02/10/comprehensive-haskell-sandboxes/).
-E
On Mon, Aug 5, 2013 at 9:14 AM, Alfredo Di Napoli
wrote:
> Hello guys,
>
> I'm
Hi Ian,
That says
HADDOCK_DOCS="YES "
-E
On Wed, Jul 24, 2013 at 11:31 PM, Ian Lynagh wrote:
>
> Hi Edsko,
>
> On Tue, Jul 23, 2013 at 12:38:25PM +0200, Edsko de Vries wrote:
>>
>> I'm trying to build and install ghc head, with the installation of the
&
> picture of what it is trying to achieve. (And I’m rushing towards the POPL
> deadline anyway!)
>
>
>
> Simon
>
>
>
> From: Edsko de Vries [mailto:edskodevr...@gmail.com]
> Sent: 08 July 2013 18:02
> To: Simon Peyton-Jones
> Cc: Luite Stegeman; Thomas Schil
the failure to install the haddocks in
the first place. I still don't know why that happened though (why it
didn't build the .haddock files nor install them, or the
inplace/lib/html directory).
-E
On Tue, Jul 23, 2013 at 12:38 PM, Edsko de Vries wrote:
> Hi,
>
> I'm trying
Hi,
I'm trying to build and install ghc head, with the installation of the
.haddocks. I'm running into all kinds of trouble though. I have
docbook and docbook-xsl installed, am using the standard sample
build.mk with the "quick" profile, modified to have
HADDOCK_DOCS = YES
BUILD_DOCBOOK_HTM
en far too long
already :) Comments/suggestions/feedback welcome. Hopefully the patch is
pretty self-explanatory; and it's only small.
-E
On Mon, Jul 1, 2013 at 9:32 AM, Edsko de Vries wrote:
> Yes, I fully intend to create a ticket with a detailed description and a
> first patch, but I&#
e a Trac Wiki page that describes the design***
> *
>
> ** **
>
> I’m more than happy to adopt patches that improve the plugin API, but
> you’ll have to lead me through it!
>
> ** **
>
> No hurry, just when you are ready.****
>
> ** **
>
> Simon
&g
: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:
Hi,
I believe the right way to fix this is to find all the places in the
> compiler that catch and rethrow exceptions inside unsafePerformIO, and make
> them use throwTo when the exception is asynchronous.
Ok, I have looked at this in detail and I'm not sure how feasible this is.
I have filed a
Luite,
On Fri, Jun 7, 2013 at 2:08 PM, Luite Stegeman 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
> recompile
Hi all,
This proposal is related to http://hackage.haskell.org/trac/ghc/ticket/1381,
which Simon Marlow closed through commit
https://github.com/ghc/ghc/commit/02c4ab049adeb77b8ee0e3b98fbf0f3026eee453.
The problem, in a nutshell, is "how do we terminate a code snippet started
with runStmt"? Befor
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API dir
Uh. I'm sorry, I don't know why that email got sent, I was still
writing it. Please ignore it for now, will send the full version later :)
On Wed, Jun 5, 2013 at 12:14 PM, Edsko de Vries wrote:
> Hi all,
>
> The plugin mechanism gives access to the program in Core; this
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API directly. Moreover, even when using the GHC API directly
rim:GHC.Types.Bool{(w) tc 3c} )
>
> :: ghc-prim:GHC.Types.Bool{(w) tc 3c}
>
> [LclId]
>
> {Foo.hs:3:1-8}
>
> ( f{v a9H} [lid] :: ghc-prim:GHC.Types.Bool{(w) tc 3c} )
>
> :: ghc-prim:GHC.Types.Bool{(w) tc 3c}
>
> [LclId]
>
things from other modules have uniques that do not
> change.
>
> ** **
>
> simon
>
> ** **
>
> *From:* ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
> *On Behalf Of *Edsko de Vries
> *Sent:* 26 March 2013 15:05
> *To:* ghc-devs@has
Hi all,
Consider the very simple test
module Test2 where
f = True
When walking the AST after renaming I see that f has unique 1912603236 and
True has unique 905969694. However, when walking the typechecked AST f
seems to have unique 1627390565 instead. Should I expect that the unique
associa
gt;
> ** **
>
> *From:* Edsko de Vries [mailto:edskodevr...@gmail.com]
> *Sent:* 25 February 2013 16:27
>
> *To:* Simon Peyton-Jones
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Top-level type signatures in TcGblEnv?
>
> ** **
>
> I'm sorry, I don't
I'm sorry, I don't see any location information ("Located .." types) in
tcg_type_env?
Edsko
On Mon, Feb 25, 2013 at 3:22 PM, Simon Peyton-Jones
wrote:
> Can’t you just use the range of the tcg_type_env?
>
> Simon****
>
> ** **
>
> *From:* Edsko de Vrie
Dear Simon, other ghc devs,
I hooked into genericHscRecompile to traverse the typechecked source and
construct an environment of type
[(SrcSpan, Id)]
recording all identifiers in the source with their type, definition site,
etc. To be precise, I am traversing the
tcg_binds :: LHsBi
36 matches
Mail list logo
