> An early prototype of the Inspector even included a significant portion of Firebug. Ultimately, integration proved to be too challenging and would have required rewrites that would have been equivalent to starting over.
93 karma · joined August 9, 2013
> An early prototype of the Inspector even included a significant portion of Firebug. Ultimately, integration proved to be too challenging and would have required rewrites that would have been equivalent to starting over.
$ find / -mindepth 10 | wc -L
273
I seem to have some slightly longer file paths on my home computer. Do I need that? Probably not. I could move those files somewhere else. But should I really have to worry about such things?Retailers don't have the resources to fix these problems, or to help fixing them. They don't have to if the customer installed their OS of choice themselves.
By streaming the data, you can do both at the same time. (The OS will already fetch the next line from the disk while you are still processing the previous one.)
With a fork-based server, you don't care much about that. Every time you connect, you get a fresh new process - with the same addresses as the older copies even.
So brute-forcing those is more viable than a browser where you probably won't have more than 1 or 2 attempts per user.
According to that link, c_str() and data() work in constant time. With that restriction, it's impossible to do the joining lazily - it must be done when data is added to the string.
I read the HTTP 1.1 RFC differently. Requests must indicate a body with a Content-Length or Transfer-Encoding header. Responses always have a body (sometimes of length 0), unless it is a response to a HEAD request or has one of a very small number of response codes. http://tools.ietf.org/html/rfc2616#section-4.3