Add proper error handling semantics to FileStream.

[davesisson]

The previous implementation was swallowing any errors so it could be confusing. For instance a missing file is treated as an empty string which successfully parses (when one would expect an error).

This will be an incompatible change and is probably best lumped in with the other incompatible changes coming up.

[millergarym]

This code doesn't compile

[EpsilonPrime]

I already have a PR out to fix this.  Need to find a better test setup for the go - what I have in github is inadequate compared to my work setup.On May 1, 2017 01:29, Gary Miller <notifications@github.com> wrote:This code doesn't compile —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[millergarym]

@EpsilonPrime I only saw your updated PR after commenting.

What setup would you aim for?
I think it would be worth while putting in a bit of effort for a nice production and development setup for antlr/go.

My antlr dev/Go environment is a bit fragmented.
I'm using Eclipse for the Java, with runner configured for quick turn around and debuggable converts of grammars to Go.
Maven is needed when test files change (something a clean is needed). This is slow, so I avoid too many changes to test grammars.
The Go working is in vscode.

As for prod - the Go target is not very go gettable.
Every now and then I prune the antlr repo and push it (with included jars) to https://github.com/wxio/antlr4-go . The readme is a bit out of date.

[davesisson]

In my work environment I have vim with YouCompleteMe (gives me tab-completion of go entities). For the most part that accomplishes what I need to do. IntelliJ isn't a bad environment but it's more pretty than useful. For runtime fixes I should just keep the files in sync in a branch in my work code. It's the rapid build through maven that's a pain. What I've done before is disable everything but the go runtime in the pom files to make the full build/test go faster. I'll probably do that for my next change. I don't use go get due to my environment so I wouldn't know about how hard go get is to use. I'm using a custom script to import the runtime (and given that it's all in one directory it's not that hard to deal with).

…

On Mon, May 1, 2017 at 8:14 AM Gary Miller ***@***.***> wrote: @EpsilonPrime <https://github.com/EpsilonPrime> I only saw your updated PR after commenting. What setup would you aim for? I think it would be worth while putting in a bit of effort for a nice production and development setup for antlr/go. My antlr dev/Go environment is a bit fragmented. I'm using Eclipse for the Java, with runner configured for quick turn around and debuggable converts of grammars to Go. Maven is needed when test files change (something a clean is needed). This is slow, so I avoid too many changes to test grammars. The Go working is in vscode. As for prod - the Go target is not very go gettable. Every now and then I prune the antlr repo and push it (with included jars) to https://github.com/wxio/antlr4-go . The readme is a bit out of date. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1844 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALUC_SJESq14jkFYlb9IgFHd6lOwNvloks5r1faugaJpZM4NLDek> .

[millergarym]

There is something funny with the Go travis tests. The compile error in master was (I've merged your fix into my code) breaking my build. Is there a go get or something like that happening during the build?