Ports 搜索

Boost provides free peer-reviewed portable C++ source libraries. The emphasis is on libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. The goal is to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2. NOTE: This package does not contain Boost.Python, it's in 'devel/boost-python-libs'.

Often in program logic, multiple different steps need to be taken that are independent of each other, but their total result is needed before the next step can be taken. In synchonous code, the usual approach is to do them sequentially. An asynchronous or event-based program could do this, but if each step involves some IO idle time, better overall performance can often be gained by running the steps in parallel. A Async::MergePoint object can then be used to wait for all of the steps to complete, before passing the combined result of each step on to the next stage. This module was originally part of the IO::Async distribution, but was removed under the inspiration of Pedro Melo's Async::Hooks distribution, because it doesn't itself contain anything IO-specific.

Data::ObjectDriver is an object relational mapper, meaning that it maps object-oriented design concepts onto a relational database. It's inspired by, and descended from, the MT::ObjectDriver classes in Six Apart's Movable Type and TypePad weblogging products. But it adds in caching and partitioning layers, allowing you to spread data across multiple physical databases, without your application code needing to know where the data is stored. It's currently considered ALPHA code. The API is largely fixed, but may seen some small changes in the future. For what it's worth, the likeliest area for changes are in the syntax for the search method, and would most likely not break much in the way of backwards compatibility.

The Inline module allows you to put source code from other programming languages directly "inline" in a Perl script or module. The code is automatically compiled as needed, and then loaded for immediate access from Perl. Inline saves you from the hassle of having to write and compile your own glue code using facilities like XS or SWIG. Simply type the code where you want it and run your Perl as normal. All the hairy details are handled for you. The compilation and installation of your code chunks all happen transparently; all you will notice is the delay of compilation on the first run. The Inline code only gets compiled the first time you run it (or whenever it is modified) so you only take the performance hit once. Code that is Inlined into distributed modules (like on the CPAN) will get compiled when the module is installed, so the end user will never notice the compilation time.

Roles are composable units of behavior. They are useful for factoring out functionality common to many classes from any part of your class hierarchy. See Moose::Cookbook::Roles::Recipe1 for an introduction to Moose::Role. While combining roles affords you a great deal of flexibility, individual roles have very little in the way of configurability. Core Moose provides alias for renaming methods and excludes for ignoring methods. These options are primarily (perhaps solely) for disambiguating role conflicts. See Moose::Cookbook::Roles::Recipe2 for more about alias and excludes. Because roles serve many different masters, they usually provide only the least common denominator of functionality. To empower roles further, more configurability than alias and excludes is required. Perhaps your role needs to know which method to call when it is done. Or what default value to use for its url attribute. Parameterized roles offer exactly this solution.

POEx::Role::Streaming provides a common idiom for streaming data from one filehandle to another. It accomplishes this by making good use of sysread and POE::Wheel::ReadWrite. This Role errs on the side of doing as many blocking reads of the "input_handle" as possible up front (until the high water mark is hit on the Wheel). If this default isn't suitable for the consumer, simply override "get_data_from_input_handle". After Streamer has exhausted the source, and flushed the last of the output, it will clean up after itself by closing the wheel, the handles, and sending all of them out of scope. If an exception happens, it will clean up after itself, and let the DIE signal propagate.

pty is a tool to help debug console programs which take the terminal out of canonical mode, by allowing the program being debugged and the debugger to run on separate terminal devices. To use pty, the programmer changes to the terminal device where he or she wishes to interact with the program to be debugged, and at the shell prompt, runs pty with no arguments. Pty will print out the filename of the slave side of the pseudo-terminal it has opened. Inside the debugger, running in another terminal device, one then redirects the program to be debugged's IO to the slave (tty command of gdb). When you are finished using pty, you must manually kill it. When pty starts it prints out its pid.

Test::Mock::LWP::Dispatch intends for testing a code that heavily uses LWP::UserAgent. Assume that function you want to test makes three different request to the server and expects to get some content from the server. To test this function you should setup request/response mappings for mocked UserAgent and test it. For doing something with mappings, here are methods map, unmap and unmap_all. For controlling context of these mappings (is it applies for all created in your code LWP::UserAgent's or only to one specific?) you should call these functions for exported $mock_ua object (global mapping) or for newly created LWP::UserAgent (local mappings). See also on Test::Mock::LWP, it provides mocked LWP objects for you, so probably you can solve your problems with this module too.

This module provides the ability to use references as hash keys if you first "tie" the hash variable to this module. Normally, only the keys of the tied hash itself are preserved as references; to use references as keys in hashes-of-hashes, use Tie::RefHash::Nestable, included as part of Tie::RefHash. It is implemented using the standard perl TIEHASH interface. Please see the "tie" entry in perlfunc(1) and perltie(1) for more information. The Nestable version works by looking for hash references being stored and converting them to tied hashes so that they too can have references as keys. This will happen without warning whenever you store a refer- ence to one of your own hashes in the tied hash.

Yapps (Yet Another Python Parser System) is an easy to use parser generator that is written in Python and generates Python code. Yapps is simple, is easy to use, and produces human-readable parsers. It is not fast, powerful, or particularly flexible. Yapps is designed to be used when regular expressions are not enough and other parser systems are too much: situations where you may write your own recursive descent parser. Yapps 1 is more like a functional language (concise grammars of the form when you see this, return this), while Yapps 2 is more like an imperative language (more verbose grammars of the form if/while you see this, do this). Yapps 2 is more flexible than Yapps 1 but it requires Python 1.5 and is not backwards-compatible with Yapps 1. This is the development version of Yapps 2.