- Nov 16, 2017
-
-
ruslantproductengine authored
In case of buff->getVertexStrider(v) return false it mean that glMapBufferRange() return NULL The next three lines can be the reason of this crash.
-
- Oct 31, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 30, 2017
-
-
Nat Goodspeed authored
-
- Oct 27, 2017
-
-
Nat Goodspeed authored
-
- Oct 26, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 25, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 24, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
Nat Goodspeed authored
Specifically, reinstate the curl, openssl, nghttp2 libraries to the previous tip of this MAINT-7081 fork.
-
Nat Goodspeed authored
-
- Oct 18, 2017
-
-
Nat Goodspeed authored
The /marker switch is passed by the (new) VMP. If any user wants to explicitly pass the /marker switch to the installer, s/he shouldn't mind ending up with an nsis.winstall file in the download directory.
-
Nat Goodspeed authored
-
- Oct 13, 2017
-
- Oct 12, 2017
-
-
Kitty Barnett authored
The trouble lines are: U8 * buffer = (U8 *) ALLOCATE_MEM(LLImageBase::getPrivatePool(), total_size); if (cur_size > 0) { memcpy(buffer, mFormattedImage->getData(), cur_size); } If 'cur_size > mHttpReplyOffset + append_size' then 'total_size -= src_offset' will cause total_size to be smaller than cur_size causing a write access violation on the memcpy. Since the response is invalid it seemed best to make it follow the other failed partial condition. (transplanted from 737e28ec6b4d74f3ff915a4effc13d7b615a6a9b)
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 11, 2017
-
-
Nat Goodspeed authored
-
Oz Linden authored
-
Oz Linden authored
-
- Oct 10, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 09, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
Nat Goodspeed authored
Now that LLManifest.prefix() supports use as a context manager: with self.prefix(...): ... convert existing calls to that form. This was an interesting exercise because it surfaced at least two places where the indentation did not match the self.prefix() nesting, plus another place where existing code was undented without a self.end_prefix() call. (That last was an uncaught logic bug.) This underscores the value of using a SINGLE consistent, idiomatic mechanism to limit the scope of each self.prefix() call.
-
Nat Goodspeed authored
LLManifest.prefix() dates back to before Python had a 'with' statement or the notion of a context manager. That's why every prefix() call requires a corresponding end_prefix() call. Existing usage is of the form: if self.prefix(...some args...): self.path(...) ... self.end_prefix() The use of an 'if' statement is solely to allow the coder to indent the statements between the self.prefix() call and the corresponding call to self.end_prefix() -- there is no intention to make that code conditional. self.prefix() unconditionally returned True to facilitate that usage. But now that we have the 'with' statement, this all feels a little silly. Make prefix() return an instance of a context-manager class so that it's reasonable to say instead: with self.prefix(...some args...): self.path(...) ... and have the Right Things happen simply by leaving the 'with' block. The only tricky part is code to preserve compatibility with old-style usage: * The context manager has a __nonzero__() method so that if it's tested in an 'if' statement, it can unconditionally return True. * On leaving the 'with' block, rather than simply popping the top of each prefix stack, the context manager restores its length to the same length it had before that prefix() call. This allows for (erroneous but hardly unlikely) usage of the form: with self.prefix(...some args...): self.path(...) ... self.end_prefix() Restoring the previous length makes the context manager insensitive to whether or not end_prefix() has popped the most recent prefix() entries.
- Oct 06, 2017
-
-
Nat Goodspeed authored
-
- Oct 05, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Oct 04, 2017
-
-
Nat Goodspeed authored
-
- Oct 02, 2017
-
-
Nat Goodspeed authored
-
Nat Goodspeed authored
-
- Sep 30, 2017
-
-
Nat Goodspeed authored
The new helper functions check_curl_easy_setopt() and check_curl_multi_setopt() encapsulate the pervasive idiom: code = curl_{easy,multi}_setopt(handle, option, arg); check_curl_{easy,multi}_code(code, option); But since each of these helper functions contains its own local CURL{,M}code variable 'code', having a caller-scope variable reused for every such call is no longer necessary -- in fact is no longer used at all. That produces a fatal warning with MSVC. Get rid of those now-unused variables.
-