In the last years I've been asked multiple times about the comparison between raylib and SDL libraries. Unfortunately, my experience with SDL was quite limited so I couldn't provide a good comparison. In the last two years I've learned about SDL and used it to teach at University so I feel that now I can provide a good comparison between both.
Hope it helps future users to better understand this two libraries internals and functionality.
| [Unit] | |
| Description=Clash service | |
| After=network.target | |
| [Service] | |
| [Service] | |
| Type=simple | |
| StandardError=journal | |
| User=clash |
| Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
| ActivityTweet | |
| generic_activity_highlights | |
| generic_activity_momentsbreaking | |
| RankedOrganicTweet | |
| suggest_activity | |
| suggest_activity_feed | |
| suggest_activity_highlights | |
| suggest_activity_tweet |
First off, thanks for all the comments and kind words on the original writeup; I've been meaning to follow up on some of the suggestions and write about the different ways to represent monads (and functors, HKTs, etc) that now exist, but a month of being busy has kind of gotten in the way (mainly with three new kittens!).
And for sure, I do not expect (nor do I want) this to become the norm for production-level Rust: rather, I hope that this can contribute to the foundations of programming with higher-level abstractions in Rust, somewhat like how early template metaprogramming in C++ and typeclass-constraint-unification metaprogramming in Haskell have contributed, perhaps indirectly, to later innovations in their respective languages and ecosystems that were much more reasoned, sound and usable.
One of the things suggested in the com
Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
numext https://github.com/yangby-cryptape/rust-numext @ f7279be
ethereum-types https://crates.io/crates/ethereum-types 0.4
bench_ser_numext_h256 time: [62.599 ns 63.126 ns 63.872 ns]
bench_ser_ethereum_types_h256
$ echo 'gem "webpacker"' >> Gemfile
$ bundle install
$ rails webpacker:install
$ yarn add bootstrap@4.0.0-beta jquery popper.jsdiff --git a/config/webpack/environment.js b/config/webpack/environment.js
index d16d9af..86bf1a7 100644
| extern crate ring; | |
| use ring::aead::*; | |
| use ring::pbkdf2::*; | |
| use ring::rand::SystemRandom; | |
| fn main() { | |
| // The password will be used to generate a key | |
| let password = b"nice password"; |
Using perf:
$ perf record -g binary
$ perf script | stackcollapse-perf.pl | rust-unmangle | flamegraph.pl > flame.svg
NOTE: See @GabrielMajeri's comments below about the
-goption.
Within GitHub it is possible to set up two types of SSH key - account level SSH keys and and repository level SSH keys. These repository level SSH keys are known in GitHub as deploy keys.
Deploy keys are useful for deploying code because they do not rely on an individual user account, which is susceptible to change, to “store” the server keys.
There is, however, an ‘issue’ with using deploy keys; each key across all repositories on GitHub must be unique. No one key can be used more than once. This becomes a problem when deploying to repositories to the same server with the same user. If you create two keys, the SSH client will not know which key to use when connecting to GitHub.
One solution is to use an SSH config file to define which key to use in which situation. This isn’t as easy as it seems.. you might try something like this:
| <%# Put this code snippet between the <head></head>-tags in your application layout and %> | |
| <%# replace 'UA-XXXXXXXX-X' with your own unique Google Analytics Tracking ID %> | |
| <%# ... %> | |
| <head> | |
| <%# ... %> | |
| <% if Rails.env.production? %> | |
| <script type="text/javascript"> | |
| (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ | |
| (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), |