Alternation, or brace expansion: https://en.wikipedia.org/wiki/Bash_(Unix_shell)#Brace_expans...
HN user
blaenk
jorge.israel.p@gmail.com • @blaenk • http://www.jip.dev
[ my public key: https://keybase.io/blaenk; my proof: https://keybase.io/blaenk/sigs/L9s0eBs0lnDYIyfgyZbxpmrBNkMBiPlHi6tEUtNcsDg ]
Consider Just-in-Time compilation which is very much used in AOT languages [0]. That could be one avenue, as long as the compiled code works on each machine (common instruction set), or maybe something slightly higher-level like LLVM IR can be produced and transmitted and then compiled on the driver/executor.
Another approach could simply be to transmit the function source to the driver, compile it, then distribute it to the executors assuming they're the same architecture, or compiling it on executors if not.
There are certainly options.
[0]: For example see https://llvm.org/docs/tutorial/BuildingAJIT3.html
I think that's just a matter of how many subdivisions/polygons they decide to devote for those assets. For example, that bucket is pretty inconsequential in the overall scene so they can save some polygons on it, to give more toward something like a character or weapon model that is more prominent, more of the time, since more polygons means higher storage and computational requirements.
Something like tessellation [1] can be used to dynamically tune how many subdivisions to give a model based on certain parameters, such as camera distance.
[1] https://en.wikipedia.org/wiki/Tessellation_(computer_graphic...
I use Iridium for this and other things: https://github.com/ParticleCore/Iridium
I tried setting the Autoplay policy at the browser level once but found that it was inconsistent and broke certain players. Iridium works perfectly.
This one surprises me the most, not the fact that DownThemAll itself isn't WebExtensions compatible, since that was known since last year [0], but that there is a huge gap in download management functionality.
I'm not even asking for all of the functionality present in DownThemAll, I'd just like:
* to be able to queue up multiple downloads without actually starting them, so I can start/resume them once I go AFK for example
* auto-scan all links on the page and be able to filter them to add links to the download queue, e.g. to queue up all files matching a certain filter
* rearrange the queue's order
* persist the queue across browser sessions
* pause any given download and be able to resume it across browser sessions
Meanwhile the usual built-in download functionality nowadays appears to be pitifully bare-bones by comparison, only providing the ability to manually download individual files one by one with no semblance of a queue, nor a way to limit concurrent downloads to one (e.g. I'd rather have one finished and ready to use than 5 downloading slowly due to the connection being spread thin).For what it's worth, thankfully the author of DownThemAll is working on a WebExtensions version [1], which may also get released on Chrome and other WebExtensions-compatible browsers [2].
[0] https://www.downthemall.net/re-downthemall-and-webextensions...
I saw this a while back and it seemed amazing but I was wondering if there's any way to open the actual live documentation page. So for example if you choose the documentation for `Array.prototype.map` then it'll pull up that page on MDN, rather than the locally cached Dash page.
I know the whole point of Dash is to have locally cached, offline documentation copies, but I was thinking it would be amazing to use that to feed Helm candidates, but actually open the real, live documentation page.
You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)
I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise.
An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning.
I suspect this is mainly for Amazon-bought books with highlights stored on Amazon's servers right? Or does this also work with notes made on side-loaded books?
The only ones that ever show are the harbingers of the purported evangelism strike force :)
I'm from/in Southern California and I've never heard it said as "Take 10", but rather as "Take the 10".
I am genuinely surprised to see this on the front page. The author has done amazing work with Emacs packages, such as general.el [ https://github.com/noctuid/general.el ], his Evil guide [ https://github.com/noctuid/evil-guide], and many others.
I used vim for many years and like everyone else in a similar position, none of the touted "vim emulators" came close at all. They would always only cover a very superficial micro-subset of vim functionality, such as some thin approximation of modes and motions.
Inevitably you would come up against a brick wall by doing something which you would otherwise express in vim without giving it a second thought, due to one's fluency, and it would all come crashing down. Once you reach that point, it's very difficult to just "make do" because it becomes blatantly obvious that what you're using is not vim. In such cases I personally would just revert to the stock editor, because I'd rather use the well made stock editor than a half-hearted attempt at vim emulation that would keep me guessing as to whether or not certain functionality I've come to expect was implemented or not.
I used vim for a long time because I truly felt (and still do) that it was the best "editing language" or "interface," as in, the means by which one communicates their intentions to the editor. However, I always felt like it came short in everything else. Options, their names, and their documentation were terse and cryptic. Vimscript felt inconsistent and left something to be desired for me. Overall I _loved_ vim but I felt most people did so _despite_ many failings. When I would see beautifully crafted Emacs packages such as Magit [ https://magit.vc/ ] and how meticulously they were documented [ https://magit.vc/manual/magit/#Top ], I started to become interested in Emacs. The fact that Emacs has a culture of and encourages everything being self-documented is what pushed me over the edge. Every variable, function, keybind, syntax highlighting face, and _much more_ (truly pretty much everything) is and can be documented. Emacs Lisp may not satiate hardcore lispers, but I've found it to be amazingly powerful. I can interactively expand macros to see what's going on at each step with macrostep. There's a built-in interactive debugger. One can "advise" existing functions to add functionality to them (before, after, around, etc.). I've found that the vast majority of package authors are very receptive and accommodating, and in the absolute worst case where they're intransigent or I recognize that it's an edge case that only applies to me, I can confidently, consistently, and safely modify things myself without having to fork the package. I could go on and on.
Admittedly however, Emacs out of the box left a _lot_ to be desired for me in terms of cosmetics and keybinds. It's important to remember that many of the keybinds for example were devised back in a time before the now-more-conventional keybinds became, well, conventional. I knew not to be deterred by that though. IMO, the way to think of Emacs is as a language or REPL with which each person creates their _own editor_, _if_ they want to. I fully expect that if I were to sit at someone else's Emacs setup, they would have vastly different binds and modifications, and _yet_ I would feel confident knowing that I could count upon some core primitives such as describe-key and so on, again due to Emacs' self-documenting nature.
To call Evil a vim emulator or even a port is to sell it short. It continues to blow my mind how amazing Evil is at _being_ vim. I realize it's blasphemous, but I truly believe that it is a _better vim than vim is_. The ease with which anyone can (and does) define new operators, motions, and text objects is breathtaking coming from vim. Likewise, I worried about losing access to many of the vim packages I used. I quickly found that the self-purported "ports" of the packages (such as evil-surround) were actually _much better_ than their vim equivalents! They could be extended and configured in many more ways than their vim equivalents, and they would _compose_ with many other Emacs constructs out of the box. I continue to be amazed.
Despite how great I believe Emacs is, I wouldn't be using it if it weren't for how amazing Evil is. I have come to depend on both, the vim "editing language" and the Emacs environment, but if it came down to it, I would have to choose vim for its editing language.
But it's 2017 and nowadays we can have both. The war is over.
Any reason why you lay blame on Redis and not Gitlab? Gitlab is what's in charge of serving and rendering the pages, after all.
For what it's worth, I've used Rust for years and understand what you're saying and completely agree.
Not since Evil, now it has the world's best editor (vim).
Yeah I'm aware that it's a system call that only knows about file descriptors. It's just that it just now hit me that a consequence of that is that a web server configured to use ssl _and_ sendfile isn't really using sendfile, short of some hairy hack of writing/encrypting the response into a file (maybe in-memory with something like memfd_create) and using sendfile on that, which would defeat the purpose of avoiding user-space entirely.
I hadn't considered this before but it seems to make sense. If I have nginx configured with ssl and sendfile (X-Accel-Redirect) and my app sends an X-Accel-Redirect response to nginx, you're saying that it's not actually using sendfile under the hood?
Out of curiosity, what about it do you think is related?
I completely agree. Perhaps things have changed for some of these plugins since I last tried them, but the only one that has not only basically matched Vim but exceeded it is Evil for Emacs.
Woah I tried it again and it seems like it's working perfectly! It seems like the initial release for windows wasn't compiled with optimizations, so perhaps that's the issue I was observing.
https://www.reddit.com/r/emacs/comments/598iot/on_windows_em...
Indeed that's the one that I used. For some reason, even just moving the cursor around the buffer was extremely unresponsive, it would take seconds for it to register a cursor movement. I'll have to figure out if it's some package I'm using.
Would you mind elaborating on what emacs in particular you're using? I use and love emacs but unfortunately the times I've tried to use it on windows it's been extremely unresponsive.
That's actually a cool idea. IIRC Servo was even (going to?) comply to the chromium embedded framework API/ABI so that it could be a drop-in replacement. If they're doing that, hopefully they'll go further in creating a rich API for embedding.
You should try profiling to see if anything comes out as taking up a lot of resources. `M-x profiler-start`, do some work or type some stuff (if you notice that it's slow), then do `M-x profiler-report` to see if anything in particular is slowing things down. Note though that the part where you type `M-x profiler-report` may sometimes show up in the profiler so ignore that.
See https://www.gnu.org/software/emacs/manual/html_node/elisp/Pr...
It's true that emacs can get pretty slow if you have so many things running that you don't even need. It's also useful to defer packages until you actually need them by using autoloads or if you use use-package, `:defer/:commands/:bind` which create them for you.
For me yanking with `y` copies to my system clipboard. I'm pretty sure this has nothing to do with evil; I think it's an emacs setting. Perhaps one of these?
(setq select-enable-clipboard t)
(setq select-enable-primary t)
See https://www.gnu.org/software/emacs/manual/html_node/emacs/Cl...Location: Los Angeles, CA
Remote: Yes
Willing to relocate: Yes
Technologies: You name it, I'll learn it—well.
- Rust, C/C++, Objective-C, Swift, Java
- JavaScript, Node.js, React
- Ruby & Rails, Python, Go
- Clojure(Script), Haskell
- Machine Learning
Github: http://github.com/blaenkWebsite: http://www.blaenkdenum.com
Résumé/CV: Available upon request.
Email: jorge.israel.p@gmail.com
---
About me:
I always love to learn new and different technologies [0] in order to gain new perspectives on computer science and software development. I don't just skim some "learn x in y minutes" post about some new topic then slap it on my resume and call it a day. I like to derive a deep understanding and discover the best practices by reading books and creating projects.
I enjoy working on every aspect of the stack. For example, I can and will debug with GDB or write bindings if needed [1] but I also enjoy working with the rich front-end ecosystem, such as React.
[0] http://www.blaenkdenum.com/notes/
[1] https://github.com/blaenk/hoedown
While I do love to learn new and different technologies, I do it from a practical perspective of gaining new insights and potentially discovering a better tool for a given job. However, if I need to use something considered "boring" like Java for the job at hand, I'll do so without complaints—I don't get hung up on petty superficial details—and I'll do my best to make useful and lasting contributions with an eye towards solid software engineering and improving the team’s productivity.
---
Recent projects:
* static site generator infrastructure for Rust: https://github.com/diecast/diecast
* React web UI for rtorrent: https://github.com/blaenk/nilla
Slope is more important than Y-intercept.
That's nice :)
Received! Thank you very much!!
I was invited many months ago but I messed up the username. After investigating I realized that there's no way to fix it, and keybase staff says the only way is to delete the account and get re-invited [1].
I forgot to delete the account, but I did so now, so if you're still willing and would be so kind as to try again, I would greatly appreciate it! If not, no problem!
Thanks for the compliment!
If it's not too late and you still have some, any chance you can send me one? would appreciate it!
FWIW, you can do that stuff with helm as well. Except it's C-l to go up a directory by default, IIRC.