Re: Is Safe Haskell intended to allow segfaults?

pointing to a T, and that users could then be granted the power to ferry > them around, but we don't trust a user to be able to do that today. > > It's the combinators that read/write to a Ptr are the dangerous bits, not > pure math. > > -Edward > > > On Wed, Aug 10, 201

Re: Is Safe Haskell intended to allow segfaults?

Hi Simon, On Wed, Aug 10, 2016 at 4:24 AM, Simon Marlow > wrote: > Definining a safe subset of IO is usually an application-specific > decision, e.g. do you want to allow access to the filesystem but without >

Re: Is Safe Haskell intended to allow segfaults?

Heh, ok, segfaults themselves are a red herring. More precisely: The operational semantics for a SafeIO language should always accurately model its memory state. The application should not compute (take a step in the semantics) in a way that exposes corrupt memory or arbitrary undefined

Re: Is Safe Haskell intended to allow segfaults?

he usual means. So if you go to run pure Safe Haskell code in say, > lambdabot, which doesn't give the user a means to execute IO, it can't > segfault if all of the Trustworthy modules you depend upon actually are > trustworthy. > > Trying to shore up segfault safety under Safe in IO seems l

Re: Is Safe Haskell intended to allow segfaults?

On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov wrote: > > Yes, this can be done with JNI, see e.g. [1]. Additionally, by using > sun.misc.Unsafe [2], one can cause segfaults even from pure Java. > [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf > [2]

Re: Is Safe Haskell intended to allow segfaults?

Hi Ed, Thanks, I went back to the paper and read those sections. It sounds like this design heavily reflects the untrusted-code use case. I believe ceding the entire IO monad is too pessimistic, and it's also against the *spirit* of the type safety guarantee mentioned in the paper: "Type

Re: Is Safe Haskell intended to allow segfaults?

> > Pretty sure it's impossible to allow IO without enabling all of it one way > or another. And as soon as you allow *any* IO, you're open to various kinds > of failures including segfaults. The only way you will get your type system > to prevent that is fully specified dependent typing both in

Is Safe Haskell intended to allow segfaults?

We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says:

Re: Benchmarking harnesses for a more modern nofib?

pril 5, 2016, Dominic Steinitz <domi...@steinitz.org> wrote: > >> Ryan Newton gmail.com> writes: >> >> > Hi all, Is anyone currently working in, or interested in helping >> > with, a new benchmark suite for Haskell? Perhaps, packaging up >> > exis

Re: Benchmarking harnesses for a more modern nofib?

Sorry, bit too late: excuse typos: Also, these days companies are building substantial apps in Hackage. > In *Haskell*, of course. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Benchmarking harnesses for a more modern nofib?

Hi all, Is anyone currently working in, or interested in helping with, a new benchmark suite for Haskell? Perhaps, packaging up existing apps and app benchmarks into a new benchmark suite that gives a broad picture of Haskell application performance today? Background: We run nofib, and we run

Re: Semantics of IORefs in GHC

On Mon, Mar 14, 2016 at 10:06 AM, Simon Peyton Jones <simo...@microsoft.com> wrote: > Maclan > > > > I’m glad you enjoyed the awkward squad paper. > > > > I urge you to write to the Haskell Café mailing list and/or ghc-devs. > Lots of smart people there. Ryan New

Re: Better calling conventions for strict functions (bang patterns)?

so we > might need to fall back to a different strategy for LLVM. > > Similar topics came up here: https://ghc.haskell.org/trac/ghc/ticket/8905 > and I think there was another ticket but I can't find it now. > > Cheers > Simon > > On 23/10/2015 19:00, Ryan New

Better calling conventions for strict functions (bang patterns)?

Hi all, With module-level Strict and StrictData pragmas coming soon, one obvious question is what kind of the code quality GHC can achieve for strict programs. When it came up in discussion in our research group we realized we didn't actually know whether the bang patterns, `f !x`, on function

Re: Better calling conventions for strict functions (bang patterns)?

> > >1. Small tweaks: The CMM code above seems to be *betting* than the >thunk is unevaluated, because it does the stack check and stack write >*before* the predicate test that checks if the thunk is evaluated (if >(R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern >

Re: Better calling conventions for strict functions (bang patterns)?

lt;http://research.microsoft.com/~simonpj/papers/strict-core/tacc-hs09.pdf>. > But it’d be a fairly big deal to implement. > > > > Simon > > > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Ryan > Newton > *Sent:* 23 October

Re: Converting unboxed sum types in StgCmm

> > >- >data RepType = UbxTupleRep [UnaryType] >| UbxSumRep [UnaryType] >| UnaryRep UnaryType > > Not, fully following, but ... this reptype business is orthogonal to whether you add a normal type to the STG level that models anonymous, untagged unions, right? That is,

Re: Converting unboxed sum types in StgCmm

> > It seems to me that we just want to rewrite the case altogether into > something that looks at the tag field of the data constructor. Also, in stg > we use the same DataCon as in core, but after stg the unboxed sum case > really only has one constructor (one with the union of all the fields),

Re: ArrayArrays

hope, also describes the menagerie of currently >> available array types and primops so that users can have some chance of >> picking the right one?! >> >> >> >> Thanks >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [m

Re: RFC: Unpacking sum types

Just a small comment about syntax. Why is there an "_n" suffix on the type constructor? Isn't it syntactically evident how many things are in the |# .. | .. #| block? More generally, are the parser changes and the wild new syntax strictly necessary? Could we instead just have a new keyword,

Re: RFC: Unpacking sum types

> > If we expose it on the Haskell level, I find MkSum_1_2# the right thing > to do: It makes it clear that (conceptually) there really is a > constructor of that name, and it is distinct from MkSum_2_2#, and the > user cannot do computation with these indices. > I don't mind MkSum_1_2#, it

Re: ArrayArrays

> vanish. >>> >>> I'll be happy to run through my current working set of issues in person >>> and -- as things get nailed down further -- in a longer lived medium than >>> in personal conversations. ;) >>> >>> -Edward >>> >>>

Re: ArrayArrays

bytes per object, which adds up if they were small enough and there are enough of them. You get a bit better locality of reference in terms of what fits in the first cache line of them. -Edward On Fri, Aug 28, 2015 at 6:14 PM, Ryan Newton rrnew...@gmail.com wrote: Yes. And for the short term I

Re: ArrayArrays

, 2015 at 5:51 PM, Ryan Newton rrnew...@gmail.com wrote: So that primitive is an array like thing (Same pointed type, unbounded length) with extra payload. I can see how we can do without structs if we have arrays, especially with the extra payload at front. But wouldn't the general solution

Re: ArrayArrays

I like the possibility of a general solution for mutable structs (like Ed said), and I'm trying to fully understand why it's hard. So, we can't unpack MutVar into constructors because of object identity problems. But what about directly supporting an extensible set of unlifted MutStruct# objects,

Re: ArrayArrays

just by adding the one primitive. The last 10% gets pretty invasive. -Edward On Fri, Aug 28, 2015 at 5:30 PM, Ryan Newton rrnew...@gmail.com wrote: I like the possibility of a general solution for mutable structs (like Ed said), and I'm trying to fully understand why it's hard. So, we can't

Re: Updating submodules

Has everyone seen the git man page generator ;-)? Hilarious. http://git-man-page-generator.lokaltog.net/ On Tue Jan 06 2015 at 7:49:30 AM Simon Peyton Jones simo...@microsoft.com wrote: Following a chat with Herbert, I've updated https://ghc.haskell.org/trac/ghc/wiki/Repositories Please

Random maintainership -- Was: [core libraries] RE: Core libraries bug tracker

Dear core library folks others, On Tue, Aug 19, 2014 at 10:31 AM, Simon Peyton Jones simo...@microsoft.com wrote: Some core libraries (e.g. random) have a maintainer that isn’t the committee. Ah, since it came up, maybe this is a good time to discuss that particular maintainership. I'm

Re: Adding atomic primops

Yes, that's exactly what I'd like to see as well. Also, we must confess that most worldwide GHC cycles are currently spent on x86. Arm will surely become more important over time. But what's right for x86 is probably right for us for the near/medium term. On Tue, May 20, 2014 at 11:04 AM,

Re: Adding atomic primops

Hi John, My understanding is that GHC does do reordering of memory operations, in the CmmSink pass ( http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/CmmSink.html, http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/). In particular ghc may

Re: Adding atomic primops

This would be fantastic and I'd be happy to work with you to expose the extra ops through the atomic-primops pkg. This would continue our trend of supporting gcc intrinsic style atomics (full fence, no configurabilit of the memory model a la lllvm). These word sized ops are most important, but

Re: Adding atomic primops

Hi John Carter, Deferring for a moment issues with CAS on lazy/pointer values, which pertain to Carter's question, I want to understand the ordering concern WRT only the IntArray primops that Johan listed. First, to my knowledge GHC doesn't do any reordering of effectful memory operations (e.g.

Re: Adding atomic primops

For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both* compilers (GHC LLVM). Since I don't think GHC is a problem, let's talk about LLVM. We need to verify that LLVM understands not to float regular loads and

Re: Adding atomic primops

the implementations by going to in-line primops. Best, -Ryan On Mon, May 5, 2014 at 12:25 AM, Ryan Newton rrnew...@gmail.com wrote: For Johan's primops to work, each primop must represent a full memory fence that is respected both by the architecture, and by *both*compilers (GHC LLVM

Re: Adding atomic primops

Oh, just the first CAS primop -- the initial decision to include these kinds of ops. Sent from my phone. On May 5, 2014 12:59 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what sailed in ghc 7.2? On Mon, May 5, 2014 at 12:46 AM, Ryan Newton rrnew...@gmail.com wrote: One last

Re: Support for glibc 2.12 in 7.8 RC2

Yes, this is a really annoying issue on RHEL, which includes many supercomputers. Sent from my phone. On Feb 7, 2014 1:35 PM, Rob Stewart robstewar...@gmail.com wrote: Hi, The 7.8 RC1 status page [1] states RC1 requires glibc 2.15, and that RC2 will support glibc 2.13 to target Debian 7.

Re: Bad news: apparent bug in casMutVar going back to 7.2

this out as a naive obvious guess) On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton rrnew...@gmail.comwrote: Then again... I'm having trouble seeing how the spec on page 3-149 of the Intel manual would allow the behavior I'm seeing: http://www.intel.com/content/dam/www/public/us/en/documents/manuals

Re: Bad news: apparent bug in casMutVar going back to 7.2

in on atomic-primops before I can test it locally :), expect those patches later today! looks like gcc's inline ASM logic is pretty correct, after testing it a bit locally, pardon my speculative jumping the gun. On Sat, Feb 1, 2014 at 9:10 AM, Ryan Newton rrnew...@gmail.com wrote: Hi Carter

Re: Bad news: apparent bug in casMutVar going back to 7.2

, clear ZF and load r/m64 into RAX. is what the docs say for the cmpxchng instruction so RAX is the old values, (EAX in the 32bit case). And it looks like we dont' set that explicitly when calling the asm .. CMPXCHG r/m64, r64 hrmmm On Sat, Feb 1, 2014 at 12:52 PM, Ryan Newton rrnew

Re: Bad news: apparent bug in casMutVar going back to 7.2

we're seeing with the current Haskell primops. Two threads simultaneously performing the same CAS(p,a,b) can both think that they succeeded. On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton rrnew...@gmail.com wrote: I commented on the commit here: https://github.com/ghc/ghc/commit

Re: GHC 7.8 release status

Thanks for the reminder. Wiki is updated; atomics branch is merged. The only further work I plan to do in the near term is add additional tests. On Wed, Sep 4, 2013 at 9:52 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Friends The 7.8 release is imminent. This email is to ask

Re: GHC 7.8 release status

By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list

Re: Any GHC plans to adopt tf-random?

...@gmail.comwrote: Adding Ryan Newton to the TO field, as the maintainer of random. On Wed, Nov 6, 2013 at 2:02 PM, Nicolas Frisby nicolas.fri...@gmail.comwrote: Bugs #3575 #3620 have to do with splitting StdGens yielding dependent generators. The Haskell 2013 paper *Splittable Pseudorandom

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Derives MyData Show NB that there is no instance Derives MyData Ord, but standalone deriving could yield one later On Mon, Oct 14, 2013 at 10:02 PM, Ryan Newton rrnew...@gmail.com wrote: Hey, that's an awesome formulation! Thanks Pedro. Any idea how much work this would be to implement

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Here‘s a thought: doesn’t Generic already have an unused phantom type that's only there “just in case we need to add something in the future”? How about using that to track whether an instance was derived or not, and enforce *that* with SafeHaskell? Your SafeEq can then use a Generic Derived

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

On Mon, Oct 7, 2013 at 10:22 AM, Edward Kmett ekm...@gmail.com wrote: Am I correct in understanding your issue arises from manually rolled instances of Generic, not from Generic itself? Exactly. Wouldn't then perhaps the better fix be to resurrect the old rule for derived Typeable

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

My understanding is that the proposed changes to ghc/Generic would mean that all data used with LVish would have to expose it's implementation to everybody through the derived Generic instance. Either that or they would have use TrustWorthy to mark a module containing custom

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam gan...@earth.li wrote: - Referential transparency: e.g. no unsafePerformIO - Module boundary control: no abstraction violation like Template Haskell and GeneralizedNewtypeDeriving - Semantic consistency: importing a safe module can't

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

PM, Ryan Newton rrnew...@gmail.com wrote: Hi all, We had a discussion on haskell-cafe, which only confirmed the unreliability of Eq and Ord. Fine. But if I instead want to define a SafeEq class and instances based on GHC.Generics, then I can't have users writing Generic instances

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

conventions. On Sun, Oct 6, 2013 at 11:18 PM, Ryan Newton rrnew...@gmail.com wrote: I can't know for certain but I think I would bet money on nothing. Edward David may know more about what actual use SafeHaskell is getting? On Sun, Oct 6, 2013 at 5:46 PM, Johan Tibell johan.tib

Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

of the user making their own Generic instances and is instead related to simply exposing to... Thanks for putting that together. On Mon, Oct 7, 2013 at 1:13 AM, John Lato jwl...@gmail.com wrote: On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton rrnew...@gmail.com wrote: On Sun, Oct 6, 2013 at 6:28

Re: Anyone else failing to validate on 'linker_unload'?

Ryan, can you do one final thing? When you run that program, be sure to specify `+RTS -Dl` (must be linked with -debug.) This will enable all the debug output where the linker is concerned. There will be a few hundred lines just for initialization (based on my machine.) If my theory is

Anyone having trouble with make install in HEAD?

Earlier this summer I had no problem with configure; make; make install But recently I'm getting errors like this on GHC HEAD: /u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0 .0-ghc7.7.20130831.so: cannot open

Design discussion for atomic primops to land in 7.8

There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1 It is a fairly simple extension of the casMutVar# that has been in since 7.2. The implementation is on the `atomics` branch currently. Feel free to add your views either here or on that

Re: Design discussion for atomic primops to land in 7.8

as well. (adding simd support on the native codegen would be nice too, but probably *substantially *more work) On Thu, Aug 22, 2013 at 11:40 AM, Ryan Newton rrnew...@gmail.com wrote: There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1

Re: how to checkout proper submodules

Hi all, I just reread this thread again. Is this one of these situations where *almost everyone agrees, but the fix just didn't happen*? In particular, there is still no formal relationship between versions of the compiler and versions of the testsuite that tests it -- that seems odd! Can we

Re: how to checkout proper submodules

Of *Austin Seipp *Sent:* 22 August 2013 20:31 *To:* Ryan Newton *Cc:* ghc-devs@haskell.org; Edward Kmett *Subject:* Re: how to checkout proper submodules ** ** Simon and I discussed this a little today. I think there are several legitimate points made throughout the threads here

Re: Reproducible build recipes for GHC development VMs?

Oh, good question. It was Ubuntu 12.04 LTS so I just assumed it would be too old without checking. On Thu, Aug 22, 2013 at 3:38 AM, Simon Marlow marlo...@gmail.com wrote: On 21/08/13 15:44, Ryan Newton wrote: Hi all, Returning to the topic discussed by Simon M. and others here: http

GHC branch atomics pushed

Hi all, There should be very little that is controversial about this branch because it adds primops upon which nothing else depends and which users will not see directly. But for now I've added it to a branch called atomics (likewise use the atomics testsuite branch of course). As soon as

Reproducible build recipes for GHC development VMs?

Hi all, Returning to the topic discussed by Simon M. and others here: http://projects.haskell.org/pipermail/haskell-platform/2009-July/000572.html This is my attempt at a script for bootstrapping a GHC-validating VM:

Re: Reproducible build recipes for GHC development VMs?

), the VM can either copy files to the host, through a shared filesystem, or just use the network to report results. I'd be happy to help setting this up for GHC https://github.com/ghcjs/ghcjs-build On Wed, Aug 21, 2013 at 4:44 PM, Ryan Newton rrnew...@gmail.com wrote: Hi all, Returning

Re: 7.8 Feature window

Hi all, It is not merged into master presently but I would like to propose the three new primops that are on the atomics branch for inclusion in 7.8. These are pretty much completely apart from everything else and don't break any existing code. For the public library that exposes these things

Re: GHC branch atomics pushed

Done! On Wed, Aug 21, 2013 at 12:21 PM, Simon Peyton-Jones simo...@microsoft.comwrote: Great. Can you add a bullet to http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8? Simon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Ryan Newton *Sent

What are the current rules about object duplication during GC?

Is the status quo still the same as it was in this paper? http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/par-gc-ismm08.pdf That is, there is a low-probability that a race will result in immutable objects being duplicated, but not mutable objects. But that leaves me

Re: Proposal: provide cas and barriers symbols even without -threaded

Do you have a branch already lined up for your LLVM-atomics work? On Sat, Aug 10, 2013 at 7:02 PM, Carter Schonwald carter.schonw...@gmail.com wrote: huh, did I suggest viewing it as a bug fix? my mistake! (a branch would make sense) On Sat, Aug 10, 2013 at 12:40 PM, Ryan Newton rrnew

Re: Proposal: provide cas and barriers symbols even without -threaded

on bitbucket or some such so I can have a lookseee/clone locally? thanks! -Carter On Sat, Aug 3, 2013 at 4:01 AM, Ryan Newton rrnew...@gmail.com wrote: Just to keep you all up to date... I'm adding the primops in question and validating the individual commits before putting them here

Re: Proposal: provide cas and barriers symbols even without -threaded

That would fix the -threaded/unthreaded disparity. But I still don't see how to access this stuff properly from foreign-primops in a library such that GHCI doesn't barf when trying to load the library If you're referring to the problem with the missing stg_MUT_VAR_CLEAN_info symbol,

Call for talks: Haskell Implementors Workshop 2013, Sept 22, Boston

to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers -- * Ryan Newton(Indiana University) * Neal Glew (Intel Labs) * Edward Yang(Stanford University) * Thomas Schilling (University of Kent) * Geoffrey

Re: Proposal: provide cas and barriers symbols even without -threaded

Edward, This makes sense to me. Especially because eliding-synchronization is already the convention followed in SMP.hs, where, for example, write_barrier becomes noops if !THREADED_RTS. All I would need would be linkable symbols for those noops (a la

Re: Proposal: provide cas and barriers symbols even without -threaded

machinery in ghc's rts On Fri, Jul 19, 2013 at 1:02 PM, Ryan Newton rrnew...@gmail.com wrote: Yes, I'd absolutely rather not suffer C call overhead for these functions (or the CAS functions). But isn't that how it's done currently for the casMutVar# primop? https://github.com/ghc/ghc/blob

Re: Proposal: provide cas and barriers symbols even without -threaded

Hi Simon, That sounds like a good solution and I'll attempt a patch. I think the fix is only three lines. That is, replace these three lines with EXTERN_INLINE C functions: #define write_barrier() /* nothing */ #define store_load_barrier() /* nothing */ #define load_load_barrier() /*

Re: Proposal: provide cas and barriers symbols even without -threaded

need some active guidance / monitoring for the native codegen analogues (also asked this on ticket for documentation purposes) On Sat, Jul 20, 2013 at 2:18 AM, Ryan Newton rrnew...@gmail.com wrote: Hi Carter, Yes, SMP.h is where I've copy pasted the duplicate functionality from (since I

Re: Proposal: provide cas and barriers symbols even without -threaded

to do then. Ill look into in a few days. On Friday, July 19, 2013, Simon Marlow wrote: On 18/07/13 14:17, Ryan Newton wrote: The atomic-primops library depends on symbols such as store_load_barrier and cas, which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT

Proposal: provide cas and barriers symbols even without -threaded

The atomic-primops library depends on symbols such as store_load_barrier and cas, which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT -threaded, the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign C' bits of this

Re: [GHC] #7820: Installing profiling library BREAKS non-profiling executable

By the way, does anyone have a positive example of a package on hackage that (1) uses foreign primops and (2) is robust across a wide variety of platforms and build methods? It would be great to work from such an example. Thanks, -Ryan On Mon, Apr 8, 2013 at 10:57 AM, GHC