"Немножко Финляндии" (Куприн)
Oct. 21st, 2012 07:48 amЭлементарно: уважение.
"Мне кажется, можно смело предсказать мощную будущность тому народу, в среде которого выработалось уважение к ребенку".
Вот с этого и начинать.
alexo@euromake:/tmp/and$ cat and.c
void *
true_(x, y)
void *x, *y;
{
return x;
}
void *
false_(x, y)
void *x, *y;
{
return y;
}
void *
bool_[] = {false_, true_};
void *
and(x, y)
void *(*x)(), *y;
{
return x(y, x);
}
main(argc, argv)
char *argv[];
{
int x = argv[1][0] - '0';
int y = argv[2][0] - '0';
return (true_ == and(bool_[x], bool_[y]));
}
alexo@euromake:/tmp/and$ cat Makefile
all: and
./and 0 0; echo $$?
./and 0 1; echo $$?
./and 1 0; echo $$?
./and 1 1; echo $$?
clean:
-rm -f and
alexo@euromake:/tmp/and$ make
cc and.c -o and
./and 0 0; echo $?
0
./and 0 1; echo $?
0
./and 1 0; echo $?
0
./and 1 1; echo $?
1
alexo@euromake:/tmp/and$ aord построим алгоритм слепого копирования агентов, такой, что для данных α, β из набора {γ, δ} на месте β оказывается тот же тип агента, что и у агента α (пусть данная задача послужит несложным упражнением читателю). Копирование агентов γ* и δ* тривиально. Поясним, что копирование необходимо при дублировании (элемент списка D), для чего требуется преобразовать оба освобождаемых после аннигиляции агента (элемент списка A) неизвестных типов, в общем случае, в неизвестные типы.
aord. Она во многом похожа на механизм транскрипции в биологии (процесс синтеза РНК с использованием ДНК в качестве матрицы).

