Prototype for evaluation on the server.

[heyLu]

Not integrated in the server yet, but you can use it on it's own:

session <- startSession "."
evalInSession "1 + 2" session
--= Right "3\n"
evalInSession "putStrLn" session
--= Left "\n<interactive>:6:1:\n    No instance for (Show (String -> IO ()))\n      arising from a use of `print'\n    Possible fix:\n      add an instance declaration for (Show (String -> IO ()))\n    In a stmt of an interactive GHCi command: print it\n"
endSession session

Comments, suggestions?

[heyLu]

I've integrated it into the server code and put two minimal tests in test_server.rb.

To make this possible we now pass LTClientState instead of Handle around.

[jetaggart]

Do we need to handle closing the repl session gracefully here?

[jetaggart]

Looks like you already wrote endSession. Does that do the job here?

[heyLu]

Yes it should. I'll add it.

[jetaggart]

This looks great. I think handling the repl sessions in the server code is definitely worth it. I added some comments, but mostly just questions for my understanding.

I'm happy to merge this if you are.

[jetaggart]

Please look at the outdated diffs. I made a commit that caused github to think they were addressed.

[heyLu]

I changed the ClojureScript part to use the server now. It works for me now as it did before. Could you test this yourself, too?

I had to change the LTPayload type to include a line number. It shouldn't interfere with the rest of the code because it defaults to 0 and is optional.

[jetaggart]

I'm getting an error whenever the process tries to boot:

cljs haskell_compiled.js[305]:  Process errored:  light-haskell: fd:10: hWaitForInput: end of file
haskell_compiled.js[308]: Process exited:  1

It looks like it's happening in clearHandle

[heyLu]

On which file did you try it?

[jetaggart]

LTHaskellClient

[jetaggart]

It happens on ReplSession too.

[heyLu]

Mhh.. it still works for me. What do you evaluate?

[jetaggart]

1 + 1. It's on booting the process though, so any command I try to do fails. I can try and figure it out later. What platform are you on? Maybe it's an OS difference?

[heyLu]

I'm on Linux. The only thing i could think of is line endings, but I don't think that is it.

Did the ClojureScript version work for you?

[heyLu]

One idea/thing you could try: Could it be that starting ghci/cabal repl fails for some reason? You could check that by using the code that I posted at the top of this pull request.

[jetaggart]

Right "3\n"

It seems fine. I'll dig around more

[jetaggart]

It's weird because the test_server works fine. Just when it's in process it fails.

[jetaggart]

And yes, the cljs version worked.

[jetaggart]

If I boot the connection manually (using the add connection sidebar) from the directory that has the cabal project, it works. I think the problem is it doesn't find the cabal file and boot a repl and boots ghci instead.

That last commit you made should have fixed that issue though.

[jetaggart]

Okay, I figured it out. It was a nasty issue with my load path. It seems LightTable's process PATH's are a bit rough still. It all looks good!

[heyLu]

That's good. :) If it's something that might occur more frequently probably create a troubleshooting section in the README for issues such as this? Or maybe print out a better debugging/error message?

[jetaggart]

Yeah, I'll add something there. Every problem I've had has come from
PATH issues.
Is there a way to get better stack traces/debug something like that
more effectively? I had to just reason out where that error was
originating, it'd be nice to see a stack trace. I know that the
semantics of Haskell makes that different, but I haven't figured out a
way to debug haskell program besides just thinking really hard, haha.
That advice might be nice for people contributing, as most are likely
to be new to haskell.

On Mon, Jan 27, 2014, at 12:11 AM, Lucas Stadler wrote:

That's good. :) If it's something that might occur more frequently
probably create a troubleshooting section in the README for issues
such as this? Or maybe print out a better debugging/error message?

—

Reply to this email directly or [1]view it on GitHub.
[161737__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNjM0MzA5Mi
wiZGF0YSI6eyJpZCI6MjQyNzYxNDN9fQ==--9d3c57a6bc6b6abb8fb952e04ae13950252
1a222.gif]

References

1. Prototype for evaluation on the server. #30 (comment)

[heyLu]

I think some tests would help to be sure that we didn't break anything on the Haskell side. We could also check if ghci or cabal are on the PATH in Haskell.

Regarding stack traces, I've never used this, but maybe this would help? http://www.haskell.org/haskellwiki/Debugging#Stack_trace Not in the case of the loading path though, because we already knew where it failed.

[jetaggart]

Agreed. I think we should really start testing both. I don't know how to test the LT stuff though. That's another reason for wanting to do most of the heavy lifting in haskell.