As a theoretical physicist, the iPad can handle work-related tasks that the MacBook cannot (and vice versa). The unique iPad features mostly center around the Pencil: annotating papers, and doing "pen-and-paper" math, except that the iPad is far superior to pen and paper (you can move things around and "re-edit" them). Actually, the iPad can handle most things the I generally prefer the MacBook for (programming and writing, mostly), but there's usually some hoops to jump through. But it's certainly good enough that when I travel, I usually only take the iPad.
I absolutely prefer to have a larger external screen, too. But if I'm traveling, and the choice is between my 13 inch Macbook Pro, or the 12.9 inch iPad Pro, I usually choose the iPad. With Blink in full screen, it's basically the same as iTerm on the Macbook, but much more portable (and I can do things on the iPad I can't do on the Laptop: Apple Pencil & Goodnotes)
In particular with Blink, the app will actually recognize the monitor as a second screen, and use it at full resolution (as opposed to mirroring the normal iPad screen). With tmux, this means you can arrange as many horizontal and vertical splits as you can fit onto the monitor.
This is so, so close to allow me to run a full local vim (with the necessary external tools, like python and git). The only thing I found that was a dealbreaker was the lack of unicode support (https://github.com/tbodt/ish/issues/28), and not being able to map caps-lock to escape.
For now, Nicolas Holzschuch's fork of iVim (https://github.com/holzschu/iVim) is still by far the best solution, but iSH definitely has the potential to take over.
The last one in that thread is 11 minutes. And, I just did `time conda create -n test -y anaconda pytest-cov pytest-xdist coverage sphinx_rtd_theme flake8` on my Macbook, and it clocked in at 36 minutes! Probably, this is affected by also having the condaforge channel active (which I need), but it's definitely not from some network/VPN issues. Everyone I work with has similar problems. So don't tell me there's "absolutely no chance that is from normally executing conda".
Yeah, this is becoming a real problem. This didn't use to happen, but now conda is slow to the point of being unusable if you need to create environments a lot (like during testing)
Since we're talking about coffee shops: the Starbucks app allows to add a tip for a certain period of time after a a mobile order (something like an hour)
Would it really be POSIX-incompatible? Does the standard mandate that a filesystem can place no such restriction on top of "filenames are unencoded bytes"? If not, then it's just that tools cannot blindly assume filenames are decodable. Isn't MacOS guaranteeing UTF8 these days, while still being POSIX-compliant?
I have some projects where the continuous-integration-testing with Travis requires a tex installation. More than 50% of the entire test run is spent installing texlive-full (since Travis doesn't seem interested in including latex in their standard environment). Maybe TinyTeX will be able to speed this up?
Do most laptops that people currently get to run Linux, like the Dell XPS or the Thinkpad X1 have a touchpad that support multi-finger-gestures that could be configured with this? If I ever were to switch from a MacBook to a Linux machine, I’d definitely be very interested in having the equivalent of BetterTouchTool for custom gestures in applications (assuming the hardware supports it)
I find that with anything where I feel I have to "start over" every time I try to get back into it, the solution is to consciously memorize the key points and the notation of anything I'm learning, using (Anki) flashcards. Michael Nielsen recently wrote a great overview of the process recently: http://augmentingcognition.com/ltm.html
Making sure the basics stick in long-term memory, you can then build on that anytime in the future without having to review everything.
Will this include an iOS app? This would be interesting on an iPad (although competing against GoodNotes will be tough). On a laptop, I haven't come across anything besides maybe a Surface Book for which there is a suitable input device for handwriting.
Goodnotes is amazing, but there's a couple of features listed on this "Styles Lab" page that it still could implement. Links/bookmarks would be at the top of my list.
Can you elaborate on that? Is there a blog post somewhere that illustrates the problem you're talking about? I was under the assumption that Python interpreters run single-threaded.
The GIL has considerable benefits: I don’t have to worry about whether Python functions are thread-safe. Thread-based parallelism is hard to get right, and given the number of workarounds, Python’s GIL is a total non-issue.
While there is a "suitesparse-5.2.0" package in conda, I haven't found any documentation. Do you have a link? There doesn't seem to be anything on the project website. I wasn't even quite sure this contains a Python package.
A good sparse matrix implementation is key to any serious numerics. SciPy's implementation is very nice and quite complete, and a foundation for the entire scientific Python ecosystem. Unfortunately, though, many of the low-level sparse operations are not implemented very efficiently, which has lead to some projects having to do their own implementation, see e.g. this discussion for the QuTiP project:
https://github.com/qutip/qutip/issues/850#issuecomment-38400...
It would be really nice if all of the sparse linear algebra in SciPy could be heavily optimized (to a similar extent as e.g. Intel optimizes their sparse operations in MKL), so that the entire ecosystem could benefit from that. This is probably something that would require some corporate support, but given how many data science and finance companies use Python for their workflow these days, it might be a wise investment.
I guess a good alternative is to have the build tools refuse to do anything until the user/developer has installed the proper hooks by running ./init-hooks (as opposed to executing ./init-hooks silently in the background). I agree that's a preferable way to do it in a public project: explicit is better than implicit
I don’t see your point. By definition, the build scripts that are part of the repo always execute arbitrary code (e.g. any line in the makefile). Interacting with any compromised repo is always a security risk. Granted, my approach is a bit hacky, but it’s not even modifying anything outside of the checked out folder!
Something I've done on some projects is to install (or check) the hooks as a side-effect of a script that any contributor is guaranteed to run. In my case, `./configure`. The Makefile would be another place for this (`make test`). It just copies the hooks from `.hooks` to `.git/hooks` and chmods them to be executable. This solves the problem of contributors (or myself) forgetting to set up the proper hooks in every checkout, and it's very low-maintenance.