I tried to download someone's Go repo that operated on gifs, but on my machine it died with an error inside of the standard library's compression code, which failed with a cryptic message.
I spent the next 30 minutes trying to figure out how to add printline debugging to the standard library. I saw the precise line of code it was failing on, so I added some logging code above it to print out more info. Nothing happened. I tried to rebuild the file. There was no obvious way to do this. I googled for "golang recompile standard library." There was no clear, simple answer. I seemed to be expected to read all of the documentation in order to do this seemingly-simple thing. I went on Freenode and asked how to do it. Crickets.
I was being intellectually lazy, a cardinal sin. Obviously, the solution was to read the documentation, learn about GOPATH, learn how and why the source code was laid out the way it was, understand how to make my own package, then try to figure out how to make changes to existing packages.
But it's a step backwards. I'm staring at the code. I made changes to it. Why does it require a magical incantation to make those changes have an effect? Why can't it detect that the code changed, and do whatever's necessary to apply those changes? Or at least let me type "go make zlib.go" and be done with it? Yeah, "make" isn't a valid command. I'm supposed to "build" a package. But I'm not trying to build a package. I'm trying to run someone's freshly-cloned Go project.
The whole GOPATH and directory magic is really bad and outdated. In almost every other language I can place my files wherever I want and write a build script.
I like everything else about Go and hope they remove that cruft from such a great language in version 2 or so. Go should learn from C/C++ in this regard.
I see that the exact other way around. With other languages, every project decides on their weird local directory layout for no good reason at all, and then everyone has to write build scripts to keep things working.
Learning from C++ builds seems like a cruel joke – not sure if trolling or not ;-)
Although I find build Go code with go tool very nice, it is in no way part of language specification. Just like in c you can build your own object files and/or archives and link them as you please. How go the tool does it is not the only possible way. See this example I've prepared on how to manually build go code: https://github.com/tumdum/go_build
In this case, the project was using Go's standard image library to operate on gifs, which itself uses Go's standard compression library to perform the compression. So the stack trace on error looked like:
> error
> go's standard compression lib
> go's standard gif lib
> the project tries to write a gif to disk
It was very easy to grep the stdlib for the error message, which turned out to be in Go's compression lib. Great! I opened it up and started reading through it.
Somehow, the compression lib was receiving an invalid parameter. Therefore, either Go's standard gif library was responsible for the problem (extremely unlikely) or the project was generating some kind of "invalid" gif data, or some gif settings that Go's gif lib didn't handle correctly when writing to disk.
Printline debugging is the fastest way to figure out this type of problem. Print out everything, every single parameter, all the way up the stack. Eventually you'll spot the logic that's failing to handle the data. Trouble was, I had no clue how to modify go's stdlib. Nothing I did seemed to have any effect whatsoever.
It sounds like you're saying the solution is to copy the gif lib to my local gopath like foo/gif, rebuild it there, then modify the project to import from foo/gif instead of image/gif. Ok, cool. I'll try this, thanks!
Since the gif lib imports the compression lib, it sounds like I'll have to copy both libs, then try to modify the gif lib to use the local copy of the compression lib. Ok, sure. At least now I have a way of making progress.
The project ran on the author's machine without any problems, so I bet I'm using a different version of Go. If I could figure out which version they were using, I could just downgrade to that. Problem solved. Unfortunately, I don't think this information is present in the project's repository, which is just a single .go file. (I guess I could check when the most recent commit was, then figure out what version of Go was in use back then...)
When you say you can't debug, you mean you don't have have a debugger, right? People have been debugging software for decades without debuggers, for example.
For a side project, I've been using Go on the App Engine for the past year, writing with Sublime Text. Sublime has a Go plugin that does some syntax checking, and App Engine reloads automatically. It's not that bad. My site isn't large but I find it more enjoyable than writing Java. I started with Python but found Go is significantly faster:
for small teams (mostly solo hackers) yes the run-print-change works;
for anything bigger, when code #reasonably# grows and span among 10+ developers, break-debug-change is much more productive than log.PrintLn all over the palces and figuring out myself, or interrupt my colleague to explain sth to me.
I'm really interested as to how they inspect Python applications without slowing it down. I know the PyDev debugger adds significant overhead, which is due to it's use of stackframe inspection/function call hooks (as far as I know).
How can they put a breakpoint/inspect objects at arbitrary locations without this slowdown? Maybe they have a modified cPython interpreter?
The Python Cloud Debugger works with the standard (unmodified) CPython 2.7.x. Breakpoints are implemented by rewriting Python bytecode at runtime. The debugger inserts a method call at the breakpoint location in a code object. This method tells the debugger that the code reached a particular point. Generator functions are particularly tricky because they need to maintain correct offsets at "yield" points.
They Python Cloud Debugger uses a combination of line trace debugging (which is very slow) and the profiling callback (fast) to inspect the line of interest.
The Cloud Debugger is different from your tradition debugger as it optimizes for application speed. For example, it would capture values, let the thread continue and run, and only then serialize is back to the Cloud Debugger server.
But many (most?) are willing to accept that trade-off.
I haven't researched this at all, but if you can use your own software on your own computer (e.g. IntelliJ) for the debugging UI, then you retain control over at least _part_ of your computing.
True, but if you replay all events that lead to a certain state, you will end up in the same state. Of course, you will need to make wrappers around certain system functions, e.g. the clock, etc.
The Cloud Debugger has open API's and plugin model. Anyone can write a Cloud Debugger agent, for any language, and have it integrated seamlessly to the Cloud Debugger experience.
There Cloud Debugger service exposes the clouddebugger API, which actually has two parts. The Debugger (which is intended for the UI) and the Controller (which is intended for the agent to interface).
emacs package don't exist yet as far as I know. But the API's are open and should be easy to write. I think that the hard part would be the UI for displaying variables and stacks.
The server side code is not open-source, mainly for use of internal technologies. But why do you really need it? Google offers it's usage for free.
