| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libbzip2
This chapter describes the programming interface to libbzip2
.
For general background information, particularly about memory use and performance aspects, you'd be well advised to read Chapter 2 as well.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libbzip2
is a flexible library for compressing and decompressing
data in the bzip2
data format. Although packaged as a single
entity, it helps to regard the library as three separate parts: the low
level interface, and the high level interface, and some utility
functions.
The structure of libbzip2
's interfaces is similar to
that of Jean-loup Gailly's and Mark Adler's excellent zlib
library.
All externally visible symbols have names beginning BZ2_
.
This is new in version 1.0. The intention is to minimise pollution
of the namespaces of library clients.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This interface provides services for compressing and decompressing
data in memory. There's no provision for dealing with files, streams
or any other I/O mechanisms, just straight memory-to-memory work.
In fact, this part of the library can be compiled without inclusion
of stdio.h
, which may be helpful for embedded applications.
The low-level part of the library has no global variables and is therefore thread-safe.
Six routines make up the low level interface:
BZ2_bzCompressInit
, BZ2_bzCompress
, and
BZ2_bzCompressEnd
for compression,
and a corresponding trio BZ2_bzDecompressInit
,
BZ2_bzDecompress
and BZ2_bzDecompressEnd
for decompression.
The *Init
functions allocate
memory for compression/decompression and do other
initialisations, whilst the *End
functions close down operations
and release memory.
The real work is done by BZ2_bzCompress
and BZ2_bzDecompress
.
These compress and decompress data from a user-supplied input buffer
to a user-supplied output buffer. These buffers can be any size;
arbitrary quantities of data are handled by making repeated calls
to these functions. This is a flexible mechanism allowing a
consumer-pull style of activity, or producer-push, or a mixture of
both.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This interface provides some handy wrappers around the low-level
interface to facilitate reading and writing bzip2
format
files (.bz2
files). The routines provide hooks to facilitate
reading files in which the bzip2
data stream is embedded
within some larger-scale file structure, or where there are
multiple bzip2
data streams concatenated end-to-end.
For reading files, BZ2_bzReadOpen
, BZ2_bzRead
,
BZ2_bzReadClose
and
BZ2_bzReadGetUnused
are supplied. For
writing files, BZ2_bzWriteOpen
, BZ2_bzWrite
and
BZ2_bzWriteFinish
are available.
As with the low-level library, no global variables are used
so the library is per se thread-safe. However, if I/O errors
occur whilst reading or writing the underlying compressed files,
you may have to consult errno
to determine the cause of
the error. In that case, you'd need a C library which correctly
supports errno
in a multithreaded environment.
To make the library a little simpler and more portable,
BZ2_bzReadOpen
and BZ2_bzWriteOpen
require you to pass them file
handles (FILE*
s) which have previously been opened for reading or
writing respectively. That avoids portability problems associated with
file operations and file attributes, whilst not being much of an
imposition on the programmer.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzBuffToBuffCompress
and
BZ2_bzBuffToBuffDecompress
are provided. These compress
data in memory from one buffer to another buffer in a single
function call. You should assess whether these functions
fulfill your memory-to-memory compression/decompression
requirements before investing effort in understanding the more
general but more complex low-level interface.
Yoshioka Tsuneo<EMAIL_ADDRESS>/
<EMAIL_ADDRESS>) has contributed some functions to
give better zlib
compatibility. These functions are
BZ2_bzopen
, BZ2_bzread
, BZ2_bzwrite
, BZ2_bzflush
,
BZ2_bzclose
,
BZ2_bzerror
and BZ2_bzlibVersion
. You may find these functions
more convenient for simple file reading and writing, than those in the
high-level interface. These functions are not (yet) officially part of
the library, and are minimally documented here. If they break, you
get to keep all the pieces. I hope to document them properly when time
permits.
Yoshioka also contributed modifications to allow the library to be built as a Windows DLL.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The library is designed to recover cleanly in all situations, including the worst-case situation of decompressing random data. I'm not 100% sure that it can always do this, so you might want to add a signal handler to catch segmentation violations during decompression if you are feeling especially paranoid. I would be interested in hearing more about the robustness of the library to corrupted compressed data.
Version 1.0 is much more robust in this respect than 0.9.0 or 0.9.5. Investigations with Checker (a tool for detecting problems with memory management, similar to Purify) indicate that, at least for the few files I tested, all single-bit errors in the decompressed data are caught properly, with no segmentation faults, no reads of uninitialised data and no out of range reads or writes. So it's certainly much improved, although I wouldn't claim it to be totally bombproof.
The file bzlib.h
contains all definitions needed to use
the library. In particular, you should definitely not include
bzlib_private.h
.
In bzlib.h
, the various return values are defined. The following
list is not intended as an exhaustive description of the circumstances
in which a given value may be returned -- those descriptions are given
later. Rather, it is intended to convey the rough meaning of each
return value. The first five actions are normal and not intended to
denote an error situation.
BZ_OK
BZ_RUN_OK
BZ_FLUSH_OK
BZ_FINISH_OK
BZ2_bzCompress
, the requested flush/finish/nothing-special action
was completed successfully.
BZ_STREAM_END
The following return values indicate an error of some kind.
BZ_CONFIG_ERROR
sizeof(char)
, sizeof(short)
and sizeof(int)
are not 1, 2 and 4 respectively, as they should be. Note that the
library should still work properly on 64-bit platforms which follow
the LP64 programming model -- that is, where sizeof(long)
and sizeof(void*)
are 8. Under LP64, sizeof(int)
is
still 4, so libbzip2
, which doesn't use the long
type,
is OK.
BZ_SEQUENCE_ERROR
libbzip2
checks as much as it can to ensure this is
happening, and returns BZ_SEQUENCE_ERROR
if not. Code which
complies precisely with the function semantics, as detailed below,
should never receive this value; such an event denotes buggy code
which you should investigate.
BZ_PARAM_ERROR
BZ_SEQUENCE_ERROR
,
this denotes a bug in the client code. The distinction between
BZ_PARAM_ERROR
and BZ_SEQUENCE_ERROR
is a bit hazy, but still worth
making.
BZ_MEM_ERROR
BZ2_bzDecompress
and
BZ2_bzRead
may return BZ_MEM_ERROR
even though some of
the compressed data has been read. The same is not true for
compression; once BZ2_bzCompressInit
or BZ2_bzWriteOpen
have
successfully completed, BZ_MEM_ERROR
cannot occur.
BZ_DATA_ERROR
BZ_DATA_ERROR_MAGIC
BZ_DATA_ERROR
, it is sometimes useful to
know when the compressed stream does not start with the correct
magic bytes ('B' 'Z' 'h'
).
BZ_IO_ERROR
BZ2_bzRead
and BZ2_bzWrite
when there is an error
reading or writing in the compressed file, and by BZ2_bzReadOpen
and BZ2_bzWriteOpen
for attempts to use a file for which the
error indicator (viz, ferror(f)
) is set.
On receipt of BZ_IO_ERROR
, the caller should consult
errno
and/or perror
to acquire operating-system
specific information about the problem.
BZ_UNEXPECTED_EOF
BZ2_bzRead
when the compressed file finishes
before the logical end of stream is detected.
BZ_OUTBUFF_FULL
BZ2_bzBuffToBuffCompress
and
BZ2_bzBuffToBuffDecompress
to indicate that the output data
will not fit into the output buffer provided.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzCompressInit
typedef struct { char *next_in; unsigned int avail_in; unsigned int total_in_lo32; unsigned int total_in_hi32; char *next_out; unsigned int avail_out; unsigned int total_out_lo32; unsigned int total_out_hi32; void *state; void *(*bzalloc)(void *,int,int); void (*bzfree)(void *,void *); void *opaque; } bz_stream; int BZ2_bzCompressInit ( bz_stream *strm, int blockSize100k, int verbosity, int workFactor ); |
Prepares for compression. The bz_stream
structure
holds all data pertaining to the compression activity.
A bz_stream
structure should be allocated and initialised
prior to the call.
The fields of bz_stream
comprise the entirety of the user-visible data. state
is a pointer to the private data structures required for compression.
Custom memory allocators are supported, via fields bzalloc
,
bzfree
,
and opaque
. The value
opaque
is passed to as the first argument to
all calls to bzalloc
and bzfree
, but is
otherwise ignored by the library.
The call bzalloc ( opaque, n, m )
is expected to return a
pointer p
to
n * m
bytes of memory, and bzfree ( opaque, p )
should free
that memory.
If you don't want to use a custom memory allocator, set bzalloc
,
bzfree
and
opaque
to NULL
,
and the library will then use the standard malloc
/free
routines.
Before calling BZ2_bzCompressInit
, fields bzalloc
,
bzfree
and opaque
should
be filled appropriately, as just described. Upon return, the internal
state will have been allocated and initialised, and total_in_lo32
,
total_in_hi32
, total_out_lo32
and
total_out_hi32
will have been set to zero.
These four fields are used by the library
to inform the caller of the total amount of data passed into and out of
the library, respectively. You should not try to change them.
As of version 1.0, 64-bit counts are maintained, even on 32-bit
platforms, using the _hi32
fields to store the upper 32 bits
of the count. So, for example, the total amount of data in
is (total_in_hi32 << 32) + total_in_lo32
.
Parameter blockSize100k
specifies the block size to be used for
compression. It should be a value between 1 and 9 inclusive, and the
actual block size used is 100000 x this figure. 9 gives the best
compression but takes most memory.
Parameter verbosity
should be set to a number between 0 and 4
inclusive. 0 is silent, and greater numbers give increasingly verbose
monitoring/debugging output. If the library has been compiled with
-DBZ_NO_STDIO
, no such output will appear for any verbosity
setting.
Parameter workFactor
controls how the compression phase behaves
when presented with worst case, highly repetitive, input data. If
compression runs into difficulties caused by repetitive data, the
library switches from the standard sorting algorithm to a fallback
algorithm. The fallback is slower than the standard algorithm by
perhaps a factor of three, but always behaves reasonably, no matter how
bad the input.
Lower values of workFactor
reduce the amount of effort the
standard algorithm will expend before resorting to the fallback. You
should set this parameter carefully; too low, and many inputs will be
handled by the fallback algorithm and so compress rather slowly, too
high, and your average-to-worst case compression times can become very
large. The default value of 30 gives reasonable behaviour over a wide
range of circumstances.
Allowable values range from 0 to 250 inclusive. 0 is a special case, equivalent to using the default value of 30.
Note that the compressed output generated is the same regardless of whether or not the fallback algorithm is used.
Be aware also that this parameter may disappear entirely in future versions of the library. In principle it should be possible to devise a good way to automatically choose which algorithm to use. Such a mechanism would render the parameter obsolete.
Possible return values:
|
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzCompress
int BZ2_bzCompress ( bz_stream *strm, int action ); |
BZ2_bzCompress
to
transfer data between them.
Before each call to BZ2_bzCompress
, next_in
should point at
the data to be compressed, and avail_in
should indicate how many
bytes the library may read. BZ2_bzCompress
updates next_in
,
avail_in
and total_in
to reflect the number of bytes it
has read.
Similarly, next_out
should point to a buffer in which the
compressed data is to be placed, with avail_out
indicating how
much output space is available. BZ2_bzCompress
updates
next_out
, avail_out
and total_out
to reflect the
number of bytes output.
You may provide and remove as little or as much data as you like on each
call of BZ2_bzCompress
. In the limit, it is acceptable to supply and
remove data one byte at a time, although this would be terribly
inefficient. You should always ensure that at least one byte of output
space is available at each call.
A second purpose of BZ2_bzCompress
is to request a change of mode of the
compressed stream.
Conceptually, a compressed stream can be in one of four states: IDLE,
RUNNING, FLUSHING and FINISHING. Before initialisation
(BZ2_bzCompressInit
) and after termination (BZ2_bzCompressEnd
), a
stream is regarded as IDLE.
Upon initialisation (BZ2_bzCompressInit
), the stream is placed in the
RUNNING state. Subsequent calls to BZ2_bzCompress
should pass
BZ_RUN
as the requested action; other actions are illegal and
will result in BZ_SEQUENCE_ERROR
.
At some point, the calling program will have provided all the input data
it wants to. It will then want to finish up -- in effect, asking the
library to process any data it might have buffered internally. In this
state, BZ2_bzCompress
will no longer attempt to read data from
next_in
, but it will want to write data to next_out
.
Because the output buffer supplied by the user can be arbitrarily small,
the finishing-up operation cannot necessarily be done with a single call
of BZ2_bzCompress
.
Instead, the calling program passes BZ_FINISH
as an action to
BZ2_bzCompress
. This changes the stream's state to FINISHING. Any
remaining input (ie, next_in[0 .. avail_in-1]
) is compressed and
transferred to the output buffer. To do this, BZ2_bzCompress
must be
called repeatedly until all the output has been consumed. At that
point, BZ2_bzCompress
returns BZ_STREAM_END
, and the stream's
state is set back to IDLE. BZ2_bzCompressEnd
should then be
called.
Just to make sure the calling program does not cheat, the library makes
a note of avail_in
at the time of the first call to
BZ2_bzCompress
which has BZ_FINISH
as an action (ie, at the
time the program has announced its intention to not supply any more
input). By comparing this value with that of avail_in
over
subsequent calls to BZ2_bzCompress
, the library can detect any
attempts to slip in more data to compress. Any calls for which this is
detected will return BZ_SEQUENCE_ERROR
. This indicates a
programming mistake which should be corrected.
Instead of asking to finish, the calling program may ask
BZ2_bzCompress
to take all the remaining input, compress it and
terminate the current (Burrows-Wheeler) compression block. This could
be useful for error control purposes. The mechanism is analogous to
that for finishing: call BZ2_bzCompress
with an action of
BZ_FLUSH
, remove output data, and persist with the
BZ_FLUSH
action until the value BZ_RUN
is returned. As
with finishing, BZ2_bzCompress
detects any attempt to provide more
input data once the flush has begun.
Once the flush is complete, the stream returns to the normal RUNNING state.
This all sounds pretty complex, but isn't really. Here's a table
which shows which actions are allowable in each state, what action
will be taken, what the next state is, and what the non-error return
values are. Note that you can't explicitly ask what state the
stream is in, but nor do you need to -- it can be inferred from the
values returned by BZ2_bzCompress
.
IDLE/ |
That still looks complicated? Well, fair enough. The usual sequence of calls for compressing a load of data is:
BZ2_bzCompressInit
.
BZ2_bzCompress
with action = BZ_RUN
.
BZ2_bzCompress
with action = BZ_FINISH
,
copying out the compressed output, until BZ_STREAM_END
is returned.
BZ2_bzCompressEnd
.
BZ2_bzCompress ( ..., BZ_RUN )
and
just do the BZ2_bzCompress ( ..., BZ_FINISH )
calls.
All required memory is allocated by BZ2_bzCompressInit
. The
compression library can accept any data at all (obviously). So you
shouldn't get any error return values from the BZ2_bzCompress
calls.
If you do, they will be BZ_SEQUENCE_ERROR
, and indicate a bug in
your programming.
Trivial other possible return values:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzCompressEnd
int BZ2_bzCompressEnd ( bz_stream *strm ); |
Possible return values:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzDecompressInit
int BZ2_bzDecompressInit ( bz_stream *strm, int verbosity, int small ); |
BZ2_bzCompressInit
, a
bz_stream
record should be allocated and initialised before the
call. Fields bzalloc
, bzfree
and opaque
should be
set if a custom memory allocator is required, or made NULL
for
the normal malloc
/free
routines. Upon return, the internal
state will have been initialised, and total_in
and
total_out
will be zero.
For the meaning of parameter verbosity
, see BZ2_bzCompressInit
.
If small
is nonzero, the library will use an alternative
decompression algorithm which uses less memory but at the cost of
decompressing more slowly (roughly speaking, half the speed, but the
maximum memory requirement drops to around 2300k). See Chapter 2 for
more information on memory management.
Note that the amount of memory needed to decompress
a stream cannot be determined until the stream's header has been read,
so even if BZ2_bzDecompressInit
succeeds, a subsequent
BZ2_bzDecompress
could fail with BZ_MEM_ERROR
.
Possible return values:
|
Allowable next actions:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzDecompress
int BZ2_bzDecompress ( bz_stream *strm ); |
BZ2_bzDecompress
to transfer data between them.
Before each call to BZ2_bzDecompress
, next_in
should point at the compressed data,
and avail_in
should indicate how many bytes the library
may read. BZ2_bzDecompress
updates next_in
, avail_in
and total_in
to reflect the number of bytes it has read.
Similarly, next_out
should point to a buffer in which the uncompressed
output is to be placed, with avail_out
indicating how much output space
is available. BZ2_bzCompress
updates next_out
,
avail_out
and total_out
to reflect
the number of bytes output.
You may provide and remove as little or as much data as you like on
each call of BZ2_bzDecompress
.
In the limit, it is acceptable to
supply and remove data one byte at a time, although this would be
terribly inefficient. You should always ensure that at least one
byte of output space is available at each call.
Use of BZ2_bzDecompress
is simpler than BZ2_bzCompress
.
You should provide input and remove output as described above, and
repeatedly call BZ2_bzDecompress
until BZ_STREAM_END
is
returned. Appearance of BZ_STREAM_END
denotes that
BZ2_bzDecompress
has detected the logical end of the compressed
stream. BZ2_bzDecompress
will not produce BZ_STREAM_END
until
all output data has been placed into the output buffer, so once
BZ_STREAM_END
appears, you are guaranteed to have available all
the decompressed output, and BZ2_bzDecompressEnd
can safely be
called.
If case of an error return value, you should call BZ2_bzDecompressEnd
to clean up and release memory.
Possible return values:
|
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzDecompressEnd
int BZ2_bzDecompressEnd ( bz_stream *strm ); |
Possible return values:
|
Allowable next actions:
None. |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This interface provides functions for reading and writing
bzip2
format files. First, some general points.
int*
first argument,
bzerror
.
After each call, bzerror
should be consulted first to determine
the outcome of the call. If bzerror
is BZ_OK
,
the call completed
successfully, and only then should the return value of the function
(if any) be consulted. If bzerror
is BZ_IO_ERROR
,
there was an error
reading/writing the underlying compressed file, and you should
then consult errno
/perror
to determine the
cause of the difficulty.
bzerror
may also be set to various other values; precise details are
given on a per-function basis below.
bzerror
indicates an error
(ie, anything except BZ_OK
and BZ_STREAM_END
),
you should immediately call BZ2_bzReadClose
(or BZ2_bzWriteClose
,
depending on whether you are attempting to read or to write)
to free up all resources associated
with the stream. Once an error has been indicated, behaviour of all calls
except BZ2_bzReadClose
(BZ2_bzWriteClose
) is undefined.
The implication is that (1) bzerror
should
be checked after each call, and (2) if bzerror
indicates an error,
BZ2_bzReadClose
(BZ2_bzWriteClose
) should then be called to clean up.
FILE*
arguments passed to
BZ2_bzReadOpen
/BZ2_bzWriteOpen
should be set to binary mode.
Most Unix systems will do this by default, but other platforms,
including Windows and Mac, will not. If you omit this, you may
encounter problems when moving code to new platforms.
malloc
/free
.
At present
there is no facility for user-defined memory allocators in the file I/O
functions (could easily be added, though).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzReadOpen
typedef void BZFILE; BZFILE *BZ2_bzReadOpen ( int *bzerror, FILE *f, int small, int verbosity, void *unused, int nUnused ); |
f
. f
should refer to a file which has been opened for reading, and for which
the error indicator (ferror(f)
)is not set. If small
is 1,
the library will try to decompress using less memory, at the expense of
speed.
For reasons explained below, BZ2_bzRead
will decompress the
nUnused
bytes starting at unused
, before starting to read
from the file f
. At most BZ_MAX_UNUSED
bytes may be
supplied like this. If this facility is not required, you should pass
NULL
and 0
for unused
and nUnused
respectively.
For the meaning of parameters small
and verbosity
,
see BZ2_bzDecompressInit
.
The amount of memory needed to decompress a file cannot be determined
until the file's header has been read. So it is possible that
BZ2_bzReadOpen
returns BZ_OK
but a subsequent call of
BZ2_bzRead
will return BZ_MEM_ERROR
.
Possible assignments to bzerror
:
|
Possible return values:
Pointer to an abstract |
Allowable next actions:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzRead
int BZ2_bzRead ( int *bzerror, BZFILE *b, void *buf, int len ); |
len
(uncompressed) bytes from the compressed file
b
into
the buffer buf
. If the read was successful,
bzerror
is set to BZ_OK
and the number of bytes read is returned. If the logical end-of-stream
was detected, bzerror
will be set to BZ_STREAM_END
,
and the number
of bytes read is returned. All other bzerror
values denote an error.
BZ2_bzRead
will supply len
bytes,
unless the logical stream end is detected
or an error occurs. Because of this, it is possible to detect the
stream end by observing when the number of bytes returned is
less than the number
requested. Nevertheless, this is regarded as inadvisable; you should
instead check bzerror
after every call and watch out for
BZ_STREAM_END
.
Internally, BZ2_bzRead
copies data from the compressed file in chunks
of size BZ_MAX_UNUSED
bytes
before decompressing it. If the file contains more bytes than strictly
needed to reach the logical end-of-stream, BZ2_bzRead
will almost certainly
read some of the trailing data before signalling BZ_SEQUENCE_END
.
To collect the read but unused data once BZ_SEQUENCE_END
has
appeared, call BZ2_bzReadGetUnused
immediately before BZ2_bzReadClose
.
Possible assignments to bzerror
:
|
Possible return values:
number of bytes read if |
Allowable next actions:
collect data from |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzReadGetUnused
void BZ2_bzReadGetUnused ( int* bzerror, BZFILE *b, void** unused, int* nUnused ); |
*unused
is set to the address
of the data, and *nUnused
to the number of bytes. *nUnused
will
be set to a value between 0
and BZ_MAX_UNUSED
inclusive.
This function may only be called once BZ2_bzRead
has signalled
BZ_STREAM_END
but before BZ2_bzReadClose
.
Possible assignments to bzerror
:
|
Allowable next actions:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzReadClose
void BZ2_bzReadClose ( int *bzerror, BZFILE *b ); |
b
.
BZ2_bzReadClose
does not call fclose
on the underlying file
handle, so you should do that yourself if appropriate.
BZ2_bzReadClose
should be called to clean up after all error
situations.
Possible assignments to bzerror
:
|
Allowable next actions:
none |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzWriteOpen
BZFILE *BZ2_bzWriteOpen ( int *bzerror, FILE *f, int blockSize100k, int verbosity, int workFactor ); |
f
.
f
should refer to
a file which has been opened for writing, and for which the error
indicator (ferror(f)
)is not set.
For the meaning of parameters blockSize100k
,
verbosity
and workFactor
, see
BZ2_bzCompressInit
.
All required memory is allocated at this stage, so if the call
completes successfully, BZ_MEM_ERROR
cannot be signalled by a
subsequent call to BZ2_bzWrite
.
Possible assignments to bzerror
:
|
Possible return values:
Pointer to an abstract |
Allowable next actions:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzWrite
void BZ2_bzWrite ( int *bzerror, BZFILE *b, void *buf, int len ); |
len
bytes from the buffer buf
, eventually to be
compressed and written to the file.
Possible assignments to bzerror
:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzWriteClose
void BZ2_bzWriteClose ( int *bzerror, BZFILE* f, int abandon, unsigned int* nbytes_in, unsigned int* nbytes_out ); void BZ2_bzWriteClose64 ( int *bzerror, BZFILE* f, int abandon, unsigned int* nbytes_in_lo32, unsigned int* nbytes_in_hi32, unsigned int* nbytes_out_lo32, unsigned int* nbytes_out_hi32 ); |
Compresses and flushes to the compressed file all data so far supplied
by BZ2_bzWrite
. The logical end-of-stream markers are also written, so
subsequent calls to BZ2_bzWrite
are illegal. All memory associated
with the compressed file b
is released.
fflush
is called on the
compressed file, but it is not fclose
'd.
If BZ2_bzWriteClose
is called to clean up after an error, the only
action is to release the memory. The library records the error codes
issued by previous calls, so this situation will be detected
automatically. There is no attempt to complete the compression
operation, nor to fflush
the compressed file. You can force this
behaviour to happen even in the case of no error, by passing a nonzero
value to abandon
.
If nbytes_in
is non-null, *nbytes_in
will be set to be the
total volume of uncompressed data handled. Similarly, nbytes_out
will be set to the total volume of compressed data written. For
compatibility with older versions of the library, BZ2_bzWriteClose
only yields the lower 32 bits of these counts. Use
BZ2_bzWriteClose64
if you want the full 64 bit counts. These
two functions are otherwise absolutely identical.
Possible assignments to bzerror
:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The high-level library facilitates use of
bzip2
data streams which form some part of a surrounding, larger
data stream.
fflush
es it but does not fclose
it.
The calling application can write its own data before and after the
compressed data stream, using that same file handle.
BZ2_bzRead
reads from the compressed file in blocks of size
BZ_MAX_UNUSED
bytes, and in doing so probably will overshoot
the logical end of compressed stream.
To recover this data once decompression has
ended, call BZ2_bzReadGetUnused
after the last call of BZ2_bzRead
(the one returning BZ_STREAM_END
) but before calling
BZ2_bzReadClose
.
This mechanism makes it easy to decompress multiple bzip2
streams placed end-to-end. As the end of one stream, when BZ2_bzRead
returns BZ_STREAM_END
, call BZ2_bzReadGetUnused
to collect the
unused data (copy it into your own buffer somewhere).
That data forms the start of the next compressed stream.
To start uncompressing that next stream, call BZ2_bzReadOpen
again,
feeding in the unused data via the unused
/nUnused
parameters.
Keep doing this until BZ_STREAM_END
return coincides with the
physical end of file (feof(f)
). In this situation
BZ2_bzReadGetUnused
will of course return no data.
This should give some feel for how the high-level interface can be used. If you require extra flexibility, you'll have to bite the bullet and get to grips with the low-level interface.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
FILE* f; BZFILE* b; int nBuf; char buf[ /* whatever size you like */ ]; int bzerror; int nWritten; f = fopen ( "myfile.bz2", "w" ); if (!f) { /* handle error */ } b = BZ2_bzWriteOpen ( &bzerror, f, 9 ); if (bzerror != BZ_OK) { BZ2_bzWriteClose ( b ); /* handle error */ } while ( /* condition */ ) { /* get data to write into buf, and set nBuf appropriately */ nWritten = BZ2_bzWrite ( &bzerror, b, buf, nBuf ); if (bzerror == BZ_IO_ERROR) { BZ2_bzWriteClose ( &bzerror, b ); /* handle error */ } } BZ2_bzWriteClose ( &bzerror, b ); if (bzerror == BZ_IO_ERROR) { /* handle error */ } |
FILE* f; BZFILE* b; int nBuf; char buf[ /* whatever size you like */ ]; int bzerror; int nWritten; f = fopen ( "myfile.bz2", "r" ); if (!f) { /* handle error */ } b = BZ2_bzReadOpen ( &bzerror, f, 0, NULL, 0 ); if (bzerror != BZ_OK) { BZ2_bzReadClose ( &bzerror, b ); /* handle error */ } bzerror = BZ_OK; while (bzerror == BZ_OK && /* arbitrary other conditions */) { nBuf = BZ2_bzRead ( &bzerror, b, buf, /* size of buf */ ); if (bzerror == BZ_OK) { /* do something with buf[0 .. nBuf-1] */ } } if (bzerror != BZ_STREAM_END) { BZ2_bzReadClose ( &bzerror, b ); /* handle error */ } else { BZ2_bzReadClose ( &bzerror ); } |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzBuffToBuffCompress
int BZ2_bzBuffToBuffCompress( char* dest, unsigned int* destLen, char* source, unsigned int sourceLen, int blockSize100k, int verbosity, int workFactor ); |
source[0 .. sourceLen-1]
into the destination buffer, dest[0 .. *destLen-1]
.
If the destination buffer is big enough, *destLen
is
set to the size of the compressed data, and BZ_OK
is
returned. If the compressed data won't fit, *destLen
is unchanged, and BZ_OUTBUFF_FULL
is returned.
Compression in this manner is a one-shot event, done with a single call
to this function. The resulting compressed data is a complete
bzip2
format data stream. There is no mechanism for making
additional calls to provide extra input data. If you want that kind of
mechanism, use the low-level interface.
For the meaning of parameters blockSize100k
, verbosity
and workFactor
,
see BZ2_bzCompressInit
.
To guarantee that the compressed data will fit in its buffer, allocate an output buffer of size 1% larger than the uncompressed data, plus six hundred extra bytes.
BZ2_bzBuffToBuffDecompress
will not write data at or
beyond dest[*destLen]
, even in case of buffer overflow.
Possible return values:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BZ2_bzBuffToBuffDecompress
int BZ2_bzBuffToBuffDecompress ( char* dest, unsigned int* destLen, char* source, unsigned int sourceLen, int small, int verbosity ); |
source[0 .. sourceLen-1]
into the destination buffer, dest[0 .. *destLen-1]
.
If the destination buffer is big enough, *destLen
is
set to the size of the uncompressed data, and BZ_OK
is
returned. If the compressed data won't fit, *destLen
is unchanged, and BZ_OUTBUFF_FULL
is returned.
source
is assumed to hold a complete bzip2
format
data stream.
BZ2_bzBuffToBuffDecompress
tries to decompress
the entirety of the stream into the output buffer.
For the meaning of parameters small
and verbosity
,
see BZ2_bzDecompressInit
.
Because the compression ratio of the compressed data cannot be known in advance, there is no easy way to guarantee that the output buffer will be big enough. You may of course make arrangements in your code to record the size of the uncompressed data, but such a mechanism is beyond the scope of this library.
BZ2_bzBuffToBuffDecompress
will not write data at or
beyond dest[*destLen]
, even in case of buffer overflow.
Possible return values:
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
zlib
compatibility functions zlib
compatibility. These functions are
BZ2_bzopen
, BZ2_bzread
, BZ2_bzwrite
, BZ2_bzflush
,
BZ2_bzclose
,
BZ2_bzerror
and BZ2_bzlibVersion
.
These functions are not (yet) officially part of
the library. If they break, you get to keep all the pieces.
Nevertheless, I think they work ok.
typedef void BZFILE; const char * BZ2_bzlibVersion ( void ); |
BZFILE * BZ2_bzopen ( const char *path, const char *mode ); BZFILE * BZ2_bzdopen ( int fd, const char *mode ); |
.bz2
file for reading or writing, using either its name
or a pre-existing file descriptor.
Analogous to fopen
and fdopen
.
int BZ2_bzread ( BZFILE* b, void* buf, int len ); int BZ2_bzwrite ( BZFILE* b, void* buf, int len ); |
BZFILE
.
Analogous to fread
and fwrite
.
int BZ2_bzflush ( BZFILE* b ); void BZ2_bzclose ( BZFILE* b ); |
BZFILE
. BZ2_bzflush
doesn't actually do
anything. Analogous to fflush
and fclose
.
const char * BZ2_bzerror ( BZFILE *b, int *errnum ) |
b
, and also sets *errnum
to its numerical value.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
stdio
-free environment
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
stdio
In a deeply embedded application, you might want to use just
the memory-to-memory functions. You can do this conveniently
by compiling the library with preprocessor symbol BZ_NO_STDIO
defined. Doing this gives you a library containing only the following
eight functions:
BZ2_bzCompressInit
, BZ2_bzCompress
, BZ2_bzCompressEnd
BZ2_bzDecompressInit
, BZ2_bzDecompress
, BZ2_bzDecompressEnd
BZ2_bzBuffToBuffCompress
, BZ2_bzBuffToBuffDecompress
When compiled like this, all functions will ignore verbosity
settings.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
libbzip2
contains a number of internal assertion checks which
should, needless to say, never be activated. Nevertheless, if an
assertion should fail, behaviour depends on whether or not the library
was compiled with BZ_NO_STDIO
set.
For a normal compile, an assertion failure yields the message
bzip2/libbzip2: internal error number N. This is a bug in bzip2/libbzip2, 1.0.2, 30-Dec-2001. Please report it to me at<EMAIL_ADDRESS>If this happened when you were using some program which uses libbzip2 as a component, you should also report this bug to the author(s) of that program. Please make an effort to report this bug; timely and accurate bug reports eventually lead to higher quality software. Thanks. Julian Seward, 30 December 2001. |
N
is some error code number. If N == 1007
, it also
prints some extra text advising the reader that unreliable memory is
often associated with internal error 1007. (This is a
frequently-observed-phenomenon with versions 1.0.0/1.0.1).
exit(3)
is then called.
For a stdio
-free library, assertion failures result
in a call to a function declared as:
extern void bz_internal_error ( int errcode ); |
In either case, once an assertion failure has occurred, any
bz_stream
records involved can be regarded as invalid.
You should not attempt to resume normal operation with them.
You may, of course, change critical error handling to suit your needs. As I said above, critical errors indicate bugs in the library and should not occur. All "normal" error situations are indicated via error return codes from functions, and can be recovered from.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
<EMAIL_ADDRESS>/
<EMAIL_ADDRESS>), so you should send your queries to
him (but perhaps Cc: me<EMAIL_ADDRESS>).
My vague understanding of what to do is: using Visual C++ 5.0,
open the project file libbz2.dsp
, and build. That's all.
If you can't
open the project file for some reason, make a new one, naming these files:
blocksort.c
, bzlib.c
, compress.c
,
crctable.c
, decompress.c
, huffman.c
,
randtable.c
and libbz2.def
. You will also need
to name the header files bzlib.h
and bzlib_private.h
.
If you don't use VC++, you may need to define the proprocessor symbol
_WIN32
.
Finally, dlltest.c
is a sample program using the DLL. It has a
project file, dlltest.dsp
.
If you just want a makefile for Visual C, have a look at
makefile.msc
.
Be aware that if you compile bzip2
itself on Win32, you must set
BZ_UNIX
to 0 and BZ_LCCWIN32
to 1, in the file
bzip2.c
, before compiling. Otherwise the resulting binary won't
work correctly.
I haven't tried any of this stuff myself, but it all looks plausible.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |


