It's a library, so only half an answer to your question, but there's a fantastic library called rayon[1] created by one of the core contributors the the Rust language itself, Niko Matsakis. It lets you use Rust's iterator API to do extremely easy parallelism:
list.iter().map(<some_fn>)
becomes:
list.par_iter().map(<some_fn>)
Seeing as in the original example code, the final copies into the minifb have to be sequential due to the lock anyway, all the usage of synchronization primitives and in fact the whole loop could be replaced with something like:
let rendered = buffers.par_iter().map(<rendering>).collect();
for buffer in rendered.iter() {
// The copy from the article
}
I've not written much Rust in a while, so maybe the state of the art is different now, but there are a lot of ways to avoid having to reach specifically for synchronization primitives.
Really cool stuff. I don't like being negative when it comes to fantastic moves like this, but I'm still really disappointed that it doesn't support 64bit executables.
x86_64 have calling conventions (namingly __fastcall) which are more inconvenient to decode than x86 _cdecl or __stdcall where every arguments are passed on the stack. Most symbolic engines usually works only on x86 for the same reason.
I have been doing this for 4 years. I can rent a 16 core server for a couple of years for less cost than a low entry Macbook, with a 1Gbps line. With mosh, I can develop literally anywhere with no lag at all (or at least, no noticeable lag) even with a 3G connection. I can RDP to an EC2 Windows instance when I need a quick Windows machine, again with minimal lag even over 3G.
I sold my desktop, and now use a cheap £200 garbage laptop as a thin-client to my machine. Not only do I get incredible compile performance due to being able to use 16 core Xeon's, but I am not tied to any desktop.
I can whip out my phone and pop open a tmux session from anywhere, in an emergency I can hop onto a friends computer and thanks to SSH 2FA fearlessly login to my dev system with my full environment that I never have to close.
At this point, I would actively avoid jobs that wouldn't let me work this way. Currently got a sweet remote gig and I'm going to fly to Spain next week and spend a couple of weeks coding on the beach with my 3G tethered laptop.
Edit: Just to clarify, I don't need to work in an IDE or use any Windows software that I couldn't tunnel over X. So it might not work for everyone. Just wanted to give an example of it working out great for someone.
Used to use a SoYouStart E5-1650v2 for the 6 Core/12 Hyper-Threads. I moved when I got a sweet server auction deal with two Xeon's but recently moved to Hetzner because the price for their AX50 Ryzen 1700X + 32GB of RAM is hard to beat.
Or underground trains, or long tunnels, or hikes, or many things. Hopefully though the typical developer doesn't spend the majority of his time on an airplane. Me personally, I don't need to be coding so consistently that the loss of a few hours on a plane is going to stop me doing this.
I tried switching to this editor permanently from vim. The selection based movements are asurdly good, I could kill for something like this in vim.
However I couldn't stick with it for two reasons. The first is when I went to figure out how to customise it, I found that the customisation is essentially vim like but weaker. Everything is hardcoded like it would be in vim but with less options. If you're used to Emacs insane customization, this is the other end of the spectrum. The stuff that IS customisable works by executing embedded bash scripts[1]!? You can only embed these in specific hooks and places, so it's really limited, and platform specific. Install this on a system missing a bash feature someone is using and who knows how it'll behave.
Basically, the features implemented are gorgeous, but past that I can't stick with it. Just going to consider trying to port the selection based movements to a vim plugin but I think it'll be a challenge.
Glad to hear you liked the interaction model, may I ask you what kind of options were missing for you ?
The extension model is, I agree, unorthodox, but I think it does work reasonably well (the file you linked manage to provide asynchrounous clang completion and syntastic like diagnostics using it), and keeps things simple. Note that we try really hard only to depends on POSIX tools, so the scripts are actually targeting POSIX shell.
Honestly it's been a little while, I can't remember. However this is more or less why I went back to vim. Your other comment in particular:
> We do not have options for everything, but I'll gladly add more options if there is a reasonable use case for them. In other words, options only get added if someone requests them (and makes a good case for them).
I don't really want to switch to an editor where missing options might have to be justified. I'm not knocking your work, it's really good, and my complaint applies to vim as well. But if I can't implement something myself as an add-on (which I definitely have more power to do in vim) and have to wait for it to be patched and released in your release cycle I'd rather just try and implement your features in vim and keep the customisability.
Having said that I could be wrong and maybe the plugin system is more powerful than I thought. But as an example, I have a 5 line function letting me have ctrl-p like functionality backed by fzf in vim. I can't figure out how I would do that in kakoune at all.
Thanks a lot for you reply, I try to be reactive to feature requests, especially easy ones like making something configurable through an option (I expect most of these to be resolved in a day or so).
Some people are using kakoune with fzf, using tmux to open a split, which is very simple to implement with fzf-tmux. Interacting with Kakoune interface ought to be possible but possibly more tricky.
Yeah, I can't see how I would do it. I could open a tmux pane with fzf and run another kak window but that's not really the goal. I'd like to use fzf to open a found file in the current kak window. The plugin architecture just really limits this kind of thing, and this fzf example was just a simple one I wanted to use to demonstrate the point.
But again, the stuff you have in this editor is absolutely fantastic, really, I can't say that enough. I just personally find kak less flexible than an already inflexible vim so I couldn't stay with it.
If you have a way to do the fzf example though I'd be curious to see how you do it.
Its more tricky if you do not use tmux, as due to Kakoune client/server nature, fzf will be launched by the server, which might not even have a terminal. That said I really enjoy fuzzy matching, and most built-in completions do fuzzy matching already.
Thanks again for giving feedback on your experience with Kakoune, always much appreciated !
I think having to remap your systems keyboard to something other than your native language in order to use an editor is a bit unreasonable.
Typing accented characters is far easier in Spanish with a Spanish layout, that we all grow up with. The software shouldn't just ignore half the planet on the basis of "use English".
I'm not sure if I follow, I don't see what the benefit is in defining an authentication protocol like this based on passwords. If websites are going to actually work with this protocol, why not use public key authentication or any of several other existing authentication protocols. Maybe I'm missing something, but unless this somehow eases the distance between password based authentication and other methods then it seems kind of like trying to shuffle our human password schemes into a protocol where details like a unique password shouldn't need to matter anymore anyway.
> Maybe I'm missing something, but unless this somehow eases the distance between password based authentication and other methods
Spot on.
PKI would be a good endpoint, but adoption is slow, probably because it's a weird leap for a lot of people. So I see this as a transitional step, a methadone for our addiction to passwords, because it could get people used to passwordless logins. It could help people adapt to a service or dongle that handles all their authentication. After that, it's a short hop to have PMs just become "authentication providers," and have them and websites figure out the best backend.
Thanks though, it's a fair point to keep in mind, PKI might even be worth holding up as the ideal in the protocol.
This is awesome! I recently read this ticket[1] mentioning that porting of µBlock seems to be a starting point for gorhill to port µMatrix. In my perfect world, I would be using Firefox with nothing but µMatrix, as it is right now I'm having to use Chrome with µMatrix and sadly can't get rid of µBlock until µMatrix can hide blocked frames. Still, getting closer to that perfect world! The work done by gorhill is amazing.
This and the paper above were extremely entertaining reads. To the point that I am downloading CHICKEN right now to start exploring. Thank you for those links.
Trying this out now, It's actually pretty nice. I get that It's a visual editor that uses Markdown as a storage format, but it still would be nice if it would actually let me type Markdown - interestingly it seems to be pretty indecisive on whether or not I should be able to that.
I can type a # and it will automatically turn the text into a Title which is nice, but any other Markdown-like syntax is printed verbatim, which is odd because when I save and reload it will suddenly render it as Markdown just fine.
If I could write Markdown in this and had some way to refresh the editor to visualize it as an alternative to the insert bindings, personally I'd be sold on this for sure.
