+1
On Jan 19, 2014 3:15 PM, "Mark Lentczner" wrote:
> Looks like GHC 7.8 is pretty near release.
>
> And while I know that we really like to have a GHC out for a while, and
> perhaps see the .1 release, before we incorporate it into the Platform,
> this GHC, while
The best way I know is to put INLINABLE on all functions with dictionaries
that you want removed. That's what we do in e.g. containers. The pragma is
perhaps a bit misnamed, as it doesn't only imply that we make the source of
the function available for inlining, but also that we specialize the
I think the difference between the inlinable and specialize pragma is
whether the specialization needs to be driven by the call site or not. If
you have a handful of known types you want to specialize for up front, you
can use the specialize pragma. If the set is large or unknown (like in the
case
Happy birthday!
On Tue, Jan 19, 2016 at 9:31 AM, raichoo wrote:
> Happy Birthday!
>
> Thanks for all your work, I'm very happy with Haskell and GHC, especially
> now that I
> can use it at work :D.
>
> I've been digging through GHC for months now, hoping to contribute
>
; I quite like this design. It's not clear to me that anything useful
> is gained by forcing y and z in M3 before evaluating the body "...".
> > >
> > >
> > > So Roman's design makes sense, but so does the implemented design
> (modulo any bugs). The troub
015 04:34 PM, Johan Tibell wrote:
> > I'm snowed under but I promise I will try to reply soon! To think about
> > in the mean time: what do existing strict languages with pattern
> > matching do?
>
> Well, strict languages do not have lazy data to force to begin with,
I believe this is just a bug, since the desugaring ought to be strict in
the \x.
On Tue, Dec 8, 2015 at 6:35 PM, Ömer Sinan Ağacan
wrote:
> I think this is a problem/bug in the implementation. In the "function
> definitions" section of the wiki page it says the argument
on random side projects, including GHC, and to
continue coming to Haskell events and conference, just with a shorter bug
backlog to worry about. :)
-- Johan Tibell
* For now I will still hack on unordered-containers and ekg, as there are
some things I'd like to experiment
->
>
>
>
> ds2 is the thing that contains either an Int or a char; ds1 is the tag
> that distinguishes htem.
>
>
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 14 September 2015 17:03
> *To:* Ryan Newton; Simo
but I’m pretty sure I’m not wrong in a
>> fundamental way.
>>
>
> Yes, the only thing the code generator needs to do with types is convert
> them to PrimReps (see idPrimRep), and all GC pointer types have the same
> PrimRep (PtrRep).
>
> Cheers
> Simon
>
>
>
data type; the AltCons will be DataAlts
| PrimAlt TyCon -- Primitive data type; the AltCons will be LitAlts
or do I also have to capture which alternative was used here? Why do we
capture the arity in *tuple* case here?
On Mon, Sep 14, 2015 at 6:21 AM, Johan Tibell <johan.tib...@gmail.
I've given this a yet some more thought. Given this simple core program:
f [InlPrag=NOINLINE] :: (#|#) Int Char -> Int
[GblId, Arity=1, Str=DmdType]
f =
\ (ds_dmE :: (#|#) Int Char) ->
case ds_dmE of _ [Occ=Dead] {
(#_|#) x_amy -> x_amy;
(#|_#) ipv_smK -> patError @ Int
needs
> to know, really, is which things are pointers. Detailed type info like
> “are you a Char or a Bool” is strictly jam; indeed never used I think. (I
> could be wrong but I’m pretty sure I’m not wrong in a fundamental way.
>
>
>
> SImon
>
>
>
> *From:* Johan Tibe
Hi!
The original idea for implementing the backend part of the unboxed sums
proposal was to convert from the core representation to the actual data
representation (i.e. a tag followed by some pointer and non-pointer fields)
in the unarise stg-to-stg
I wonder if rewriting any aliased pointer field as Any in Stg and any
non-pointer field as Word# would work. I suspect that not all non-pointer
fields (e.g. Double# on 32-bit) can be represented as Word#.
On Wed, Sep 9, 2015 at 3:22 PM, Johan Tibell <johan.tib...@gmail.com> wrote:
I have a draft design for unpacking sum types that I'd like some feedback
on. In particular feedback both on:
* the writing and clarity of the proposal and
* the proposal itself.
https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes
-- Johan
___
ntly put unboxed tuples in data types now. I'm not certain
> if they would cover all cases, though (like the strictness concerns
> above).
>
> -- Dan
>
>
> On Tue, Sep 1, 2015 at 1:23 PM, Johan Tibell <johan.tib...@gmail.com>
> wrote:
> > I have a draft design for un
e
> >> motivating factors for me doing this. It is rather astoundingly
> difficult to
> >> beat the performance of HashMap, so I had to start cheating pretty
> badly. ;)
> >>
> >> -Edward
> >>
> >> On Sat, Aug 29, 2015 at 5:45 PM, Johan Tibell <jo
I'd also be interested to chat at ICFP to see if I can use this for my HAMT
implementation.
On Sat, Aug 29, 2015 at 3:07 PM, Edward Kmett ekm...@gmail.com wrote:
Sounds good to me. Right now I'm just hacking up composable accessors for
typed slots in a fairly lens-like fashion, and treating
attractive.
I don’t understand. Can you describe the problem more precisely, perhaps
with an example?
S
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
Tibell
*Sent:* 25 August 2015 10:42
*To:* ghc-devs@haskell.org
*Subject:* OVERLAPPABLE/OVERLAPPING
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com wrote:
I think there are two important consequences of MonadFail. First of all,
we can
all safely write failable patterns if we so desire. Second, the compiler
can
ensure other people's codebases do not lie
On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka r...@ro-che.info wrote:
On 10/06/15 14:22, Johan Tibell wrote:
On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
dluposchain...@googlemail.com mailto:dluposchain...@googlemail.com
wrote:
I think there are two important
Thanks for putting this together.
The proposal says:
As a consequence, in current Haskell, you can not use Monad-polymorphic
code safely, because although it claims to work for all Monads, it might
just crash on you. This kind of implicit non-totality baked into the class
is terrible.
Is this
On Thu, Jun 4, 2015 at 10:30 PM, Edward Z. Yang ezy...@mit.edu wrote:
Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700:
Looks to me like it's confused about whether a ~ is part of an equality
constraint or is a laziness annotation. The former would be illegal at
that
On Apr 19, 2015 09:44, Joachim Breitner m...@joachim-breitner.de wrote:
Dear devs,
in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
code like
f :: Int - Bool
f a = case a of
1 - True
5 - True
8 -
cabal-install should be 1.22.2.0 (latest). Otherwise looks good.
On Mar 25, 2015 7:32 AM, Mark Lentczner mark.lentcz...@gmail.com wrote:
*Hey you* yes you... Platform committee member, or Platform library
maintainer, Platform packager... that's right, you:
GHC 7.10 is about to be
On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
But time has passed and it hasn't happened. Is this because I'm
misunderstanding? Or because it is harder than I think? Or because there
are much bigger problems? Or because there is insufficient effort
We will probably want to ship that with GHC 7.10.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On Tue, Jan 27, 2015 at 3:12 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
| 1. What are the IV instances provided in base? These could give
| selector functions, lenses, both or neither.
My instinct: just selector functions. Leave lenses for a lens package.
+1
I really like this proposal (except I would bike shed about the syntax for
record selector to be dot, like in the majority of languages.)
On Fri, Jan 23, 2015 at 3:41 PM, Simon Peyton Jones simo...@microsoft.com
wrote:
| I just
| noticed that it effectively gives us a syntax for
Don't worry about the merge commit.
On Jan 22, 2015 11:57 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
BOTHER!
I have no idea how my commit, which was meant to change two all.T files,
also ended up adding libraries/haskell98.
I'll revert and re-commit.
I also inadvertently did 'git
On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:
On 21/01/2015 16:01, Johan Tibell wrote:
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
Backwards compatible in what sense? Extension flags provide backwards
My thoughts mostly mirror those of Adam and Edward.
1) I want something that is backwards compatible.
2) Anonymous records are nice to have, but I don't want to have all records
be anonymous (and have to jump through newtype hoops to get back
non-anonymous records.)
3) I don't think it's a good
but the
latter is source code specified.
· Why isn't this information split over two data types. Because
there’s a bit of overlap. See comments with HsSrcBang
Simon
*From:* Johan Tibell [mailto:johan.tib...@gmail.com]
*Sent:* 08 January 2015 07:36
*To:* ghc-devs@haskell.org
*Cc
have -funbox-strict-fields?
On Sun, Jan 11, 2015 at 6:28 PM, Johan Tibell johan.tib...@gmail.com
wrote:
Those comments and the renaming really help. Here are a couple of more
questions I got after exploring some more:
DsMeta.repBangTy look wrong to me:
repBangTy :: LBangType Name - DsM
or mismatched brackets)
-- Johan
On Sun, Jan 11, 2015 at 8:11 PM, Johan Tibell johan.tib...@gmail.com
wrote:
Yet another one. TcSplice.reifyStrict doesn't take the unboxing flags into
account either. Should it?
reifyStrict :: DataCon.HsSrcBang - TH.Strict
reifyStrict HsNoBang
We could file a tracking bug against the 7.14 milestone.
Just curious, is there a way to keep these functions for backwards compat
in 7.14 or is that unfeasible?
On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
I want to deprecate some Template Haskell functions in
I think using the words error and warning makes sense. For example, this is
how Clang (LLVM) does it:
format-strings.c:91:13: warning: '.*' specified field precision is missing
a matching 'int' argument
printf(%.*d);
^
t.c:7:39: error: invalid operands to binary expression ('int'
On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka r...@ro-che.info wrote:
On 09/01/15 12:02, Jan Stolarek wrote:
We could file a tracking bug against the 7.14 milestone.
I was considering that but we don't have 7.14 milestone yet.
Just curious, is there a way to keep these functions for
On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
Why hide them? DEPRECATEd entities have the deprecation-message shown in
discouraging red letters (including any hyperlinks to their
replacements) in the generated Haddock documentation...
I think Java's (!)
probably upstream this patch.
Shipping libraries with debug symbols should be fine, as long as they can
be stripped - Peter, does stripping remove everything that -g creates?
Cheers,
Simon
On 02/01/2015 23:18, Johan Tibell wrote:
Hi!
We are now able to generate DWARF debug info, by passing
On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
I agree. You'll get rid of the redundancy in the library by removing it
but
you're users will have to live with (...)
That's why I want to deprecate them first and give users one release cycle
to switch to new
On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
I think Java's (!) policy for deprecation is good
I think it's not. It keeps the library code a mess and many times I have
seen users using
functions that have been deprecated for years just because it's easier to
anyways. We can always re-introduce the data
for higher -gn levels.
Greetings,
Peter
On 05/01/2015 00:59, Johan Tibell wrote:
What about keeping exactly what -g1 keeps for gcc (i.e. functions,
external variables, and line number tables)?
On Sun, Jan 4, 2015 at 5:48 PM, Peter Wortmann sc
annotations with a missing !, considered banged?
On Thu, Jan 8, 2015 at 8:36 AM, Johan Tibell johan.tib...@gmail.com wrote:
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
before now.
Alan
On Thu, Jan 8, 2015 at 10:15 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I also note that the definition of isBanged is confusing:
isBanged :: HsBang - Bool
isBanged HsNoBang = False
isBanged (HsUserBang Nothing bang) = bang
isBanged
HsBang is defined as:
-- HsBang describes what the *programmer* wrote
-- This info is retained in the DataCon.dcStrictMarks field
data HsBang
= HsUserBang -- The user's source-code request
(Maybe Bool) -- Just True{-# UNPACK #-}
I think this probably makes sense, especially since you can silence the
warning when you intend to add an unnecessary constraint.
I had one thought though: consider an abstract data type with functions
that operates over it. I might want to require e.g Ord in the definition of
a function so I
properly this would most certainly affect debuggers.
Greetings,
Peter
On 03/01/2015 21:22, Johan Tibell wrote:
How much debug info (as a percentage) do we currently generate? Could we
just keep it in there in the release?
___
ghc-devs mailing
On Sat, Jan 3, 2015 at 2:36 AM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
Hi,
On 3 January 2015 at 03:36, Johan Tibell johan.tib...@gmail.com wrote:
If I don't hear anything the next few days I will make the release.
The test suite doesn't compile with GHC HEAD on Travis
inconsequential data from .debug_info. In contrast to other programming
languages, we just don't have that much debug information in the first
place. Well, at least not yet.
Greetings,
Peter
[1] https://gcc.gnu.org/wiki/DebugFission
On 03/01/2015 00:18, Johan Tibell wrote:
Hi!
We are now
/cabal
On Sat, Jan 3, 2015 at 10:17 PM, Johan Tibell johan.tib...@gmail.com
wrote:
It might be as simple as bumping the Cabal submodule in GHC to match the
upstream 1.22 branch.
On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com
wrote:
On 3 January 2015 at 15:05, Johan
It might be as simple as bumping the Cabal submodule in GHC to match the
upstream 1.22 branch.
On Sat, Jan 3, 2015 at 8:46 AM, Jake Wheat jakewheatm...@gmail.com wrote:
On 3 January 2015 at 15:05, Johan Tibell johan.tib...@gmail.com wrote:
The error (https://travis-ci.org/haskell/cabal/jobs
Brandon,
If we just built GHC with debug symbols enabled, everything should just
work from a packaging perspective?
On Fri, Jan 2, 2015 at 7:26 PM, Brandon Allbery allber...@gmail.com wrote:
On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I believe other compilers
Hi!
We are now able to generate DWARF debug info, by passing -g to GHC. This
will allow for better debugging (e.g. using GDB) and profiling (e.g. using
Linux perf events). To make this feature more user accessible we need to
ship debug info for the core libraries (and perhaps the RTS). The reason
Try
cabal install --allow-newer=base -j3 cabal-install
Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the
upper bound on the base dependency if 1.20 is indeed compatible with the
latest base.
On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts george.colpi...@gmail.com
I've just uploaded the Cabal-1.22.0.0 RC:
http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz
I know it's a bit late, but if you could update the GHC 7.10 branch to use
it (Git tag: Cabal-v1.22.0.0-rc) that would be great.
When do you need the actual release to happen, so it's out before GHC
Some times when I play around with GHC I'd like to turn off dynamic linking
to make GHC compile faster. I'm not sure what the right way to do this in
build.mk. It's made confusing by the conditional statements in that file:
GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v)
I will make the actual cabal 1.18 release today as the RCs looked good.
On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp aus...@well-typed.com wrote:
Hello *,
I've just pushed a final round of patches to the 7.8 branch, including
the notorious Cabal fix for the -fPIC bug that was discussed
Cabal 1.18.1.5 is out.
On Mon, Dec 15, 2014 at 5:16 PM, Johan Tibell johan.tib...@gmail.com
wrote:
I will make the actual cabal 1.18 release today as the RCs looked good.
On Mon, Dec 15, 2014 at 4:28 PM, Austin Seipp aus...@well-typed.com
wrote:
Hello *,
I've just pushed a final round
at 4:52 AM, Ben Gamari bgamari.f...@gmail.com wrote:
Johan Tibell johan.tib...@gmail.com writes:
I've uploaded release candidates for Cabal/cabal-install patch releases
on
the 1.18 and 1.20 branches:
https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz
https
I've uploaded release candidates for Cabal/cabal-install patch releases on
the 1.18 and 1.20 branches:
https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz
https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-1.18.0.6.tar.gz
to an https page, even though cabal-install doesn't support it.
On Fri, Dec 12, 2014 at 2:22 AM, Johan Tibell johan.tib...@gmail.com
wrote:
I've uploaded release candidates for Cabal/cabal-install patch releases on
the 1.18 and 1.20 branches:
https://www.haskell.org/cabal/release/cabal-1.18.1.5
If someone can figure out what the right fix is and if it happens to be in
Cabal I'd be happy to merge any changes.
On Tue, Dec 2, 2014 at 10:43 PM, Miëtek Bak mie...@bak.io wrote:
On 2014-12-02, at 21:31, Carter Schonwald carter.schonw...@gmail.com
wrote:
whats an example of such a
In general I think a good course of action when this happens is:
* Use git bisect to find the offending commit. This works now because we
moved to submodules.
* Revert the commit.
* Push the patch to master and notify the author.
This style of early rollback will become more important as we grow
it
for me.
Herbert suggested some commits to revert. I’ll try that first
*From:* Johan Tibell [mailto:johan.tib...@gmail.com]
*Sent:* 01 December 2014 09:45
*To:* Herbert Valerio Riedel
*Cc:* ghc-devs@haskell.org; Simon Marlow; Simon Peyton Jones
*Subject:* Re: Windows build broken again
I think this flag is useful for debugging e.g. why something didn't
optimize the way you thought.
On Nov 6, 2014 1:05 PM, g...@git.haskell.org wrote:
Repository : ssh://g...@git.haskell.org/ghc
On branch : master
Link :
Agreed. For example, the HTTP standard has moved away from X-prefixed
headers for similar reasons.
On Thu, Nov 6, 2014 at 2:13 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
What about standardizing on an 'experimental' prefix such as
-fx-use-rpaths
or -fx-kill-oneshot? These flags would
Thanks for the interesting analysis Joachim. I wouldn't trust nofib's
runtime numbers (but the allocation ones should be good). The tests don't
run long enough and the way we don't handle typical noise issues (e.g.
clock resolution, benchmark length, etc) well enough. I'd love to see some
numbers
This is probably the biggest shortcoming of Phab. If you don't want this
merging behavior you need to make a separate Phab review *per commit*.
When I use arc I usually use git to rewrite the message after the review to
something less messy.
On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg
Same here. My interaction with the user guide is infrequent enough that it
doesn't matter much to me.
On Wed, Oct 8, 2014 at 10:49 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
Therefore I'd like to hear your opinion on migrating away from the
current Docbook XML markup to some other
On Tue, Oct 7, 2014 at 10:12 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
| 8960 looks rather serious and potentially makes all of 7.8 a no-go
| for some users.
I think this is the big issue. If you look at all the related bugs linked
from #8960, lots of users are affected. I think
is a show stopper i.e. it affects lots of people/core libraries and
doesn't really have a good workaround, as turning of SpecConstr will most
likely make e.g. vector too slow.
On Tue, Oct 7, 2014 at 11:23 AM, Johan Tibell johan.tib...@gmail.com
wrote:
On Tue, Oct 7, 2014 at 10:12 AM, Simon
On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2014-10-06 at 11:03:19 +0200, p.k.f.holzensp...@utwente.nl wrote:
The danger, of course, is that people aren't very enthusiastic about
bug-fixing older versions of a compiler, but for
Aside: I really miss derived Show instances in GHC. The Outputable class is
only really useful if you already know how things work. If you e.g. want to
see the AST used to represent some piece of Haskell code, in all its glory,
the Outputable instances aren't useful because they elide too much
At least for cabal there was a large uptick in contributions once we moved
to GitHub.
On Sun, Oct 5, 2014 at 7:03 AM, Ben Gamari bgamari.f...@gmail.com wrote:
Richard Eisenberg e...@cis.upenn.edu writes:
I've just finished reading this:
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp aus...@well-typed.com wrote:
- Cull and probably remove the 7.8.4 milestone.
- Simply not enough time to address almost any of the tickets
in any reasonable timeframe before 7.10.1, while also shipping them.
- Only one, probably
We need to get a windows build not up for phabricator that stops breaking
changes from getting submitted.
On Oct 2, 2014 10:40 PM, Simon Peyton Jones simo...@microsoft.com wrote:
Sigh. The testsuite fails utterly on Windows, with thousands of
identical errors
= tc012(normal) 3039 of
The reason to support trailing commas are entirely related to engineering
and not language expressiveness. Having trailing commas means that diff
tools and version control systems work better. This is why most languages
support them.
___
ghc-devs mailing
Sounds good to me.
On Thu, Sep 25, 2014 at 11:18 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
There’s a danger of disappearing into a bikeshed here. I think it’s
clear that:
· If we have it at all, ExtraCommas should be a {-# LANGUAGE
ExtraCommas #-} extension, like any
I must say that requiring a language pragma makes the feature quite a bit
more heavy weight. We're not changing the meaning of any existing programs,
just allowing some new ones. One could argue that perhaps the HaskellXX
standard might pick up this new pragma and thus making it unnecessary
+1
I think this makes sense and we should allow trailing commas wherever the
syntax allows it without adding ambiguity (e.g. tuple sections prevent
trailing commas for tuple declarations.)
P.S. Last time we tried to discuss something like this (on libraries@ I
believe) the whole discussion
On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote:
Forwarding this my reply to the ML as well,
On 22/09/14 14:27, David Luposchainsky wrote:
+1. While you're at it, you may also want to consider
with it, but fails without
·develop a patch
Easy really! I doubt it’s controversial.
Simon
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
Tibell
*Sent:* 22 September 2014 14:28
*To:* Alexander Berntsen
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Permitting
On Fri, Sep 12, 2014 at 3:52 PM, Joachim Breitner m...@joachim-breitner.de
wrote:
nothing overly exciting, but since I am running this ghcspeed thing, I
guess I should inform you about changes, just to get some practice doing
that :-)
I'm very much in support of doing this.
Once we think
I think make maintainer-clean removes it. I find this hidden pieces of
state annoying. It has definitely tripped me up in the past. Perhaps we can
have make clean remove it?
On Fri, Aug 29, 2014 at 2:14 PM, Dr. ERDI Gergo ge...@erdi.hu wrote:
On Fri, 29 Aug 2014, Edward Z. Yang wrote:
OK,
I think reverting the patch (and notifying the author) is an OK course of
action if it's affecting other people's work. I believe it's common
practice at many other places. The patch can always be replied later, after
fixing it.
P.S. We should re-open the bug if we revert the patch (i.e. by git
f9f89b7884ccc8ee5047cf4fffdf2b36df6832df is probably to blame.
Found by running `git log -SsetIOManagerControlFd`. The -S flag is a good
way to find when a symbol is added/removed.
On Wed, Aug 20, 2014 at 12:16 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
Aaargh! My windows build is
Edward made some changes so that GHC 7.10 is backwards compatible with
older cabals (older cabals just can't use the new goodies, that's all),
which means that we won't need an earlier release. I'm still aiming for
another major release before 7.10? When's 7.10 scheduled before?
On Fri, Aug 8,
Hi,
How's the integration of DWARF support coming along? It's probably one of
the most important improvements to the runtime in quite some time since
unlocks *two* important features, namely
* trustworthy profiling (using e.g. Linux perf events and other
low-overhead, code preserving, sampling
On Wed, Aug 13, 2014 at 5:07 PM, Tuncer Ayaz tuncer.a...@gmail.com wrote:
On Wed, Aug 13, 2014 at 5:02 PM, Johan Tibell wrote:
Hi,
How's the integration of DWARF support coming along? It's probably
one of the most important improvements to the runtime in quite some
time since unlocks
Ömer Sinan Ağacan omeraga...@gmail.com:
Will generated stack traces be different that
---
Ömer Sinan Ağacan
http://osa1.net
2014-08-13 19:56 GMT+03:00 Johan Tibell johan.tib...@gmail.com:
Yes, it doesn't use any code modification so it doesn't have runtime
overhead (except when
://arashrouhani.com/papers/master-thesis.pdf
On 2014-08-13 17:02, Johan Tibell wrote:
Hi,
How's the integration of DWARF support coming along? It's probably one
of the most important improvements to the runtime in quite some time since
unlocks *two* important features, namely
The biggest disadvantage in my mind is that you're setting yourself up for
a potentially huge merge just before the GHC release and might block the
GHC release until that merge is done (assuming that haddock is still
shipped with GHC).
___
ghc-devs
On Fri, Aug 8, 2014 at 10:11 AM, Simon Peyton Jones simo...@microsoft.com
wrote:
The biggest disadvantage in my mind is that you're setting yourself up
for a potentially huge merge just before the GHC release and might block
the GHC release until that merge is done (assuming that haddock is
Hi,
We seem to have two ways to get the same piece of information. We can get
the target (?) word size as wORD_SIZE but there's also the platformWordSize
field in the Platform data type, which is held as targetPlatform in
DynFlags. Which one should I use? Most code uses wORD_SIZE.
-- Johan
Inside GHC we mostly use Int instead of Word, even when we want to
represent non-negative values, such as sizes of things or indices into
things. This is now causing some grief in
https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary
case test fails with a segfault because a n
Simon M, is the intention of ByteOff and WordOff that they should be able
to represent negative quantities as well? If so we might need to split it
into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
indexing into arrays.
On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang
, they
were when I introduced them!
SImon
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
Tibell
*Sent:* 07 August 2014 12:21
*To:* Simon Marlow
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Improving the Int/Word story inside GHC
Simon M, is the intention
introduced them!
SImon
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
*Johan
Tibell
*Sent:* 07 August 2014 12:21
*To:* Simon Marlow
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Improving the Int/Word story inside GHC
Simon M
1 - 100 of 298 matches
Mail list logo