5 ms·

One thing I like about rsc (and Austin) is that they have these well explained commit logs that let's people follow along at home. The changes seem like they a

• idank 10y ago
  You weren't joking, it is a story. Isn't it kind of unfortunate that all this information is in a commit message, that 1) needs to be discovered through git blame, 2) at risk of requiring code archeology if enough lines change, e.g. by moving code around, and 3) is immutable so parts of it cannot be edited in the future? I see this habit in a lot of commit messages and while it is important to convey intent, there are better ways to document your code (either inline, or in this particular case, a wiki page).
  • obstinate 10y ago
    Much of it is reproduced in the comment in the patch.
    • LukeShu 10y ago
      Indeed, the only actual code change is: - sellock(scases, lockorder) + systemstack(func() { + sellock(scases, lockorder) + }) The rest of the patch is adding/changing comments explaining everything.
      • bsdetector 10y ago
        I feel this kind of thing should be remembered when people say they're going to reinvent decades-old technology. This bug exists because they wanted to reinvent threading so you could have millions of threads, except when you actually use millions of threads for anything non-trivial it doesn't actually work out so well. To do that they couldn't use the standard since-1970 fixed stacks so they needed movable/growable stacks. They reinvented exceptions in a way that broke selinux. They reinvented the memory allocator in a way that breaks ulimit. They reinvented a javadoc/doxygen that's less useful. It's great to try to improve things, but a lot of times there's actually very good reasons for the old ways.
        • rounce 10y ago
          Are you kidding? How is `go doc` anything like Javadoc aside from being automatically generated by machine from your sources. Might as well compare it to Jekyll.
          • gravypod 10y ago
            https://docs.oracle.com/javase/8/docs/api/java/util/List.html#size-- https://docs.oracle.com/javase/8/docs/api/java/util/List.htm... https://golang.org/pkg/container/list/#List.Len https://golang.org/pkg/container/list/#List.Len
            • rounce 10y ago
              Note the backticks, I was referring to the `go doc` command built into the standard tooling. There are many generated HTML documentation generation tools for every language. It's Golang's general approach to documentation which many find appealing, not the fact they can output to HTML.
              • gravypod 10y ago
                My tooling does this too and I don't even need to remember a terminal command: http://i.imgur.com/YmAkBPG.png http://i.imgur.com/YmAkBPG.png I get what your saying but it's apples to oranges. They are in effect similar though.
                • rounce 10y ago
                  I (and I guess many others) enjoy that Golang's documentation strategy is coupled far tighter to the language (almost as a component of the language), in contrast to JavaDoc's existence as more of a standard for writing comments, `javadoc` being the first of many implementations and variations on it. I'm not saying this is in any way empirically superior, in fact I think Go's approach owes a lot to Sun's original vision with JavaDoc. Some just prefer it and feel it's approach benefits them, and it's a preference that is often factored in when making the choice to use it. My original point was that Sun's approach is now so commonplace it's an 'apples and oranges' argument. Golang has made a legitimate step forward (I think), in how a language treats and encourages it's documentation: As a first class citizen from day 0, rather than a convenient afterthought. The parity of experience between godoc.org & `go doc` demonstrates this with ample effect.
      • bsaul 10y ago
        doesn't it mean some kind of global lock ? i'd be curious to see the impact on benchmarks for parallelization.
• masklinn 10y ago
  I like going through Postgres's commit logs once in a while for exactly that reason, non-trivial commits (logic wise, they may be a 1LOC commit) get short-story-scale messages, often with references to ML thread(s) where the issue or change was discussed. It's a nice change of pace from $dayjob where a commit changing half the codebase in ways unspecified gets logged as "improvements".
  • koolba 10y ago
    > It's a nice change of pace from $dayjob where a commit changing half the codebase in ways unspecified gets logged as "improvements". The best (worst?) one is where you'll see a series of major changes with the following commit messages: - Add feature X (no explanation of what it does) - Fix feature X - Really fix feature X - Fix feature X for real - Finally fixed X - Fix test environment
    • masklinn 10y ago
      I know you don't work at $dayjob because the last commit would be "fix X test which is dumb", which removes the test entirely.