{"shas":[["20b31b79bf92dca0661566d1373583f4c7e781ed","db68fba232b2c49ed3e9d3081df349dde7b61dfd@golang.org","compress/bzip2: add package.\n\nThis code implements bzip2 decompression only.\n\nR=bradfitzgo, r2, nigeltao, rsc\nCC=golang-dev\nhttp://codereview.appspot.com/4176051","Adam Langley"],["d0e55e20f453fd012cbe1f21766c5a2f003e9f28","4e317290bbb82623ece0bfb0548ac21ebd5b23f1@gmail.com","json: use base64 to encode []byte\n\nR=rsc\nCC=golang-dev\nhttp://codereview.appspot.com/4160058\n\nCommitter: Russ Cox <rsc@golang.org>","Roger Peppe"],["3731a0720b3c4c4b8ccc40c04037e85da161abea","beac5f8171fcde5e2ec734cc5d25d03e7362e8de@niemeyer.net","codereview: fix clpatch with empty diffs\n\nAvoid passing the placeholder diff to hgpatch, so that\nclpatch-ing an empty diff grabs the metadata and warns\nabout it being empty, rather than failing with a\nhard-to-debug problem (\"mkdir: no such file or dir\",\nno metadata, etc).\n\nR=rsc\nCC=golang-dev\nhttp://codereview.appspot.com/4172060\n\nCommitter: Russ Cox <rsc@golang.org>","Gustavo Niemeyer"],["41aa75fec1cfe721652243ab8add5f52fd145aa3","db68fba232b2c49ed3e9d3081df349dde7b61dfd@golang.org","compress/bzip2: fix bugs\n\n(Once again, proving that a fuzz tester is the first thing that I\nshould try.)\n\nR=bradfitzgo\nCC=golang-dev\nhttp://codereview.appspot.com/4227042","Adam Langley"],["5d9a77ad0351141f42ee7c764cfa858520fd7168","4dc7c9ec434ed06502767136789763ec11d2c4b7@golang.org","gob: protect against pure recursive types.\n\nThere are further changes required for things like\nrecursive map types.  Recursive struct types work\nbut the mechanism needs generalization.  The\ncase handled in this CL is pathological since it\ncannot be represented at all by gob, so it should\nbe handled separately. (Prior to this CL, encode\nwould recur forever.)\n\nR=rsc\nCC=golang-dev\nhttp://codereview.appspot.com/4206041","Rob Pike"],["1f9233a13088cb201c21c2daf7c552fa178ca53b","a6752097faebf1f02d80107d77a9be009089afe3@golang.org","sync: make package comment appear\n\nR=rsc\nCC=golang-dev\nhttp://codereview.appspot.com/4220044","Robert Griesemer"],["cc773f4e2fb3633620963330d698171dbdbd120c","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","5g: fix optimizer bug\n\nsame as in issue below, never fixed on ARM\n\nchangeset:   5498:3fa1372ca694\nuser:        Ken Thompson <ken@golang.org>\ndate:        Thu May 20 17:31:28 2010 -0700\n\ndescription:\nfix issue 798\ncannot allocate an audomatic temp\nwhile real registers are allocated.\nthere is a chance that the automatic\nwill be allocated to one of the\nallocated registers. the fix is to\nnot registerize such variables.\n\nR=rsc\nCC=golang-dev\nhttp://codereview.appspot.com/1202042\n\nR=ken2\nCC=golang-dev\nhttp://codereview.appspot.com/4226042","Russ Cox"],["5ac7fc97e9fb87d73ab2bf052296f10d8ea5bedf","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","runtime: traceback through active lessstack\n\nWith this change, a panic trace due to a signal arriving while\nrunning on the scheduler stack during a lessstack\n(a stack unsplit) will trace through the lessstack to show\nthe state of the goroutine that was unsplitting its stack.\n\nR=r\nCC=golang-dev\nhttp://codereview.appspot.com/4206042","Russ Cox"],["13da5abee1da9836eb2589c0e6cdf7ca8ca9c04f","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","runtime: pass to signal handler value of g at time of signal\n\nThe existing code assumed that signals only arrived\nwhile executing on the goroutine stack (g == m->curg),\nnot while executing on the scheduler stack (g == m->g0).\n\nMost of the signal handling trampolines correctly saved\nand restored g already, but the sighandler C code did not\nhave access to it.\n\nSome rewriting of assembly to make the various\nimplementations as similar as possible.\n\nWill need to change Windows too but I don't\nunderstand how sigtramp gets called there.\n\nR=r\nCC=golang-dev\nhttp://codereview.appspot.com/4203042","Russ Cox"],["a6121ea1be13e33fb2c6a753c10aa98fb2403744","ae9783c0b0efc69cd85ab025ddd17aa44cdc4aa5@golang.org","http: introduce start of Client and ClientTransport\n\nMuch yet to come, but this is a safe first step, introducing\nan in-the-future configurable Client object (where policy for\ncookies, auth, redirects will live) as well as introducing a\nClientTransport interface for sending requests.\n\nThe CL intentionally ignores everything around the creation\nand configuration of Clients and merely ports/wraps the old\ninterfaces to/around Client/ClientTransport.\n\nR=rsc, dsymonds, nigeltao, bradfitzwork\nCC=golang-dev\nhttp://codereview.appspot.com/4182086\n\nCommitter: Brad Fitzpatrick <bradfitz@golang.org>","Brad Fitzpatrick"],["948f21e21df2d42646b06ce7aef531b859d51a97","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","runtime: omit breakpoint during terminal panic\n\nA terminal panic (one that prints a stack trace and exits)\nhas been calling runtime.breakpoint before calling exit,\nso that if running under a debugger, the debugger can\ntake control.  When not running under a debugger, though,\nthis causes an additional SIGTRAP on Unix and pop-up\ndialogs on Windows.\n\nSupport for debugging Go programs has gotten good\nenough that we can rely on the debugger to set its own\nbreakpoint on runtime.exit if it wants to look around.\n\nR=r, r2\nCC=golang-dev\nhttp://codereview.appspot.com/4222043","Russ Cox"],["f08b12915955731e55832cd8920edb4dd6db1459","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","runtime: always run stackalloc on scheduler stack\n\nAvoids deadlocks like the one below, in which a stack split happened\nin order to call lock(&stacks), but then the stack unsplit cannot run\nbecause stacks is now locked.\n\nThe only code calling stackalloc that wasn't on a scheduler\nstack already was malg, which creates a new goroutine.\n\nruntime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139\n       runtime.futex()\nfutexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51\n       futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)\nfutexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119\n       futexlock(0x5b0188, 0x5b0188)\nruntime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158\n       runtime.lock(0x5b0188, 0x7f0d27b4a000)\nruntime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336\n       runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)\nruntime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705\n       runtime.oldstack()\nruntime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224\n       runtime.lessstack()\n----- lessstack called from goroutine 2 -----\nruntime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158\n       runtime.lock(0x5b0188, 0x40a5e2)\nruntime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316\n       runtime.stackalloc(0x1000, 0x4055b0)\nruntime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803\n       runtime.malg(0x1000, 0x40add9)\nruntime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854\n       runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)\nruntime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831\n       runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)\n...\n\nR=r, r2\nCC=golang-dev\nhttp://codereview.appspot.com/4216045","Russ Cox"],["5ad0e068303c9af35326be61340ff7c4a8d35adc","5ad239cb8a44f659eaaee0aa1ea5b94947abe557@golang.org","build: remove _gcc_main.c during make clean\n\nR=r, r2\nCC=golang-dev\nhttp://codereview.appspot.com/4226043","Russ Cox"]],"repo":"rsbx/go","actor":"rsbx","ref":"refs/heads/master","size":13,"head":"5ad0e068303c9af35326be61340ff7c4a8d35adc","actor_gravatar":"a2a2859784844388dc41021cf3d0c5bd","push_id":25413871}