Ok you meant async/await. I googled a bit
Node.js added async/wait in v7.6.0, which was released on 2017-02-21.
Python added async/await in v3.5, which was released on 2015-09-13.
> anyone care to actually provide an example of something Python is better at rather than just downvoting me for giving my opinion on request?
JS numbers aren't really integers - they're doubles. They're inaccurate when dealing with numbers greater than 2^53. Meanwhile, Python uses built-in bigints to provide accurate support for integers of any size. I enjoy solving problems on http://projecteuler.net, and I greatly prefer a language which frees me from worrying about whether I'm hitting a hidden integer ceiling. I'm sure JS has bigint libraries somewhere, but I chose Python because it lets me just solve these problems.
JS> x = Math.pow(2, 55)
36028797018963970 # power of 2 that’s divisible by 5?
JS> x + 1
36028797018963970 # same number?
Python> x = 2**55
Python> x
36028797018963968
Python> x + 1
36028797018963969
It's hard to tell if you understand the difference based on this answer, but real threads in Node use this API. Quick and easy way to tell if you understand:
If you run one of your CPU-intensive Node JS process and look at it in top
, does it ever get more than 100% CPU utilization?
I'm not sure exactly what you mean here when you say I'm mixing WebSockets with async. My original comment actually referred to gRPC because we used to be on that instead of WebSockets. The IPC protocol is irrelevant. What I mean when I'm referring to asynchronicity in this context is the ability to effectively do the following:
socket.on('message', async message => {
// ... route and determine how to respond to the message ...
await bindings.intensiveTask(); // does not block the API thread; thread is free to receive more messages
});
Now, this does rely on the bindings being written in such a way that they will not block. I'm sure Python has a way to deal with this (having multiple threads listening maybe? not sure exactly), but I really doubt it's as pleasant as the above, and in any case, if your bindings are forcing you to be sychronous and there's no way around it for whatever reason, you can just run multiple copies of the Node process or run a cluster, which is basically the same story as Python.
You can move it if you move the window right while at the top edge and the resize icon appears. It is a bit tricky but works. Or you can have something like spectacle (https://www.spectacleapp.com/) to do window management.
Oh. I am using a beta version of iterm 2 which has a theme mode called minimal. It basically makes the title bar the same color as your theme similar to how hyper.js terminal looks https://www.iterm2.com/3.3/documentation-preferences-appearance.html
That sounds messy.
I am pretty sure you would have heard about this, but just in case. You might wanna check out flux . Don't know if it will help or not, it kinda does help me at times.
Hey mate, your theme is very beautiful I really love it and I am considering getting it.
However I just have a question. How come you are using tint2 though, cause it seems like it is not even supported anymore since 2016:
The font is Space Mono, the best code font ever I ever saw! Turn off font ligatures or things like </
in HTML will become ↙
, unless you like that.
Looks like Kotlin supports <code>break</code> and <code>continue</code>.
I don't know much about Kotlin, but it looks as if you can simply write a function which runs your OpenCV pipeline and check for waitforstart()
and when its called, simply break your loop.
It's this fontconfig configuration, which mixes original Terminus for regular font with NerdFont variant and Noto Color Emoji as fallback for Unicode, plus IBM Plex Mono for italics. It works on Alacritty.
Not really. That's a very specific meaning of async.
It could just as easily have been
socket.on('message', message => {
bindings.intensiveTask().then(result => {
// ...
});
});
or even
socket.on('message', message => {
bindings.intensiveTask((err, result) => {
// ...
});
});
All three work the same in practice, and the core concept (most easily described with the last "callback style" example) has been around since Node's inception (it's actually the basis of why Ryan Dahl decided to make a Node runtime), or since at least extremely early in JavaScript (like, before Y2K early, possibly since the very first release but I'm having trouble finding information) if you count stuff like DOM handlers. async/await
is basically just syntactic sugar for the first (promise based) one. Promises are somewhat newer, but the point here is really that the event loop is built into the language. Python's asyncio is definitely nice, and actually resolves a good amount of the issues I have with the language, and it even has C++ style (needs to be synchronized, etc.) multi-threading support which Node doesn't have natively quite yet.
I actually used infinality for better font rendering but yes to be honest the I couldn't see much difference but just thought I should let you know.
http://www.webupd8.org/2013/06/better-font-rendering-in-linux-with.html?m=1
Ahh well there certainly are benefits to an IDE there you're missing out on if you switch over to vim. Vim does have the thing you're talking about in the form of a plugin (https://github.com/junegunn/fzf), but it definitely isn't exactly like the global project text search that VS Code offers. I think they're both great, but I guess it's a matter of preference.
I'm not making a case for Vim over VS Code. There are certainly things I'm sacrificing leaving VS Code (such as its amazing Git Diff tool), but with respect to my own personal style of development Vim just makes more sense. Use the tool that best suits you :]
edit: a word
I have MacVim installed, but that's just so I get a more up-to-date version of the terminal Vim, which I use in iTerm.
I used to be a tmux person, but then I found Amethyst, which lets me do window tiling on the Mac desktop. So now I just open multiple iTerm windows and tile them how I like instead of using tmux in a single terminal window.
It may be slightly more resource heavy doing that, but tmux gave me a lot of issues with terminal and Vim color schemes, and then one time it just up and died after an upgrade, so I never went back to it.
Also, as others have said, MacVim and Neovim are not equivalent. MacVim is a GUI on top of regular Vim to work outside of the terminal, but Neovim is a fork of Vim that has a different feature set. It typically works inside of a terminal, but I think there are GUIs available for it.
Last I read on the situation was this in 2017 https://github.com/kovidgoyal/kitty/issues/84 and switched to Alacritty soon after, but Kitty has better opacity support (Alacritty gets weird artifacts (https://github.com/jwilm/alacritty/issues/889) so I'm tempted to switch back to Kitty.
I have hide_window_decorations
set to true, but my kitty version might be a bit old by now.
Coc needs hidden
set. I use
nmap <silent><TAB> :CocList buffers<cr>
to quickly jump between buffers (https://asciinema.org/a/dY29dS98VJzZ6O42zYyZiKxlY) . Wipeout is for cleaning up the session and removing all buffers not displayed.
neovim 0.5.0
terminus
and icons from nerd fonts and it's combined with not very simple fontconfig
Basically, the gist of it is:
Define highlight group for the colors you want for sections you want i.e. highlight [Mode]Color guifg=[color] guibg=[color]
Define 2 functions for an active state and inactive state of the statusline i.e. function! ActiveStatus()
and function InactiveStatus()
For the dynamic mode color, let statusline.="%#[Mode]Color#%{(mode()=='n')?'\ \ [MODE]\ ':''}"
See :h mode
for other modes and :h statusline
for other elements that can be added
Define autocmds to switch between the two States when you exit/enter windows i.e. autocmd WinEnter,BufEnter * setlocal statusline=%!ActiveStatus()
Finally set statusline=%!ActiveStatus()