On Mon, Aug 26, 2013 at 12:51 PM, Herbert Valerio Riedel wrote:
> ...btw, do we actually know which (or how many) packages are affected?
I believe at least one of my packages will be affected, and even if we go
and run the analysis on Hackage (I expect only a handful of packages to run
into this
I guess that's a valid argument. I'll discuss this with Simon tomorrow.
Janek
Dnia poniedziałek, 26 sierpnia 2013, Simon Marlow napisał:
> On 26/08/13 10:38, Jan Stolarek wrote:
> >> So since we have to break the API anyway, why not break it in the way
> >> that we want?
> >
> > Oh, but the thing
On 2013-08-26 at 10:56:15 +0200, Gregory Collins wrote:
> On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote:
>> On 25/08/13 20:16, Jan Stolarek wrote:
>>> We really want people to use the new primops, not the wrappers
>>> We do? Could you justify why we want to people to use primops?
>>>
>>
On 26/08/13 10:38, Jan Stolarek wrote:
So since we have to break the API anyway, why not break it in the way
that we want?
Oh, but the thing is we don't! We have a plan to rename GHC.Prim to
GHC.Prim.BuiltIn, rename
GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export
GHC.Prim.Buil
On 26/08/13 09:56, Gregory Collins wrote:
On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
On 25/08/13 20:16, Jan Stolarek wrote:
We really want people to use the new primops, not the wrappers
We do? Could you justify why we want to peop
> So since we have to break the API anyway, why not break it in the way
> that we want?
Oh, but the thing is we don't! We have a plan to rename GHC.Prim to
GHC.Prim.BuiltIn, rename
GHC.PrimWrappers (in ghc-prim) to GHC.Prim and make it re-export
GHC.Prim.BuiltIn [1]. This way
change will be com
On 26/08/13 09:50, Jan Stolarek wrote:
I don't mind breaking these very low-level APIs.
We are breaking that API at the moment, except that you propose to break it by
chnaging type
signatures, whereas I chose to break it by changing names. So currently the
change in primops
will not go unnoti
On Sun, Aug 25, 2013 at 9:47 PM, Simon Marlow wrote:
> On 25/08/13 20:16, Jan Stolarek wrote:
>
>> We really want people to use the new primops, not the wrappers
>>>
>> We do? Could you justify why we want to people to use primops?
>>
>
> What I meant was, if people are already using primops we w
> Previously the tagToEnum# was optimised away in the code generator in
> the common cases. Perhaps the Simplifier will do that for the wrappers
> now, I don't know.
This special case is still in the code generator and it will be there until we
move handling of
tagToEnum# to Core. So using wra
On 25/08/13 20:16, Jan Stolarek wrote:
We really want people to use the new primops, not the wrappers
We do? Could you justify why we want to people to use primops?
What I meant was, if people are already using primops we want them to
use the new ones instead.
> Wrappers are equivalent to p
> We really want people to use the new primops, not the wrappers
We do? Could you justify why we want to people to use primops? Wrappers are
equivalent to previous
implementation of primops: previously we had call to tagToEnum# generated
implicitly by the code
generator, whereas now we have an
e: czwartek, 22 sierpień 2013 14:43:29
| Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature
| window)
|
| > 1. Why do you say "this naming feels more consistent"? Consistent
| with what?
| Convention is that functions ending with # operate on unboxed values and
| retur
: RE: Changes to primops break libraries (was Re: 7.8 Feature window)
I think that's a pretty good idea. It's not just a hack... it makes sense even
if you ignore the issues of managing the transition.
Maybe GHC.Prim.Builtin for the machine-generated not-written-in-Haskell
operation
---
| From: Geoffrey Mainland [mailto:mainl...@apeiron.net]
| Sent: 22 August 2013 16:18
| To: Jan Stolarek
| Cc: Simon Peyton-Jones; ghc-devs@haskell.org
| Subject: Re: Changes to primops break libraries (was Re: 7.8 Feature
| window)
|
| This is not a completely serious suggestions, but... If we
In addition to the Hooks patch (see other mail on this post) I have a few
minor updates to support GHCJS that I think are pretty uncontroversial:
1. Add a WayCustom to the Ways type in DynFlags to make custom tags. We use
this to generate native code (.o, .hi) and JS code (.js_o, .js_hi) in the
sa
k" , "Gabor Greif"
> DW: ghc-devs@haskell.org
> Wysłane: czwartek, 22 sierpień 2013 13:40:09
> Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window)
>
> Jan
>
> Four things:
>
> | •Six primops are an exception to the rules above: s
k, 22 sierpień 2013 15:31:32
Temat: RE: Changes to primops break libraries (was Re: 7.8 Feature window)
| Oh, and I think that using sameTVar# for primop and sameTVar for wrapper
| is a good choice, even if we make transition slightly more difficult.
| This naming feels better to me
You said that
es to primops break libraries (was Re: 7.8 Feature window)
Jan
Four things:
| •Six primops are an exception to the rules above: sameMutableArray#,
| sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar#
| and sameTVar#. Their names have remained the same as before and new
| wrapp
k the consistency of this naming convention.
Simon
|
| Janek
|
| - Oryginalna wiadomość -
| Od: "Jan Stolarek"
| Do: "Simon Peyton-Jones"
| DW: ghc-devs@haskell.org, "Gabor Greif"
| Wysłane: czwartek, 22 sierpień 2013 14:43:29
| Temat: Re: Changes to prim
- Oryginalna wiadomość -
Od: "Jan Stolarek"
Do: "Simon Peyton-Jones"
DW: ghc-devs@haskell.org, "Gabor Greif"
Wysłane: czwartek, 22 sierpień 2013 14:43:29
Temat: Re: Changes to primops break libraries (was Re: 7.8 Feature window)
> 1. Why do you say &
> 1. Why do you say "this naming feels more consistent"? Consistent with what?
Convention is that functions ending with # operate on unboxed values and return
unboxed values (usually), so to me it seemed consistent that sameTVar# returns
an unboxed value, while sameTVar does not. I raised that p
Jan
Four things:
| •Six primops are an exception to the rules above: sameMutableArray#,
| sameMutableByteArray#, sameMutableArrayArray#, sameMutVar#, sameMVar#
| and sameTVar#. Their names have remained the same as before and new
| wrappers created for them lack # at the end of their name. We mad
On 21/08/13 16:11, Ryan Newton wrote:
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 th
http://ghc.haskell.org/trac/ghc/ticket/5144
>
> ** **
>
> Talk later this week.
>
>
> Simon
>
> ** **
>
> ** **
>
> ** **
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Dr.
> ÉRDI Gergo
> *Sent:* 21 August
On Tue, Aug 20, 2013 at 10:01 AM, Austin Seipp wrote:
> There are a few things we know for sure are - or were - tentatively
> scheduled for this release:
>
> * SIMD improvements
> * New Template Haskell
> * Constraint solver for type naturals
>
I have some additional optimizations to the new
mailto:ghc-devs-boun...@haskell.org] On Behalf Of Dr. ÉRDI Gergo
Sent: 21 August 2013 01:56
To: Austin Seipp
Cc: ghc-devs@haskell.org
Subject: Re: 7.8 Feature window
On Aug 21, 2013 1:05 AM, "Austin Seipp"
mailto:ase...@pobox.com>> wrote:
> * ERDI was working on pattern synony
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 thing
> Hmm, almost, but I get now:
> (...)
> How to repackage Int# to Bool?
Oh dear... that's that 5% :) You just want sameMutableArray instead of
sameMutableArray#. There will be problems with sameMVar and so on (if primitive
uses them - I don't remember), but that's fixed in a similar way. A quick l
On 8/21/13, Jan Stolarek wrote:
> Hi Gabor,
>
>> I get these errors when building a cabal package:
>> (...)
>> I guess this is related to those changes.
> Yes, that's because of my patches.
>
>> If yes, what to do next? Contact the 'primitive' maintainer?
> It's just like with any other backwards-
Hi Gabor,
> I get these errors when building a cabal package:
> (...)
> I guess this is related to those changes.
Yes, that's because of my patches.
> If yes, what to do next? Contact the 'primitive' maintainer?
It's just like with any other backwards-incompatible changes in GHC - package
mainta
On 8/20/13, Jan Stolarek wrote:
>> Details here: do please modify directly:
>> http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
> Feature I was working on has been merged into HEAD. Should I remove it from
> the list?
Hello Jan,
I get these errors when building a cabal package:
Data/Primitiv
On Aug 21, 2013 1:05 AM, "Austin Seipp" wrote:
> * ERDI was working on pattern synonyms. I believe you were having some
trouble with the implementation. Can someone help him if necessary?
Hi,
I've updated the Trac ticket with the latest status of my work. There are
only two loose ends remainin
Hello,
For the constraint solver for type naturals: I think we should certainly
have some form of it in 7.8, even if it is the really simple version that
just knows things like: 5 + 3 = 8.There is a bit of work to be done to
catch up the type-nats branch to HEAD, mainly to do with Richard's ch
Yes - but leavae it to me. I'll do some cleanup since some of Richard's
work was also merged.
On Tue, Aug 20, 2013 at 12:14 PM, Jan Stolarek wrote:
> > Details here: do please modify directly:
> > http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
> Feature I was working on has been merged into
> Details here: do please modify directly:
> http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
Feature I was working on has been merged into HEAD. Should I remove it from the
list?
Janek
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haske
Details here: do please modify directly:
http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8
S
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Austin Seipp
Sent: 20 August 2013 18:01
To: ghc-devs@haskell.org
Subject: 7.8 Feature window
All,
GHC 7.8's release is drawing
All,
GHC 7.8's release is drawing near. We would like to make a release
candidate sometime around ICFP, which will be in late September.
Unfortunately that's just over a month a way, so the clock is ticking!
The tree will need a few weeks of stabilization. After that, we will
release an RC, and l
37 matches
Mail list logo
