HN user

traviscline

22 karma
Posts4
Comments30
View on HN

In the current state you can insert “mcpspy” in front of a server and it intercepts and streams out a plain text format that’s nice for humans and machines. There’s also a replay tool that emulates previous traffic, including in mock client and server modes, and a diffing program that is mcp protocol aware.

Oh, and most importantly, a vim syntax plugin for the .mcp file format.

Thanks for this, I’ve been feeling similarly.

I’m working on some Go programs/tools with the explicit goal of describing existing servers in a language neutral manner to try to get some sanity into the mix.

I was reenergized to pick this back up because Google is working on a version so I want to get these tools ready.

Open to ideas and input, have been noodling on it for a bit now, lots not in form to share but figured I’d share early:

https://github.com/tmc/mcp

Interesting, I've had an almost opposite experience, but I don't know the ruby landscape all that well (bundler/gemsets/rbenv/rvm etc) and I suppose it just depends on what background you're coming from.

FWIW, when creating a virtualenv the -p flag lets you choose a python binary (and therefore version).

Great writeup. This shows the power of gevent+redis really succinctly.

I think most importantly vs a twisted or tornado based solution this is using the vanilla redis client library. As long as your datastore's client library is pure-python it JustWorks with gevent.

Adding gevent-websocket and gevent-socketio to the mix gives some interesting possibilities as well.

Good call, added it, initial run didn't show a huge difference.

edit: here are numbers from a few runs: gvent,http.go 361.43,386.68 354.69,397.15 388.96,377.69 424.81,430.34

http.go averaged 26% utilization gvent.py averaged 15% utilization

I'm embarrassed posting this because of how grossly unscientific this is..

Not quite as fast as I thought initially but likely faster than the other python competitors.

On branching 16 years ago

The possible workflows with git encompass hg workflows. You're obviously not interested in gaining anything but self-fulfillment throughout this thread.

On branching 16 years ago

Actually, git supports more workflows, you could simply implement read-only branches with a naming scheme and a hook.

In lots of ways git is a superset, branch workflow included.

On branching 16 years ago

I don't really see much value in keeping a branch around after development is complete (or defunct).

If the work is complete then merge it (with no-ff if you want to show the merge explicitly). If it's defunct then delete it. If you want to keep it around but discourage further development then tag it or come up with a naming convention.

That you have the ability to mark branches as closed in mercurial is mainly paper over their odd decision to not allow deletion of branches.