And I dipped my toes into the phabricator water, and uploaded a diff to
https://phabricator.haskell.org/D153
I left the lines long for now, so that it is clear that I simply added
parameters to existing type signatures.
On Tue, Aug 12, 2014 at 10:51 PM, Alan Kim Zimmerman alan.z...@gmail.com
Dear Alan,
I’ve had a look at the diffs on Phabricator. They’re looking good. I have a few
comments / questions:
1) As you said, the renamer and typechecker are heavily interwoven, but when
you *know* that you’re between renamer and typechecker (i.e. when things have
‘Name’s, but not ‘Id’s),
Hi Philip
Thanks for the feedback.
Firstly, I see this as a draft change as a proof of concept, and as such I
deliberately tried to keep things obvious until it had been fully worked
through. It helped in managing my own confusion to limit the changes to be
things that either HAD to change
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,
On 13 August 2014 16:12, Johan Tibell johan.tib...@gmail.com wrote:
I'm still aiming for another
major release before 7.10? When's 7.10 scheduled before?
End of the year, I think.
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
On 13 August 2014 16:22, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
End of the year, I think.
Correction: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
says February 2015.
___
ghc-devs mailing list
ghc-devs@haskell.org
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
Is this stack trace support different than what we have currently?
(e.g. the one implemented with GHC.Stack and cost centers)
---
Ömer Sinan Ağacan
http://osa1.net
2014-08-13 18:02 GMT+03:00 Johan Tibell johan.tib...@gmail.com:
Hi,
How's the integration of DWARF support coming along? It's
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 generating the actual trace) or interfere with
Sorry for my previous email. (used a gmail shortcut by mistake)
We won't have stacks as we have in imperative(without TCO) and strict
languages. So we still need some kind of emulation and I think this
means some extra run-time operations. I'm wondering about two things:
1) Do we still get same
Without any overhead we'll get the runtime stack trace, which isn't exactly
the same as what we can get with emulation, but has the benefit that we can
leave it on in all of our shipped code if we like. This latter is a really
crucial property for stack traces to be widely useful.
On Wed, Aug
Hi Johan!
I haven't done much (just been lazy) lately, I've tried to benchmark my
results but I don't get any sensible results at all yet.
Last time Peter said he's working on a more portable way to read dwarf
information that doesn't require Linux. But I'm sure he'll give a more
acurate
What's the minimal amount of work we need to do to just get the dwarf data
in the codegen by 7.10 (RC late december) so we can start using e.g. linux
perf events to profile Haskell programs?
On Wed, Aug 13, 2014 at 7:31 PM, Arash Rouhani rar...@student.chalmers.se
wrote:
Hi Johan!
I haven't
On Wed, 13 Aug 2014 11:39:56 +0200
Tuncer Ayaz tuncer.a...@gmail.com wrote:
On Tue, Aug 12, 2014 at 10:31 PM, Sergei Trofimovich wrote:
Good evening all!
Currently when being ran './validate' script (without any parameters):
- builds ghc using 2 parallel jobs
- runs testsuite using 2
Peter will have to answer that. But it seemed to me that it has been
working fine all the time. I suppose it's just to resolve merge
conflicts. There were some refactorings he wanted to do. In addition to
this it will also be some packaging issues I suppose. I'm hoping Peter
will answer in
At this point I have a bit more time on my hands again (modulo post-thesis
vacations), but we are basically still in “review hell”.
I think “just” for perf_events support we’d need the following patches[1]:
1. Source notes (Core support)
2. Source notes (CorePrep Stg support)
3. Source notes
Johan Tibell wrote:
Do you mind expanding on what tick scopes are. It sounds scarily like something
that happens at runtime. :)
It’s a pretty basic problem - for Core we can always walk the tree upwards to
find some source ticks that might be useful. Cmm on the other hand is flat:
Given one
$ git clone git://github.com/ghc/ghc.git ghc-github
$ cd ghc-github
$ ./sync-all get
$ perl boot
$ ./configure
$ make
[…]
inplace/bin/ghc-stage1 -this-package-key rts -shared -dynamic -dynload deploy
-no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath
-optl-Wl,'$ORIGIN'
On 08/08/2014 06:25 AM, Mateusz Kowalczyk wrote:
Hello,
[snip]
Transition from current setup:
If I receive some patches I was promised then I will then make a 2.14.4
bugfix/compat release make sure that master is up to date and then
create something like GHC-tracking branch from master
Indeed, the float register stuff was a red herring -- restoring it caused no
problems and all my tests are working great. So yahoo!! We've got ARM64
support.
I'll tidy up the patches and create a ticket for review and merge.
Luke
On Tue, Aug 12, 2014 at 4:47 PM, Luke Iannini lukex...@gmail.com
one thing I wonder about is how should we approach noting
theres a new language constructor, we should figure out a good way to
present it in haddock in this work flow?
because the initial haddocks presentation might just be a strawman till
someone thinks about it carefully right?
On Wed, Aug
Luke Iannini lukex...@gmail.com writes:
Indeed, the float register stuff was a red herring -- restoring it caused no
problems and all my tests are working great. So yahoo!! We've got ARM64
support.
Yay! Awesome work!
Cheers,
- Ben
pgpC53b1AIFVm.pgp
Description: PGP signature
23 matches
Mail list logo
