If you’re interested in exploring tooling around stacked PRs, I wrote git-spice (https://abhinav.github.io/git-spice/) a while ago. It’s free and open-source, no strings attached.
The README covers the idea behind errtrace in more details, but the primary difference is in what is captured:
pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program.
errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.
This gives you a different view of the code path: the stack trace is the path that led to the error, while the return trace is the path that the error took to get to the user.
The difference is significant because in Go, errors are just plain values that you can store in a struct, pass between goroutines etc. When the error passes to another goroutine, the stack trace from the original goroutine can become less useful in debugging the root cause of the error.
As an example, the Try it out section (https://github.com/bracesdev/errtrace/#try-it-out) in the README includes an example of a semi-realistic program comparing the stack trace and the return trace for the same failure.
Judging by the project, it's implemented by instrumenting the source code; either manually modifying error returns with a wrapper function, or by running source files through an automated tool that will find and modify the return statements for you.
I'm a happy duck.com address user. I can answer these questions:
What it is: It gives you private throwaway email addresses.
Instead of signing up for a website with <real>@gmail.com, use <fixed>@duck.com. It will forward the email to <real>@gmail.com after removing any trackers from it.
It also lets you generate <random>@duck.com addresses on demand. If you sign up for something with <random>@duck.com, and they start spamming you, you can turn the email address off without doing anything to <real>@gmail.com or <fixed>@duck.com.
How to re-access it:
Information about your duck.com address is stored in that browser. If you use the Browser extension, that remembers it. You simply need to log into that email address from your current browser.
To do this, visit https://duckduckgo.com/email/, click on "I already have a Duck address", and enter your original <fixed>@duck.com address. It will email you a one-time password to <real>@gmail.com, and you'll be back in again.
Another option for recording gifs is LICEcap (http://www.cockos.com/licecap/). It supports OSX and Windows.
No support for overlaid keystrokes, though.
I believe you need to enable "Raw Message Delivery" in the subscription attributes for that subscription for it to deliver raw JSON content instead of wrapping your message in an envelope like that.
I honestly don't see a problem here. They decided to change a backend library for a non-essential system in their product. Most services don't ask for permission or make announcements when they make changes like this.
The approach seemed to be, if things break, people will report it and we’ll fix it.
While this may not be the best approach, the number of languages supported is too high for a person to check each one manually. Generally, I imagine they wouldn't expect a change like this to break anything significant.
[people] use it as a portfolio. [..] To suddenly doink the appearance of people’s portfolios is unfortunate.
It is very unlikely that syntax highlighting errors in GitHub will affect someone's chances of getting a job.
Sure, this switch could cause some issues but they don't seem to be severe enough to kick up a fuss over.
I beg to differ. Github pushes its code rendering as far as possible, including providing widgets to embed code snippets into you blog. It is also the _main content they display all the time_. That's not "non-essential".
Just switching the library and breaking things at a whim is problematic.
Also, the number of languages may be 316 (including some oddballs like "Unified Parallel C") but that's still a possible number to check for at least for major, obvious breakages. Still, for people that do use Unified Parallel C, adequate highlighting might just be the reason to choose that platform and use it to write your blog in, instead of writing a custom highlighter for prism.js.
Sorry, if you business is code and you decide to support 316 languages, expect people to hold you on that promise.
That said, also: errors happen. But that isn't a reason to give them a pass, just not to put too much weight on such things. It doesn't break the platform at large, but terribly inconveniences some users, and they are very right in being upset, too.
The other half being providing a service they find worthwhile that doesn't change at every whim.
Taken to the other extreme, a constantly breaking Github doesn't have any value proposition.
Promises are not always explicit and not at all related to laws.
The next Transformers being something to look forward to is a promise, but that doesn't mean not liking it is in any way wrong or that I could sue someone for it. I can choose to leave the movie and never go see one again. The producers of Transformers certainly owe me nothing, but they also cannot tell me how to feel about their handling of the material.
Github promises the most awesome code hosting around. That's a very different thing for many people. And to some people you can live up to the promise, to some people you cannot and it's perfectly fine for those to feel let down. Calling all those people "entitled" is, quite frankly, insulting.
As I said: putting this like it is the end of the world is overreaching, but it is a valid complaint and a valid sentiment. Saying that this is the most important thing on Github, because it happens to be specific your problem is entitlement.
Finally, it isn't true that you are only bound by spelled out things. The law many people cite so often has the concept of Good Faith: http://en.wikipedia.org/wiki/Good_faith_%28law%29 and similar fun things that extend beyond that. So Github _does_ owe me beyond their ToS.
(I appreciate that this is probably not a case covered by this)
It's a common sentiment in these circles that only the rules written on the contract are the ones that count, while nothing can be further from the truth, widely varying from legislation to legislation.
Agreed. A business relationship is more like personal relationships than I think some technical people think. Pointing at the contract is a failure condition.
nobody's talking about legal contracts. the issue is of good will. the promise github has made is they would provide all kinds of hosting (git, gitsts, pages, whatnot). people move from other solutions to github because the github's promise (again, not a legal contract) is "we're better".
the other half the difficulty of running a business comes from making tacit promises and then acting annoyed that the other side holds you to them.
I didn't expect my blog post to be on the front page of HN. Here's a TL;DR summary:
For many languages this is a significant and distracting degradation in the presentation.
I could understand GitHub removing highlighting completely because they feel speed is the overriding priority. That would be even faster than what they're doing now. Languages would look "plain" instead of "wrong". Not my first choice, but a reasonable choice.
The situation now is that they've replaced a library that had been handling highlighting thoroughly, with a variety of text-editor lexers that mostly are not. People like me who already contributed to Pygments, aren't feeling motivated to do this all over again for no good reason. So it seems likely the lexers will remain poor for quite a long time. Which is unfortunate.
Finally, at the time I wrote my blog post, I was speculating about the motivation because GitHub hadn't explained why, yet. Someone later did explain ("because speed") in the issue thread.
Are the majority of languages now broken, or just a small niche subset that don't see much use vs. ruby, python, etc?
If a few minor languages hardly anyone uses as compared to the whole site might need some fixing, this still seems like a win from Github's side of things since per the graph the change did in fact significantly improve render times.
Which is sad, because the TextMate lexer design is really really awful. Mostly undocumented. Lots of oniguruma-specific regexes used in the syntaxes. Inefficient beyond comprehension.
For instance, TM syntaxes can legally have recursion loops in them, which TextMate will cut so that the app doesn't spin into infinite recursion. But the precise way that it does this is a mystery.
The pygments design is better for static syntax highlighting.
Point of curiosity: Chocolat is compatible with TextMate syntax files, IIRC. Was going with TM syntax purely a pragmatic choice? Is it not so bad for in-editor syntax highlighting? It seems like virtually every text editor that hit the market -- or whatever one would say for free programs like Atom -- after TextMate adapted TM syntax files. (While BBEdit's comparative inflexibility in syntax highlighting, even the new BBEdit 11 format, irks me, it's hard not to notice that it's a much better performer on giant files.)
There are two types of syntax highlighting: static and dynamic. Static is like GitHub/Gist/Pastebin, dynamic is like Atom/TM/Sublime. Static highlights the file straight through, and the result can be cached indefinitely. Dynamic highlighting in a text editor parses as little of the document as is theoretically possible, in response to an insertion, deletion or replacement.
For static there's tons of choices. Pygments, prism.js, GeSHi for PHP, etc. Any idiot can write a static highlighting system. But none of these can be used in-editor.
For dynamic highlighting, there is only one game in town and that's tmbundles. Only TextMate has support for the 100s of languages in existence, including the new ones that pop up each day.
I would love to replace tmbundles. I know just how to implement it. But the problem is, who is going to write all the long-tail language support? VHDL, Pascal, GAP, AtScript, Julia, ...
- - -
Interesting you mention BBEdit. I have a test file I call "the behemoth" which consists of a python file with 32000 copies of this:
""" """
The challenge is to insert """ at the top of the file and see how the text editor cries in pain. It's torture to a syntax highlighter.
To pass, the editor must
1. Load the file quickly
2. Have smooth scrolling inside the file, even after making the change.
3. Color the quotes properly through the end of the file, before and after.
To my knowledge BBEdit is the only editor to pass the test. Emacs is a good 2nd place.
The rule of thumb is that most languages are rarely used (since there are a finite number of users), so if you support only the most used languages you necessarily drop support for most languages.
Then depending on exactly how popular a language must be to be supported you could end up breaking language support for quite a lot of them.
It's not that people necessarily choose to host portfolios on github, but more that employers will treat whatever's on there under your name as a portfolio regardless.
