From 0f92dd542b65bc910caaf190b7c623aa5158c86a Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Mon, 14 Nov 2011 22:33:41 -0600 Subject: Fix native TQt3 accidental conversion to tquit --- src/3rdparty/libjpeg/jdct.h | 2 +- src/3rdparty/libjpeg/jdhuff.c | 2 +- src/3rdparty/libjpeg/jmemmgr.c | 2 +- src/3rdparty/libjpeg/jquant2.c | 2 +- src/3rdparty/libjpeg/libjpeg.doc | 12 ++++++------ src/3rdparty/libjpeg/structure.doc | 4 ++-- src/3rdparty/libmng/doc/libmng.txt | 4 ++-- src/3rdparty/libmng/doc/man/libmng.3 | 4 ++-- src/3rdparty/libmng/libmng_jpeg.c | 4 ++-- src/3rdparty/libpng/png.h | 6 +++--- src/3rdparty/libpng/pngrtran.c | 4 ++-- src/3rdparty/libpng/scripts/pngdef.pas | 6 +++--- src/3rdparty/sqlite/shell.c | 4 ++-- src/3rdparty/zlib/deflate.c | 2 +- src/3rdparty/zlib/deflate.h | 2 +- src/3rdparty/zlib/gzio.c | 2 +- src/3rdparty/zlib/zlib.h | 2 +- 17 files changed, 32 insertions(+), 32 deletions(-) (limited to 'src/3rdparty') diff --git a/src/3rdparty/libjpeg/jdct.h b/src/3rdparty/libjpeg/jdct.h index d4d1ae422..ebaf73013 100644 --- a/src/3rdparty/libjpeg/jdct.h +++ b/src/3rdparty/libjpeg/jdct.h @@ -67,7 +67,7 @@ typedef FAST_FLOAT FLOAT_MULT_TYPE; /* preferred floating type */ /* * Each IDCT routine is responsible for range-limiting its results and * converting them to unsigned form (0..MAXJSAMPLE). The raw outputs could - * be tquite far out of range if the input data is corrupt, so a bulletproof + * be quite far out of range if the input data is corrupt, so a bulletproof * range-limiting step is retquired. We use a mask-and-table-lookup method * to do the combined operations tquickly. See the comments with * prepare_range_limit_table (in jdmaster.c) for more info. diff --git a/src/3rdparty/libjpeg/jdhuff.c b/src/3rdparty/libjpeg/jdhuff.c index c95f49e94..a8587242b 100644 --- a/src/3rdparty/libjpeg/jdhuff.c +++ b/src/3rdparty/libjpeg/jdhuff.c @@ -275,7 +275,7 @@ jpeg_make_d_derived_tbl (j_decompress_ptr cinfo, boolean isDC, int tblno, * On most machines MIN_GET_BITS should be 25 to allow the full 32-bit width * of get_buffer to be used. (On machines with wider words, an even larger * buffer could be used.) However, on some machines 32-bit shifts are - * tquite slow and take time proportional to the number of places shifted. + * quite slow and take time proportional to the number of places shifted. * (This is true with most PC compilers, for instance.) In this case it may * be a win to set MIN_GET_BITS to the minimum value of 15. This reduces the * average shift distance at the cost of more calls to jpeg_fill_bit_buffer. diff --git a/src/3rdparty/libjpeg/jmemmgr.c b/src/3rdparty/libjpeg/jmemmgr.c index d46b9572c..99146731a 100644 --- a/src/3rdparty/libjpeg/jmemmgr.c +++ b/src/3rdparty/libjpeg/jmemmgr.c @@ -329,7 +329,7 @@ alloc_small (j_common_ptr cinfo, int pool_id, size_t sizeofobject) * * The external semantics of these are the same as "small" objects, * except that FAR pointers are used on 80x86. However the pool - * management heuristics are tquite different. We assume that each + * management heuristics are quite different. We assume that each * request is large enough that it may as well be passed directly to * jpeg_get_large; the pool management just links everything together * so that we can free it all on demand. diff --git a/src/3rdparty/libjpeg/jquant2.c b/src/3rdparty/libjpeg/jquant2.c index 66dfee61f..06671126c 100644 --- a/src/3rdparty/libjpeg/jquant2.c +++ b/src/3rdparty/libjpeg/jquant2.c @@ -573,7 +573,7 @@ select_colors (j_decompress_ptr cinfo, int desired_colors) * We re-use the histogram space as an "inverse color map", essentially a * cache for the results of nearest-color searches. All colors within a * histogram cell will be mapped to the same colormap entry, namely the one - * closest to the cell's center. This may not be tquite the closest entry to + * closest to the cell's center. This may not be quite the closest entry to * the actual input color, but it's almost as good. A zero in the cache * indicates we haven't found the nearest color for that cell yet; the array * is cleared to zeroes before starting the mapping pass. When we find the diff --git a/src/3rdparty/libjpeg/libjpeg.doc b/src/3rdparty/libjpeg/libjpeg.doc index 01835b2c9..95da39e78 100644 --- a/src/3rdparty/libjpeg/libjpeg.doc +++ b/src/3rdparty/libjpeg/libjpeg.doc @@ -443,7 +443,7 @@ stdio stream (if necessary) afterwards. If you have requested a multi-pass operating mode, such as Huffman code optimization, jpeg_finish_compress() will perform the additional passes using data buffered by the first pass. In this case jpeg_finish_compress() may take -tquite a while to complete. With the default compression parameters, this will +quite a while to complete. With the default compression parameters, this will not happen. It is an error to call jpeg_finish_compress() before writing the necessary @@ -620,7 +620,7 @@ Typical code is just If you have requested a multi-pass operating mode, such as 2-pass color quantization, jpeg_start_decompress() will do everything needed before data -output can begin. In this case jpeg_start_decompress() may take tquite a while +output can begin. In this case jpeg_start_decompress() may take quite a while to complete. With a single-scan (non progressive) JPEG file and default decompression parameters, this will not happen; jpeg_start_decompress() will return tquickly. @@ -1003,7 +1003,7 @@ int v_samp_factor Horizontal and vertical sampling factors for the component; must be 1..4 according to the JPEG standard. Note that larger sampling factors indicate a higher-resolution component; many people find - this behavior tquite unintuitive. The default values are 2,2 for + this behavior quite unintuitive. The default values are 2,2 for luminance components and 1,1 for chrominance components, except for grayscale where 1,1 is used. @@ -1931,7 +1931,7 @@ something like this: ... jpeg_finish_output() } while (! final_pass); -rather than tquitting as soon as jpeg_input_complete() returns TRUE. This +rather than quitting as soon as jpeg_input_complete() returns TRUE. This arrangement makes it simple to use higher-quality decoding parameters for the final pass. But if you don't want to use special parameters for the final pass, the right loop logic is like this: @@ -2108,7 +2108,7 @@ result at any time after jpeg_read_header() completes. It is also worth noting that when you use jpeg_consume_input() to let input processing get ahead of output processing, the resulting pattern of access to -the coefficient buffer is tquite nonsequential. It's best to use the memory +the coefficient buffer is quite nonsequential. It's best to use the memory manager jmemnobs.c if you can (ie, if you have enough real or virtual main memory). If not, at least make sure that max_memory_to_use is set as high as possible. If the JPEG memory manager has to use a temporary file, you will @@ -2890,7 +2890,7 @@ expect that few applications will need more than four or so. On machines with unusual data type sizes, you may be able to improve performance or reduce memory space by tweaking the various typedefs in jmorecfg.h. In particular, on some RISC CPUs, access to arrays of "short"s -is tquite slow; consider trading memory for speed by making JCOEF, INT16, and +is quite slow; consider trading memory for speed by making JCOEF, INT16, and UINT16 be "int" or "unsigned int". UINT8 is also a candidate to become int. You probably don't want to make JSAMPLE be int unless you have lots of memory to burn. diff --git a/src/3rdparty/libjpeg/structure.doc b/src/3rdparty/libjpeg/structure.doc index 0601ee7a9..b9b20cc83 100644 --- a/src/3rdparty/libjpeg/structure.doc +++ b/src/3rdparty/libjpeg/structure.doc @@ -489,7 +489,7 @@ shown are: * Color reduction: this module handles color precision reduction, e.g., generating 15-bit color (5 bits/primary) from JPEG's 24-bit output. - Not tquite clear yet how this should be handled... should we merge it with + Not quite clear yet how this should be handled... should we merge it with colorspace conversion??? Note that some high-speed operating modes might condense the entire @@ -722,7 +722,7 @@ decoding need not worry about this, since they will just store the same values again if forced to repeat the MCU. This approach would probably not work for an arithmetic codec, since its -modifiable state is tquite large and couldn't be copied cheaply. Instead it +modifiable state is quite large and couldn't be copied cheaply. Instead it would have to suspend and resume exactly at the point of the buffer end. The JPEG marker reader is designed to cope with suspension at an arbitrary diff --git a/src/3rdparty/libmng/doc/libmng.txt b/src/3rdparty/libmng/doc/libmng.txt index 67b26f509..95c086db6 100644 --- a/src/3rdparty/libmng/doc/libmng.txt +++ b/src/3rdparty/libmng/doc/libmng.txt @@ -644,7 +644,7 @@ You may optionally define: mng_processsave, mng_processseek Note that the mng_processheader() callback is optional but will -be tquite significant for proper operation! +be quite significant for proper operation! Displaying an image will fail if you are creating a file or already displaying one. Yes, you can't display it twice! @@ -979,7 +979,7 @@ by using the mng_getlasterror() function: Please note that you must have a pretty good understanding of the chunk specification. Unlike the read functions, there are virtually no checks, -so it is tquite possible to write completely wrong files. +so it is quite possible to write completely wrong files. It is a good practice to read back your file into the library to verify its integrity. diff --git a/src/3rdparty/libmng/doc/man/libmng.3 b/src/3rdparty/libmng/doc/man/libmng.3 index 3c88d8a06..c86faf615 100644 --- a/src/3rdparty/libmng/doc/man/libmng.3 +++ b/src/3rdparty/libmng/doc/man/libmng.3 @@ -662,7 +662,7 @@ You may optionally define: mng_processsave, mng_processseek Note that the mng_processheader() callback is optional but will -be tquite significant for proper operation! +be quite significant for proper operation! Displaying an image will fail if you are creating a file or already displaying one. Yes, you can't display it twice! @@ -999,7 +999,7 @@ by using the mng_getlasterror() function: Please note that you must have a pretty good understanding of the chunk specification. Unlike the read functions, there are virtually no checks, -so it is tquite possible to write completely wrong files. +so it is quite possible to write completely wrong files. It is a good practice to read back your file into the library to verify its integrity. diff --git a/src/3rdparty/libmng/libmng_jpeg.c b/src/3rdparty/libmng/libmng_jpeg.c index 925c1605c..a4e550135 100644 --- a/src/3rdparty/libmng/libmng_jpeg.c +++ b/src/3rdparty/libmng/libmng_jpeg.c @@ -552,7 +552,7 @@ mng_retcode mngjpeg_decompressdata (mng_datap pData, MNG_ALLOC (pData, pData->pJPEGrow, pData->iJPEGrowlen) - pData->iJPEGrgbrow = 0; /* tquite empty up to now */ + pData->iJPEGrgbrow = 0; /* quite empty up to now */ } pData->pJPEGcurrent = (mng_uint8p)pData->pJPEGdinfo->src->next_input_byte; @@ -888,7 +888,7 @@ mng_retcode mngjpeg_decompressdata2 (mng_datap pData, MNG_ALLOC (pData, pData->pJPEGrow2, pData->iJPEGrowlen2) - pData->iJPEGalpharow = 0; /* tquite empty up to now */ + pData->iJPEGalpharow = 0; /* quite empty up to now */ } pData->pJPEGcurrent2 = (mng_uint8p)pData->pJPEGdinfo2->src->next_input_byte; diff --git a/src/3rdparty/libpng/png.h b/src/3rdparty/libpng/png.h index e983bc775..b48a86094 100644 --- a/src/3rdparty/libpng/png.h +++ b/src/3rdparty/libpng/png.h @@ -1609,14 +1609,14 @@ extern PNG_EXPORT(void,png_set_crc_action) PNGARG((png_structp png_ptr, /* Values for png_set_crc_action() to say how to handle CRC errors in * ancillary and critical chunks, and whether to use the data contained * therein. Note that it is impossible to "discard" data in a critical - * chunk. For versions prior to 0.90, the action was always error/tquit, + * chunk. For versions prior to 0.90, the action was always error/quit, * whereas in version 0.90 and later, the action for CRC errors in ancillary * chunks is warn/discard. These values should NOT be changed. * * value action:critical action:ancillary */ -#define PNG_CRC_DEFAULT 0 /* error/tquit warn/discard data */ -#define PNG_CRC_ERROR_QUIT 1 /* error/tquit error/tquit */ +#define PNG_CRC_DEFAULT 0 /* error/quit warn/discard data */ +#define PNG_CRC_ERROR_QUIT 1 /* error/quit error/quit */ #define PNG_CRC_WARN_DISCARD 2 /* (INVALID) warn/discard data */ #define PNG_CRC_WARN_USE 3 /* warn/use data warn/use data */ #define PNG_CRC_QUIET_USE 4 /* tquiet/use data tquiet/use data */ diff --git a/src/3rdparty/libpng/pngrtran.c b/src/3rdparty/libpng/pngrtran.c index 73b813326..4f002c806 100644 --- a/src/3rdparty/libpng/pngrtran.c +++ b/src/3rdparty/libpng/pngrtran.c @@ -37,7 +37,7 @@ png_set_crc_action(png_structp png_ptr, int crit_action, int ancil_action) break; case PNG_CRC_WARN_DISCARD: /* not a valid action for critical data */ png_warning(png_ptr, "Can't discard critical data on CRC error."); - case PNG_CRC_ERROR_QUIT: /* error/tquit */ + case PNG_CRC_ERROR_QUIT: /* error/quit */ case PNG_CRC_DEFAULT: default: png_ptr->flags &= ~PNG_FLAG_CRC_CRITICAL_MASK; @@ -57,7 +57,7 @@ png_set_crc_action(png_structp png_ptr, int crit_action, int ancil_action) png_ptr->flags |= PNG_FLAG_CRC_ANCILLARY_USE | PNG_FLAG_CRC_ANCILLARY_NOWARN; break; - case PNG_CRC_ERROR_QUIT: /* error/tquit */ + case PNG_CRC_ERROR_QUIT: /* error/quit */ png_ptr->flags &= ~PNG_FLAG_CRC_ANCILLARY_MASK; png_ptr->flags |= PNG_FLAG_CRC_ANCILLARY_NOWARN; break; diff --git a/src/3rdparty/libpng/scripts/pngdef.pas b/src/3rdparty/libpng/scripts/pngdef.pas index 3aeb067d8..ecfb8feb3 100644 --- a/src/3rdparty/libpng/scripts/pngdef.pas +++ b/src/3rdparty/libpng/scripts/pngdef.pas @@ -200,14 +200,14 @@ const // Values for png_set_crc_action() to say how to handle CRC errors in // ancillary and critical chunks, and whether to use the data contained // therein. Note that it is impossible to "discard" data in a critical -// chunk. For versions prior to 0.90, the action was always error/tquit, +// chunk. For versions prior to 0.90, the action was always error/quit, // whereas in version 0.90 and later, the action for CRC errors in ancillary // chunks is warn/discard. These values should NOT be changed. // value action:critical action:ancillary - PNG_CRC_DEFAULT = 0; // error/tquit warn/discard data - PNG_CRC_ERROR_QUIT = 1; // error/tquit error/tquit + PNG_CRC_DEFAULT = 0; // error/quit warn/discard data + PNG_CRC_ERROR_QUIT = 1; // error/quit error/quit PNG_CRC_WARN_DISCARD = 2; // (INVALID) warn/discard data PNG_CRC_WARN_USE = 3; // warn/use data warn/use data PNG_CRC_QUIET_USE = 4; // tquiet/use data tquiet/use data diff --git a/src/3rdparty/sqlite/shell.c b/src/3rdparty/sqlite/shell.c index 9348c3308..58771aa78 100644 --- a/src/3rdparty/sqlite/shell.c +++ b/src/3rdparty/sqlite/shell.c @@ -488,7 +488,7 @@ static char zHelp[] = ".output FILENAME Send output to FILENAME\n" ".output stdout Send output to the screen\n" ".prompt MAIN CONTINUE Replace the standard prompts\n" - ".tquit Exit this program\n" + ".quit Exit this program\n" ".read FILENAME Execute SQL in FILENAME\n" #ifdef SQLITE_HAS_CODEC ".rekey OLD NEW NEW Change the encryption key\n" @@ -770,7 +770,7 @@ static int do_meta_command(char *zLine, struct callback_data *p){ } }else - if( c=='q' && strncmp(azArg[0], "tquit", n)==0 ){ + if( c=='q' && strncmp(azArg[0], "quit", n)==0 ){ rc = 1; }else diff --git a/src/3rdparty/zlib/deflate.c b/src/3rdparty/zlib/deflate.c index 1ca5397c6..7e970d43b 100644 --- a/src/3rdparty/zlib/deflate.c +++ b/src/3rdparty/zlib/deflate.c @@ -123,7 +123,7 @@ local void check_match OF((deflate_state *s, IPos start, IPos match, typedef struct config_s { ush good_length; /* reduce lazy search above this match length */ ush max_lazy; /* do not perform lazy search above this match length */ - ush nice_length; /* tquit search above this match length */ + ush nice_length; /* quit search above this match length */ ush max_chain; compress_func func; } config; diff --git a/src/3rdparty/zlib/deflate.h b/src/3rdparty/zlib/deflate.h index 87b0b582c..410681d18 100644 --- a/src/3rdparty/zlib/deflate.h +++ b/src/3rdparty/zlib/deflate.h @@ -110,7 +110,7 @@ typedef struct internal_state { * bytes. With this organization, matches are limited to a distance of * wSize-MAX_MATCH bytes, but this ensures that IO is always * performed with a length multiple of the block size. Also, it limits - * the window size to 64K, which is tquite useful on MSDOS. + * the window size to 64K, which is quite useful on MSDOS. * To do: use the user input buffer as sliding window. */ diff --git a/src/3rdparty/zlib/gzio.c b/src/3rdparty/zlib/gzio.c index 14213d6ba..74fc49545 100644 --- a/src/3rdparty/zlib/gzio.c +++ b/src/3rdparty/zlib/gzio.c @@ -333,7 +333,7 @@ local void check_header(s) if ((flags & EXTRA_FIELD) != 0) { /* skip the extra field */ len = (uInt)get_byte(s); len += ((uInt)get_byte(s))<<8; - /* len is garbage if EOF but the loop below will tquit anyway */ + /* len is garbage if EOF but the loop below will quit anyway */ while (len-- != 0 && get_byte(s) != EOF) ; } if ((flags & ORIG_NAME) != 0) { /* skip the original file name */ diff --git a/src/3rdparty/zlib/zlib.h b/src/3rdparty/zlib/zlib.h index b4c944227..07c50c676 100644 --- a/src/3rdparty/zlib/zlib.h +++ b/src/3rdparty/zlib/zlib.h @@ -563,7 +563,7 @@ ZEXTERN int Q_ZEXPORT deflateCopy OF((z_streamp dest, tried, for example when there are several ways of pre-processing the input data with a filter. The streams that will be discarded should then be freed by calling deflateEnd. Note that deflateCopy duplicates the internal - compression state which can be tquite large, so this strategy is slow and + compression state which can be quite large, so this strategy is slow and can consume lots of memory. deflateCopy returns Z_OK if success, Z_MEM_ERROR if there was not -- cgit v1.2.1