Hello, my name is Kate Adams! If you in search of an interior designer, I can help you! Check my works on this page, or visit my studio, it is opened from 9:15 am to 4:45 pm on business days.Reading of professional and fiction literature. Swimming, fitness, yoga (no extreme). Active recreation in nature. Visiting the cinema, museums, exhibitions.
Education is necessary and very important. Just getting it is not a finale. This is the beginning or the continuation of the practical realization of oneself as an individual. Expansion of the outlook, intellectual development, sociability, oratory, communication with adequate people, the ability to find a way out of a difficult situation through negotiations.
Check out my Works


Sept. 07, 2015
When setting up webpage with CSS, tiny differences can make huge changes. Positioning, display, floats and space are all important to the importance your site. The differences between the positioning values can be dramatic.
First things first, you need to know a few terms.
 Please see the graphic below.
Let's start with the default setting, which is static. There’s nothing really special about it, the image will go with the normal flow of the page. It cannot be moved with properties like top, right, bottom and left. The most important thing to remember is that this where all your placements start. If you don't specify otherwise, your image will have a static position value.
The relative value moves an element in relation to its static position. When you use the position: relative; ruleset, you use additional properties, like top, right, bottom and left to direct the object where you want it to be. For the example: top: 5em; imagine the element starting in it's static position, adding 5 em to top effectively inserts 5 em between the static position and where the element now appears. It lowers your element 5ems.
The fixed property is a pretty interesting one. I would say it should be used sparingly. When you use the fixed position property, an element stays in the same place on the screen, regardless of scrolling and resizing. If you put it in upper right corner of you page, it will always be there!
The last positioning value is absolute. This one is a little tricky. Instead of being linked in relation to the flow of the page or the browser, it’s linked to the nearest positioned object. (A positioned object is just any object that isn’t static.) What this really means is that it can be relative to other relative objects on the screen, or to fixed objects. It’s a pretty useful thing, but it takes a little work to get used to it. I recommend just putting in some different values and watching the way the objects move in relation to each other.


