view release on metacpan or search on metacpan
lib/Graph.pm view on Meta::CPAN
horAxisLabel => 'delta (added or modified files)',
vertAxisLabel => 'size (nb files)',
);
$img->draw();
my $gd = $img->getGDobject();
$gd->transparent(-1);
return $gd;
}
sub EnergyCv {
my $cvs_log = shift;
view release on metacpan or search on metacpan
lib/CWB/Web/Cache.pm view on Meta::CPAN
##
## The CWB::Web::Cache module can also execute simple CQP queries and make their results
## persistent. The query results are identified by corpus, query string, and an optional sort
## (stored as metadata) rather than a single unique identifier, and can be shared among different
## processes using the same cache directory. When a persistent query result has expired from the
## cache, it is re-created in a way transparent to the calling program (by re-executing the query
## expression in the CQP process).
##
## The cache directory contains two subdirectories and an optional CONFIG file:
## index/ ... text files as 'markers' for cached queries (may contain 'metadata' about the cached query)
## data/ ... named query results stored in CQP's internal format
lib/CWB/Web/Cache.pm view on Meta::CPAN
$cqp = new CWB::CQP;
$cache = new CWB::Web::Cache -cqp => $cqp, -cachedir => $dir,
[-cachesize => $cache_size,] [-cachetime => $expiration_time];
# transparently execute and cache simple CQP queries
$id = $cache->query(-corpus => "DICKENS", -query => '[pos="NN"] "of" "England"');
($size) = $cqp->exec("size $id");
# optional features: sort clause, set keyword, subquery, and maximal number of matches
$id = $cache->query(
lib/CWB/Web/Cache.pm view on Meta::CPAN
Note that a B<CWB::Web::Cache> handle must be created with a pre-initialised CQP backend (i.e.
a B<CWB::CQP> object), which will be used to access the cache and (re-)run a query when necessary.
Most scripts will access the cache through the B<query()> method, which executes and caches CQP queries
in a fully transparent way (with optional C<sort> clause, C<set keyword> command, subquery,
and C<cut> to limit the maximal number of matches). After successful execution, the query result is
loaded into the CQP backend, the appropriate corpus is activated, and the I<$id> of the named query is
returned.
The C<sort> clause is executed I<after> a C<set keyword> command
view release on metacpan or search on metacpan
html/intro.html view on Meta::CPAN
<ul>
<li>CaCOREperl itself is not a data store, but a delegate to the caCORE server.
<li>CaCOREperl encapsulates the gory details of webservice call to the caCORE server, and serializing/deserializing
of domain objects.
<li>Communication with caCORE server is transparent to the user.
</ul>
<h2><a name="installing">Installing CaCOREperl</a></h2>
Perl comes installed on Unix and Linux platforms. For window based systems, you can download
view release on metacpan or search on metacpan
lib/Cache/SharedMemoryBackend.pm view on Meta::CPAN
return $share;
}
# this method uses the shared created by Instantiate_Share to
# transparently retrieve a reference to a shared hash structure
sub _Restore_Shared_Hash_Ref
{
my ( $p_ipc_identifier ) = Static_Params( @_ );
lib/Cache/SharedMemoryBackend.pm view on Meta::CPAN
return Thaw_Data( $frozen_hash_ref );
}
# this method uses the shared created by Instantiate_Share to
# transparently retrieve a reference to a shared hash structure, and
# additionally exclusively locks the share
sub _Restore_Shared_Hash_Ref_With_Lock
{
my ( $p_ipc_identifier ) = Static_Params( @_ );
lib/Cache/SharedMemoryBackend.pm view on Meta::CPAN
return Thaw_Data( $frozen_hash_ref );
}
# this method uses the shared created by Instantiate_Share to
# transparently persist a reference to a shared hash structure
sub _Store_Shared_Hash_Ref
{
my ( $p_ipc_identifier, $p_hash_ref ) = @_;
lib/Cache/SharedMemoryBackend.pm view on Meta::CPAN
_Instantiate_Share( $p_ipc_identifier )->store( Freeze_Data( $p_hash_ref ) );
}
# this method uses the shared created by Instantiate_Share to
# transparently persist a reference to a shared hash structure and
# additionally unlocks the share
sub _Store_Shared_Hash_Ref_And_Unlock
{
my ( $p_ipc_identifier, $p_hash_ref ) = @_;
view release on metacpan or search on metacpan
lib/Cache/CacheFactory.pm view on Meta::CPAN
Pruning and validity policies are set on a per-cache basis rather than
on a per-storage-policy basis, this makes multiple storage policies
largely pointless for most purposes where you'd find it useful.
If you wanted the cache to transparently use a small fast memory cache
first and fall back to a larger slower file cache as backup: you can't
do it, because the size pruning policy would be the same for both storage
policies.
About the only current use of multiple storage policies is to have a
view release on metacpan or search on metacpan
lib/Cache/Cascade.pm view on Meta::CPAN
For example, caching in a FastMmap based storage is much slower than using a
memory based cache, because pages must be locked to ensure that no corruption
will happen. Likewise Memcached is even more overhead than FastMmap because it
is network bound, and uses blocking IO (on the client side).
This module attempts to make a transparent cascade of caches using several
backends.
The idea is to search from the cheapest backend to the most expensive, and
depending on the options also cache results in the cheaper backends.
view release on metacpan or search on metacpan
lib/Cache/Memcached/Fast.pm view on Meta::CPAN
$memd->set($key, $value, $expiration_time);
Store the I<$value> on the server under the I<$key>. I<$key> should
be a scalar. I<$value> should be defined and may be of any Perl data
type. When it is a reference, the referenced Perl data structure will
be transparently serialized by routines specified with
L</serialize_methods>, which see.
Optional I<$expiration_time> is a positive integer number of seconds
after which the value will expire and wouldn't be accessible any
longer.
view release on metacpan or search on metacpan
lib/Cache/Memcached/Managed.pm view on Meta::CPAN
2D3H
means 2 days and 3 hours, which means B<183600> seconds.
=head2 transparent fork handling
Using this module, you do not have to worry if everything will still work
after a fork(). As soon as it is detected that the process has forked, new
handles will be opened to the memcached servers in the child process (so the
meticulous calling of "disconnect_all" of L<Cache::Memcached> is no longer
view release on metacpan or search on metacpan
=head1 DESCRIPTION
This module implements a shared data cache, using memory mapped files.
If routines are provided which interact with the underlying data, access to
the cache is completely transparent, and the module handles all the details of
refreshing cache contents, and updating underlying data, if necessary.
Cache entries are assigned to "buckets" within the cache file, depending on
the key. Within each bucket, entries are stored approximately in order of last
access, so that frequently accessed entries will move to the head of the
view release on metacpan or search on metacpan
lib/Cache/RedisDB.pm view on Meta::CPAN
Cache::RedisDB - RedisDB based cache system
=head1 DESCRIPTION
This is just a wrapper around RedisDB to have a single Redis object and connection per process. By default uses server redis://127.0.0.1, but it may be overwritten by REDIS_CACHE_SERVER environment variable. It transparently handles forks.
=head1 COMPATIBILITY AND REQUIREMENTS
Redis 2.6.12 and higher strongly recommended. Required if you want to use
extended options in ->set().
view release on metacpan or search on metacpan
examples/css/bootstrap-responsive.css view on Meta::CPAN
float: none;
display: block;
max-width: none;
margin: 0 15px;
padding: 0;
background-color: transparent;
border: none;
-webkit-border-radius: 0;
-moz-border-radius: 0;
border-radius: 0;
-webkit-box-shadow: none;
view release on metacpan or search on metacpan
Schedule.pm view on Meta::CPAN
# more examples in "Example entries" section
=head1 DESCRIPTION
The module is created with a purpose to provide functionality for handling a
personal calendar schedule in a transparent and simple way. The calendar
data is assumed to be kept in a plain file in a format easy to edit and
understand. It was inspired by the C<calendar> program on older Unix-like
systems, which used C<~/.calendar> file to produce entries for each day
and send them in the morning by email.
view release on metacpan or search on metacpan
static/orig/css/blueprint/print.css view on Meta::CPAN
blockquote {margin:1.5em;padding:1em;font-style:italic;font-size:.9em;}
.small {font-size:.9em;}
.large {font-size:1.1em;}
.quiet {color:#999;}
.hide {display:none;}
a:link, a:visited {background:transparent;font-weight:700;text-decoration:underline;}
a:link:after, a:visited:after {content:" (" attr(href) ")";font-size:90%;}
view release on metacpan or search on metacpan
doc/catalog.texinfo view on Meta::CPAN
After a while, you will want to reload a new version of the dmoz.org
data. It can be done using the same commands. The problem is that while
you do that the catalog will be unavailable to the users. The data are
first removed and then populated. Catalog does not currently offer support
for user transparent reloading. Instead we suggest you follow these steps:
@itemize @bullet
@item
Load dmoz on another machine.
view release on metacpan or search on metacpan
lib/Catalyst/Controller/REST.pm view on Meta::CPAN
Catalyst::Controller::REST implements a mechanism for building
RESTful services in Catalyst. It does this by extending the
normal Catalyst dispatch mechanism to allow for different
subroutines to be called based on the HTTP Method requested,
while also transparently handling all the serialization/deserialization for
you.
This is probably best served by an example. In the above
controller, we have declared a Local Catalyst action on
"sub thing", and have used the ActionClass('REST').
view release on metacpan or search on metacpan
lib/Catalyst/Controller/JMS.pm view on Meta::CPAN
=head1 DESCRIPTION
This controller base class makes it easy to handle JMS-style messages
in your Catalyst application. It handles deserialisation and
serialisation transparently (thanks to
L<Catalyst::Action::Deserialize> and L<Catalyst::Action::Serialize>)
and sets up the attributes needed by L<Catalyst::ActionRole::JMS>. It
also sets up some sensible default configuration.
=head1 CONFIGURATION
view release on metacpan or search on metacpan
lib/Catalyst/Controller/MovableType.pm view on Meta::CPAN
Captures the path of the Movable Type.
=head2 run_mt_script
Runs the requested Movable Type .cgi script transparently with cgi_to_response.
=head2 not_found
Sets the response to a simple 404 Not found page. You can override this method
with your own.
view release on metacpan or search on metacpan
share/cpan.css view on Meta::CPAN
color: #ff6600;
text-decoration: underline;
}
A:link, A:visited {
background: transparent;
color: #006699;
}
A[href="#POD_ERRORS"] {
background: transparent;
color: #FF0000;
}
TD {
margin: 0;
share/cpan.css view on Meta::CPAN
padding: 0.4ex 1ex;
text-align: left;
}
TH A:link, TH A:visited {
background: transparent;
color: black;
}
.box {
border: 1px solid #006699;
share/cpan.css view on Meta::CPAN
padding: 0.5ex 1ex;
vertical-align: baseline;
}
.path A {
background: transparent;
color: #006699;
font-weight: bold;
}
.pages {
share/cpan.css view on Meta::CPAN
margin: 1ex 0;
padding: 1px;
}
.menubar .links {
background: transparent;
color: white;
padding: 0.2ex;
text-align: left;
}
share/cpan.css view on Meta::CPAN
font: bold 10pt Arial,Helvetica,sans-serif;
text-decoration: none;
}
A.o:hover {
background: transparent;
color: #ff6600;
text-decoration: underline;
}
A.m:hover {
background: transparent;
color: #ff6600;
text-decoration: underline;
}
table.dlsip {
share/cpan.css view on Meta::CPAN
padding: 1em;
white-space: pre;
}
.pod H1 {
background: transparent;
color: #006699;
font-size: large;
}
.pod H1 A { text-decoration: none; }
.pod H2 A { text-decoration: none; }
.pod H3 A { text-decoration: none; }
.pod H4 A { text-decoration: none; }
.pod H2 {
background: transparent;
color: #006699;
font-size: medium;
}
.pod H3 {
background: transparent;
color: #006699;
font-size: medium;
font-style: italic;
}
.pod H4 {
background: transparent;
color: #006699;
font-size: medium;
font-weight: normal;
}
share/cpan.css view on Meta::CPAN
.chmenu TD {
padding: 0.2ex 1ex;
}
.chmenu A:link, .chmenu A:visited {
background: transparent;
color: white;
text-decoration: none;
}
.chmenu A:hover {
background: transparent;
color: #ff6600;
text-decoration: underline;
}
.column {
share/cpan.css view on Meta::CPAN
margin: auto;
width: 14em;
}
.date {
background: transparent;
color: #008000;
}
.footer {
margin-top: 1ex;
view release on metacpan or search on metacpan
lib/Catalyst/Engine/HTTP/Prefork.pm view on Meta::CPAN
This engine fully supports the following HTTP/1.1 features:
=head2 Chunked Requests
Chunked body data is handled transparently by L<HTTP::Body>.
=head2 Chunked Responses
By setting the Transfer-Encoding header to 'chunked', you can indicate you
would like the response to be sent to the client as a chunked response. Also,
view release on metacpan or search on metacpan
lib/Catalyst/Manual/Components.pod view on Meta::CPAN
Lets you create a very quick and dirty user database in your application's
config hash. Great for testing or getting up and running quickly.
=head4 L<Catalyst::Authentication::Store::Null>
The Null store is a transparent store where any supplied user data is
accepted. This is mainly useful for remotely authenticating credentials
(e.g. OpenID) which may not be tied to any local storage.
=head4 L<Catalyst::Authentication::Store::RDBO>
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/AtomServer.pm view on Meta::CPAN
=item * REST and SOAP interfaces
The Atom API supports either a REST interface or a SOAP interface using
a document-literal SOAP envelope. I<Catalyst::Plugin::AtomServer> supports
both interfaces, transparently for your application.
=item * Error Handling
I<Catalyst::Plugin::AtomServer> will automatically catch any exceptions
thrown by your application, and it will wrap the exception in the proper
view release on metacpan or search on metacpan
lib/Catalyst/Authentication/Store/Null.pm view on Meta::CPAN
}
});
=head1 DESCRIPTION
The Null store is a transparent store where any supplied user data is
accepted. This is mainly useful for remotely authenticating credentials
(e.g. TypeKey, OpenID) which may not be tied to any local storage. It also
helps facilitate integration with the Session plugin.
=head1 METHODS
view release on metacpan or search on metacpan
t/root/static/css/blueprint/print.css view on Meta::CPAN
blockquote {margin:1.5em;padding:1em;font-style:italic;font-size:.9em;}
.small {font-size:.9em;}
.large {font-size:1.1em;}
.quiet {color:#999;}
.hide {display:none;}
a:link, a:visited {background:transparent;font-weight:700;text-decoration:underline;}
a:link:after, a:visited:after {content:" (" attr(href) ")";font-size:90%;}
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/HashedCookies.pm view on Meta::CPAN
=head2 Implementation
HashedCookies adds a keyed cryptographic hash to each cookie that your
application creates, and checks every client-provided cookie for a valid hash.
This is done in a transparent way such that you do not need to change B<any>
application code that handles cookies when using this plugin. A cookie that
fails to contain a valid hash will still be available to your application
through C<< $c->request->cookie() >>.
Two additional methods within the Catalyst request object allow you to check
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/I18N/Request.pm view on Meta::CPAN
Localization involves taking paths and parameter names and replacing
them with values which make more sense to users speaking the requested
language. In the above example, 'search' may not look intuitive to
German users. Out of the box, this plugin allows you to localize these
values transparently via the standard $c->uri_for and
$c->request->uri_with methods which are already standard features of
the Catalyst framework.
Like delocalization, this functionality depends upon the $c->localize
method. However, PATH_delocalize_ is replaced with PATH_localize and
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Server/JSONRPC.pm view on Meta::CPAN
=item * Single entrypoint for JSONRPC calls, like http://host.tld/rpc
=item * DispatchTypes (attributes) which work much the same as Catalyst attrs
=item * JSONRPC Parameter handling transparent to Catalyst parameter handling
=back
=head1 HOW IT WORKS
lib/Catalyst/Plugin/Server/JSONRPC.pm view on Meta::CPAN
=back
=head1 CATALYST REQUEST
To make things transparent, we try to put JSONRPC params into the Request
object of Catalyst. But first we will explain something about the JSONRPC
specifications.
A full draft of these specifications can be found on:
C<http://www.jsonrpc.com/spec>
lib/Catalyst/Plugin/Server/JSONRPC.pm view on Meta::CPAN
}
=item $c->req->parameters
Because JSONRPC parameters are a LIST, we can't B<just> fill
$c->req->paremeters. To keep things transparent, we made an extra config
option what tells the JSONRPC server we can assume the following conditions
on all JSONRPC requests:
- There is only one JSONRPC parameter
- This JSONRPC parameter is a struct (HASH)
lib/Catalyst/Plugin/Server/JSONRPC.pm view on Meta::CPAN
=item Make stash filterable before returning
Just like the error messages, it would be nice to be able to filter the
stash before returning so you can filter out keys you don't want to
return to the client, or just return a certain list of keys.
This all to make transparent use of JSONRPC and web easier.
=back
=head1 SEE ALSO
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Server/XMLRPC.pm view on Meta::CPAN
=item * Single entrypoint for XMLRPC calls, like http://host.tld/rpc
=item * DispatchTypes (attributes) which work much the same as Catalyst attrs
=item * XMLRPC Parameter handling transparent to Catalyst parameter handling
=back
=head1 HOW IT WORKS
lib/Catalyst/Plugin/Server/XMLRPC.pm view on Meta::CPAN
=back
=head1 CATALYST REQUEST
To make things transparent, we try to put XMLRPC params into the Request
object of Catalyst. But first we will explain something about the XMLRPC
specifications.
A full draft of these specifications can be found on:
C<http://www.xmlrpc.com/spec>
lib/Catalyst/Plugin/Server/XMLRPC.pm view on Meta::CPAN
}
=item $c->req->parameters
Because XMLRPC parameters are a LIST, we can't B<just> fill
$c->req->paremeters. To keep things transparent, we made an extra config
option what tells the XMLRPC server we can assume the following conditions
on all XMLRPC requests:
- There is only one XMLRPC parameter
- This XMLRPC parameter is a struct (HASH)
lib/Catalyst/Plugin/Server/XMLRPC.pm view on Meta::CPAN
=item Make stash filterable before returning
Just like the error messages, it would be nice to be able to filter the
stash before returning so you can filter out keys you don't want to
return to the client, or just return a certain list of keys.
This all to make transparent use of XMLRPC and web easier.
=back
=head1 SEE ALSO
view release on metacpan or search on metacpan
lib/Catalyst/Plugin/Session/Tutorial.pod view on Meta::CPAN
</table>
As you can see the way that items are added into C<< $c->session->{cart} >> is
pretty simple. Since C<< $c->session >> is restored as necessary, and contains
data from previous requests by the same client, the cart can be updated as the
user navigates the site pretty transparently.
=head1 SECURITY ISSUES
These issues all relate to how session data is managed, as described above.
These are not issues you should be concerned about in your application code,
view release on metacpan or search on metacpan
0.21 2009-03-29 20:31:49
- Documentation improvements (jester)
- Change from NEXT to MRO::Compat - RT#40628, RT#44553 (ilmari)
- Bump prereq to MIME::Types to 1.25 to correctly send files
commonly used to graft support for transparent PNGs into
MSIE6 - RT#41314 (Florian Ragwitz)
0.20 2007-09-24 10:00:00
- Fixed issue where the static dir regex did not add a trailing
slash so URLs such as /static1 were served as static when they
view release on metacpan or search on metacpan
0.21 2009-03-29 20:31:49
- Documentation improvements (jester)
- Change from NEXT to MRO::Compat - RT#40628, RT#44553 (ilmari)
- Bump prereq to MIME::Types to 1.25 to correctly send files
commonly used to graft support for transparent PNGs into
MSIE6 - RT#41314 (Florian Ragwitz)
0.20 2007-09-24 10:00:00
- Fixed issue where the static dir regex did not add a trailing
slash so URLs such as /static1 were served as static when they