The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
| extern crate comm; | |
| extern crate rand; | |
| use std::{thread}; | |
| use comm::{spmc}; | |
| use rand::{Rng}; | |
| fn main() { | |
| let (send, recv) = spmc::unbounded::new(); |
Web app development entails:
| /* | |
| * Test glibc overlapping memcpy. | |
| * glibc resorts to a downward direction memcpy for anything exceeding ~200 bytes. | |
| * No clue for the so-called optimization that breaks apps resorting to memcpy | |
| * for overlapping boundaries instead of using memmove. | |
| * This is only specific to x86_64/64 bit as for 32 bits, it always uses a forward memcpy. | |
| * | |
| * Try this -- | |
| * gcc -o memcp memcp.c -DHAVE_MEMCPY | |
| * ./memcp |
Do your part to resist Government surveillance and take back your privacy:
This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
| // FizzBuzz revisited | |
| // This is a follow-up to the "FizzBuzz" chapter of "Rust for | |
| // Rubyists" (http://www.rustforrubyists.com/book/chapter-06.html). | |
| // We're going to take the code from there and refactor it to use | |
| // pattern matching. | |
| // Here's the original code from the book. The only change I've made | |
| // is to comment out the original main() function so that we can write | |
| // a few versions of our own. |
| #!/usr/bin/env python | |
| import time | |
| from sys import stdin, stdout, argv, exit | |
| try: | |
| if argv[1] == 'help' or argv[1] == '--help' or argv[1] == '-h': | |
| print "%s: times each line of stdin.\n Optional parameter is a float of a threshold. (defaults to 2.0)" % argv[0] | |
| exit(255); | |
| else: |
Couldn't find the text of this for a while...
This tutorial guides you through creating your first Vagrant project.
We start with a generic Ubuntu VM, and use the Chef provisioning tool to:
Afterwards, we'll see how easy it is to package our newly provisioned VM
