Hello Austin,
On Sun, Sep 8, 2013 at 4:27 PM, Austin Seipp ase...@pobox.com wrote:
* Iavor Diatchki and SPJ are working together on the type-nats-simple
branch. I believe this will hopefully land in time. Iavor, SPJ - can
you comment here?
I think we are on track to get this done on
Hi,
I built GHC head today (with d61c3ac186c94021c851f7a2a6d20631e35fc1ba
reverted). While I'm supporting GHC head for doctest on Mac, I found
the following problems relating to dynamic linking:
(1) Every .dylib installed with GHC head refers to itself in its
build directory. E.g.
%
Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:
% make show VALUE=GhcLibWays
make -r --no-print-directory -f ghc.mk show
GhcLibWays=v p dyn
Yes, it looks like you are missing p_dyn from this list. I think
this is a bug in the build system. When I
Thanks Kazu! This should get me going. Can you temporarily work with my commit
reverted? I should have some time to look into this at the end of this week.
It's interesting that this time you got failure for a different file than in
your original email to the list. Seems like the error was
Hi,
Thanks Kazu! This should get me going. Can you temporarily work with
my commit reverted?
Yes. I got this log without reverting. And now I'm using GHC head with
your commit reverted.
It's interesting that this time you got failure for a different file
than in your original email to the
Hi Joachim,
I wouldn't know which place is preferable. Simon?
(Your snippet did remind me that I forgot to remove the
-fwarn-typeable-instances flag...
working on that now.)
Thanks,
Pedro
On Mon, Sep 9, 2013 at 8:25 AM, Joachim Breitner
m...@joachim-breitner.dewrote:
Dear Predro,
Am
Hi,
While I support GHC head for doctest, I encountered the following
bug.
doctest uses a GHCi subprocess to evaluate an expression represented
in String. Stderr from GHCi is merged into stdout by hDuplicateTo in
the GHCi side. Even evaluating an error expression, for instance 1
`div` 0, the
On Sep 8, 2013, at 7:27 PM, Austin Seipp ase...@pobox.com wrote:
* Pedro and Richard - what's the story on propositional equality,
etc? This is mentioned on the status page[1] but I'm not sure what
else needs to be done. I know Pedro committed the work to make manual
Typeable instances an
I am refactoring new Bool primops (#6135). There was a discussion on
core-libraries-commitee list and the decision was made that we should keep
names of primops we used so far and change their type signature (right now HEAD
has different names for new primops and reuses old names for
Perhaps the core libraries committee should reconsider their decision?
:) Backwards compatibility is good. If HEAD implements the backwards
compatibility plan that Simon PJ and I suggested and said plan is
working, there should be a compelling reason to break compatibility and
have to go chasing
I say this only somewhat facetiously, but this is *exactly* the sort of
problem that the pro-backwards compatibility camp anticipates, and I
mean the pro-backwards compatibility camp in the most general possible
way :) The point is that you can never anticipate all the ways in which
breaking
I'm OK with this.
Simon, since you've been doing the most work helping Joachim, I
presume you can help him land the patch sometime this week? Or should
I put it on my merge queue (along with AMP, etc?)
On Mon, Sep 9, 2013 at 9:51 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| However,
Just my 02c: I feel the GHC API is allowed to be less stable and a
little more in-flux than most things. We've never particularly
advertised stability here anyway, so having a design that evolves a
little is reasonable, IMO. Perhaps it being in the release will help
drive more feedback, earlier.
Thanks Richard!
On Mon, Sep 9, 2013 at 7:40 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
On Sep 8, 2013, at 7:27 PM, Austin Seipp ase...@pobox.com wrote:
* Pedro and Richard - what's the story on propositional equality,
etc? This is mentioned on the status page[1] but I'm not sure what
| However, there is perhaps a middle road: what if much of the
| infrastructure is merged, without the user-facing feature? From a user's
| point of view, these coercions feel much more like a library than a
| language feature. Yes, the instances appear out of thin air, but
| otherwise, the
Excellent. Simon, are you privvy to this work at all? We lightly
talked about it last week, but I'm not sure if you've reviewed it. Or
perhaps Pedro or someone else could if we have time (I seem to
remember he drew up the initial design points.)
On Sun, Sep 8, 2013 at 11:08 PM, Trevor Elliott
Iavor, I think we'll need to update the list of DynFlags-imported
modules for the windows DLL split for this to work.
Check compiler/ghc.mk, and look at the variable
'compiler_stage2_dll0_modules' flag. This essentially contains a list
of the modules reachable from DynFlags. Try updating this
On 09/09/13 16:53, Gabor Greif wrote:
On 9/9/13, Adam Gundry adam.gun...@strath.ac.uk wrote:
On 06/09/13 17:45, Gabor Greif wrote:
On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote:
I have been working on a new extension, OverloadedRecordFields, and it
is now essentially
I think I'd prefer all of these checks to be done in checkValidInstHead. It
makes sense... it's just the kind of thing that checkValidInstHead is for. It
would remove clutter (and filtration) from tcInstDecls1.
The same goes for the SafeHaskell checks in tcInstDecls1.
I'm not sure who is
Is it OK if I release Cabal-1.18.0.1 on Monday if we want it to ship
with GHC 7.8? 1.18.0.1 is a tiny bugfix release on top of 1.18.0.
On Mon, Sep 9, 2013 at 8:44 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
Yes I will try to review it this week. (This is the first time I've had
access
The reason it's not safe in Safe Haskell is precisely #1496, the newtpye
deriving bug. Now that's fixed, Safe Haskell can remove the safety check.
Probably.
This is another question that could usefully be articulated on the design page,
Joachim.
Simon
| -Original Message-
| From:
Edsko
I'm very short of time right now. I think you understand the issues here. Can
you do a round or two with Luite and emerge with a design that you both think
is best?
As I said earlier I'm uncomfortable with doing design work so late in the
cycle, and I feel that I don't have time to
Hello, I've been looking at http://ghc.haskell.org/trac/ghc/ticket/8244,
following the discussions:
-http://www.mail-archive.com/haskell-cafe@haskell.org/msg107850.html
-http://www.haskell.org/pipermail/ghc-devs/2013-March/000762.html
This is basically about the fact that GHC-as-a-library as a
Herbert brought this question to my attention earlier - what's the
cutoff date for boot libraries?
IMO, I think boot library updates can happen until the actual branch
in Oct. I'm planning on pushing the Applicative-Monad patch today,
which will require some upstream coordination as well,
I think the there was a general agreement in the committee that we should
follow the best long-term solution, not the best short-term one. Here are two
arguments (Plan B = break backwards compatibility):
I'd rather not hamstring GHC.* with a rats nest of backwards compatibility
decisions,
Hi,
On Mon, Sep 9, 2013 at 10:11 PM, Simon Marlow marlo...@gmail.com wrote:
I think Kazu is saying that when he builds something with profiling using
cabal-install, it fails because cabal-install tries to build a dynamic
version too. We don't want dyanmic/profiled libraries (there's no
On 9/9/13, Adam Gundry adam.gun...@strath.ac.uk wrote:
On 06/09/13 17:45, Gabor Greif wrote:
On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote:
I have been working on a new extension, OverloadedRecordFields, and it
is now essentially feature-complete. Unfortunately, I doubt it will make
Hello Mikhail,
It is a known issue that Template Haskell does not work with profiling (because
GHCi and profiling do not work together, and TH uses GHCi's linker). [1]
Actually,
with the new linker patches that are landing soon we are not too far off from
having this work.
Edward
[1]
I'm in the to field alone. Are you asking me? I have no opinion! But Monday
16 sounds fine to me.
S
| -Original Message-
| From: Johan Tibell [mailto:johan.tib...@gmail.com]
| Sent: 09 September 2013 17:40
| To: Simon Peyton-Jones
| Cc: Austin Seipp; Trevor Elliott;
On Mon, Sep 9, 2013 at 1:14 PM, Edward Z. Yang ezy...@mit.edu wrote:
I think Kazu is saying that when he builds something with profiling
using cabal-install, it fails because cabal-install tries to build a
dynamic version too. We don't want dyanmic/profiled libraries (there's
no point, you
On 09/09/13 08:14, Edward Z. Yang wrote:
Excerpts from Kazu Yamamoto (山本和彦)'s message of Sun Sep 08 19:36:19 -0700 2013:
% make show VALUE=GhcLibWays
make -r --no-print-directory -f ghc.mk show
GhcLibWays=v p dyn
Yes, it looks like you are missing p_dyn from this list. I think
this
Dear Core Libraries Committee
I think we need your advice.
This thread (mostly on ghc-devs) shows that if the shim-package and
boolean-primop decision goes as currently proposed, then we'll need a new
release of Alex
* Either to generate an import of GHC.Exts.Compat
(ie depend on the shim
According to the original post and the comments on #5498
(http://ghc.haskell.org/trac/ghc/ticket/5498), breaking through abstraction is
another reason for keeping GND outside of Safe Haskell. I'm worried that the
same concern would affect newtype coercions given the current proposal.
Richard
Yes I will try to review it this week. (This is the first time I've had access
to the code.)
Simon
| -Original Message-
| From: Austin Seipp [mailto:ase...@pobox.com]
| Sent: 09 September 2013 16:25
| To: Trevor Elliott
| Cc: Austin Seipp; ghc-devs@haskell.org; glasgow-haskell-
|
On 06/09/13 17:45, Gabor Greif wrote:
On 9/5/13, Adam Gundry adam.gun...@strath.ac.uk wrote:
I have been working on a new extension, OverloadedRecordFields, and it
is now essentially feature-complete. Unfortunately, I doubt it will make
it into 7.8, as the changes are quite extensive, but I
Hi,
On Mon, Sep 9, 2013 at 11:21 PM, Edward Z. Yang ezy...@mit.edu wrote:
Hello Mikhail,
It is a known issue that Template Haskell does not work with profiling
(because
GHCi and profiling do not work together, and TH uses GHCi's linker). [1]
Actually,
with the new linker patches that are
Hi,
Kazu (or someone else), can you please file a ticket on the Cabal bug
tracker [1] if you think that this a Cabal bug?
I'm not completely sure yet.
GHCi 7.8 uses dynamic linking. This is true.
So, what is a consensus for GHC 7.8 and cabal-install 1.18? Are they
supposed to use dynamic
That sounds terrible expensive to do on every `cabal build` and its a
cost most users won't understand (what was broken before?).
On Mon, Sep 9, 2013 at 4:06 PM, Edward Z. Yang ezy...@mit.edu wrote:
If I am building some Haskell executable using 'cabal build', the
result should be *statically
I took a look here and would like to help, but I'm confused: What makes you
think the dictionary for (Eq [b]) would be in scope? I can see where the (Eq b)
comes from (the theta that pops out of patSynSig), but where does (Eq [b]) come
from?
Richard
On Sep 8, 2013, at 4:31 AM, Dr. ERDI Gergo
Template Haskell *does* work with profiling, you just have to compile the
code without profiling first (Cabal knows how to do this and does it
automatically).
The big obstacles to loading profiled code into ghci are (a) lack of
support in the byte code compiler and interpreter and (b) ghci itself
40 matches
Mail list logo