QRCode reader plugin examples
Single input (settings in data attributes: no audio, regexp to match URLs):
Read QRCode
Single input (rebound click, depending on target input's content):
Read or follow QRCode
Multiple input (settings in data attributes: exclude duplicates, disable repeat timeout):
Read QRCodes
Multiple input 2 (include duplicates, settings in runtime call):
Read QRCodes
Multiple input 3 (settings in data attributes overridden in runtime call):
Read QRCodes


New York, NY, United States
The Golden Retriever is a large-sized breed of dog bred as gun dogs to retrieve shot waterfowl such as ducks and upland game birds during hunting and shooting parties and were named 'retriever' because of their ability to retrieve shot game undamaged. Golden Retrievers have an instinctive lover of water and are easy to train to basic or advanced obedience standards.
Contact Owner


{% extends "horizon/common/_modal_form.html" %} {% load i18n %} {% block modal-body-right %}
{% block title %}{% trans "Volumes are block devices that can be attached to instances." %}{% endblock %}


Copyright (c) 1999 Jacob Zunti, Saskatchewan Internet News
This game is played on the following square board:
The board is cylindrical, i.e., the right column is adjacent to the left column. Each player starts with 15 stones off board.
|
| An example Black's turn on 2nd phase. He slides the marked stone to the green dot making a 3 in-a-row, choosing to capture the marked white stone (to prevent f1 of making a vertical 3 in-a-row on that column). |
This is a modern variant of Nine Men Morris, with additional stones, a different board topology (in the original game, a Pentagon) and an extra rule (the liberty to move with less than six stones) to balance the endgame.


Toggle navigation
Promise Demo
Home
Promise Demo
Load Games
Title
NA Release
EU Release
Publisher
{{game.title}}
{{game.na_releaseDate}}
{{game.eu_releaseDate}}
{{game.publisher}}


This Probably Won't Do Anything...
Alcohol, Cannabis & Mushrooms - P. cubensis (smoked)
I was visiting with some old friends back in my hometown after being a way for a while. As tends to happen with this group, we ended up putting away a few cases of beer, numerous joints, and began the search for other means of intoxication. This wasn't a group that was looking for spiritual enlightenment, or personal insight. We had all grown up and experimented with drugs together in this small town. A few years after high school alot of us had drifted off into other lives with different friends, interests, and jobs. I say this to try and explain our headspace at the time. We were all searching to recapture that feeling of being young and together. Invincible and insane. Some one mentioned that they had a few caps of mushrooms left. Barely enough for one person to enjoy.
We decided to smoke the caps. Figuring nothing would happen. The bong is passed to me. I inhale deeply. The smoke is earthy and thick. I don't feel anything. Too bad, we think. Let's go hiking. About 20 minutes later we find ourselves at the top of a bluff overlooking the city in the middle of the night. I feel an uneasy anxiousness, not unlike the come up of a mushroom trip, creeping up my stomach and tingling through my arms. We all start to look at each other and smile. Something is different. Something is definately happening. I start to run in a large circle around every one. One by one, every one starts running at top speed in a circle in the pitch dark on top of a large hill overlooking our hometown. I had so much energy. The lights from the city were swirling and twisting. All I could hear was the distorted breathing of 10 guys as we ran as fast as we could. We must have ran in that circle for two hours. Non stop. Not saying a thing. Definately tripping.
I had heard that smoking mushrooms was a waste of time, money and stash. I haven't done it since, but it was one of the strongest experiences I've had.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


This opening stage sets the stage (pun intended) for the rest of the course. It gives a high-level overview of the internet (Part 1) and then jumps into basic HTML structure and commands (Part 2).
Part 1 (a.k.a How the Web Works)The Internet connects to the various servers through a protocal called HTTP. This video here gives a great overview.
Part 2 (HTML = Hyper Text Markup Language)The web is mainly made up of HTML pages. An HTML page has 4 main components
1. Text (what you see or 'content')
2. Markup (what it looks like)
3. References (images, videos)
4. Links (other web pages)
Part 2 mainly focuses on the second component of the HTML page.
A Tag directs a specific action. We learned the b (bold),
br (break), a (anchor), em (emphasis), img (image), p (paragraph)
tags. Some of these tags are "Inline" (e.g. b, br) and some are
"Block" (e.g. p). The main difference to know now is that "Block"
tags essentially put an invisible box around the content.
An Element is the tag and the content that the tag surrounds
An Attribute is a property of the Element
Finally, we reviewed how a complete HTML document looks (Doc Type, Opening HTML Tag, Header/Meta Data, Body/Content, Closing HTML tag). Good video reference here
Key Items to Remember:


Preliminary Published Research
Using a subset of the preliminary research we conducted for our Harry Frank Guggenheim grant application, we published an accessible version of our findings in the Washington Post and an abridged version of our methodology on GitHub.
Like we discuss in our application, the Harry Frank Guggenheim Foundation grant would allow us to expand this research and make it even more accessible and useful for other researchers, academics, and the general public.
Dissemination of Research Findings
We hope that the Harry Frank Guggenheim foundation will consider the DroneScout website, and the server expenses associated with it, to not be in violation of their policy to not support the dissemination of research findings with grant funds.
While we understand and agree with the motiviations and reasoning to enforce such a policy against publication and conference fees, we believe the DroneScout website is an exception to this rule, as it is evidently different from using research funds for conference travel or publication fees.
We consider the DroneScout website, while untraditional, an essential aspect of our research: it will support our strike search, government analysis, and strike multimedia collection.


--- layout: post title: SVN post-commit hook cronjob date: 2010-04-04 14:08:17.000000000 +02:00 categories: - Opensource - Technical tags: - python - svn status: publish type: post published: true meta: _edit_last: '10173910' _wpas_done_twitter: '1' author: login: saherneklawy email<EMAIL_ADDRESS>display_name: saherneklawy first_name: '' last_name: '' excerpt: !ruby/object:Hpricot::Doc options: {} ---
Few SVN hosting sites provide ssh access to their svn servers. Such is needed to create hooks, like a post-commit hook that sends an email with every commit. Such hooks are often required by the development team. This article discusses the creation of a cron job that polls the SVN repository to simulate a post-commit hook that sends an email with every commit.
sendEmail is a nice tool to send emails via command line. This is needed to script in the cronjob sending an email. On ubuntu, install it from apt-get by:
sudo apt-get install sendemail libio-socket-ssl-perl libcrypt-ssleay-perl
The latter 2 packages are needed for connecting to an SMTP server that uses a secure connection (like Gmail, which is used in the example).
The following is a python script, that could be added as an entry in the cron table
[sourcecode language="python"]
#! /usr/bin/env python
import os,re
log_file = LOG_DIR
svn_log_seperator = '------------------------------------------------------------------------'
svn_dir = SVN_DIR
mail_filter = '[special mail identifier in subject]'
message_file = '/tmp/commit_mail'
mail_from = MAIL_FROM
mail_to = MAIL_TO
smtp_server = "smtp.gmail.com:587"
smtp_user = SMTP_USER
smtp_pass = SMTP_PASS
def send_mail(subject,mail):
mail_file = open(message_file,'w')
mail_file.write(mail)
mail_file.close()
mail_command = 'sendEmail -f %s -t %s -u "%s" -s %s -xu "%s" -xp "%s" -o message-file="%s"' % (mail_from, mail_to, subject, smtp_server, smtp_user, smtp_pass,message_file)
print mail_command
os.system(mail_command)
print "analyzing old log file"
old_log_f = open(log_file)
old_log = old_log_f.read().split(svn_log_seperator)
old_log_f.close()
print "updating svn"
os.system("/usr/local/bin/svn update %s" % svn_dir)
os.system("/usr/local/bin/svn log %s > %s" % (svn_dir,log_file))
print "got new log"
new_log_f = open(log_file)
new_log = new_log_f.read().split(svn_log_seperator)
new_log_f.close()
delta = set(new_log) - set(old_log)
for commit in delta:
l = [x for x in commit.split('\n') if x]
details = l[0].split('|')
subject = "%s %s %s" %(mail_filter,details[0],details[1])
f_diff=os.popen('/usr/local/bin/svn diff -c %s %s' % (details[0], svn_dir))
diff = f_diff.read()
f_diff.close()
mail = "%s\n%s" % (commit, diff)
send_mail(subject,mail)
[/sourcecode]
svn log > $PATH_TO_LOG_FILE


Style.really_get_image
really_get_image(path, [colorkey, [nocache]]) -> pygame.Surface
path should be a sting. Example: really_get_image("data/image/my_image.png") Use forward slashed as demonstrated even if you are developing under windows, it will open the files os independent.
StyleSet
StyleSet(widget, [parent]) -> StyleSet objectA styleset is a collection of style options grouped together for a specific event for a widget. Each widget has an dictionary named "stylesets" which contains several stylesets. For example:
{"disabled":styleset, "hover":styleset, "default":styleset, "focused":styleset, "down":styleset}
When the widget is hovered for example it will use stylesets["hover"] At any time you can change a styling option for a widget by doing something like this:
mywidget.stylesets["hover"]["color"] = (255,10,10)
Style options
| option | value |
|---|---|
| padding | 8 4 4 5 | 4 5 | 10 |
| padding-top | 3 |
| padding-right | 3 |
| padding-bottom | 3 |
| padding-left | 3 |
| color | (255,255,255) |
| font-weight | normal | bold |
| font-family | Verra.ttf |
| font-size | 12 |
| effect | pulsate 5 |
| width | 300 |
| height | 200 |
| x | 57 |
| y | 102 |
| position | relative | absolute |
| bgcolor | (200,0,0) |
| bgimage | image.png repeat|repeat-x|repeat-y|no-repeat|slice |
| border | 3 (0,250,20) |
| spacing | 12 # For certain container widgets. |
| opacity | 25 # Alpha value. Valid otpions between 0 and 255. |
| antialias | 1 | 0 |
| align | left | right | center |
| valign | top | bottom | center |
Something to note about align and valign. When they are changed from their default values (top and left), the x and y values act as an offset. So if you are aligning a widget center and have an x value of 100, the widget will display 100 pixels to the right of the center of it's parent (or container) widget.
Also, aligning only takes effect when positioning is relative (which is default).
Arguments
- widget
- The widget this styleset is for.
- parent
- Another styleset that this styleset should inherit from.
StyleSet.surf
StyleSet.surf -> pygame.SurfaceThe surface generated from the styling.
StyleSet.apply
StyleSet.apply(surf, option, values) -> pygame.SurfaceApplies styling to surf. If you are just wanting to change a style option, use:
StyleSet["option"] = values
This function is mainly for internal use.


midori - fast and lightweight web browser
midori [OPTION...] [URL]
midori is a lightweight web browser.
-v, --version Display program version
--display=DISPLAY X display to use
-?, --help Show help options
--help-all Show all help options
--help-gtk Show GTK+ Options
Please report comments, suggestions and bugs to<EMAIL_ADDRESS>Check for new versions at: http://software.twotoasts.de
Midori is copyright (C) 2007 Christian Dywan.
This manual page was written by Emanuele Rocca<EMAIL_ADDRESS>for the Debian GNU/Linux system (but may be used by others).
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation.


Your ip is: {{ip}} (from: {{ipname}})
{{comment.umail}} posted in {{comment.date}}: {{comment.comment}}


OT - A quick post on using gpg to manage github in Linux
20 Apr 2017After being used to OSX Keychains in my old mac, I wanted a similar functionality on my Linux laptop. Being prompted each time to login, while interacting with github for instance was annoying. Searching the web, led me to git-credential-store. I was not too happy with the fact that credentials would be stored in clear text, locally, indefinitely. I came across this stackoverflow post that I adapted for Linux. The concept is as follows:
- Use a .netrc file to store your credentials. This follows the file format for netrc
- Encrypt this file, using GNU Privacy Guard
- Download and add the git credential helper script to your path.
- Update git config to tell it to use the encrypted credentials file
STEP 1: The .netrc file
As described in the link above, the .netrc file follows a standard and looks like this:
We save this in our home directory - this is obviously clear-text. We will now encrypt the file and delete the clear-text one
STEP 2: Encrypt the .netrc file
GNU Privacy Guard, was new to me. Solving this specific problem also taught me about how to use GPG in general to sign and encrypt any piece of data that needs to be exchanged securely. The basic premise is we create a public/private key pair, similar to SSH. This is stored in a “key-ring” on our computer. We can potentially add other trusted public-keys to this key-ring and decrypt/verify files that are signed by the sender’s private key. For our example, here is how I did it:
GENERATE THE KEY PAIRS
After moving the mouse around for a bit:
You can see the keyring :
Now we can use our private key to encrypt the .netrc file
(I had to specify a recipient. In our case since github was going to use my email id as the ‘end-user’ to decrypt the .netrc file, I specified it as the recipient)
At this point, you may delete your clear text .netrc and will be left with a .netrc.gpg file
STEP 3: Download and add the git credential helper:
This perl script is
used by git to unencrypt the .netrc.gpg file. So you will need to make
it executable and store it in a directory in your $PATH
variable.
curl -o /home/ajay/bin/git-credential-netrc https://raw.github.com/git/git/master/contrib/credential/netrc/git-credential-netrc
STEP 4: Tell git about the encrypted credentials
Finally, you use the git config command to inform git to use the credential helper. This is when you also point it to the location of the newly encrypted .netrc.gpg file.
git config --local credential.helper "netrc -f /home/ajay/.netrc.gpg -v -d"
( The -v and -d are diagnostic flags - verbose/debug. This helps you track issues if you run into any. )
If you happen to follow these steps and if you had any questions, I would be happy to help and hopefully better my understanding as well.
Twitter: Share it with your followers or Follow me on Twitter!


Berkeley DB 4.7 thru 6.1 Python Extension Package¶
Introduction¶
This is a simple bit of documentation for the bsddb3.db Python extension module which wraps the Berkeley DB 4.7 thru 6.1 C library. The extension module is located in a Python package along with a few pure python modules.
It is expected that this module will be used in the following general ways by different programmers in different situations. The goals of this module are to allow all of these methods without making things too complex for the simple cases, and without leaving out funtionality needed by the complex cases.
- Backwards compatibility: It is desirable for this package to be a near drop-in replacement for the bsddb module shipped with Python which is designed to wrap either DB 1.85, or the 1.85 compatibility interface. This means that there will need to be equivalent object creation functions available, (btopen(), hashopen(), and rnopen()) and the objects returned will need to have the same or at least similar methods available, (specifically, first(), last(), next(), and prev() will need to be available without the user needing to explicitly use a cursor.) All of these have been implemented in Python code in the bsddb3.__init__.py module.
- Simple persistent dictionary: One small step beyond the above. The programmer may be aware of and use the new DB object type directly, but only needs it from a single process and thread. The programmer should not have to be bothered with using a DBEnv, and the DB object should behave as much like a dictionary as possible.
- Concurrent access dictionaries: This refers to the ability to simultaneously have one writer and multiple readers of a DB (either in multiple threads or processes) and is implemented simply by creating a DBEnv with certain flags. No extra work is required to allow this access mode in bsddb3.
- Advanced transactional data store: This mode of use is where the full capabilities of the Berkeley DB library are called into action. The programmer will probably not use the dictionary access methods as much as the regular methods of the DB object, so he can pass transaction objects to the methods. Again, most of this advanced functionality is activated simply by opening a DBEnv with the proper flags, and also by using transactions and being aware of and reacting to deadlock exceptions, etc.
Types Provided¶
The bsddb3.db extension module provides the following object types:
- DB: The basic database object, capable of Hash, BTree, Recno, and Queue access methods.
- DBEnv: Provides a Database Environment for more advanced database use. Apps using transactions, logging, concurrent access, etc. will need to have an environment object.
- DBCursor: A pointer-like object used to traverse a database.
- DBTxn: A database transaction. Allows for multi-file commit, abort and checkpoint of database modifications.
- DBLock: An opaque handle for a lock. See DBEnv.lock_get() and DBEnv.lock_put(). Locks are not necessarily associated with anything in the database, but can be used for any syncronization task across all threads and processes that have the DBEnv open.
- DBSequence: Sequences provide an arbitrary number of persistent objects that return an increasing or decreasing sequence of integers. Opening a sequence handle associates it with a record in a database.
- DBSite: Site object for Replication Manager.
Top level functions¶
-
version
()¶ Returns a tuple with major, minor and patch level. More info...
-
full_version
()¶ Returns a tuple with the full version string, family, release, major, minor and patch level. More info...
Exceptions Provided¶
The Berkeley DB C API uses function return codes to signal various errors. The bsddb3.db module checks for these error codes and turns them into Python exceptions, allowing you to use familiar try:... except:... constructs and not have to bother with checking every method’s return value.
Each of the error codes is turned into an exception specific to that error code, as outlined in the table below. If you are using the C API documentation then it is very easy to map the error return codes specified there to the name of the Python exception that will be raised. Simply refer to the table below.
Each exception derives from the DBError exception class so if you just want to catch generic errors you can use DBError to do it. Since DBNotFoundError is raised when a given key is not found in the database, DBNotFoundError also derives from the standard KeyError exception to help make a DB look and act like a dictionary. We do the same trick with DBKeyEmptyError.
When any of these exceptions is raised, the associated value is a tuple containing an integer representing the error code and a string for the error message itself.
DBError Base class, all others derive from this DBCursorClosedError When trying to use a closed cursor DBForeignConflictError DB_FOREIGN_CONFLICT DBKeyEmptyError DB_KEYEMPTY (also derives from KeyError) DBKeyExistError DB_KEYEXIST DBLockDeadlockError DB_LOCK_DEADLOCK DBLockNotGrantedError DB_LOCK_NOTGRANTED DBNotFoundError DB_NOTFOUND (also derives from KeyError) DBOldVersionError DB_OLD_VERSION DBPageNotFoundError DB_PAGE_NOTFOUND DBRepHandleDeadError DB_REP_HANDLE_DEAD DBRepLeaseExpiredError DB_REP_LEASE_EXPIRED DBRepLockoutError DB_REP_LOCKOUT DBRepUnavailError DB_REP_UNAVAIL DBRunRecoveryError DB_RUNRECOVERY DBSecondaryBadError DB_SECONDARY_BAD DBVerifyBadError DB_VERIFY_BAD DBNoServerError DB_NOSERVER DBNoServerHomeError DB_NOSERVER_HOME DBNoServerIDError DB_NOSERVER_ID DBInvalidArgError EINVAL DBAccessError EACCES DBNoSpaceError ENOSPC DBNoMemoryError DB_BUFFER_SMALL DBAgainError EAGAIN DBBusyError EBUSY DBFileExistsError EEXIST DBNoSuchFileError ENOENT DBPermissionsError EPERM
Other Package Modules¶
- dbshelve.py: This is an implementation of the standard Python shelve concept for storing objects that uses bsddb3 specifically, and also exposes some of the more advanced methods and capabilities of the underlying DB.
- dbtables.py: This is a module by Gregory Smith that implements a simplistic table structure on top of a DB.
- dbutils.py: A catch-all for python code that is generally useful when working with DB’s
- dbobj.py: Contains subclassable versions of DB and DBEnv.
- dbrecio.py: Contains the DBRecIO class that can be used to do partial reads and writes from a DB record using a file-like interface. Contributed by Itamar Shtull-Trauring.
 PyUnit is used and the tests are structured such that they can be run unattended and automated. There are currently 482 test cases! (March 2010)
Reference¶
See the C language API online documentation on Oracle’s website for more details of the functionality of each of these methods. The names of all the Python methods should be the same or similar to the names in the C API.
Berkeley DB is very powerful and versatile, but it is complex to use correctly. Oracle documentation is very complete. Please, review it.
NOTE: All the methods shown below having more than one keyword argument are actually implemented using keyword argument parsing, so you can use keywords to provide optional parameters as desired. Those that have only a single optional argument are implemented without keyword parsing to help keep the implementation simple. If this is too confusing let me know and I’ll think about using keywords for everything.


Contributing to Ruby OpenSSL¶ ↑
Thank you for your interest in contributing to Ruby OpenSSL!
This documentation provides an overview how you can contribute.
Bugs and feature requests¶ ↑
Bugs and feature requests are tracked on GitHub.
If you think you found a bug, file a ticket on GitHub. Please DO NOT report security issues here, there is a separate procedure which is described on “Security at ruby-lang.org”.
When reporting a bug, please make sure you include the version of Ruby, the version of openssl gem, the version of the OpenSSL library, along with a sample file that illustrates the problem or link to repository or gem that is associated with the bug.
There is a number of unresolved issues and feature requests for openssl that need review. Before submitting a new ticket, it is recommended to check known issues and bugs.ruby-lang.org, the previous issue tracker.
Submitting patches¶ ↑
Patches are also very welcome!
Please submit a pull request with your changes.
Make sure that your branch does:
-
Have good commit messages
-
Follow Ruby's coding style (DeveloperHowTo)
-
Pass the test suite successfully (see “Testing”)
-
Add an entry to History.md if necessary
Testing¶ ↑
We have a test suite!
Test cases are located under the test/ directory.
You can run it with the following three commands:
$ rake install_dependencies # installs rake-compiler, test-unit, ... $ rake compile $ rake test
Docker¶ ↑
You can also use Docker Compose to run tests. It can be used to check that your changes work correctly with various supported versions of Ruby and OpenSSL.
First, you need to install Docker and Docker Compose on your computer.
If you're on MacOS or Windows, we recommended to use the official Docker Toolbox. On Linux, follow the instructions for your package manager. For further information, please check the official documentation.
Once you have Docker and Docker Compose, running the following commands will build the container and execute the openssl tests. In this example, we will use Ruby version 2.3 with OpenSSL version 1.0.2.
$ docker-compose build $ export RUBY_VERSION=ruby-2.3 $ export OPENSSL_VERSION=openssl-1.0.2 $ docker-compose run test # You may want an interactive shell for dubugging $ docker-compose run debug
All possible values for RUBY_VERSION
and
OPENSSL_VERSION
can be found in .travis.yml.
NOTE: these commands must be run from the openssl repository root, in order to use the docker-compose.yml file we have provided.
This Docker image is built using the Dockerfile provided in the repository.
Relation with Ruby source tree¶ ↑
After Ruby 2.3, ext/openssl
was converted into a “default
gem”, a library which ships with standard Ruby builds but can be upgraded
via RubyGems. This means the development of this gem has migrated to a separate repository and will be
released independently.
The version included in the Ruby source tree (trunk branch) is synchronized with the latest release.
Release policy¶ ↑
Bug fixes (including security fixes) will be made only for the version series included in a stable Ruby release.
Security¶ ↑
If you discovered a security issue, please send us in private, using the security issue handling procedure for Ruby core.
You can either use HackerOne or send an email to<EMAIL_ADDRESS>Please see Security page on ruby-lang.org website for details.
Reported problems will be published after a fix is released.
Thanks for your contributions!
- The Ruby OpenSSL team


A project is a place to manage a group of people working on a common set of tasks. It is similar to a tribe in providing a wiki and threaded discussion but is invitation only and adds issue tracking.
{% if user.is_authenticated %}{% trans "Start your own project" %}
{% else %} {% url acct_signup as signup_url %} {% url acct_login as login_url %}{% blocktrans %}Sign up and log in to create your own project or join an existing one.{% endblocktrans %}
{% endif %} {% if objects %} {% display_search %} {% display_ordering %} {% autopaginate objects %}No projects have been created yet.
{% endif %} {% endblock %}


s6-portable-utils
Software
skarnet.org
The s6-ls program
s6-ls lists the contents of a directory.
Interface
s6-ls [ -0 ] [ -a | -A ] [ -x exclude ] dir
s6-ls lists the contents of dir, one file per line. It
omits files starting with a dot.
Options
- -0 : separate file names with a null character
instead of a newline.
- -a : do not omit files starting with a dot. Do
not list . or .. though.
- -A : do not omit files starting with a dot, even
. and ..
- -x exclude : if a file name is
exclude, do not print it.
Posixness
s6-ls is not suitable as a Single Unix
ls
program.


This page contains a brief explaination of the tracker UDP protocol.
- Note
- The official and detailed specification can be found at http://www.bittorrent.org/beps/bep_0015.html
- Why use UDP Tracker Protocol insted of HTTP?
- Initially the Bittorrent protocol specify that the only way to contact the tracker and craft the appropriate request was via HTTP GET request. In 2008 the protocol become extremely popular and the overhead caused by this choice start becoming a problem. (See link for detailed overhead estimation). Depending on the case the tracker should be contacted from a period to 30 minutes to 30 seconds, so a new protocol extension that uses UDP insted of TCP was created. With this approach only (in the ideal case) two packets are necessary to complete the tracker request. Obviously due the unreliable nature of the UDP protocol the application is responsible for manage retransmission in case of packet loss.
- Our procotol implementation
- alphaTorrent doesn't implement the protocol completely (at the moment) and this list contains a list of all features lacks:
- Timeout : The application does not retransmit the request if a timeout occurs, it simply consider the peer dead.
- IPv6 support : IPv6 announce response is not supported (neither implemented).
- Scrape request : Scrape request (and response) are not supported (neither implemented).
- Connection ID verification : No check is perfomed on the connection_id (while the procotol say that is should be done).


#include <texture.h>
Inheritance diagram for Texture:
Public Member Functions | |
| virtual Bool | Load (Render3D *render_, const Char *name_) |
| Loads texture from file. | |
| Int | GetWidth () |
| Returns texture width. | |
| Int | GetHeight () |
| Returns texture height. | |
| const string & | GetName () const |
| Returns name of texture. | |
| Render3D * | GetRender () |
| Returns pointer to Render3D object. | |
Static Public Member Functions | |
| static ObjRef< Texture > | New () |
| Creates new Texture object. | |
Protected Member Functions | |
| Texture () | |
| Default constructor. | |
| ~Texture () | |
| Destructor. |
|
|
Returns texture height.
|
|
|
Returns name of texture.
|
|
|
Returns pointer to Render3D object.
|
|
|
Returns texture width.
|
|
|
Loads texture from file.
|
|
|
Creates new Texture object. Call this function instead constructor calling.
Reimplemented in LightMap. |


---
layout: post
title: I Have To Go To Japan
tags:
- Articles
- Black and White
- film
- General Photography
- Nikon FM3a
status: publish
type: post
published: true
meta:
aktt_notify_twitter: "yes"
_edit_last: "2"
_edit_lock: "1282218670"
_thumbnail_id: "2150"
ghostpool_post_template: Default
ghostpool_link: Post/Page
ghostpool_post_image: http://photo.rwboyer.com/wp-content/uploads/2010/08/DSC_1019-Version-3.jpg
ghostpool_post_faded_image: http://photo.rwboyer.com/wp-content/uploads/2010/08/DSC_1019-Version-3.jpg
ghostpool_circle_image: http://photo.rwboyer.com/wp-content/uploads/2010/08/DSC_1019-Version-3.jpg
ghostpool_port_image_small: http://photo.rwboyer.com/wp-content/uploads/2010/08/DSC_1019-Version-3.jpg
ghostpool_slider_image: http://photo.rwboyer.com/wp-content/uploads/2010/08/DSC_1019-Version-3.jpg
aktt_tweeted: "1"
_wp_old_slug: ""
dsq_thread_id: "371050763"
---
I just love some of these Japanese photographers. They produce some of the coolest images with the most meager of gear. Should I learn the language first? I am actually serious about the Japan visit - even if just for a vacation and to see some of what I understand are a ton of photography exhibitions that are all over the place.
Anyway, remember this site I linked to a while ago that displays images of the cameras people carry around Tokyo? Well his latest post was about Michio Yamauchi's camera that he was carrying, an FM3a. One of the reasons that I love that site in addition to reassuring me that I am not the only nut shooting old cameras and film is that at least once a week I stumble across a photographer with really nice work. Check out Michio Yamauchi’s. You have to see the photos on his "news" page all of them are really cool but the jumping cat from below against the city scape is awesome, hurry before he updates it and it is gone.
RB


|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object com.tcl.lzhang1.mymusic.Contants
public class Contants
This class define the intent filter's action
| Field Summary | |
|---|---|
static java.lang.String |
FILTER_ACTION_MARK_FAV
filed indicates mark read action |
static java.lang.String |
FILTER_ACTION_PLAY_LIST_CHANGED
indicates play list changed |
static java.lang.String |
FILTER_ACTION_SEEK_UPDATED
action update progress |
static java.lang.String |
FILTER_PLAY_ACTION
action indicates play music |
static java.lang.String |
FILTER_PLAY_MODE
filed indicates play mode |
static java.lang.String |
FILTER_PLAY_STATE_CHANGED
filed indicates play state changed |
static java.lang.String |
FILTER_WIDGET_PLAY_ACTION
filed indicates widgets play action |
| Constructor Summary | |
|---|---|
Contants()
|
| Method Summary |
|---|
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Field Detail |
|---|
public static final java.lang.String FILTER_PLAY_ACTION
public static final java.lang.String FILTER_PLAY_MODE
public static final java.lang.String FILTER_PLAY_STATE_CHANGED
public static final java.lang.String FILTER_WIDGET_PLAY_ACTION
public static final java.lang.String FILTER_ACTION_MARK_FAV
public static final java.lang.String FILTER_ACTION_SEEK_UPDATED
public static final java.lang.String FILTER_ACTION_PLAY_LIST_CHANGED
| Constructor Detail |
|---|
public Contants()
|
|||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


Serving Multiple Department Level Search Applications with a Single Enterprise Search Engine
Last Updated Jan 2009
By: Mark Bennett, NIE Tech Staff - Issue 4 - August/September, 2003
Often departments and divisions of larger companies need a custom search application for their knowledge workers or customers and partners.
If you already have an enterprise class search engine you may not realize that you don't need to buy a new search tool to easily implement these custom solutions. Each group can have a powerful, customized search solution without the need to buy and maintain additional software. This is usually preferable to deploying separate search applications, which can become a logistical nightmare to maintain for busy IT staff.
This provides the additional benefit that search activity reporting can be more precise, and help to easily identify important department or customer specific trends. And of course the data is still accessible to other business units, since it still resides in the central search repositories.
Outline of the Process
What makes a department-specific search application?
- They have their own data that needs to be searchable.
- They want customized search forms specific to the searches their users need to perform
- They need a results list that presents detailed, relevant data
- They may need to tweak the search results in certain ways
- They need control over their content
- They want department-specific reporting
- They may have special integration needs in order to access certain data repositories
- They may have specific security requirements
Though this list may seem a bit long, no single item is particularly complex. Most enterprise class solutions provide tools to address most of these areas. We will examine them one at a time, and show how simple each one might be to accomplish. The end result of implementing this list can be quite striking and positive.
Search-Enabling Department-Specific Data
If the department has file-oriented content, then create a networked directory for their content to reside on. One idea is to create this directory on a central content server, perhaps on the same server as the search engine software, and give that group permission to manage that directory. Alternately, have the group maintain their content on their server, and then periodically replicate the files over. The Windows Resource Kit has a utility called robocopy that can be very helpful for synchronizing directories. Just leaving the data on their servers, and accessing it via UNCs, can be problematic - servers tend to go up and down or have permissions reset; ideally the raw content that is indexed will be on the same machine as the search engine collection that has been created from it.
Then point the search engine at this new content area. Non-HTML content might be best served by indexing it with a file-system based indexer. If the content is heavily linked, then a virtual web directory can be created, and then the search engine can index it via HTTP. Specify that this is a new "collection" (or "catalog" or "index", depending on your search engine's vocabulary). And give this new collection a good meaningful name. If the content is not particularly sensitive, then you might want to include it by default in company wide searches; alternately, it may need special security settings.
By giving each department their own directory tree, they maintain control over their content. You many want to proactively give all content owners a document explaining your policies for look and feel of documents, and meta-tagging guidelines.
Providing Department-Specific Search Forms
Most modern search engines are Web based. As such, they provide a CGI interface for searching, using the HTML <form> tag. This means that different HTML forms can point to the same search engine! Therefore, a department can have a special search engine just for their group. It can have special instructions and search fields, and have links to department-specific search instructions and links for assistance.
To link department specific HTML forms to that department's specific content, hidden fields can be used to limit the scope of search to just their data. Or, for more advanced users, check boxes can be used, one check box for each section of data. By default, the check boxes for that department's data can be selected, whereas the check boxes for broader company data can be un-checked by default. Another solution is to provide radio buttons to say "(*) Search our department's data only, or ( ) Search all company data".
Sometimes check boxes will not have a one-to-one correspondence with indexed collections, so some server side scripting may be needed to map user selections into a set of specific physical collections. Most search engines provide a "pre-search filter" or have some other way for a query to be "tweaked" before it is sent to the actual underlying search engine kernel.
A sample form for Tech Support, using a fictitious search engine, might look like:

<title>Tech Support Search Form</title>

Tech Support Search Form

???. Introductory text and graphics ???.
<form method="POST" action="http://search.ourcorp.com/cgi/do_search">
Enter your search:

<input type="text" name="query">

Where to look:

<input type="checkbox" name="collection"
value="calltrack" checked>Call Tracking System

<input type="checkbox" name="collection"
value="bugs" checked>Bug Tracking System

<input type="checkbox" name="collection"
value="marketing">Press Releases

<input type="submit" value=" Search ">
</form>

Notice that "Call Tracking" and "Bugs" are enabled by default, whereas Marketing's press releases are not included in the search by default.
More importantly, you can provide an advanced search form for Tech Support. The advanced form could have additional search fields, such as:
- Previous Incident Number
- Contact Name
- Product
- Date Range
- Tech Support Rep
These fields might be very specific to Tech Support. Many of the fields might only exist in a data dump from a Call Tracking system. It would be inappropriate to put these fields on a company-wide search form.
But since Tech Support now has their own form, these fields can be added.
Of course, in order for these fields to be searchable they must be properly indexed by the search engine. Custom fields will usually require some additional configuration by the administrator in order to be searchable in this way.
Since this is such a powerful concept, I've outlined some examples of fields that other departments might like on their custom search form. Again, remember, behind the scenes we're still talking about just ONE search server.
Possible Sales Department Specific Form Fields:
- Company Name
- Sales Region
- Sales Person
- Sales Engineer
- Last Purchase Date Range
- Last Contact Date Range
- Last Quote Date Range
Possible Engineering Specific Form Fields:
- Bug Number
- Submit Date Range
- Last Updated
- Dev Engineer
- QA Engineer
- Reported By
- Urgency
- Codebase
- Priority
- Status
Possible Marketing Specific Form Fields:
- Release Date
- Collateral Type
- Source
- Partner Name
- Audience
The idea of mixing these types of custom fields with full text searches will explored in more detail in a future article; this type of search is also referred to as a hybrid search.
Providing a Department Specific Results List
We normally advise clients to keep results lists and search forms fairly simple, including adequate white space. Often times results lists are too cluttered and distracting. We believe the success of Google as a portal is due, in part, to their less cluttered appearance.
However, some knowledge workers at your company may do searches all day long. These power users may benefit from additional domain specific information in their results list. Since most search engines allow for the presentation of the same data in different formats at results time, different levels of detail can be shown to different classes of users.
Extending our previous example of a Tech Support engineer, if they were searching through old Tech Support calls, it might be very helpful to display the customer contact and company name in the results list. If a Tech Support person is trying to find a specific previous incident, this information will help them locate it much more quickly. In fact, many search engines even allow results lists to be resorted by the various fields that are displayed. So perhaps this Tech Support person could even sort by company name to locate the record they're after.
If that same Tech Support person was searching the bugs database, it might be nice to show the bug number, priority, bug status and last-updated-date in the result list. When a senior Tech Support person searches in a bugs database, they may be looking for a very specific set of bugs - this content-specific information can be very helpful.
Notice the duality of user experiences that is evolving. A casual corporate user can enter a search in a very simple one-box search form and see very basic results. A senior Tech Support engineer can compose a power search from an advanced search form, possibly setting a half dozen fields, and see very detailed results. Both users can be searching the same data, but with very different levels of detail.
The exact mechanics of presenting different result list formats from the same search engine vary from vendor to vendor. Some vendors allow a results template to be specified at search time, as a hidden field on the HTML form. Other vendors might allow different versions of an ASP search script to run, and each form would call a slightly different version of these ASP scripts, which would be set in the action attribute of the form tag. A third method might be to have a hidden field that simply states the source of the query. Subsequent code then keys off of this hidden value and renders the page differently using classic if/then/else logic. But however it is done, most engines are capable of this type of behavior.
Tweaking Search Results for Department Level Searches
Given the broad range of data indexed by an all encompassing enterprise wide search engine, the odds that a strictly full-text based approach applied to a one or two word query will bring the intended document at the top of the results list are slim. Don't blame you search engine vendor! To do this task "perfectly", without expert intervention, would almost require the engine to be psychic.
Below we present some strategies for tweaking your results list. Some of these are generic ideas, some of which we even covered in an earlier article (here); others are specific to departments. Describing each item in detail is beyond the scope of this article, and implementing it will be vendor specific, but this should at least give you some ideas. Also, please feel free to send us questions if you'd like clarification on any of these points.
- Start by setting the default enabled and disabled data sources appropriately for each department. Users can always override them.
- Make use of sorting. Most engines will allow you to sort by any arbitrary field. And you can even let the user re-sort as they view the results list. Some good candidate fields for sorting are data source and last-updated date. For departments have an advanced search form with content-specific fields, considering adding those fields to the sorting options for that group.
- Use weighting adjustments, instead of sorting, to provide a softer "boost" to certain documents. So perhaps a Tech Support person's search gives some preference to previous calls and bugs when ranking the documents, but does not necessarily force those documents to the top, even if they only have a small amount of full text query evidence.
- If your search engine supports it, institute a plan for identifying domain experts for various areas of content, and allow those experts to help adjust the query results.
- Consider using a third party results tuning solution. As an example, NIE's Search Tuning and Reporting Toolkit can provide very specific results list tweaking on a per department basis. It offers a wide range of presentation options, and works with virtually any search engine.
Providing Department Specific Reporting
Search activity reporting is one of most valuable and accurate types of behavior based intelligence gathering available. It provides deep insight into exactly what users are looking for, and quickly identifies important business trends.
You say you don't currently have a search-activity specific reporting solution in place?  You are throwing away some of the best data you could ever get your hands on. In all seriousness, if you do not have this type of system in place, please do contact us!
Assuming you do have a search activity reporting system in place, consider configuring it to track the origin of the search. In other words, which search form was the search submitted by? Being able to see what your business partners were searching for, vs. what Tech Support and Sales Engineers were search for, can help identify issues in your sales and product lifecycles.
One easy way to track the source of a search is by adding a hidden field to your various search forms. If you provide a mini-search form at the top of your results lists, don't forget to tag that search form as well.
If your reporting solution does not support this direct type of form tagging, you might be able to use the HTTP "referer" field (please note the intentional misspelling of the word "referrer", this dropping of the double-r is part of the legacy HTTP specification). Processing this information may take a little more effort; it will also be impacted by whether your HTML forms use the GET or POST methods.
A third approach might be to configure each department's search as a different "site ID". Many products allow sites to be subdivided into smaller virtual web sites, each with their own unique ID.
If your enterprise infrastructure supports consistent site wide user logins, then tracking the user can indirectly lead to tracking the source of each search; the "source" can be attributed to the department that the user belongs to, or the sales region the customer or partner is in. This type of indirect inference may be less precise, and may be more complicated to setup.
NIE's Search Tracking and Reporting Toolkit has a number of options to track and report the origin of searches.
Department Specific Security Requirements
When data is specifically search enabled, the implied assumption is that it's useful and is intended to be found! We encourage our clients to think twice before implementing draconian and often complex security measures to lockdown data in their full text database.
Do you trust your corporate firewall and user login systems? If so, might that be sufficient for securing the majority of your searchable data? If somebody can get on to your network, presumably they are a valid employee, and therefore shouldn't they be generally trusted to have access to most of the searchable data?
Of course there are some obvious exceptions. Financial and Human Resources data often require very careful access control. The extent to which data can be tightly secured to specific user logins is very vendor specific. Some vendors may not provide adequate security, in that may argue for a second search engine setup specifically for sensitive corporate data.
At the other end of the spectrum, might this data be useful to customer facing employees? Senior customer facing employees may have very broad and unpredictable data needs in the pursuit of customer related tasks. And they usually have the additional burden of needing to respond quickly. Please at least consider giving these employees the broadest access possible, unless a demonstrated pattern of behavior would indicate otherwise. A good Tech Support person may have legitimate needs to occasionally look at Sales data. A good Presales Engineer will often want to see ALL relevant customer and technical data related to their accounts. We urge you to not artificially constrain or delay these power users.
There could be potential for abuse. Managers should be leveraging your search activity reports to spot potential abuse, along with other interesting department level trends.
Department Specific Integration
Some department level data does not reside in simple files that can easily be copied to a networked file system. Many customer centric data is stored in databases, for example.
Most search vendors provide a "gateway" option to directly access, index, and search-enable database records.
With the ubiquity of web browsers, most database data is also available to users via a web browser. Since most search engines now ship with a "spider", and those spiders can index Web content by mimicking a web browser, database data can often be indexed by treating it as simple HTML content and using regular spider. This can sometimes require special settings or tweaks to the web content engine and or the spider settings, but is often a second viable option to consider.
Therefore, just because data is in a traditional SQL-style database, it is not precluded from being search enabled by your enterprise full-text search engine.
Conclusion
A single enterprise class search engine can provide different search forms and result lists to different user groups. Each group can have a powerful, custom search solution without the need to buy and maintain additional software.
A secondary benefit is that search activity reporting can be more precise, and spot important department and customer specific trends.
I realize we've covered a lot of ground in this article, but as you look back you'll notice that no single item is particularly complex. It's when all of these individual items are combined that a very powerful design strategy emerges.
As always, if you have any questions on this material, or would like any assistance with implementing it, please don't hesitate to contact us. We love this stuff!


Team Budget Planner
Home
(current)
Product Manager
Finance Manager
Team Budget Planner
Welcome to the Team Budget Planner!


+++ title = "HortaCloud" linkTitle = "HortaCloud" +++ {{< blocks/cover title="HORTACLOUD" image_anchor="top" height="full" color="orange" >}}
Collaborative neuron annotation in the cloud
}}"> Documentation Login to HortaCloud-Janelia {{< blocks/link-down color="white" >}}HortaCloud combines state-of-the-art volumetric visualization, advanced features for 3D neuronal annotation, and real-time multi-user collaboration with a set of enterprise-grade backend microservices for moving and processing large amounts of data rapidly and securely. Users can load multi-terabyte image volumes with up to three signal channels, and visualize them in 3D with multiscale volume rendering. An optimized workflow allows annotators to efficiently trace long range projection neurons in light microscopy data, including easy merging/splitting of skeletal reconstructions. Collaboration features allow a team of annotators to work together to annotate different neurons in a single volume, or build consensus by annotating the same neurons.
Horta also provides other useful features, including:
This software is built on the Janelia Workstation platform, leveraging Java NetBeans to provide modularity and extensibility. The backend consists of Java-based microservices that scale to handle large volumes of data. Metadata is stored in MongoDB and real-time event handling is implemented using RabbitMQ. We deploy both the client and backend services to the AWS Cloud, leveraging AWS AppStream to process the 3D rendering and virtualize the desktop infrastructure.
Image data is stored on AWS S3, and we provide many open data sets on AWS Open Data registry that are immediately accessible in the application.


