Of course, there are also much more complicated issues at stake with GHC. But hopefully this PR will get merged in at some point. Now there’s a somewhat annoying issue with the fact that the CI builds don’t actually seem to be passing right now. So we’ll create our fork, clone the repo, open a new branch, and open a pull request against master. Great, so let’s submit a pull request for this! We’ll fork the repository and open a pull request. From the context, it seems pretty clear that the author intended to write “there seems to be no way to merge them”. in Lexer.x, but sadly there seems to be way to merge them. At the top of compiler/basicTypes/BasicTypes.hs, it states: - There is considerable overlap between the logic here and the logic While exploring the lexing types, I found a comment that didn’t quite make sense. But there's good news for us as newcomers to the GHC code base! We’re in the best position to find holes in the documentation, since we’re the ones who need to read it most! This is how I found the first contribution I could make. Still though, it’s inevitable that something will slip through the cracks. And documentation never breaks!Įxperienced developers will remember to change documentation more. We look for issues by making changes, compiling, and seeing what breaks. Haskell, if anything, is more prone to this kind of lapse. This means documentation is always likely to fall out of date. So the temptation is to not change any of the comments. When you understand the code already, you don’t need to look at the documentation. At any given moment, most of the effort is going into making sure the program works as it ought to. Documentationĭocumentation is a tricky thing on any software project. This week, we’re going to wrap this series up by looking at some basic ways of making contributions. Last week, we made some more complicated changes. We validated that by changing an error message and seeing how it appeared in the compiler. After that, we looked at the basic way of creating a development cycle for ourselves. This was an especially difficult process on Windows, so we focused there. We started by looking at the steps we would need to prepare our local machine for GHC development. In the last few weeks, we’ve taken a good look at GHC. It’ll give you some more ideas for advanced libraries to use for your projects! So stay tuned for more!Īs always, if you’re new to Haskell, we’ve got some great resources to help you get started! Download our Beginners Checklist to get the language installed and discover some cool tools! For more language details, read our Liftoff Series!Īnd for you more experienced Haskell developers, take a look at our Production Checklist. We’ve also got some more cerebral articles for how to take the next steps in your Haskell development. We’ll specifically look at a couple concepts we’ve handled in the past, but we’ll find new ways to build those programs. We’ll be highlighting some more of our permanent content as well as showing some new tutorials. In the next few weeks, we’ve got a wide variety of content planned. This will lead to us submitting some code for a couple very simple issues. In the final part, we’ll look at how GHC handles issue tracking.We’ll look at adding some of our own keywords and adding a new syntactic construct. In the third part of the series, we’ll do some more serious hacking.We’ll also learn about the organization of the codebase. In part 2, we’ll set up a basic development cycle and make a simple change.This part focuses on Windows but also has good advice for Mac and Linux Users. Part 1 goes over how to set up our local development environment to use GHC.As a reminder, here are the different parts of that series: Our recent blog series on GHC is now part of our permanent collection of material on the site! Check it out in the advanced section.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |