Resurrect vim #2

wants to merge 4 commits into

3 participants


This patch makes the new architecture work with Vim.
I had to do some minor refactoring.

It also drops all the .vim files adding some notes instead.

MarcWeber added some commits May 26, 2011
@MarcWeber MarcWeber drop testing file which is missleading d4fdd2e
@MarcWeber MarcWeber drop server/Main.hs - its not used 6dd4094
@MarcWeber MarcWeber readd JSON support:
because derive is used for creating most JSON instances
it made sense to move all the deriving template haskell stuff into its
own module src-execs/ProtocolJSON.hs. To make that work I had to move
some type definitions into an extra file: src-execs/ServerTypes.hs
@MarcWeber MarcWeber drop Vim code in this branch because Thomas Schilling told me once th…
…at he'd like to keep Vim stuff separate

Are these instances compatible with the old instances? EclipseFP uses json to communicate with the Scion server.

The EclipseFP fork also switched to AttoJSON, presumably because they had some performance issues. Because of that I was actually planning to reimplement the JSON serialisation on top of bos's "aeson" library, which seems to be well-maintained an focused on performance. Aeson also has the advantage that there are separate type classes for serialisation and deserialisation, so only one of them needs to be implemented if only one is needed.

No, the only thing which is "comptabile" is the format of error lines. I copy pasted the old code generating error locations.
Those instances carn't be dervide because contstructors are not iexposed.
I haven't done that much Haskell - so I may have picked the wrong JSON library. Is "SerevrCommand" compatible to the old commands?

I'm totally fine with this being a temporary solution only and documenting it.
If we want a consistent JSON interface we should document it how it should look like.

Also note that this patch drops two .hs files which are confusing but which are not used at all.

The generated instances are quite silly: "{Nothing:null}" represents Nothing. In the end its only about 5 commands.

I think its more important that we start protocol version negotiation such as the first line being returned being a version identifier or such.
Then clients can configure themselves or tell the user that they are connecting to the wrong server version.
In the Vim case its so cheap loading a different plugin that I'm not going to maintain many versions within the same code base.

I also wonder why there are two separate executables: worker and server. Why not pass an argument? This would mean less memory consumption case some executable memory could be shared between both executables ? Also compilation would be simpler: Currently a library is build, the library is regsitered locally - then two time consuming link phases happen. .. What is the reason for this?

I don't think that parsing JSON queries takes so much time that its worth caring too much about it. Same for serialization.
You seldomly have 10.000 lines of notes.

I know I went off topic..


Regarding protocol negotiation: Yes, that's something to add eventually.

Regarding server vs. worker: I discussed that in my other comment, here's the link again: Both executables share some time and therefore link against the Ghc API which is incredibly time consuming on OS X (it's much faster on Linux). I'll see what I can do to make the server independent of the Ghc API, that would make it faster to link.


Ok, that's an idea. I'll look into it.


I was planning to use Neil Mitchell's CmdArgs. This can be done later, but long options should have two dashes. So this should become --json.


The scion-worker executable is internal to Scion. See for some background. Only the scion-server executable will have a documented interface.

That said, there currently isn't really a stable branch. I'll merge things back into master (and drop the development branch) once I feel it's ready. I'll let you know when I'm there.


I had some problems with buffering, so this is to make sure.


BTW, why are you using JSON for Vim? I remember there being some hacks needed for Vim. Would it perhaps be more useful to send an expression directly interpetable by python? For example, the string could then be read by:

an expression directly interpetable by python

btw, JSON is actually a subset of Python, and as such can be evaluated directly by Python...

And what about "null"?

Yes, you need an environment where null, false and true are predefined to None, False and True respectively, but that doesn't change the fact that the JSON grammar is parse-able by the Python grammar to semantically equivalent values (if the 3 atoms are defined in the environment appropriately)... I just wanted to point that out... nothing more nothing less :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment