Always hang after ctrl-space on Windows 7.

[AllenDang]

Any one ever made it work on Windows 7?

[nsf]

Gocode may have problems on windows. It relates to syscall.StartProcess stuff in Go, hopefully I will have time to raise that issue on the Go ML soon. In the mean time, try Sh4rK's gocode serverless fork: https://github.com/Sh4rK/gocode, it should work on windows without any hangs.

[AllenDang]

I tried newest Sh4rk's serverless gocode, but still hangs... sad...

[nsf]

Hm, maybe it's not a gocode issue then.

[DisposaBoy]

Is gocode already running? The only times I've seen hangs is when it's already running an for whatever reason it(gocode) couldn't communicate with the server. I imagine if you have one or more old instances running or in a zombie state(if there's such a thing on windows) you'll have problems.

I don't have a windows machine so it's hard to test but I did get to test on vista for a few minutes and in that short time I didn't see any issues in vanilla gocode or GoSublime.

[AllenDang]

I noticed that each time when I started sublime text 2 and make it hangs by pressing ctrl+space, there is a new gocode process will be created and it will never be closed.

[DisposaBoy]

Ok, let's see if we can't get to the bottom of this hopefully by the end this weekend.

Is it consistently reproducable? - I'm going to try and get Win7 running in a VM later, it'd be great if I can see the issue right away or be able to reproduce it. The hang you describe sounds familiar, though I cannot reproduce it (it happened on Linux).. It appeared that the first server hung, and every instance after that became blocked. The processes you see, at least in my case were not the ones started by GS, but started by gocode but I like to be sure before before blindly jumping in and trying to see what I can fix or otherwise improve. I already noticed something which I'd like to take a closer look at in gocode; namely the way the server is automatically started - starts normally then we .Release() - I'll have to look at the semantics of this and how it's supposed to work underneath but I pick on it because this is exactly how zombie processes come about - the parent goes away - which is why we have the concept of daemons.... but as I said, I'm not sure so let's not start off on wild goose-chases.

Is it possible for you to verify which process hangs? you can probably look at the processes to see what arguments they were started with(I don't know how to do this on windows). If not, then you should be able to do it by making a copy of gocode.exe to something like gocode-xxx.exe then in the GS settings change gocode_cmd to gocode-xxx.exe. kill all the other processes and then try to make it hang again. After than you should be able to see which copy(s) of gocode is running which should tell us where to start looking.

I'm not 100% confident that the server-less version would work 100% of the time if we're already getting server hangs because I know that python(as stated in its docs) is prone to deadlocks in communicating with processes and something similar might be happening gocode or GS.

[nsf]

Well, I guess I should describe the problem I'm experiencing with gocode on windows. I have a bunch of testing scripts in 'testing' dir for gocode and there is a ruby script that runs them all. On windows basically when ruby script starts a gocode process the pipe it uses to communicate with it never gets closed. Because it turns out that when gocode client starts gocode server, the pipe file handle gets passed to the server (which is a child process of the client in that case) and as a result never gets closed. It happens only on windows, due to misbehaving syscall.StartProcess in go. I want to make few simple examples and raise that issue on Go's ML. So.. personally I think this may cause that problem and that's why I suggested serverless version, it was created to address that problem.

P.S. It's easy to check if that is an issue. Just try running gocode daemon ("gocode -s") manually before doing any autocompletions.

[DisposaBoy]

I finally got Win7 and compiler up and running. The hang occurred immediately and upon investigating I found that running the server manually with gocode -s panics(http://pastebin.com/anyQUbxp) my git settings were set to extract? with native windows newlines(CRLF) as opposed to unix(LF). The latter is universally dependable if the file is opened in textmode as the conversion is done for us. Funny I can't believe I haven't thought about this at all in Golang, I can't even seem to find a way to do that in Go... but anyway.

I patched my fork to include some more common whitespace characters: carriage return, form feed and vertical tabs

After that the servers starts ok and completion works ok so loong as I start the server manually beforehand. The hang occurs if I run gocode directly - in the same fashion as GS does so I think we can be sure what we're dealing with now. I'll see if I can get it to work, If not I'll look into starting the server in Python but I don't see that ending well.

EDIT: I forgot to mention that Sh4rK's fork also panic'd and upon applying the patch it hung in the same way. When I looked at the processes, I could see that it appeared to actually start a server? (I might have been seeing things though, I'd just woken upon a few minutes before I started looking into this)

[nsf]

Ok, pulled your whitespaces patch. But regarding that hang issue, see my post above. It's the problem with syscall.StartProcess. I have a short example that demonstrates the problem and I will raise that issue tomorrow on the Go ML.

[nsf]

http://code.google.com/p/go/issues/detail?id=2250