As it's said above

[asa@kirito IntaLancer]$ golab -http -addr=:8910 -work="/home/asa/dev/Go/"
2013/06/17 02:31:11 found gocode at: /home/asa/go/bin/gocode
2013/06/17 02:31:11 starting http://:8910/
starting lab for: [/home/asa/go/src/pkg /home/asa/gopath/src]

The lab isn't started for the area I specify in -work and within the browser the areas it does look at aren't shown within the document browser window.

Here shown if I look in the documents tab it just shows the tray icon with the work documents

but then if I manually enter my home directory after #file in the url it shows me some more options but crucially still ignores the one I specified

How do I uninstall golab. Even when I do not start it, it seems to be using the port I previously started it with and there does not seem to be a running process listening on the port when I use netstat -tulpn

The respository github.com/garyburd/go-websocket is 404 now

github.com/garyburd/go-websocket (download)
Username for 'https://github.com': kokizzu
Password for 'https://[email protected]': 
# cd .; git clone https://github.com/garyburd/go-websocket /home/kyz/Dropbox/go/src/github.com/garyburd/go-websocket
Cloning into '/home/kyz/Dropbox/go/src/github.com/garyburd/go-websocket'...
remote: Repository not found.
fatal: repository 'https://github.com/garyburd/go-websocket/' not found
package github.com/mb0/lab/golab
        imports github.com/garyburd/go-websocket/websocket: exit status 128

this issue is a declaration of intent. even though a simple chat box is the first thing that comes to mind when thinking about a collaborative workspace this or similar features are not going to be part of golab.

my reasoning is that any effort in that direction will ultimately be too big for this project and in any way lacking the features you are used to. instead use your preferred way of communication like jabber, mumble, voip or carrier pigeons.

it would be useful if golab has the ability to create, rename and delete files. not a hard problem in general the one thing holding me back are interface considerations. but i come more and more to the conclusion that context menus and modal dialogs are the way forward.

looking at the github.com/sirnewton01/godbg project by chris mcgee gbd integration with golab seems feasible.

i have not often had the need for debugging but in some cases it is very much called for and then often obstructed by the the unwieldy usage of gdb.

so i want to add this as a long term goal to collect ideas and considerations.

the first substantial one is that golab needs some kind of lockdown mode. so files and document buffers cannot be changed during the debug run. because golab is a shared and collaborative workspace there needs to be initialization sequence for the lockdown other collaborators can object to.

that reveals other questions of which aspects of the ui and control are shared.

I tend to suspend my computer rather than shutting it off. I left golab open in my browser, and when I resumed I had to click the reconnect icon in the upper left. I edited a file that I had left open. It seemed to work - console output showed that packages were being rebuilt when I pressed ^s. However, behavior of the modified code did not change.

I didn't realize what the problem was until I opened the file in a text editor and found that the last changes were ones I made before putting my computer to sleep.

I think an error should be displayed to the user if any OT transform fails to apply.