182 karma · joined September 27, 2012
Tried Safari, it's working as well.
Anyone else really impressed by their development speed? I've not used Go and following someone else in an editor can be difficult, but it took me some effort to keep up: you guys never slowed down for nearly two hours!
Did you ever find out why ip.appspot.com yielded "Bad Request"?
One more thing: Developers using IO instead of Node are,
well, not invited.
“IO.js, what’s that?” asked Joyent CEO Scott Hammond in
response to my query about whether projects based on the
fork would be able to enter. “This is a Node.js project
for Node.js innovations.”
I'm not sure I can take the criticism seriously after seeing the source.Unfortunately, analyzing symphony caused an HHVM segfault. =( I'm not sure it's the same issue, but this happened to me before: https://github.com/facebook/hhvm/issues/4363
This was a good exercise: I was happy to see that hussar adapts pretty easily to outside projects. Basically, I ended up doing this:
$ git clone git@github.com:Wordpress/Wordpress.git
$ cd Wordpress
$ ~/hussar/bin/make-report
There were one or two hiccups that required some manual changes to the scripts; I'll get fixes for these up soon.The project is on github if you want to skip the blog post: https://github.com/wayfair/hussar
Happy to answer any questions!
foo bar baz buz qux pip pop tut rof art uff dex dom zedSomething to think about: if I write a program that outputs a work under copyright (without actually containing the copywritten work), can I still use a permissive license?
When the source itself is available, why not just read the code? I understand using articles and documentation to get the high to mid level view, but why not go to the real source of truth if it's available?
Still, I'll take the documentation. :)
The implementation probably just involves walking backwards through history until you reach the initial commit, maintaining a bidirectional linked list as you go.
Github already allows users to walk forward and backward though history via the commits page[0]. It seems reasonable to provide the same "Newer", "Older" buttons when viewing an individual commit.
[0]: https://github.com/torvalds/linux/commits/master?page=1
The trouble is, for many projects claiming to start from scratch, the "Initial commit" includes hundreds or thousands of lines of code. The practicality of learning this way is very much dependent on the author/committer making digestible, incremental commits and maintaining a linear history.
Thanks for making this!
Your main point stands though: all major editors have the ability to add plugins to achieve this same functionality.
[1]: http://semver.org/
Major releases break the API, so programs that depend upon them may not work. Minor releases add or improve features while preserving existing functionality. Patches fix bugs.
This is exactly why having version numbers is important. Even if the number becomes arbitrary, it's existence is necessary to build dependency trees.
Aside: I'm not certain, but it seem as though Firefox does have a major.minor version scheme: my user-agent reads "Mozilla/5.0 ... Firefox/25.0"; Firefox 5.25 is probably the most correct.
I have just two bars[2] for either browser, enough real-estate for me (wish I had a high resolution though).
[1]: https://support.mozilla.org/en-US/kb/pinned-tabs-keep-favori... [2]: http://i4.minus.com/i4lX5yMWuwoGi.png
This appears to be a helpful article: http://tangledhelix.com/blog/2012/07/16/tmux-and-mouse-mode/