Are you accepting pull requests?

[razzeee]

Seeing the not merged pull requests, I'm a bit concerned.

I'm planning on maybe having a student work on this as part of gsoc, but it would be very bad to have him work on something, that has no chance of over coming to fruition.

[XVilka]

Indeed, there are some interesting PRs waiting some attention as a prerequisite to add more languages in Semantic:

• Add R support #295
• Add C parser #294
• add Scala language #293

cc @patrickt @robrix @maxbrunsfeld

[siraben]

I would like to see more languages added as well, is the project still maintained?

[XVilka]

@siraben last commit was two years ago. At this point, it's obvious this project is dead. Issues and PRs are stalling without any response. Maybe a fork would be an option.

[patrickt]

@XVilka @siraben @razzeee My apologies for the radio silence on this issue and this repository. This repo is not dead, but it is somewhat moribund: haskell-tree-sitter is no longer a part of our (the GitHub Semantic Code team) production code pathways, and we are a small team with a lot of irons in the fire, so we don’t have much time to maintain this library (it’s time-consuming to maintain, as there are a lot of submodules and subprojects), especially when it comes to adding new languages—if that breaks, then people get mad on this issue tracker, and there’s not a whole lot we can do for them. I’m going to take a look at #295 and #293. #294 appears to have problems with the C parser itself crashing, which I’d like to resolve first. (I’m also somewhat skeptical that you can get a useful syntax tree out of a C parser without running the preprocessor, but that’s a separate issue.)

Clearly, there’s still a degree of interest in keeping this alive. At this point, I think the best thing rather than a fork is to start handing out commit bits to people interested in helping maintain the library and incorporate new languages, assuming @maxbrunsfeld approves. Would anyone in this thread be interested in volunteering?

[patrickt]

It’s also worth questioning our approach. Is it too cumbersome to have all these projects in one big monorepo? Or should we double down and have one gigantic project with every parser in it? That would be kind of wild, but maybe workable?

[maxbrunsfeld]

I haven’t been too involved with this Haskell binding. I’m fine with anybody taking it over; not sure if any other folks at GitHub have any plans for it.

[razzeee]

But will adding a language here, enable code navigation (etc) on github or has that moved to another integration point? If it's the later, I'm not interested in this anymore.

[patrickt]

@razzeee No, the instructions on how to add code navigation support for a language are here. We switched to a DSL for generating that information so as to prevent people from having to set up a full Haskell environment. Please feel free to close this issue if it’s no longer relevant to you.

[razzeee]

@patrickt
okay, but just adding that to my tree-sitter implementation will not add it automatically to github.com
is there still a process for that?

[dcreager]

just adding that to my tree-sitter implementation will not add it automatically to github.com

That's correct. We have a fixed list of language grammars (and specific pinned SHAs of those grammars) that we run in our production system. We have an internal process for vetting any additions or changes to that list so that we can carefully measure the impact on CPU, storage, and cost. If you have tree-sitter tagging rules for a language that you want to have included on GitHub, you can reach out to @patrickt or myself to kick off that vetting process.

[razzeee]

Thank you, will try to find time for that somewhen :)