Cram into 80 columns by 24 rows.

6 files changed, 66 insertions, 345 deletions

diff --git a/devel/asl/pkg-descr b/devel/asl/pkg-descr
index e477ff6aa2c..6d5c0bc2d2b 100644
--- a/devel/asl/pkg-descr
+++ b/devel/asl/pkg-descr
@@ -1,43 +1,20 @@
-ASL offers the possibility to generate code for totally different
-processors. Currently, the following processor families are
-implemented:
+ASL can generate code for totally different processors.  These are implemented:
 
- - Motorola 68000..68030,683xx incl. math co-processor and MMU
- - Motorola DSP56000
- - Motorola/IBM MPC601/MPC505/PPC403
- - Motorola 6800, 6805, 6809, 68(HC)11, as well as Hitachi 6301
- - Hitachi 6309
- - Hitachi H8
- - Hitachi SH7000/7600
- - Rockwell 6502 and 65(S)C02
- - CMD 65816
- - Mitsubishi MELPS-740
- - Mitsubishi MELPS-7700
- - Mitsubishi MELPS-4500
- - Mitsubishi M16
- - Intel MCS-48/41
- - Intel MCS-51
- - Intel MCS-96
- - Intel 8080/8085
- - AMD 29K
- - Siemens 80C166/167
- - Zilog Z80, Z180, Z380
- - Zilog Z8
- - Toshiba TLCS-900(L)
- - Toshiba TLCS-90
- - Toshiba TLCS-870
- - Toshiba TLCS-47
- - Toshiba TLCS-9000
- - Microchip PIC16C54..16C57
- - Microchip PIC16C84/PIC16C64
- - Microchip PIC17C42
- - SGS-Thomson ST62xx
- - SGS-Thomson 6804
- - Texas Instruments TMS32010/32015
- - Texas Instruments TMS3202x
- - Texas Instruments TMS320C3x
- - Texas Instruments TMS370xxx
- - NEC uPD 78(C)1x
- - NEC uPD 75xxx (a.k.a. 75K0)
+Motorola 68000..68030,683xx including math co-processor and MMU; DSP56000;
+	Motorola/IBM MPC601/MPC505/PPC403; 6800, 6805, 6809, 68(HC)11 and
+	Hitachi 6301
+Hitachi 6309, H8 and SH7000/7600
+Rockwell 6502 and 65(S)C02
+CMD 65816
+Mitsubishi MELPS-740; MELPS-7700; MELPS-4500 and M16
+Intel MCS-48/41, MCS-51, MCS-96 and 8080/8085
+AMD 29K
+Siemens 80C166/167
+Zilog Z80, Z180, Z380 and Z8
+Toshiba TLCS-900(L), TLCS-90, TLCS-870, TLCS-47 and TLCS-9000
+Microchip PIC16C54..16C57, PIC16C84/PIC16C64 and PIC17C42
+SGS-Thomson ST62xx and 6804
+Texas Instruments TMS32010/32015, TMS3202x, TMS320C3x and TMS370xxx
+NEC uPD 78(C)1x and uPD 75xxx (a.k.a. 75K0)
 
 WWW: http://john.ccac.rwth-aachen.de:8000/as/
diff --git a/devel/flick/pkg-descr b/devel/flick/pkg-descr
index be0ce1730cf..1c44f1601ff 100644
--- a/devel/flick/pkg-descr
+++ b/devel/flick/pkg-descr
@@ -1,31 +1,23 @@
-Flick is an interface definition language (IDL) compiler ("stub generator")
-supporting remote procedure call (RPC) and remote method invocation (RMI) for
-client/server or distributed object systems.  What sets it apart from other IDL
-compilers is that it is highly optimizing while also supporting several IDLs,
-message formats, and transport mechanisms.  Flick currently has front ends for
-the CORBA, Sun ONC RPC, and Mach MIG IDLs, and middle and back ends that support
-CORBA IIOP, ONC/TCP, MIG-style Mach messages, and Fluke IPC (see below).  Flick
-produces stubs in the C language.  A substantial user's manual is provided.
+from the Web page:
 
