Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Resurrect vim #2

Open
wants to merge 4 commits into from

3 participants

Marc Weber Herbert Valerio Riedel Thomas Schilling
Marc Weber

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
Marc Weber MarcWeber drop testing file which is missleading d4fdd2e
Marc Weber MarcWeber drop server/Main.hs - its not used 6dd4094
Marc Weber 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
7beb79c
Marc Weber MarcWeber drop Vim code in this branch because Thomas Schilling told me once th…
…at he'd like to keep Vim stuff separate
826da71
Thomas Schilling

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..

Owner

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: https://github.com/nominolo/scion/blob/scion-2nd-attempt/docs/Architecture.markdown 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.

Owner

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

Thomas Schilling

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.

Owner

The scion-worker executable is internal to Scion. See https://github.com/nominolo/scion/blob/scion-2nd-attempt/docs/Architecture.markdown 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.

Thomas Schilling

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

Thomas Schilling

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: http://docs.python.org/library/ast.html#ast.literal_eval

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
Commits on May 26, 2011
  1. Marc Weber
  2. Marc Weber
Commits on May 27, 2011
  1. Marc Weber

    readd JSON support:

    MarcWeber authored
    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
  2. Marc Weber

    drop Vim code in this branch because Thomas Schilling told me once th…

    MarcWeber authored
    …at he'd like to keep Vim stuff separate
Something went wrong with that request. Please try again.