Announce fork

[cocreature]

Probably makes sense to wait until we have made actual changes and maybe even until we are ready for a release.

[acowley]

The release of LLVM-4.0 and the change in their version numbering scheme is probably a good natural break to take advantage of if announcing anything.

[cocreature]

Good point

[minad]

Is this a fork which is compatible with ghc8 and newest llvm? When will it be on hackage?

[cocreature]

@minad Yep, we support GHC 7.8-8.0 and LLVM 4.0. We are planning the first release after LLVM 4.0 has been officially released (rc2 has been released a few days ago so this should happen in the next few weeks).

[minad]

great! looking forward to that!

[cocreature]

LLVM 4.0 RC 3 has been tagged and it looks like we could get a release next week. From my side, the only thing blocking a release of llvm-hs is updating the travis config. I’ve already tested locally that nothing broke with RC3 so that should be a boring change. @sdiehl, @acowley is there anything that you would like to do/feel like someone should do before we release?

[acowley]

No blockers that I'm aware of. I'm going to make an effort to add more docs and how-tos, but it will be easier when LLVM 4.0 is more readily available. There's a bit of a hangup with nixpkgs-unstable at the moment, but it should clear up in a couple hours.

[sdiehl]

Let's update the install directions, and maybe include Nix, Cabal, Stack suite of setup directions to README. Other than that, I think this is good to go.

Let's synchronize on the announcement, so we can handle any community inbound.

[sdiehl]

The example's repo also needs to either point at a specific commit or a tag of this repo. Right now it uses: bf5f2f7

Let's decide which to use here.

[cocreature]

Creating a tag once we are ready to release and then pointing the example repo to that seems like a good idea.

[aherrmann]

I've opened a PR for Nix support in #35.
Let me know what you think.

[cocreature]

Alright, the Travis config is updated and the README has also been updated in the same PR. I would like to merge #35 before a release and we should decide what we do about #36 in this release. I would suggest just exposing Internal modules for now and then take some more time to properly think about the abstraction we want for OrcJIT (I prefer releasing more often than delaying releases too long).

Apart from that, I think we only need to create a tag for the release and update the example repo.
So let’s aim for a release this weekend?

[sdiehl]

Sounds good, I'll point the other repos at the tag we cut this weekend.

[sdiehl]

I think #35 is effectively settled after we sort out Homebrew directions for macOS. Perhaps #36 is a larger project and can wait for the next release.

We can sync up on the announcement. Apart from that, I think everything is good to go for tagging stable initial release. 😄

[minad]

I am not involved here, but I disagree. Warnings should be enabled and I think the pretty printing should be replaced by a saner alternative (ghc.generics or pretty-show). if the things are not improved now, when are they going to?

[cocreature]

if the things are not improved now, when are they going to?

In the next release? I don’t see why we need to improve everything at once. Enabling warnings has absolutely no effect on users of this library (apart from maybe catching bugs) and I would be surprised if the pretty printing is used outside of our test suite. I’m not arguing that these things shouldn’t be improved and we can probably merge #48 before the release but in general I don’t think either of these issues are release blockers.

[minad]

Ok, I agree. Sorry if I sounded too harsh. If things are gonna be improved I am perfectly happy.

Concerning the pretty printing - if this gets changed, it will probably be a breaking change. Therefore it could be nice to fix it sooner than later - if you feel it is broken or needs fixing.

[cocreature]

It will technically be a breaking change but I doubt anybody actually depends on the exact output of this (I think even our test suite doesn’t. It just uses it to show the AST on test failures). So the practical impact of this change will probably be small.

[acowley]

Yes, #36 is absolutely not a blocker. As for pretty printer changes, if we wanted to be very cautious we could add a comment to the pretty printer noting that its output is not stable (if there isn't already such a comment).

[cocreature]

Release tagged! I uploaded the releases and docs to Hackage. I can post to reddit, does anybody want to announce on haskell-cafe?