altsoph @ 2012-08-13 09:41:00:
Мэтью Генри aka P01 сделал JS-браузерную дему MATRAKA с 3D-графикой, музыкой и текстом, которая представляет собой 1K PNG-файл, самораспаковывающийся в JavaScript-код:
А кроме того:
Что еще почитать:
И, да, все ссылки работают у меня в Хроме, на кроссбраузерность не проверял.
— Так… Товарищи! У нас сегодня диспут! На любую тему. Столкновение разных мнений. Утверждение! Возражение! Вот вы, гражданин из первого ряда… Идите сюда! Подойдите! О чем вы хотели бы поспорить?Жванецкий
— Я?
— Да, вы. Именно вы! Я вчера с вами говорил. Вы были таким темпераментным, запальчивым. Вот теперь здесь, на сцене, попробуйте отстоять свое мнение. Покажите, как это делается! Итак, что вам не понравилось?
— Где?
— Вчера. Вам что-то не понравилось. Вы спросили.
— Мне все понравилось. Я еще вчера говорил, что мне все понравилось.
— Ну, это не разговор. Вот, к примеру, мне не нравится ваш галстук!
— Мне тоже! (Сорвал, выбросил.) Тряпье!
— Ну, постойте… Вы не понимаете. Это диспут. А диспут — разговор, где сталкиваются разные мнения. То есть если я «за», вы должны быть «против». У нас должен быть спор, понимаете? Я считаю, что в семье должен быть один ребенок. А вы возражайте!
— А я считаю, что и одного много.
— Нет, вы возражайте!
— Я возражаю!
— А вы возражайте.
— Я возражаю!
— Вот. (После паузы.) Вот. Почему вы возражаете?
— Я возражаю.
— Почему?
— Я возражаю.
— Нет, но почему?
— Я возражаю.
— Это хорошо. Но почему вы возражаете?
— Я возражаю.
— Нет. Вы так просто не возражайте. Вы должны говорить — два.
— Два.
— Вот. (После паузы.) А я считаю, один.
— И я считаю, один.
— Вы же говорили, два.
— Два.
— Вот. (После паузы.) А я говорю, один.
— Два.
— Вот. (После паузы.) А я говорю, один.
— Два.
— Вот видите, уже спор. А я говорю, один.
— Два.
— Вот, чудно. Так что я говорю: один.
— Два.
— Так, один.
— Два.
— Один.
— Два.
— Ну, спорьте, спорьте… Один.
— Два.
— Ну, вы спорьте, возражайте… Один.
— Два.
— Один.
— Два.
I should have learnt this before.
Let us suppose you have just made a pull request with about twenty commits: something borrowed, something blue, and something from Linus. Say, few commits have typos in their commit logs, few should have been merged into a single one, some should have been removed, a couple of them are so huge that you should split them into several ones, and except, maybe, one lucky change, the rest is to be completely rewritten.
In GitHub, it is however not common practice to deal with pull requests that way. After a pull request has been reviewed, it usually happens to be appended with nearly as many commits as in the original pull request. When the pull request has finally been merged, this in turn makes the master branch contain almost nothing but garbage.
Reviewing patch series and making the developer redo all the stuff from the very beginning, probably several times, might look as inapplicable approach to deal with pull requests. Besides, it does not guarantee the master branch not to contain any garbage. Of course, it is not a silver bullet. Nevertheless, it does help avoid more than 90% of junk, keeping the master branch log much more clear. That appears to be really helpful when you deal with a bug using git-bisect(1).
There exists at least the following scheme which makes GitHub-style pull requests do the trick, quite close to reviewing patch series in LKML.
bug2645 to master.git branch bug2645-backup bug2645 just in case.git rebase -i master (edit and squash), git reset HEAD^ (splitting commits), git add -p wtf.c (s and e), and git stash -k (test results before committing) to address the comments from the review.git push -f origin bug2645 and start from the very beginning.
This scheme has been tested on an artificial task simulating huge and ugly patch series. Specifically, we cleared the master branch, and pretended that its backup is the development branch far away ahead of master. Then, we agreed on the rules to write commit logs in a different manner than it was before. Namely, all commit logs should have the form of 2645: update time stamps in msync(), where 2645 is the number of an issue on GitHub which corresponds to the applied changes. This way, one can always track which exactly bug implied each particular commit.
So, give it a try!
From the Preface
Have you ever...
- wasted a lot of time coding the wrong algorithm?
- used a data structure that was much too complicated?
- tested a program but missed an obvious problem?
- spent a day looking for a bug you should have found in five minutes?
- needed to make a program run three times faster and use less memory?
- struggled to move a program from a workstation to a PC or vice versa?
- tried to make a modest change in someone else's program?
- rewritten a program because you couldn't understand it?
Was it fun?
These things happen to programmers all the time. But dealing with such problems is often harder than it should be because topics like testing, debugging, portability, performance, design alternatives, and style -- the practice of programming -- are not usually the focus of computer science or programming courses. Most programmers learn them haphazardly as their experience grows, and a few never learn them at all.
In a world of enormous and intricate interfaces, constantly changing tools and languages and systems, and relentless pressure for more of everything, one can lose sight of the basic principles -- simplicity, clarity, generality -- that form the bedrock of good software. One can also overlook the value of tools and notations that mechanize some of software creation and thus enlist the computer in its own programming.
Our approach in this book is based on these underlying, interrelated principles, which apply at all levels of computing. These include simplicity, which keeps programs short and manageable; clarity, which makes sure they are easy to understand, for people as well as machines; generality, which means they work well in a broad range of situations and adapt well as new situations arise; and automation, which lets the machine do the work for us, freeing us from mundane tasks. By looking at computer programming in a variety of languages, from algorithms and data structures through design, debugging, testing, and performance improvement, we can illustrate universal engineering concepts that are independent of language, operating system, or programming paradigm.
This book comes from many years of experience writing and maintaining a lot of software, teaching programming courses, and working with a wide variety of programmers. We want to share lessons about practical issues, to pass on insights from our experience, and to suggest ways for programmers of all levels to be more proficient and productive.
screen(1) при входе в систему. Мне нужно еще перенаправлять порт, чтобы легче тестировать Web-приложение, так что к файлам с ключами добавился и config с соответствующими строчками.А вот этого я уже в других языках программирования как-то не видал. Эдакая «лиспо-лямбда» получается:
alexo@codedot:~$ wscat -c ws://localhost:8080/ connected (press CTRL+C to quit) < (function () { socket.say = function(data) { data = JSON.stringify(data); this.send(data); }; })(undefined) < (function () { socket.say("Hello World!"); })(undefined) > "Hello World!" < (function (data) { window.alert(data); })("Hello World!") disconnected alexo@codedot:~$
Кстати, wscat вчера починили.
Опубликовал свой первый пакет на свалке Node.js. Теперь запустить пример с «Hello World!», который будет доступен по локальному адресу, можно следующим образом:
alexo@codedot:/tmp$ npm install uniweb npm http GET https://registry.npmjs.org/uniweb npm http 200 https://registry.npmjs.org/uniweb npm http GET https://registry.npmjs.org/ws npm http 304 https://registry.npmjs.org/ws > ws@0.4.13 preinstall /private/tmp/node_modules/uniweb/node_modules/ws > make node-waf configure build Checking for program g++ or c++ : /usr/bin/g++ Checking for program cpp : /usr/bin/cpp Checking for program ar : /usr/bin/ar Checking for program ranlib : /usr/bin/ranlib Checking for g++ : ok Checking for node path : ok /usr/local/lib/node_modules Checking for node prefix : ok /usr/local 'configure' finished successfully (0.183s) Waf: Entering directory `/private/tmp/node_modules/uniweb/node_modules/ws/build' [1/4] cxx: src/validation.cc -> build/Release/src/validation_1.o [2/4] cxx: src/bufferutil.cc -> build/Release/src/bufferutil_2.o [3/4] cxx_link: build/Release/src/validation_1.o -> build/Release/validation.node [4/4] cxx_link: build/Release/src/bufferutil_2.o -> build/Release/bufferutil.node Waf: Leaving directory `/private/tmp/node_modules/uniweb/node_modules/ws/build' 'build' finished successfully (1.050s) npm http GET https://registry.npmjs.org/commander npm http GET https://registry.npmjs.org/options npm http 304 https://registry.npmjs.org/commander npm http 304 https://registry.npmjs.org/options uniweb@1.1.1 ./node_modules/uniweb └── ws@0.4.13 (options@0.0.3, commander@0.5.2) alexo@codedot:/tmp$ npm test uniweb > uniweb@1.1.1 test /private/tmp/node_modules/uniweb > node hello.js
Не считая примера, код пакета занимает всего 62 строки. Ниже комбинированный HTTP/HTTPS/WebSocket-сервер на его основе, который работает под рутом, так как использует порты 80 и 443, и ожидает SSL-сертификат в файлах key.pem и cert.pem:
var start = require("uniweb"); var read = require("fs").readFileSync; function hello(socket) { socket.on("message", function(msg) { socket.send("alert(\"" + msg + "\");"); }); socket.send("socket.send(\"Hello World!\");"); } start({ handler: hello, domain: "example.com", key: read("key.pem"), cert: read("cert.pem") });
Below are index.html and server.js sources. The server expects the index.html file as well as SSL key.pem and cert.pem to be located in the current directory.
<!doctype html> <meta charset="utf-8"> <title></title> <script> var socket = new WebSocket("ws://localhost/"); socket.onmessage = function(msg) { eval(msg.data); }; </script>
var read = require("fs").readFileSync; function server(socket) { socket.on("message", function(msg) { socket.send("alert(\"" + msg + "\");"); }); socket.send("socket.send(\"Hello World!\");"); } function client(ws) { var html = read("index.html", "utf8"); return function(request, response) { response.writeHead(200, { "Content-Type": "text/html" }); response.end(html.replace("ws", ws)); }; } function uniweb(host, ws, port) { (new (require("ws").Server)({ server: host })).on("connection", server); host.on("request", client(ws)); host.listen(port); } uniweb(require("http").createServer(), "ws", 80); uniweb(require("https").createServer({ key: read("key.pem"), cert: read("cert.pem") }), "wss", 443);
<!doctype html> <meta charset="utf-8"> <title></title> <script> var socket = new WebSocket("wss://127.0.0.1:8888/"); socket.onmessage = function(msg) { eval(msg.data); }; </script>
The above HTML5 code successfully validated by W3C, unlike the previous one, uses the secure WebSocket protocol. One can easily create a Node.js-based secure WebSocket server for such a client as follows. We assume files named key.pem and cert.pem to contain the private key and the corresponding certificate both PEM-formatted, and that server.js contains the source code from below. If you have the ws package installed using npm install ws, running node server.js will then start the server.
var fs = require("fs"); var https = require("https"); var ws = require("ws"); var host = { server: https.createServer({ key: fs.readFileSync("key.pem"), cert: fs.readFileSync("cert.pem") }) }; (new ws.Server(host)).on("connection", function(socket) { socket.on("message", function(msg) { socket.send("window.alert(\"" + msg + "\");"); }); socket.send("socket.send(\"Hello World!\");"); }); host.server.listen(8888);