FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
| { | |
| "AWSEBDockerrunVersion": "1", | |
| "Image": { | |
| "Name": "<AWS_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/<NAME>:<TAG>", | |
| "Update": "true" | |
| }, | |
| "Ports": [ | |
| { | |
| "ContainerPort": "443" | |
| } |
Availability and quality of developer tools are an important factor in the success of a programming language. C/C++ has remained dominant in the systems space in part because of the huge number of tools tailored to these lanaguages. Succesful modern languages have had excellent tool support (Java in particular, Scala, Javascript, etc.). Finally, LLVM has been successful in part because it is much easier to extend than GCC. So far, Rust has done pretty well with developer tools, we have a compiler which produces good quality code in reasonable time, good support for debug symbols which lets us leverage C++/lanaguge agnostic tools such as debuggers, profilers, etc., there are also syntax highlighting, cross-reference, code completion, and documentation tools.
In this document I want to layout what Rust tools exist and where to find them, highlight opportunities for tool developement in the short and long term, and start a discussion about where to focus our time an
| use std::comm::{Receiver, channel}; | |
| use std::io; | |
| use std::mem::replace; | |
| use std::task::spawn; | |
| struct Future<'a, A> { | |
| state: FutureState<'a, A> | |
| } |
| ./configure --c-compiler=clang --cpp-compiler=clang \ | |
| --flags="-stdlib=libc++" \ | |
| --ldflags="-stdlib=libc++" \ | |
| --raw-cmake-args \ | |
| -DCMAKE_C_COMPILER=/usr/bin/clang \ | |
| -DCMAKE_CXX_COMPILER=/usr/bin/clang \ | |
| -DPYTHON_INCLUDE_DIR=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/include/python3.4m/ \ | |
| -DPYTHON_LIBRARY=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/libpython3.4.dylib \ | |
| -DPython_FRAMEWORKS=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework \ | |
| -DOPUSFILE_INCLUDE_DIR=/usr/local/Cellar/opusfile/0.6/include/ \ |
| [Unit] | |
| Description=App Redis Sidekick | |
| Requires=docker.service | |
| Requires=etcd.service | |
| After=docker.service | |
| After=etcd.service | |
| After=app-redis.service | |
| BindsTo=app-redis.service |
**~~ NOTE: This is a Stage 0 proposal. ~~**
Please direct all future feedback to that repo in the form of directed issues.
| #[feature(asm, macro_rules)]; | |
| extern crate test; | |
| use test::BenchHarness; | |
| static whitespace: &'static [u8] = bytes!("\r\n\t \0 "); | |
| #[inline(never)] | |
| fn has_space_sse(s: &str) -> bool { |
| M[16],X=16,W,k;main(){T(system("stty cbreak") | |
| );puts(W&1?"WIN":"LOSE");}K[]={2,3,1};s(f,d,i | |
| ,j,l,P){for(i=4;i--;)for(j=k=l=0;k<4;)j<4?P=M | |
| [w(d,i,j++)],W|=P>>11,l*P&&(f?M[w(d,i,k)]=l<< | |
| (l==P):0,k++),l=l?P?l-P?P:0:l:P:(f?M[w(d,i,k) | |
| ]=l:0,++k,W|=2*!l,l=0);}w(d,i,j){return d?w(d | |
| -1,j,3-i):4*i+j;}T(i){for(i=X+rand()%X;M[i%X] | |
| *i;i--);i?M[i%X]=2<<rand()%2:0;for(W=i=0;i<4; | |
| )s(0,i++);for(i=X,puts("\e[2J\e[H");i--;i%4|| | |
| puts(""))printf(M[i]?"%4d|":" |",M[i]);W-2 |
The core problem with UI rendering boils down to these two questions:
There are several implementations that can tell you what has been changed, some of which are:
