Ports Search

Gerber Viewer (gerbv) is a viewer for Gerber files. Gerber files are generated from PCB CAD system and sent to PCB manufacturers as basis for the manufacturing process. The standard supported by gerbv is RS-274X. The basic difference between RS-274D (the old standard) and RS-274X is basically the addition of apertures in RS-274X. It might be possible to make an RS-274X file out of an RS-274D file and an aperture list. gerbv also supports drill files. The format supported are known under names as NC-drill or Excellon. The format is a bit undefined and different EDA-vendors implement it different. But basically you need to have the tools definition in the file, then the parser is quite tolerant. The different holes are shown as dots in the (scaled) correct size. The different layers of the PCB are separated into different files. gerbv can load all files at the same time and display them "on top of each other". You can independently turn them on and off.

The EAGLE Layout Editor is an easy to use, yet powerful tool for designing printed circuit boards (PCBs). The name EAGLE is an acronym, which stands for Easily Applicable Graphical Layout Editor. The program consists of three main modules: o Layout Editor o Schematic Editor o Autorouter which are embedded in a single user interface. Therefore there is no need for converting netlists between schematics and layouts. This is a Light Freeware Edition. It has the following limitations: o The useable board area is limited to 100 x 80 mm (4 x 3.2 inches). o Only two signal layers can be used (Top and Bottom). o The schematic editor can only create one sheet. o Support is only available via email or through our forum (no fax or phone support). o Use is limited to non-profit applications or evaluation purposes. Apart from these limitations the EAGLE Light Edition can do anything the Professional Edition can do. You can even load, view and print drawings that exceed these limits!

bitmapped vectors of booleans (no NAs), coercion from and to logicals, integers and integer subscripts; fast boolean operators and fast summary statistics. With 'bit' vectors you can store true binary booleans {FALSE,TRUE} at the expense of 1 bit only, on a 32 bit architecture this means factor 32 less RAM and ~ factor 32 more speed on boolean operations. Due to overhead of R calls, actual speed gain depends on the size of the vector: expect gains for vectors of size > 10000 elements. Even for one-time boolean operations it can pay-off to convert to bit, the pay-off is obvious, when such components are used more than once. Reading from and writing to bit is approximately as fast as accessing standard logicals - mostly due to R's time for memory allocation. The package allows to work with pre-allocated memory for return values by calling .Call() directly: when evaluating the speed of C-access with pre-allocated vector memory, coping from bit to logical requires only 70% of the time for copying from logical to logical; and copying from logical to bit comes at a performance penalty of 150%. the package now contains further classes for representing logical selections: 'bitwhich' for very skewed selections and 'ri' for selecting ranges of values for chunked processing. All three index classes can be used for subsetting 'ff' objects (ff-2.1-0 and higher).

The Firm library implements the Firm intermediate representation (IR). libFirm contains algorithms for construction of the SSA form directly from the attributed syntax tree. A set of analyses and optimisation phases is provided. This version includes a complete backend for the IA32 architecture, as well as some unfinished backends for SPARC, ARM * support for object oriented type hierarchies * analyses: dominance, loop tree, execution frequency, control dependencies, call graph, rapid type, def-use, alias analysis, class hierarchy analysis * Optimisations: constant folding, local common subexpression elimination, global common subexpression elimination, code placement, operator strength reduction, scalar replacement, load/store, control flow optimisations, if-conversion, partial condition evaluation, reassociation, tail recursion elimination, inlining, procedure cloning, dead code elimination, ... * enhanced debugging support: extensive checkers, breakpoints on node creation, entity creation, graph dumping * lowering of intrinsics, double word arithmetics, bitfields * backend with SSA based register allocation including several algorithms for spilling and copy coalescing. Instruction and block scheduling, support for ABI handling. * working ia32 backend with support for x87 and SSE2 floating point * handwritten recursive descent C90/C99 frontend available (lang/cparser)

Nana provides improved support for assertion checking and logging in C, C++ using GDB. In particular it provides: o Operations can be implemented directly in C or by generating debugger commands which do the checking and logging only if the application is run under the debugger. The debugger based calls require are very space efficient (0 or 1 bytes per call). o Support for checking real time constraints. o Support for assertion (invariant checking) including: + Space and time efficient (at least versus <assert.h>) For example: assert(i>=0) uses 53 bytes on a i386 vs an optimised nana call which uses 10 bytes per call. + Checking can be turned on or off at compile or run time. + The action taken when an error is detected can be modified on a global and per/call basis. o Support for logging (printf style debugging) including: + Logging can be turned on and off at compile or run time. + Logging to files, processes or circular buffers in memory with optional time stamping. o Support for the quantifiers of predicate calculus (forall, exists). o Support for before and after state saving and checking (x, x').

Devel::CallChecker makes some new features of the Perl 5.14.0 C API available to XS modules running on older versions of Perl. The features are centred around the function cv_set_call_checker, which allows XS code to attach a magical annotation to a Perl subroutine, resulting in resolvable calls to that subroutine being mutated at compile time by arbitrary C code. This module makes cv_set_call_checker and several supporting functions available. (It is possible to achieve the effect of cv_set_call_checker from XS code on much earlier Perl versions, but it is painful to achieve without the centralised facility.) Devel::CallCheckerprovides the implementation of the functions at runtime (on Perls where they are not provided by the core). It also, at compile time, supplies the C header file and link library which provide access to the functions. In normal use, "callchecker0_h" and "callchecker_linkable" should be called at build time (not authoring time) for the module that wishes to use the C functions.

Expect::Simple is a wrapper around the Expect module which should suffice for simple applications. It hides most of the Expect machinery; the Expect object is available for tweaking if need be. Generally, one starts by creating an Expect::Simple object using new. This will start up the target program, and will wait until one of the specified prompts is output by the target. At that point the caller should send() commands to the program; the results are available via the before, after, match_str, and match_idx methods. Since Expect simulates a terminal, there will be extra \r characters at the end of each line in the result (on UNIX at least). This is easily fixed: ($res = $obj->before) =~ tr/\r//d; @lines = split( "\n", $res ); This is not done automatically. Exceptions will be thrown on error (match with /Expect::Simple/). Errors from Expect are available via the error_expect method. More human readable errors are available via the error method. The connection is automatically broken (by sending the specified disconnect command to the target) when the Expect::Simple object is destroyed.

Perl module to prevent leakage of lexical hints Lexical::SealRequireHints works around two historical bugs in Perl's handling of the %^H (lexical hints) variable. One bug causes lexical state in one file to leak into another that is required/used from it. This bug, [perl #68590], was present from Perl 5.6 up to Perl 5.10, fixed in Perl 5.11.0. The second bug causes lexical state (normally a blank %^H once the first bug is fixed) to leak outwards from utf8.pm, if it is automatically loaded during Unicode regular expression matching, into whatever source is compiling at the time of the regexp match. This bug, [perl #73174], was present from Perl 5.8.7 up to Perl 5.11.5, fixed in Perl 5.12.0. Both of these bugs seriously damage the usability of any module relying on %^H for lexical scoping, on the affected Perl versions. It is in practice essential to work around these bugs when using such modules. On versions of Perl that require such a workaround, this module globally changes the behaviour of require, including use and the implicit require performed in Unicode regular expression matching, so that it no longer exhibits these bugs.

The Log::Agent module provides an abstract layer for logging and tracing, which is independent from the actual method used to physically perform those activities. It acts as an agent (hence the name) that collects the requests and delegates processing to a sublayer: the logging driver. The Log::Agent module is meant to be used in all reusable components, since they cannot know in advance how the application which ends up using them will perform its logging activities: either by emitting messages on stdout and errors on stderr, or by directing messages to log files, or by using syslog(3). The logging interface is common for all the logging drivers, and is therefore the result of a compromise between many logging schemes: any information given at this level must be either handled by all drivers, or may be ignored depending on the application's final choice. WARNING: THIS INTERFACE IS STILL SOMEWHAT ALPHA AND COULD STILL CHANGE DEPENDING ON THE FEEDBACK THE AUTHOR RECEIVES, WITHOUT ANY BACKWARD COMPATIBILITY ASSURANCE.

Perl 5.6 introduced something called interpreter threads. Interpreter threads are different from 5005threads (the thread model of Perl 5.005) by creating a new Perl interpreter per thread, and not sharing any data or state between threads by default. Prior to Perl 5.8, this has only been available to people embedding Perl, and for emulating fork() on Windows. The threads API is loosely based on the old Thread.pm API. It is very important to note that variables are not shared between threads, all variables are by default thread local. To use shared variables one must use threads::shared. It is also important to note that you must enable threads by doing use threads as early as possible in the script itself, and that it is not possible to enable threading inside an eval "", do, require, or use. In particular, if you are intending to share variables with threads::shared, you must use threads before you use threads::shared. (threads will emit a warning if you do it the other way around.)