-Flick is designed to be a "kit": the user picks the IDL, language mapping, and
-transport components that are required for any particular system.  Our goal is
-to make it straightforward to add new components to the kit to process new
-IDLs, language mappings, and transports.  (Collaborators welcome!)  Flick's
-framework can also be used to support interface annotation.  Full source for
-the Flick compiler is distributed under the terms of the GNU General Public
-License; source for the Flick runtime is distributed under a BSD-style license.
+	Flick, our IDL (interface definition language) compiler, is the research
+	and production IDL compiler within the Flux Project. Flick uses
+	techniques from traditional language compilers in order to produce very
+	fast client/server communication code. Flick-generated code can
+	typically encode and decode data between 2 and 17 times faster than code
+	produced by traditional IDL compilers, both commercial and free. The
+	result is that on stock hardware and operating systems, Flick-generated
+	stubs can increase end-to-end application throughput by factors of 4 or
+	more.
 
-Flick-generated marshal and unmarshal code generally runs between 2 and 17
-times as fast as code produced by other IDL compilers, commercial and free.  On
-stock hardware and operating systems, Flick-generated stubs can increase
-end-to-end client/server throughput by factors between 1.2 and 3.7 or more.
-
-Our paper describing these results was presented at PLDI'97, the major compiler
-conference, in June (see http://www.cs.bu.edu/pub/pldi97/).  The paper is
-included as part of the Flick distribution, and is separately available at
-ftp://mancos.cs.utah.edu/papers/flick-pldi-97-abs.html.
-
-Jay Lepreau, lepreau@cs.utah.edu
-University of Utah Computer Science Dept.
+	Flick is not just optimizing: it is also extremely flexible. Flick
+	currently supports the CORBA, ONC RPC (Sun RPC), and MIG IDLs.
+	Interfaces written in any of these languages can be implemented by
+	CORBA-, ONC RPC-, or MIG-style C language ``stubs'' communicating via
+	CORBA IIOP, ONC/TCP, Mach 3 ports, Trapeze, or Fluke IPC. Flick also
+	generates optimized CORBA C++ stubs that work with TAO, the real-time
+	CORBA ORB. Finally, because Flick is a ``kit'' of components, it can be
+	extended to support new IDLs, message data formats, and transport
+	mechanisms.
 
 WWW: http://www.cs.utah.edu/flux/flick/
diff --git a/devel/kimwitu++/pkg-descr b/devel/kimwitu++/pkg-descr
index e42837b5ef1..cf4fefe338b 100644
--- a/devel/kimwitu++/pkg-descr
+++ b/devel/kimwitu++/pkg-descr
@@ -1,25 +1,22 @@
-Kimwitu++ is the successor to Kimwitu. Like Kimwitu, it is a tool for
+	Kimwitu++ is the successor to Kimwitu. Like Kimwitu, it is a tool for
 processing trees (i.e. terms). It is a meta tool: Kimwitu++ can be used for
-generating software - especially when building compilers. Kimwitu++ has its
-own input language, which allows the definition fo the tree structure and of
-functions operating on the tree. It uses the input to generate a number of
-C++ files, which are then bound to a program using the C++ compiler.
-
-Kimwitu++ can be easily combined with parser generators like lex and yacc.
-While the parser deals with processing the grammar rules, kimwitu++ deals
-with creating an abstract syntax tree. In further passes, this tree can be
-used to generate target code. These passes can be implemented in the same
-program or a different one - kimwitu++ supports saving the tree into files.
-
-For processing the tree, Kimwitu++ supports two mechanisms: unparse rules
-(for code generation), and rewrite rules (for transformations). Each rule
-can be tailored to a specific node structure using pattern matching; all
-rules together are applied to the tree recursively. To support different
-rules for the same kind of node (in different application contexts),
-Kimwitu++ supports the definition of views.
-
-Inside the rules, Kimwitu++ allows to integrate C++ code; it also provides
-some extensions to C++. For each node type, a class is generated, which can
-be extended with user-defined methods.
+generating software - especially when building compilers.  Kimwitu++ has its own
+input language, which allows the definition fo the tree structure and of
+functions operating on the tree. It uses the input to generate a number of C++
+files, which are then bound to a program using the C++ compiler.
+	Kimwitu++ can be easily combined with parser generators like lex and
+yacc.  While the parser deals with processing the grammar rules, kimwitu++ deals
+with creating an abstract syntax tree. In further passes, this tree can be used
+to generate target code. These passes can be implemented in the same program or
+a different one - kimwitu++ supports saving the tree into files.
+	For processing the tree, Kimwitu++ supports two mechanisms: unparse
+rules (for code generation), and rewrite rules (for transformations).  Each rule
+can be tailored to a specific node structure using pattern matching; all rules
+together are applied to the tree recursively.  To support different rules for
+the same kind of node (in different application contexts), Kimwitu++ supports
+the definition of views.
+	Inside the rules, Kimwitu++ allows to integrate C++ code; it also
+provides some extensions to C++. For each node type, a class is generated, which
+can be extended with user-defined methods.
 
 WWW: http://site.informatik.hu-berlin.de/kimwitu++/
diff --git a/devel/mprof/pkg-descr b/devel/mprof/pkg-descr
index 29dff8b558c..93df37d7a78 100644
--- a/devel/mprof/pkg-descr
+++ b/devel/mprof/pkg-descr
@@ -1,3 +1,4 @@
+from the README:
 
 MPROF -- memory profiler (version 3.0)
 
@@ -12,86 +13,6 @@ mprof.man.
 Simply by linking in the new malloc and executing your application, a
 file called ``mprof.data'' will be created in the current directory.
 This is the data file that mprof uses to build its dynamic call graph.
-Call the program mprof with the following arguments:
-
-mprof [ options ] [ executable-file (a.out) ] [ data-file (mprof.data) ]
-
-The output contains four tables, the fields of which are described in
-the man page in mprof.man.  Further documentation is available in a
-paper which describes the implementation of mprof (published in the
-1988 summer USENIX conference) .  The LaTeX source of that paper is
-located in mprof.tex.  The printable DVI file is located in mprof.dvi.
-
-There are currently four makefiles, for the VAX, Sun-3, Sun-4, and
-MIPS (specifically, the Decstation 3100 and 5000).  To remake mprof,
-copy the appropriate file to `Makefile'.  If you need to recompile
-mprof for any reason, type ``make all'' in this directory.  To remove
-.o files, type ``make clean'' in this directory.  mprof has been
-tested on VAX (4.3 BSD and Ultrix using gcc and cc), SUN-3 (gcc and
-cc), Sun-4 (cc) computers, and Decstation 3100 (gcc and cc).  To test
-if mprof works in simple cases, type `make test'.
-
+[...]
 Mprof does not use Kyoto Common Lisp anymore.  To use mprof, all you
 need is a C compiler.
-
-The current incarnation of mprof does not handle calls to Sun calls to
-valloc or memalign correctly.  The calls will be profiled, but if your
-program calls valloc or memalign and tries to later free that memory,
-mprof will cause it to core dump.  On the VAX, memory allocated by
-valloc cannot be freed, and so valloc can be profiled correctly on the
-VAX.  A version of malloc.c is provided with mprof.  If this version
-is not compatible with the version used on your machine, you may need
-to replace this file.  If you have problems like this, please let me
-know so I can keep a record of the bugs encountered.
-
-My thanks to Stuart Sechrest, Fred Douglis, Dain Samples, John
-Ousterhout, Luigi Semenzato, Richard Tuck, Robert Scheifler, Mark
-Eichin, Pat Stephenson, and Steven Sargent for their interest and
-comments.
-
-My special thanks to Jeffrey Hsu who did the tricky port of mprof to
-the MIPS architecture.
-
-In the future (although the exact date is uncertain) I plan to make
-the following improvements to mprof:
-
-1.  Add code to detect duplicate frees.
-2.  Fix up the type determination code in mpfilt (see BUGS section in
-    the man page for mprof).
- 
-If you have any questions or comments, please feel free to contact me.
-
--Ben Zorn
- e-mail: zorn@boulder.colorado.edu
- phone:  303-492-4398
-
-
-Differences between version 2.0 and 2.1:
-
-1. In mpfilt.c, the variable stab_i was being incremented without
-checking for an overflow.  Overflow checks were added.
-
-2. A user discovered that a value of 5000 for ST_SIZE in mpfilt.c was
-too small.  Large programs may require a larger value for ST_SIZE.
-
-
-Differences between version 2.1 and 2.2:
-
-1. mprof now runs on the Decstation 3100 (a MIPS machine).
-
-2. A bug that prevented mprof from working in version 4.0 of the Sun
-operating system was fixed.
-
-
-Difference between version 2.2 and 3.0:
-
-1. All analysis is now done in C.
-
-2. The file mprof.c was renamed mprof_mon.c and the file mpfilt.c was
-renamed mprof.c.
-
-3. The old C-shell script ``mprof'' is not needed anymore.  The file
-analysis.lsp is also not needed.  It's functionality is now provided
-in the file mpgraph.c.
-
-4. Small bugs previously reported were fixed.
diff --git a/devel/p5-C-Scan/pkg-descr b/devel/p5-C-Scan/pkg-descr
index 8107a0306fc..56a7fb073c7 100644
--- a/devel/p5-C-Scan/pkg-descr
+++ b/devel/p5-C-Scan/pkg-descr
@@ -1,81 +1,6 @@
-       This description is VERY incomplete.
+C-Scan is a Perl module to scan C language files for easily recognized
+constructs such as included header files, macros and their arguments,
+declarations of functions, extern declarations, and typedefs.  It uses the
+Data::Flow interface.
 
-       This module uses Data::Flow interface, thus one uses it in
-       the following fashion:
-
-         $c = new C::Scan(attr1 => $value1, attr2 => $value2);
-         $c->set( attr3 => $value3 );
-
-         $value4 = $c->get('attr4');
-
-       Attributes are depending on some other attributes. The
-       only required attribute, i.e., the attribute which should
-       be set, is filename, which denotes which file to parse.
-
-       All other attributes are either optional, or would be
-       calculated basing on values of required and optional
-       attributes.
-
-       Output attributes
-
-
-       includes      Value: reference to a list of included
-                     files.
-
-       defines_args  Value: reference to hash of macros with
-                     arguments. The values are references to an
-                     array of length 2, the first element is a
-                     reference to the list of arguments, the
-                     second one being the expansion.  Newlines
-                     are not unescaped, thus
-
-                       #define C(x,y) E\
-                                      F
-
-                     will finish with ("C" => [ ["x", "y"],
-                     "E\nF"]).
-
-       defines_no_args
-                     Value: reference to hash of macros without
-                     arguments.  Newlines are not escaped, thus
-
-
-                       #define A B
-
-                     will finish with ("A" => "B").
-
-       fdecls        Value: reference to list of declarations of
-                     functions.
-
-       inlines       Value: reference to list of definitions of
-                     functions.
-
-       parsed_fdecls Value: reference to list of parsed
-                     declarations of functions.
-
-                     A parsed declaration is a reference to a
-                     list of (rt, nm, args, ft, mod). Here rt is
-                     return type of a function, nm is the name,
-                     args is the list of arguments, ft is the
-                     full text of the declaration, and mod is the
-                     modifier (which is always undef).
-
-                     Each entry in the list args is of the same
-                     form (ty, nm, args, ft, mod), here ty is the
-                     type of an argument, nm is the name (a
-                     generated one if missing in the
-                     declaration), args is undef, and mod is the
-                     string of array modifiers.
-
-       typedef_hash  Value: a reference to a hash which contains
-                     known typedefs as keys.
-
-       typedef_texts Value: a reference to a list which contains
-                     known expansions of typedefs.
-
-       typedefs_maybe
-                     Value: a reference to a list of typedefed
-                     names. (Syncronized with typedef_texts).
-
-       vdecls        Value: a reference to a list of extern
-                     variable declarations.
+WWW:  http://search.cpan.org/search?dist=C-Scan
diff --git a/devel/p5-Penguin/pkg-descr b/devel/p5-Penguin/pkg-descr
index 2c463078687..9d0f53f0bcf 100644
--- a/devel/p5-Penguin/pkg-descr
+++ b/devel/p5-Penguin/pkg-descr
@@ -1,95 +1,4 @@
-From the FAQ:
-
-5.  'Saaaay, what _is_ the design of Penguin?'
-
-    Glad you asked.
-
-    Consider two machines, foo and bar.  A user on foo (or perhaps
-    a program on foo) wishes to execute a program on machine bar.
-    However, imagine that the people running bar don't want just
-    anyone running code on their machine for security reasons.
-    This is the normal case on the Internet, and one which the
-    World Wide Web attempts to emulate with HTTP and CGI.
-
-    Normally, there is no well-known channel for foo to transmit
-    code to bar.  Further, there is no provision for the code to
-    undergo verification after transmission.  Too, there is no
-    well-defined way for bar to ensure that foo's code does not
-    attempt to perform insecure or damaging operations.
-
-    Penguin attempts to solve these issues while making sure the
-    code language maintains some acceptable degree of sufficiency
-    and power.
-    
-    Using Penguin, the user/program on foo 'digitally signs' the
-    code that's earmarked for delivery to bar.  The signature
-    encodes the code in such a way that it is impossible to alter
-    the code or deny that the signer signed it.
-
-    The code is then wrapped up into a packet and transmitted
-    through a 'channel' to a Penguin process running on machine
-    bar.  The channel's protocol layer is abstracted away
-    enough that it becomes unimportant; Penguin code can just 
-    as easily be delivered through SMTP or AOL Mail as through
-    TCP/IP, DECNet, AppleTalk, whatever.
-
-    The Penguin process on bar unwraps the packet, which contains
-    further verification and checksum information, and then
-    'digitally unsigns' the code, a process which provides the
-    code in 'clear' form while telling the receiver who digitally
-    signed it.
-
-    The receiver then cross-references the signer's identity with
-    a list of rights that the receiver associates with the signer,
-    reverting to a set of default rights if the signer is unknown
-    or unlisted.
-
-    A safe compartment is then created, populated with the
-    functions allowed to the signer, and told to limit the
-    operations it can perform to only those permitted to the
-    signer.
-
-    The code is then compiled within that safe compartment.  If
-    it attempts to do something which the signer is not allowed
-    to do, or if it attempts to call a function not permitted
-    to the signer, the compartment immediately traps the operation
-    and throws the code away before it can execute.  If the code
-    uses no unsafe or illegal operations, then it executes and
-    produces a result.
-
-    The code executing side then becomes the master in the
-    transaction, and can send code to the original sender,
-    send the return value back in a data packet, and so forth.
-    The process repeats as necessary until both parties are
-    done; the channel then closes, and the Penguin transaction is complete.
-
-    The basic sentiment behind the idea of 'identity' being
-    correlated to 'rights' in the receiver is that in signing
-    the code, the signer commits her identity and her reputation
-    on the correct operation of the code.
-
-    'highly trustable' signers (as one might imagine Larry Wall,
-    Randal Schwartz, and Tom Christiansen to be) might be assigned
-    very high levels of trust and equivalent degrees of 'rights',
-    so that programs they sign can perform very complex and
-    interesting operations on your computer.  By the same token,
-    paranoid sites or those wishing isolation could assign zero
-    rights to everyone except for a select (perhaps internal) few.
-
-    Part of the 'rights' given to signers include possibly specialized
-    functions that encapsulate the functionality of extremely dangerous
-    operations.  For instance, a store opening up on the Internet might
-    put up a Penguin server which put functions called 'list_items'
-    and 'buy_item()' into the limited compartments all users get.
-    'list_items' might open up a file on the store's machine, read
-    the contents, and spit them out -- an operation which, if allowed
-    in the general case, would clearly breach security.  However,
-    by creating a specialized function, the security concern is
-    removed, and by letting potential customers know of the function,
-    the power and ease of use are kept high.
-
-    Niggling but important technical issues currently being wrestled
-    with include the way that foreign functions are registered into
-    the namespace, the construction of a foreign function framework
-    so that the names and function of the functions are well-known,
-    and a superior-than-current 'digital signature' method.
+The Penguin module provides a framework within which a user on one host
+electronically signs a piece of Perl code, sends it to another host where the
+signature is checked and the code is executed with privileges that are
+particular to that user.