shafte
Joined 9 years ago
Karma
387
Submissions
37
Member since
Mar 1
Recent submissions
Comment · 3 years ago
Comment · 6 years ago
I'm curious: what's sorts of things were bad about libtorch? What did you see in this release that you thought was an improvment?
Comment · 6 years ago
That doesn't seem very fair. They link a docs folder and an overview document, neither of which require that the user read code to get a good idea of the library's contents.
That said, the code is also reasonably well commented as well, for example: https://github.com/facebook/folly/blob/master/folly/Singleto.... So "read the code" is not terrible advice in this case either.
Comment · 6 years ago
Perhaps you missed the "What's in it" section while skimming the readme? :)
>Because of folly's fairly flat structure, the best way to see what's in it is to look at the headers in top level folly/ directory. You can also check the docs folder for documentation, starting with the overview.
Comment · 6 years ago
EternalTerminal[1] was mentioned in a comment below. It supports port forwarding, and other goodies like native scrollback, at the cost of latency on laggy connections (because it doesn't do full terminal emulation). If that tradeoff sounds good to you, try it!
Comment · 7 years ago
Watch David's talk coming up (https://www.facebook.com/pytorch/), it will contain some answers :)
Comment · 7 years ago
Aside from its merits as a database, SQLite is also a great example of good documentation[0], thorough testing[1], and focused development. It's something that all library maintainers should study and try to learn from.
Comment · 7 years ago
I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit.
For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.
Comment · 7 years ago
Not really related, but a quick plug for the work that Mercurial is doing to port substantial portions of its main binary to Rust: https://www.mercurial-scm.org/wiki/OxidationPlan
My understanding is that they want to get it fully ported before Python 2 EOL.
Comment · 7 years ago
This is so awesome. Makes me really excited for the future of PyTorch—being able to define symbolic deriviatives in a python subset is super cool
Comment · 7 years ago
The best explanation is coincidence, I think. I have direct knowledge of two of the incidents in the past few weeks, and they have completely unrelated causes.
Sometimes you just get unlucky!
Comment · 7 years ago
I think it's cool to see projects like this! It's sort of like an "alternate history" for a C++ programming model. I agree that it doesn't seem immediately useful for most projects, but that's okay :)
I hope the author publishes more explaining some of the architecture and design choices and how they diverge from what the rest of the community has come up with. At the very least it will be an interesting comparison.
Comment · 7 years ago
Glad to see the team really embrace the nitty-gritty of keeping the open-source community healthy. React Native is a project with a lot of potential that's taken a few high-profile lumps this past year. Being an OSS maintainer can be difficult and thankless sometimes, but it's good to see teams that recommit to open source instead of withdrawing and focusing solely on internal needs.
This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.