On 01/15/13 08:56 PM, Thijs Alkemade wrote:
Op 15 jan. 2013, om 18:16 heeft Karel Gardas het
volgende geschreven:
Well, if you make some board available in DMZ I'm certainly interested to run
at least configure on it from GHC HEAD to see what we need to hack in order to
add support for RPi
Op 15 jan. 2013, om 18:16 heeft Karel Gardas het
volgende geschreven:
> Well, if you make some board available in DMZ I'm certainly interested to run
> at least configure on it from GHC HEAD to see what we need to hack in order
> to add support for RPi into GHC HEAD.
>
> Unfortunately GHC HE
Well, just wild guessing what's needed on RPi, but could you who do have
this board attempt to use attached patch? Don't forget to ./boot as this
change configure. Also testing it on completely clean tree may be wise
idea. Also after configure run please check that you do have VFPv2 in
the ex
rocon...@theorem.ca writes:
> Okay, I tried:
>
> SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard
> -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2
> GhcStage1HcOpts= -O -fllvm
> GhcStage2HcOpts= -O0 -fllvm
> GhcLibHcOpts = -O -fllvm -optlc-float-abi=hard
>
> and I
Well, if you make some board available in DMZ I'm certainly interested
to run at least configure on it from GHC HEAD to see what we need to
hack in order to add support for RPi into GHC HEAD.
Unfortunately GHC HEAD is now in a wrong state w.r.t. LLVM based build,
but Austin is working on thi
In theory we could try a couple variations of builds at the same time.
But at the moment, I'm running low on ideas on what to try.
I just got the, extensive, raspbian patches for 7.4.1 and I'm going to
browse through them when I get time (apt-get source ghc).
On Tue, 15 Jan 2013, Neil Davies
On Tue, 15 Jan 2013, Thijs Alkemade wrote:
Op 15 jan. 2013, om 17:36 heeft rocon...@theorem.ca het volgende geschreven:
Okay, I tried:
SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-march=armv6
-optc-mfpu=vfp -optlc=-mattr=+vfp2
GhcStage1HcOpts= -O -fllvm
GhcStage2H
Hi - would another RPi (or even 2 from tomorrow another one arriving) help?
I can make them accessible (i.e. in our DMZ) -
Neil
On 15 Jan 2013, at 16:36, rocon...@theorem.ca wrote:
> On Mon, 14 Jan 2013, Thijs Alkemade wrote:
>
>> Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgend
Op 15 jan. 2013, om 17:36 heeft rocon...@theorem.ca het volgende geschreven:
> Okay, I tried:
>
> SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard
> -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2
> GhcStage1HcOpts= -O -fllvm
> GhcStage2HcOpts= -O0 -fllvm
> GhcLibHcOpt
On Mon, 14 Jan 2013, Thijs Alkemade wrote:
Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven:
On Thu, 10 Jan 2013, Karel Gardas wrote:
Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of
ARMv6/ARM11 chip here...
I'm afraid LLVM is not well g
Hi,
Am Montag, den 14.01.2013, 18:09 + schrieb Simon Peyton-Jones:
> I’d appreciate
>
> ·A sense of whether you care. Does this matter?
> ·Improvements to the design I propose
I do care (but that is no news, given my pestering on #2110 :-)) and
obviously I am happy that thing
| If you as the library writer don't want to allow unsafe things, then
| don't export the constructor. Then no one can break your invariants,
| even with newtype malarky. If you as the the library user go and
| explicitly import the bare Set constructor from (theoretical)
| Data.Set.Unsafe, then
On Tue, Jan 15, 2013 at 3:15 AM, Iavor Diatchki
wrote:
> In general, I was never comfortable with GHC's choice to add an axiom
> equating a newtype and its representation type, because it looks unsound to
> me (without any type-functions or newtype deriving).
> For example, consider:
>
> newtype T
13 matches
Mail list logo
