On Thu, Nov 03, 2011 at 07:34:44AM +, Simon Peyton-Jones wrote:
>
> Ian knows the build system.
I think the build system is a red herring in this case - it just so
happens that build system problems can cause the same symptoms. At
least, when I looked into it last time, I got the error with a
varty [mailto:c...@cse.unsw.edu.au]
| Sent: 02 November 2011 23:11
| To: Simon Peyton-Jones
| Cc: Ben Lippmeier; Ian Lynagh; Simon Marlow
| Subject: Re: Safe Haskell haddock segfault
|
| I had this error as well, but could resolve it by fixing a bit-rotted rule in
| rules/haddock.mk:
|
|
On 26 October 2011 09:04, Thomas Schilling wrote:
> I while ago I saw a commit to Safe Haskell changing modules from
> default Unsafe to default Safe.
>
> This seems wrong to me (and Duncan agreed on IRC) -- in security the
> usual advice is to use white listing instead of black listing. The
> re
On Wednesday 26 October 2011, 20:54:46, Johan Tibell wrote:
> Right, but that's not how it used to work.
Oh.
> As soon as any module (e.g. in base) had a Trustworthy pragma you
> needed to ghc-pkg trust base to use base, regardless if you wanted
> to use Safe Haskell or not.
Hmm. In that case,
On Wed, Oct 26, 2011 at 11:04 AM, Daniel Fischer <
daniel.is.fisc...@googlemail.com> wrote:
> I don't understand this. If I don't use Safe Haskell, the compiler should
> ignore all the Safe/Trustworthy/Unsafe pragmas no matter what's the
> default.
> Only if I explicitly choose to use Safe Haskell
On Wednesday 26 October 2011, 19:50:09, Johan Tibell wrote:
> On Wed, Oct 26, 2011 at 9:04 AM, Thomas Schilling
>
> wrote:
> > I while ago I saw a commit to Safe Haskell changing modules from
> > default Unsafe to default Safe.
> >
> > This seems wrong to me (and Duncan agreed on IRC) -- in secur
On Wed, Oct 26, 2011 at 9:04 AM, Thomas Schilling
wrote:
> I while ago I saw a commit to Safe Haskell changing modules from
> default Unsafe to default Safe.
>
> This seems wrong to me (and Duncan agreed on IRC) -- in security the
> usual advice is to use white listing instead of black listing. T
Modules are not considered safe by default, so System.IO.Unsafe is not
considered safe by the absence of a marking.
On 7 September 2011 22:20, Daniel Peebles wrote:
> Does trusting all of base mean we trust System.IO.Unsafe? Or is there an
> explicit "DO NOT TRUST THIS MODULE" attached to it some
Does trusting all of base mean we trust System.IO.Unsafe? Or is there an
explicit "DO NOT TRUST THIS MODULE" attached to it somehow?
On Wed, Sep 7, 2011 at 6:13 PM, David Terei wrote:
> On 6 September 2011 20:33, Corey O'Connor wrote:
> > I'm running into a lot of issues like the following:
> >
On 6 September 2011 20:33, Corey O'Connor wrote:
> I'm running into a lot of issues like the following:
>
> libraries/hoopl/src/Compiler/Hoopl/Collections.hs:14:1:
> base:Data.List can't be safely imported! The package (base) the
> module resides in isn't trusted.
>
> Which can be resolved by a
On Thursday 11 August 2011, 19:23:28, David Terei wrote:
> Hmmm thats annoying. So the issue is that you need to have the base
> package trusted. Originally packages were untrusted by default. I
> changed that so that packages are now trusted by default. However that
> change to Cabal didn't make i
Hmmm thats annoying. So the issue is that you need to have the base
package trusted. Originally packages were untrusted by default. I
changed that so that packages are now trusted by default. However that
change to Cabal didn't make it into 7.2.1. So you need to do this for
your bootstrapping 7.2.1
On 9 August 2011 14:32, Ian Lynagh wrote:
> On Tue, Aug 09, 2011 at 09:16:44PM +, Simon Peyton-Jones wrote:
>> | > Or is the patch only in the upstream Cabal? In which case, it should be
>> pulled
>> | into the GHC repos before committing, no? Else validate fails.
>> |
>> | No I learnt fr
On Tue, Aug 09, 2011 at 09:16:44PM +, Simon Peyton-Jones wrote:
> | > Or is the patch only in the upstream Cabal? In which case, it should be
> pulled
> | into the GHC repos before committing, no? Else validate fails.
> |
> | No I learnt from my mistake last time (I hope so anyway!) and
| > Or is the patch only in the upstream Cabal? In which case, it should be
pulled
| into the GHC repos before committing, no? Else validate fails.
|
| No I learnt from my mistake last time (I hope so anyway!) and manually
| sync'd our lagging Cabal with upstream after pushing the patch.
A
know if not.
>
> Simon
>
> | -Original Message-
> | From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf Of David
> | Terei
> | Sent: 09 August 2011 19:38
> | To: Simon Peyton-Jones
> | Cc: cvs-ghc@haskell.org
> | Subject: Re: Safe Haskell valid
d... maybe
it'll work this time. I'll let you know if not.
Simon
| -Original Message-
| From: davidte...@gmail.com [mailto:davidte...@gmail.com] On Behalf Of David
| Terei
| Sent: 09 August 2011 19:38
| To: Simon Peyton-Jones
| Cc: cvs-ghc@haskell.org
| Subject: Re: S
On 9 August 2011 00:34, Simon Peyton-Jones wrote:
> I’m getting this on a clean validate on Windows
>
> base:Prelude can't be safely imported! The package (base) the module
> resides in isn't trusted.
>
> Any ideas?
>
You need to pull in a recent path to Cabal.
Cheers,
David
___
On 06/08/2011 02:46, David Terei wrote:
Another question, the Haskell 2010 package. Some of the modules here
are unsafe (e.g Foreign.ForeignPtr). My understanding is these
packages are designed to strictly conform to the language
specification. So should I leave Foreign.ForeignPtr alone and do
n
On Fri, Aug 05, 2011 at 06:46:09PM -0700, David Terei wrote:
>
> Another question, the Haskell 2010 package. Some of the modules here
> are unsafe (e.g Foreign.ForeignPtr). My understanding is these
> packages are designed to strictly conform to the language
> specification. So should I leave Fore
On 5 August 2011 01:53, Simon Marlow wrote:
> On 04/08/2011 21:22, David Terei wrote:
>>
>> On 3 August 2011 03:08, Simon Marlow wrote:
>>>
>>> Perhaps all packages should be trusted by default? (Perhaps with some
>>> Cabal
>>> configuration option to reverse the behaviour). After all, trusting
On 04/08/2011 21:22, David Terei wrote:
On 3 August 2011 03:08, Simon Marlow wrote:
Perhaps all packages should be trusted by default? (Perhaps with some Cabal
configuration option to reverse the behaviour). After all, trusting a
package is a no-op unless the package defines some Safe or Trus
On 3 August 2011 03:08, Simon Marlow wrote:
> Perhaps all packages should be trusted by default? (Perhaps with some Cabal
> configuration option to reverse the behaviour). After all, trusting a
> package is a no-op unless the package defines some Safe or Trustworthy
> modules. If we don't do th
On 03/08/2011 03:23, David Terei wrote:
I think we should setup GHC so that the base library is trusted by
default. I'd like to use the 'Safe' pragma in some of the packages
included with GHC but that relies on base being trusted. Assuming no
objections could someone point out please where in the
I think we should setup GHC so that the base library is trusted by
default. I'd like to use the 'Safe' pragma in some of the packages
included with GHC but that relies on base being trusted. Assuming no
objections could someone point out please where in the build process I
need to change so that st
kell.org [mailto:cvs-ghc-boun...@haskell.org] On
Behalf Of
| Simon Peyton-Jones
| Sent: 26 July 2011 08:13
| To: David Terei; Ian Lynagh
| Cc: cvs-ghc@haskell.org; David Mazieres expires 2011-10-22 PDT
| Subject: RE: Safe Haskell
|
| [Widening to cvs-ghc because others may have opinions]
|
| | >
On 26 July 2011 00:12, Simon Peyton-Jones wrote:
> [Widening to cvs-ghc because others may have opinions]
>
> | > Generally, if you want to put a language extension in a pragma then the
> | > compiler needs to support that extension, or compilation will fail.
> | > There may be some odd exceptions
[Widening to cvs-ghc because others may have opinions]
| > Generally, if you want to put a language extension in a pragma then the
| > compiler needs to support that extension, or compilation will fail.
| > There may be some odd exceptions (the main one that comes to mind is
| > {-# LANGUAGE NoSom
The reason is simply I have a bunch of tests I want to run that
require some common infrastructure (in this case a certain package
needs to be initially setup). I'd rather not duplicate the
infrastructure for each test. I can instead of using 'alone' put the
tests into a make file test case, basica
On Tue, Jul 12, 2011 at 01:14:42PM -0700, David Terei wrote:
>
> They should be fixed. I kept the tests dependent on each other but
> added the 'alone' function to the setup field of the tests so that
> they aren't run in parallel. Let me know if this approach is ill
> advised but seems to work fi
On 12 July 2011 06:01, Ian Lynagh wrote:
>
> Hi David,
>
> I'm seeing some Safe Haskell test failures:
>
> safeHaskell/check/pkg01 ImpSafeOnly01 [exit code non-0] (normal)
> safeHaskell/check/pkg01 ImpSafeOnly02 [exit code non-0] (normal)
> safeHaskell/check/pkg01 ImpSafeOnly03 [stderr mi
31 matches
Mail list logo
