Stepping through ghc
Omar Mefire
omefire at yahoo.fr
Tue Oct 7 07:35:26 UTC 2014
Hi Arash,
Thanks for your reply.
I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for now.
Thanks for the link to the commentary. I'm going through it right now.
-------
"Hi Omar,
You might want to narrow your scope to one part of GHC. For example, I
mostly focused on the Run Time System to be able to conduct my master's
thesis. Also, you might want to start off with a tiny goal, like to fix
bug XYZ.
Oh, and most important of all is the Commentary, which I think of as a
wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary
Cheers,
Arash"
Omar Mefire,
Le Mardi 7 octobre 2014 0h08, Omar Mefire <omefire at yahoo.fr> a écrit :
Hi Arash,
Thanks for your reply.
I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for a beginning.
Thanks for the link to the commentary. I'm going through it right now.
P.S: I emailed you directly because I had some difficulties figuring out how to respond only to your message instead of the whole daily digest.
Hopefully, will figure it out shortly. :)
"
Hi Omar,
You might want to narrow your scope to one part of GHC. For example, I
mostly focused on the Run Time System to be able to conduct my master's
thesis. Also, you might want to start off with a tiny goal, like to fix
bug XYZ.
Oh, and most important of all is the Commentary, which I think of as a
wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary"
Omar Mefire,
Le Lundi 6 octobre 2014 12h55, "ghc-devs-request at haskell.org" <ghc-devs-request at haskell.org> a écrit :
Send ghc-devs mailing list submissions to
ghc-devs at haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/ghc-devs
or, via email, send a message with subject or body 'help' to
ghc-devs-request at haskell.org
You can reach the person managing the list at
ghc-devs-owner at haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ghc-devs digest..."
Today's Topics:
1. Re: GitHub pull requests (Richard Eisenberg)
2. RE: Show instance for SrcSpan (Simon Peyton Jones)
3. Re: GitHub pull requests (Ben Gamari)
4. Re: Stepping through ghc (Arash Rouhani)
5. RE: Again: Uniques in GHC (p.k.f.holzenspies at utwente.nl)
----------------------------------------------------------------------
Message: 1
Date: Mon, 6 Oct 2014 10:32:23 -0400
From: Richard Eisenberg <eir at cis.upenn.edu>
To: andreas.abel at gu.se
Cc: "ghc-devs at haskell.org Devs" <ghc-devs at haskell.org>
Subject: Re: GitHub pull requests
Message-ID: <DB3A2790-D285-4DE1-B05A-AF6F68389B88 at cis.upenn.edu>
Content-Type: text/plain; charset=us-ascii
I think the "arc" barrier is significant. Personally, while I feel quite comfortable hacking on Haskell code, system tools are always a bit of a mystery. Those of you who help manage the infrastructure may feel like the
tools are easy enough to pick up, but I'm sure there are many competent Haskell programmers out there who dread learning new tooling. (Perhaps I'm a representative sample of this set. I still say `git help merge` before just about every merge, just to make sure that I'm remembering the concepts correctly.)
I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst.
All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue
tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed.
I agree with the comment that users will be more committed to learn Phab once they have contributed. That's why I wanted to point them to Phab in the automated response to the GH pull request. I think there's a psychological commitment made by a person once they click "submit pull request" and they will be happy enough to follow up on Phab, especially if commenting and such doesn't require the installation of a local tool.
Richard
------------------------------
Message: 2
Date: Mon, 6 Oct
2014 18:10:37 +0000
From: Simon Peyton Jones <simonpj at microsoft.com>
To: Alan & Kim Zimmerman <alan.zimm at gmail.com>, "ghc-devs at haskell.org"
<ghc-devs at haskell.org>
Subject: RE: Show instance for SrcSpan
Message-ID:
<618BE556AADD624C9C918AA5D5911BEF3F319EA3 at DB3PRD3001MB020.064d.mgd.msft.net>
Content-Type: text/plain; charset="utf-8"
By all means do so
S
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 06 October 2014 13:59
To: ghc-devs at haskell.org
Subject: Show instance for SrcSpan
Is there any reason I can't put in a diff
request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable?
Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/f036ca76/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 06 Oct 2014 14:17:12 -0400
From: Ben Gamari <bgamari.foss at gmail.com>
To: Richard Eisenberg
<eir at cis.upenn.edu>, andreas.abel at gu.se
Cc: "ghc-devs at haskell.org Devs" <ghc-devs at haskell.org>
Subject: Re: GitHub pull requests
Message-ID: <87sij1qd07.fsf at gmail.com>
Content-Type: text/plain; charset="us-ascii"
Richard Eisenberg <eir at cis.upenn.edu> writes:
> I absolutely believe that we should use the best tools available and
> that committed GHC contributors should have to learn these tools as
> necessary. Though I've had my problems with Phab and `arc`, I'm
> confident that this tool was chosen after a deliberative process and
> am grateful that we have leaders in this area in our midst.
>
Agreed. Phab certainly has a learning curve and is not without its
papercuts but on the whole seems to be an excellent tool.
> All that said, I think that the suggestion just to accept GitHub pull
> requests will lead to confusion, if only for the namespace problem. If
> we start to accept pull requests, then we are de facto going to have
> to deal with both the GH issue tracker and Trac's (and Phab's), and
> that is a terrible place to be. Part of the automated response to pull
> request submissions could be a post on the GH pull request record
> pointing folks to the Phab review that was created in response. The
> pull request would then be closed.
>
This is where I was going with the beginning of a script I posted on
Saturday. To me this seems like an excellent compromise: using the familiarity
of Github to attract contributions and (hopefully) siphon them into
Phabricator. The numbering conflicts may still be problematic but I
suspect that in practice people
will learn that the Github numbers are
meaningless fairly quickly.
Cheers,
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/fcbadacf/attachment-0001.sig>
------------------------------
Message: 4
Date: Mon, 6 Oct 2014 20:50:25 +0200
From: Arash
Rouhani <rarash at student.chalmers.se>
To: <ghc-devs at haskell.org>
Subject: Re: Stepping through ghc
Message-ID: <5432E471.5070703 at student.chalmers.se>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Omar,
You might want to narrow your scope to one part of GHC. For example, I
mostly focused on the Run Time System to be able to conduct my master's
thesis. Also, you might want
to start off with a tiny goal, like to fix
bug XYZ.
Oh, and most important of all is the Commentary, which I think of as a
wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary
Cheers,
Arash
On 2014-10-06 17:23, Omar Mefire wrote:
> Hi,
>
> I'm new to ghc codebase and I'm interested in stepping through the
> code in order to gain a better idea of how it all works.
>
> - Is there a way to load ghc into ghci ? and debug through it ?
> - What are the ways experienced ghc devs step
through the code ?
> - Any techniques you guys recommend ?
> - What would your advices be for a newbie to the source code ?
>
> Thanks,
> Omar Mefire,
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/c7127b97/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 6 Oct 2014 19:55:17 +0000
From: <p.k.f.holzenspies at utwente.nl>
To: <mail at joachim-breitner.de>, <ghc-devs at haskell.org>
Subject: RE: Again: Uniques in GHC
Message-ID:
<01db8f0b509747669bbf426fc0dd18c2 at EXMBX31.ad.utwente.nl>
Content-Type: text/plain; charset="us-ascii"
Dear Joachim,
Although I can't quite get what you're saying from the posts on that link, I'm not immediately sure what you're saying should extend to hi-files. These files are very much specific to the compiler version you're using, as in, new GHCs add stuff to them all the time and their binary format does not (seem to) provision for being able to skip unknown things (i.e. it doesn't say how large the next semantic block is in the hi-file).
If we're going to keep the formats the same for any
architecture, we're going to have to limit 64-bit machines to 32-bit (actually 30-bits, another thing I don't quite understand in BinIface) Uniques. There seem to be possibilities to alleviate the issues with parallel generation of fresh Uniques in a parallel version of GHC. The idea is that, since 64-bits is more than we'll ever assign anyway, to use a few for thread-ids, so we would guarantee non-conflicting Uniques generated by different threads.
Anyway, maybe someone a tad more knowledgeable about Uniques could maybe tell me on what scale Uniques in the hi-files should be unique? Must they only be non-conflicting in a Module? In a Package? If I first compile a file with GHC and then, in a separate invocation of GHC, compile another, surely their hi-files will have some of the same Uniques for their own, different things? Where are these conflicts resolved when linking multiple
independently compiled files? Are they ever?
Regards,
Philip
?
________________________________
From: Joachim Breitner <mail at joachim-breitner.de>
Sent: 06 October 2014 12:36
Subject: Re: Again: Uniques in GHC
<snip>
A while ago we had problems with haddock in Debian when the
serialization became bit-dependent.^1 I suggest to keep the specification
of any on-disk format independent of
architecture specifics.
Greetings,
Joachim
^1 http://bugs.debian.org/586723#15
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141006/a826dac1/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
------------------------------
End of ghc-devs Digest, Vol 134, Issue 23
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141007/3394f0bf/attachment-0001.html>
More information about the ghc-devs
mailing list