The Butcher Boy (R) *** 1/2 (out of ****)
No film in recent has left me with such conflicted feelings as Neil Jordan's harrowing, humorous, horrifying adaptation of Patrick McCabe's novel about young lad Francie Brady's (Eamonn Owens) descent into madness in 1960s Ireland. On one hand, it was difficult for me to become invested in Francie's story because he is such an unsavory character, unjustifyably venting his rage at his nosy but otherwise harmless neighbor Mrs. Nugent (Fiona Shaw).  On yet another hand, I also found it difficult to completely sympathize with Francie during his more emotional scenes because some of his, for lack of a better word, "bad" deeds are so incredibly shocking in their brutality and the malicious glee in which he performs them.
However, The Butcher Boy's power is undeniable, and the film as a whole is unforgettable--perhaps because it is so disturbing. What makes it so unsettling is the Francie's overall wink-wink yet matter-of-fact attitude about everything, expressed in a cheeky voiceover narration delivered by the adult Francie (Rea again). Think Heavenly Creatures played largely for laughs, and you'll sort of understand. Anchoring the whole film is the astonishing debut performance of Owens; love Francie or hate him, you cannot take your eyes off of Owens. The Butcher Boy truly is a twisted, unusual film that is bound to make just about anyone uncomfortable. In the lobby after the screening, I overheard one man raving about how great yet disturbing it was; I also heard one particularly offended woman say with disgust, "That movie was SO UNFUNNY!"
Michael Dequina Chat Forum Host, The Official Michael Jordan Web Site http://jordan.sportsline.com
<EMAIL_ADDRESS><EMAIL_ADDRESS>|<EMAIL_ADDRESS>>My personal WWW sites< Mr. Brown's Movie Site: http://welcome.to/mrbrown Michael Jordan Beyond the Court: http://fly.to/michaeljordan A Michael Jordan Fan's Heartbreak: http://fly.to/mj23 Personal Page: http://welcome.to/w3md >Other WWW sites I work on< CompuServe Hollywood Hotline: http://www.HollywoodHotline.com Albany Online: http://www.AlbanyOnline.com Eyepiece Network: http://www.eyepiece.com
"I didn't know what to expect. It's like something you chase for so long, but then you don't know how to react when you get it. I still don't know how to react." --Michael Jordan, on winning his first NBA championship in 1991 ...or, my thoughts after meeting him on November 21, 1997
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


--- layout: archive title: Zulip Chat Archive permalink: /stream/116395-maths/topic/order_dual.20disappointment.html ---
How sad...
example (a b : β) : max a b = @min (order_dual β) _ a b := rfl --doesn't work
import order.basic variables (β : Type*) [decidable_linear_order β] example (a b : β) : max a b = @min (order_dual β) _ b a := rfl --works
I might go and change the definition of list.maximum
, with this in mind, and swap the order
Last updated: Apr 24 2020 at 19:02 UTC