Cram into 80 columns by 24 rows.
This commit is contained in:
Trevor Johnson
+20
-33
@@ -1,37 +1,24 @@
|
||||
INTRODUCTION
|
||||
============
|
||||
mp3encode is a package for encoding MPEG layer I, II and III audio
|
||||
files. This is the reference implementation so don't expect
|
||||
spectacular performance.
|
||||
|
||||
Driving encode is pretty simple although it may take some practice to
|
||||
work out an optimal compression rate. AIFF files are the only type of
|
||||
files that seem to work with this version so you may need to install a
|
||||
port like "sox" to convert your file types. I use the "nas" port to
|
||||
record and edit all of my audio files but so long as you have a valid
|
||||
AIFF file it shouldn't matter what you use.
|
||||
|
||||
Although the source code includes a decoder I have decided not to port
|
||||
it because we already have a couple of top class mpeg decoders in the
|
||||
ports collection.
|
||||
|
||||
HINTS & TIPS
|
||||
============
|
||||
Physcoacoustic model 2 is the only supported model in layer III
|
||||
encoding. A bit-rate of 128Kbps is adequate for most forms of music but
|
||||
you may need to turn down the compression to 160Kbps if the music is
|
||||
The mp3encode package encodes MPEG layer I, II and III audio files.
|
||||
This is the reference implementation so don't expect spectacular performance.
|
||||
Driving encode is pretty simple although it may take some practice to
|
||||
work out an optimal compression rate. AIFF files are the only type of files that
|
||||
seem to work with this version so you may need to install a port like "sox" to
|
||||
convert your file types. I use the "nas" port to record and edit all of my audio
|
||||
files but so long as you have a valid AIFF file it shouldn't matter what you
|
||||
use.
|
||||
Although the source code includes a decoder I have decided not to port
|
||||
it because we already have a couple of top class MPEG decoders in the ports
|
||||
collection.
|
||||
Psychoacoustic model 2 is the only supported model in layer III
|
||||
encoding. A bit-rate of 128 kilobits/s is adequate for most forms of music but
|
||||
you may need to turn down the compression to 160 kilobits/s if the music is
|
||||
particularly atmospheric.
|
||||
|
||||
Vocal spoken recordings are best encoded using a 32Kbps bit-rate with
|
||||
layer II (layer III makes you sound like a Dalek under digital water)
|
||||
with a 32kHz sample rate in mono. Using this method I have managed to
|
||||
get about 5 minutes of AM Radio quality audio into around 1 MB.
|
||||
|
||||
MISC
|
||||
====
|
||||
If anyone finds any bugs in this software please let me know and
|
||||
include patches to fix them.
|
||||
Vocal spoken recordings are best encoded using a 32 kilobits/s bit-rate
|
||||
with layer II (layer III makes you sound like a Dalek under digital water) with
|
||||
a 32 kHz sample rate in mono. Using this method I have managed to get about 5
|
||||
minutes of AM radio quality audio into around 1 MB.
|
||||
If anyone finds any bugs in this software please let me know and include
|
||||
patches to fix them.
|
||||
|
||||
Share and enjoy,
|
||||
|
||||
Joel...
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
gbscript converts GB simplified Chinese text to PostScript.
|
||||
|
||||
Chinese bitmap fonts, which are:
|
||||
o without 'zone gap', and
|
||||
o 16x16 or 24x24 sized
|
||||
Chinese bitmap fonts which are without 'zone gap' and 16x16 or 24x24 sized
|
||||
|
||||
Some usable fonts are:
|
||||
Name Description File Size
|
||||
@@ -16,14 +14,11 @@ Chinese bitmap fonts, which are:
|
||||
[16x16]
|
||||
ncclib.16 (Simplified) 267,712
|
||||
|
||||
NOTE:
|
||||
o cclib.j24, cclib.f24, cclib.k24, cclib.h24 and cclib.n24
|
||||
are a different set of font files (although derived from
|
||||
same origins); they cannot be used with GBscript.
|
||||
o some fonts do not include those zones for special symbols
|
||||
(in order to save some disk space), thus they are not
|
||||
continuous in zone and there exist 'zone gaps'. GBscript
|
||||
currently cannot handle this type of font.
|
||||
|
||||
Location: Chinese bitmap fonts can be found in
|
||||
/ftp@ifcss.org:/software/fonts/
|
||||
NOTES:
|
||||
o cclib.j24, cclib.f24, cclib.k24, cclib.h24 and cclib.n24 are a different set
|
||||
of font files (although derived from same origins); they cannot be used with
|
||||
GBscript.
|
||||
o some fonts do not include zones for special symbols, to save disk space, thus
|
||||
they are not continuous in zone and there exist 'zone gaps'. GBscript
|
||||
currently cannot handle this type of font.
|
||||
o Chinese bitmap fonts can be found in /ftp@ifcss.org:/software/fonts/
|
||||
|
||||
+9
-14
@@ -2,28 +2,23 @@ cdb is a fast, reliable, lightweight package for creating and reading
|
||||
constant databases. Its database structure provides several features:
|
||||
|
||||
* Fast lookups: A successful lookup in a large database normally takes
|
||||
just two disk accesses. An unsuccessful lookup takes only one.
|
||||
|
||||
just two disk accesses. An unsuccessful lookup takes only one.
|
||||
* Low overhead: A database uses 2048 bytes, plus 24 bytes per record,
|
||||
plus the space for keys and data.
|
||||
|
||||
plus the space for keys and data.
|
||||
* No random limits: cdb can handle any database up to 4 gigabytes. There
|
||||
are no other restrictions; records don't even have to fit into memory.
|
||||
Databases are stored in a machine-independent format.
|
||||
|
||||
are no other restrictions; records don't even have to fit into memory.
|
||||
Databases are stored in a machine-independent format.
|
||||
* Fast atomic database replacement: cdbmake can rewrite an entire
|
||||
database two orders of magnitude faster than other hashing packages.
|
||||
|
||||
database two orders of magnitude faster than other hashing packages.
|
||||
* Fast database dumps: cdbdump prints the contents of a database in
|
||||
cdbmake-compatible format.
|
||||
cdbmake-compatible format.
|
||||
|
||||
cdb is designed to be used in mission-critical applications like e-mail.
|
||||
Database replacement is safe against system crashes. Readers don't have
|
||||
to pause during a rewrite.
|
||||
|
||||
Note for developers:
|
||||
Packages that need to read cdb files should incorporate the
|
||||
necessary portions of the cdb library rather than relying on
|
||||
an external cdb library. (See WWW)
|
||||
Note for developers: packages that need to read cdb files should
|
||||
incorporate the necessary portions of the cdb library rather than
|
||||
relying on an external cdb library. (See WWW)
|
||||
|
||||
WWW: http://cr.yp.to/cdb.html
|
||||
|
||||
@@ -1,35 +1,12 @@
|
||||
README for Mini SQL Version 2.0 Beta 1
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Welcome to Mini SQL 2! It's been a long time coming but we hope the
|
||||
wait has been worth it. As the development of mSQL 2 continues, further
|
||||
funtionality will be made available. This release concentrates on
|
||||
adding the underlying performance and data handling features to mSQL.
|
||||
|
||||
The software has changed quite a lot since the 1.x version of mSQL.
|
||||
Some of the new features are greatly improved support for indexing your
|
||||
data, much better performance for complex queries and large data sets,
|
||||
the addition of variable length TEXT fields, support for server managed
|
||||
numeric sequences, better regular expression handling, and easier
|
||||
control over the configuration of the server.
|
||||
|
||||
|
||||
FreeBSD-specific port notes
|
||||
---------------------------
|
||||
|
||||
The ports of mSQL 1.x lived in it's own tree, /usr/local/Minerva. At the
|
||||
time, mSQL was a part of a larger project called Minerva, to which other
|
||||
tools would be added. These other tools would also live in
|
||||
/usr/local/Minerva.
|
||||
|
||||
As of the 2.x release of mSQL, the author of mSQL has put many of these
|
||||
tools into the base mSQL distribution, and so it is no longer feasible to
|
||||
have the program live in it's own directory.
|
||||
|
||||
So, in keeping with the BSD directory tree structure, you will find the
|
||||
following changes between the "official" mSQL 2.x distribution and the
|
||||
FreeBSD port :
|
||||
|
||||
The port of mSQL 1.x lived in its own tree, /usr/local/Minerva. At the
|
||||
time, mSQL was a part of a larger project called Minerva, to which other tools
|
||||
would be added. These other tools would also live in /usr/local/Minerva.
|
||||
As of the 2.x release of mSQL, the author of mSQL has put many of these
|
||||
tools into the base mSQL distribution, so it is no longer feasible to have the
|
||||
program live in its own directory.
|
||||
So, in keeping with the BSD directory tree structure, you will find the
|
||||
following changes between the "official" mSQL 2.x distribution and the FreeBSD
|
||||
port.
|
||||
|
||||
Documentation states: Port uses:
|
||||
===================== ==========================
|
||||
@@ -40,7 +17,4 @@ Documentation states: Port uses:
|
||||
/usr/local/Hughes/msql.conf /usr/local/etc/msql2/msql.conf
|
||||
/usr/local/Hughes/msql.acl /usr/local/etc/msql2/msql.acl
|
||||
|
||||
--
|
||||
j.
|
||||
|
||||
WWW: http://www.hughes.com.au/
|
||||
|
||||
@@ -1,35 +1,12 @@
|
||||
README for Mini SQL Version 2.0 Beta 1
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Welcome to Mini SQL 2! It's been a long time coming but we hope the
|
||||
wait has been worth it. As the development of mSQL 2 continues, further
|
||||
funtionality will be made available. This release concentrates on
|
||||
adding the underlying performance and data handling features to mSQL.
|
||||
|
||||
The software has changed quite a lot since the 1.x version of mSQL.
|
||||
Some of the new features are greatly improved support for indexing your
|
||||
data, much better performance for complex queries and large data sets,
|
||||
the addition of variable length TEXT fields, support for server managed
|
||||
numeric sequences, better regular expression handling, and easier
|
||||
control over the configuration of the server.
|
||||
|
||||
|
||||
FreeBSD-specific port notes
|
||||
---------------------------
|
||||
|
||||
The ports of mSQL 1.x lived in it's own tree, /usr/local/Minerva. At the
|
||||
time, mSQL was a part of a larger project called Minerva, to which other
|
||||
tools would be added. These other tools would also live in
|
||||
/usr/local/Minerva.
|
||||
|
||||
As of the 2.x release of mSQL, the author of mSQL has put many of these
|
||||
tools into the base mSQL distribution, and so it is no longer feasible to
|
||||
have the program live in it's own directory.
|
||||
|
||||
So, in keeping with the BSD directory tree structure, you will find the
|
||||
following changes between the "official" mSQL 2.x distribution and the
|
||||
FreeBSD port :
|
||||
|
||||
The port of mSQL 1.x lived in its own tree, /usr/local/Minerva. At the
|
||||
time, mSQL was a part of a larger project called Minerva, to which other tools
|
||||
would be added. These other tools would also live in /usr/local/Minerva.
|
||||
As of the 2.x release of mSQL, the author of mSQL has put many of these
|
||||
tools into the base mSQL distribution, so it is no longer feasible to have the
|
||||
program live in its own directory.
|
||||
So, in keeping with the BSD directory tree structure, you will find the
|
||||
following changes between the "official" mSQL 2.x distribution and the FreeBSD
|
||||
port.
|
||||
|
||||
Documentation states: Port uses:
|
||||
===================== ==========================
|
||||
@@ -40,7 +17,4 @@ Documentation states: Port uses:
|
||||
/usr/local/Hughes/msql.conf /usr/local/etc/msql2/msql.conf
|
||||
/usr/local/Hughes/msql.acl /usr/local/etc/msql2/msql.acl
|
||||
|
||||
--
|
||||
j.
|
||||
|
||||
WWW: http://www.hughes.com.au/
|
||||
|
||||
@@ -1,2 +1,2 @@
|
||||
This module is a simple creator of XML data from DBI datasources. It allows you to
|
||||
easily extract data from a database, and manipulate later using XML::Parser.
|
||||
This module is a simple creator of XML data from DBI datasources. It allows you
|
||||
to easily extract data from a database, and manipulate later using XML::Parser.
|
||||
|
||||
+17
-40
@@ -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/
|
||||
|
||||
+19
-27
@@ -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/
|
||||
|
||||
+19
-22
@@ -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++/
|
||||
|
||||
+2
-81
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -2,35 +2,21 @@ Evilfinder shows you whether things are evil. By default, the port will
|
||||
install a wrapper called "evilfinder," but you can define WITH_WRAPPER
|
||||
to build the web-oriented default binary only.
|
||||
|
||||
|
||||
**** THE PROOF THAT The FreeBSD Project IS EVIL ****
|
||||
|
||||
T H E F R E E B S D P R O J E C T
|
||||
20 8 5 6 18 5 5 2 19 4 16 18 15 10 5 3 20 - as numbers
|
||||
2 8 5 6 9 5 5 2 1 4 7 9 6 1 5 3 2 - digits added
|
||||
\___________/ \________/ \__________/ \_________/ \_/
|
||||
3 3 3 6 2 - digits added
|
||||
|
||||
Thus, "The FreeBSD Project" is 33362.
|
||||
|
||||
Add 1947, the year Aleister Crowley paid a longer visit to hell - the
|
||||
result is 35309.
|
||||
|
||||
Turn the number backwards, and add 1945 - the year Mussolini was
|
||||
executed for the first time. The number is now 92298.
|
||||
|
||||
Add 9981 to it - this is the year "Scrabble" was invented to promote
|
||||
violence and anger, written backwards - you will get 102279.
|
||||
|
||||
Subtract 23, the symbol of death. The result will be 102256.
|
||||
|
||||
Divide the number by 83 - this is the symbol of slavery, backwards. It
|
||||
gives 1232.
|
||||
|
||||
This number, read as octal, gives 666 - the number of the Beast.
|
||||
|
||||
This is truly evil. QED.
|
||||
|
||||
Thus, "The FreeBSD Project" is 33362. Add 1947, the year Aleister Crowley paid
|
||||
a longer visit to Hell. The result is 35309. Turn the number backwards, and
|
||||
add 1945 - the year Mussolini was executed for the first time. The number is now
|
||||
92298. Add 9981 to it - this is the year "Scrabble" was invented to promote
|
||||
violence and anger, written backwards - you will get 102279. Subtract 23, the
|
||||
symbol of death. The result will be 102256. Divide the number by 83 - this is
|
||||
the symbol of slavery, backwards. It gives 1232. This number, read as octal,
|
||||
gives 666 - the number of the Beast. This is truly evil. QED.
|
||||
|
||||
WWW: http://lcamtuf.coredump.cx/evilfinder/ef.shtml
|
||||
-Adam Weinberger <adamw@FreeBSD.org>
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
LTris is just another tetris clone but imho a good one. So if you like tetris,
|
||||
download and play it!
|
||||
LTris is just another clone of Tetris but IMHO a good one, so if you like
|
||||
Tetris, download and play it!
|
||||
|
||||
Features:
|
||||
|
||||
Tetris clone using SDL
|
||||
Sound
|
||||
Menu
|
||||
@@ -17,10 +16,9 @@ Features:
|
||||
Two player mode
|
||||
Two game modes
|
||||
|
||||
Two game modes? Yes. The first one called "normal" is the mode everbody knows
|
||||
well. You play as long as you can while the blocks are getting faster. The
|
||||
second one called "advanced" has got some additional features. First there is
|
||||
a new figure in each new level and second later on there are suddenly appearing
|
||||
tiles and rows.
|
||||
Two game modes? Yes. The "normal" mode is the one everbody knows well. You
|
||||
play as long as you can while the blocks are getting faster. The second one
|
||||
called "advanced" has some additional features. First there is a new figure in
|
||||
each new level and second later on there are suddenly appearing tiles and rows.
|
||||
|
||||
WWW: http://lgames.sourceforge.net/index.php?project=LTris
|
||||
|
||||
+17
-28
@@ -1,35 +1,24 @@
|
||||
Quake Server README
|
||||
===================
|
||||
|
||||
Ok, this one definately falls into the "I had some time one Sunday
|
||||
Ok, this one definitely falls into the "I had some time one Sunday
|
||||
afternoon..." category.
|
||||
|
||||
This port allows you to host Quake network games on your FreeBSD machine.
|
||||
|
||||
This installs the v1.01 shareware version of Quake, and the required files
|
||||
to automate a server. If you have purchased the registered version of Quake
|
||||
and wish to host a registered server, take the files from the ID1/
|
||||
subdirectory of your installed version of Quake, and put them into the id1/
|
||||
subdirectory of /usr/local/quakeserver. Be sure to make the filenames
|
||||
lowercase.
|
||||
|
||||
NOTE: I'm not sure how this will work with the v1.06 version of registered
|
||||
quake. Currently, I can't get the intel loader to work with the 1.06 game
|
||||
files, so I'm not optimistic. YMMV.
|
||||
|
||||
Credits to iD for creating a great game, and to Dan Nelson
|
||||
This port allows you to host Quake network games on a FreeBSD machine.
|
||||
This installs the v1.01 shareware version of Quake, and the required
|
||||
files to automate a server. If you have purchased the registered version of
|
||||
Quake and wish to host a registered server, take the files from the ID1/
|
||||
subdirectory of your installed version of Quake, and put them into
|
||||
/usr/local/quakeserver/id1. Be sure to make the filenames lowercase.
|
||||
Note: I'm not sure how this will work with the v1.06 version of
|
||||
registered quake. Currently, I can't get the intel loader to work with the 1.06
|
||||
game files, so I'm not optimistic. YMMV.
|
||||
Credits to iD for creating a great game, and to Dan Nelson
|
||||
<dnelson@emsphone.com> for creating the expect script that wraps around the
|
||||
server in case it crashes.
|
||||
|
||||
Note that this port can technically be used to play Quake under X, but I
|
||||
don't recommend it. It's slow, small, and prone to crashing. If you want
|
||||
to host a very fast and responsive Quake game, use this. If you want to
|
||||
play it, run DOS.
|
||||
|
||||
Shameless plug: I've also ported qcc, the QuakeC compiler to let server ops
|
||||
make their own quake games. You do need registered Quake to do this, but
|
||||
Note that this port can technically be used to play Quake under X, but I
|
||||
don't recommend it. It's slow, small, and prone to crashing. If you want to
|
||||
host a very fast and responsive Quake game, use this. If you want to play it,
|
||||
run DOS.
|
||||
Shameless plug: I've also ported qcc, the QuakeC compiler to let server
|
||||
ops make their own quake games. You do need registered Quake to do this, but
|
||||
it's well worth it. Look for qcc in the games collection of FreeBSD's ports
|
||||
repository.
|
||||
|
||||
--
|
||||
j.
|
||||
|
||||
@@ -2,7 +2,6 @@ This is the XEVIOUS (NAMCO(C)) like game.
|
||||
|
||||
TYPE:
|
||||
xbat
|
||||
|
||||
OPTION:
|
||||
-hs : high speed mode
|
||||
-dc : use default colormap
|
||||
@@ -11,17 +10,15 @@ OPTION:
|
||||
-h -help : print usage
|
||||
-mode [0-4] : set game level
|
||||
0:easy, 1:normal, 2:difficult, 3:more difficult, 4:abnormal
|
||||
|
||||
COMMAND:
|
||||
[s] for Start or Pause
|
||||
[q] for quit
|
||||
[c] for setup (at Title screen only)
|
||||
|
||||
Cursor key or Number key to move.
|
||||
i, j, l, k, m also to move.
|
||||
[z] and [x] to shot.
|
||||
[z] and [x] to shoot.
|
||||
|
||||
Please e-mail to the author ( wai@nemoto.ecei.tohoku.ac.jp) for
|
||||
improvement or other something about this game.
|
||||
Please e-mail the author (wai@nemoto.ecei.tohoku.ac.jp) with improvements or
|
||||
other comments about this game.
|
||||
|
||||
Nakai@Mlab.t.u-tokyo.ac.jp
|
||||
|
||||
+19
-35
@@ -1,39 +1,23 @@
|
||||
This is version 5.4.1 of xbattle, by Greg Lesher, based on the original
|
||||
by Steve Lehar released in 1991, and including certain enhancements,
|
||||
modifications, and bug fixes suggested by a number of contributers from
|
||||
all over the world. The extensive changes from version 5.1, the last
|
||||
official xbattle release, are outlined below. The latest version can be
|
||||
obtained by anonymous ftp to cns-ftp.bu.edu in the pub/xbattle direction
|
||||
in compressed and gzip-ed tar format (xbattle-5.4.1.tar.Z and
|
||||
xbattle-5.4.1.tar.gz).
|
||||
|
||||
xbattle is a concurrent multi-player game which combines elements of
|
||||
strategy with arcade-like action to capture a wide range of military
|
||||
scenarios. The game is based on X Windows, which you must have
|
||||
installed to run xbattle. Opponents play from separate displays, with commands
|
||||
being executed concurrently -- the players do not take "turns", but rather
|
||||
they all issue their commands simultaneously. There can be any number of
|
||||
players, with each player assigned to a specific team, indicated by
|
||||
marker colors. The game board is a matrix of cells (square, hexes, etc.) that
|
||||
can be occupied by colored troops, with the goal of the game being to
|
||||
eliminate the enemy from the board by attacking cells occupied by enemy
|
||||
troops. A wide variety of command line options (and previously configured game
|
||||
files) provide an abundance of different scenarios and gaming environments.
|
||||
|
||||
If you have never used xbattle before, we strongly suggest you read
|
||||
through the online introduction at the Web site specified below. To get the
|
||||
feel of the game, you can run the tutorials (called "tutorial1" and
|
||||
"tutorial2") that are supplied with the game. These are shell scripts
|
||||
that run on unix systems and start up a series of small example games that
|
||||
you can play around with to learn the various options available with the
|
||||
game. If you are not on a unix system, print out the tutorials and type
|
||||
in the embedded command lines by hand. If you are interested in the
|
||||
philosophical and game design issues of xbattle, or want to get immediate
|
||||
notice of the latest releases, updates, and bug fixes, send email to
|
||||
xbattle_request@gnu.ai.mit.edu and we will put you on the xbattle mailing
|
||||
list.
|
||||
This is xbattle by Greg Lesher, based on the original by Steve Lehar
|
||||
released in 1991, and including enhancements, modifications, and bug fixes by
|
||||
contributers from all over the world.
|
||||
It is a concurrent multi-player game which combines elements of strategy
|
||||
with arcade-like action to capture a wide range of military scenarios. The game
|
||||
is based on X Windows. Opponents play from separate displays, with commands
|
||||
being executed concurrently--the players do not take "turns", but rather they
|
||||
all issue their commands simultaneously. There can be any number of players,
|
||||
with each player assigned to a specific team, indicated by marker colors. The
|
||||
game board is a matrix of cells (square, hexes, etc.) that can be occupied by
|
||||
colored troops, with the goal of the game being to eliminate the enemy from the
|
||||
board by attacking cells occupied by enemy troops. A wide variety of command
|
||||
line options (and previously configured game files) provide an abundance of
|
||||
different scenarios and gaming environments.
|
||||
If you have never used xbattle before, read the introduction on the
|
||||
xbattle Web site. To get the feel of the game, you can run the "tutorial1" and
|
||||
"tutorial2" scripts supplied with the game. These start a series of small
|
||||
example games that you can play around with to learn the various options
|
||||
available with the game.
|
||||
|
||||
WWW: http://cns-web.bu.edu/pub/xpip/html/xbattle.html
|
||||
|
||||
- Gregory W. Lesher
|
||||
lesher@cns.bu.edu
|
||||
|
||||
@@ -1,24 +1,15 @@
|
||||
Xsoldier is a shooting game for x11.
|
||||
|
||||
Xsoldier is a shooting game for x11. This is adapted from the man page:
|
||||
OPTIONS:
|
||||
-display <displayname> Specify display.
|
||||
|
||||
-wait <unsigned int n> Specify wait. To change this will let
|
||||
your highscore unregistered.
|
||||
|
||||
-cmap Use default colormap.
|
||||
Without this option, xsoldier use pri-
|
||||
vate colormap.
|
||||
|
||||
-score Show 10 highscores.
|
||||
|
||||
-help Show usage message.
|
||||
|
||||
You can use the head 1 charactor of an option instead.
|
||||
|
||||
You can use the first character of an option instead.
|
||||
PLAY:
|
||||
% xsolder
|
||||
|
||||
- Start game with [space]
|
||||
- Cursor keys to move, [left-shift] to shot
|
||||
- Defeat enemies and you sometimes find [Weapon] or [Power]
|
||||
@@ -29,8 +20,5 @@ PLAY:
|
||||
- You can get bonus points along defeat average at clear
|
||||
stage
|
||||
- 1UP per 100,000 points
|
||||
- 8 stages all and try to clear!!
|
||||
|
||||
AUTHOR:
|
||||
When you find bugs or some, please e-mail to the author
|
||||
hachi@surfline.ne.jp
|
||||
- 8 stages all and try to clear!
|
||||
Author: hachi@surfline.ne.jp
|
||||
|
||||
+20
-47
@@ -1,51 +1,24 @@
|
||||
Yamsweeper is a game to clear the field filled with bombs (mines).
|
||||
|
||||
On the left top corner of the main window,
|
||||
the number of mines left is displayed.
|
||||
You can mark hidden mines underneath the panels, then
|
||||
the number is decreased.
|
||||
The number can be minus, but that means you have over-marked.
|
||||
|
||||
On the right top corner, the time passed is displayed.
|
||||
The time counts up to 999 seconds.
|
||||
|
||||
On center top, there's the symbol of yamsweeper.
|
||||
You can start a new game by clicking this symbol.
|
||||
|
||||
A panel is opened with the left mouse button.
|
||||
If panels not opened are around the panel, and
|
||||
if they don't have mines underneith and around them,
|
||||
panels are also opened.
|
||||
This can be happened like chain reaction.
|
||||
But be carefull; the game is over when you open a mine.
|
||||
|
||||
If the panel opened has mines around,
|
||||
you will see a number varies from 1 to 8, which means
|
||||
the number of mines.
|
||||
For example, `1' tells you one of the panels around
|
||||
has a mine. `2' says that two mines are hidden next to.
|
||||
|
||||
You can mark suspicious panels by the right button.
|
||||
The right button changes the state of the panel, as:
|
||||
|
||||
Normal -> "Bomb" -> "?" -> Back to Normal -> ...
|
||||
|
||||
Once you mark a panel (as "Bomb" or "?"), it cannot be opened.
|
||||
You have to click the panel until it becomes to Normal state.
|
||||
|
||||
The middle button is assigned a special functionality.
|
||||
You can use the middle button to open the unmarked panels around,
|
||||
under a certain condition.
|
||||
|
||||
1. The panel you clicked is opened.
|
||||
|
||||
2. The panel is not null, a number is displayed.
|
||||
|
||||
3. the number of marked panels is equal to the number displayed on
|
||||
Yamsweeper is a game to clear the field filled with bombs (mines). On the left
|
||||
top corner of the main window, the number of mines left is displayed. You can
|
||||
mark hidden mines underneath the panels, then the number is decreased. The
|
||||
number can be minus, but that means you have over-marked. On the right top
|
||||
corner, the time passed is displayed. The time counts up to 999 seconds. On
|
||||
center top, there's the symbol of yamsweeper. You can start a new game by
|
||||
clicking the symbol. A panel is opened with the left mouse button. If unopened
|
||||
panels are around the panel, and if they don't have mines underneath and around
|
||||
them, panels are also opened. This can happen like a chain reaction. Be
|
||||
careful; the game is over when you open a mine. If the panel opened has mines
|
||||
around, you will see a number varies from 1 to 8, which means the number of
|
||||
mines. For example, `1' tells you one of the panels around has a mine. `2' says
|
||||
that two mines are hidden next to. You can mark suspicious panels by the right
|
||||
button, which toggles the state of the panel between "Bomb" or "?" (in which it
|
||||
cannot be opened) and Normal. The middle button is assigned a special
|
||||
functionality. You can use the middle button to open the unmarked panels
|
||||
around, under certain conditions:
|
||||
- the panel you clicked is opened
|
||||
- the panel is not null, a number is displayed
|
||||
- the number of marked panels is equal to the number displayed on the
|
||||
clicked panel.
|
||||
|
||||
Click the middle button on a opened panel.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
|
||||
This port was created by Hidekazu Kuroki <hidekazu@cs.titech.ac.jp>.
|
||||
|
||||
+11
-38
@@ -1,51 +1,24 @@
|
||||
This collection provides a complete package for manipulating and
|
||||
converting color and black and whites images, including 24bit RGB, 8bit
|
||||
mapped color, 8bit grayscale, and 1bit bitmapped images.
|
||||
|
||||
clr2gray Convert color to grayscale
|
||||
fbcat Copy image (used for format conversion)
|
||||
Adapted from the README: the FBM collection provides a complete package for
|
||||
manipulating and converting images, including 24-bit RGB, 8-bit color, 8-bit
|
||||
grayscale, and 1-bit bitmaps. This is a partial list of the commands:
|
||||
fbclean Flip isolated pixels (clean image)
|
||||
fbconv Arbitrary convolutions
|
||||
fbedge Compute derivative image (edge detection)
|
||||
fbext Extract region, resize, change aspect ratio
|
||||
fbgamma Gamma correct grayscale or color image for display
|
||||
fbhalf Halftone grayscale image (Blue noise, Floyd-Steinberg, etc)
|
||||
fbham Convert FBM 24bit RGB to Amiga HAM mode
|
||||
fbhist Compute histogram
|
||||
fbinfo Dump image header
|
||||
fbm2pod Convert grayscale image to Diablo graphics (!)
|
||||
fbm2tga Convert image to Targa format
|
||||
fbm2tiff Convert FBM files to 1, 2, 4, 8, or 24 bit TIFF
|
||||
fbmask Set region to gray value
|
||||
fbmedian Median filter 3x3 regios
|
||||
fbmedian Median filter 3x3 regions
|
||||
fbnorm Normalize image intensity / increase contrast
|
||||
fbpalet Replace an imager's colormap with another, remove duplicates
|
||||
fbps Convert to PostScript
|
||||
fbquant Color quantization (24 bit to 8..256 colors) Mod. Heckbert
|
||||
fbquant Color quantization (24-bit to 8..256 colors) Mod. Heckbert
|
||||
fbrot Rotate 90, 180, or 270 degrees
|
||||
fbthin Thin 1bit images
|
||||
fbsample Sample a 1bit file to produce an 8bit file
|
||||
fbthin Thin 1-bit images
|
||||
fbsharp Sharpen (edge enhancement) by digital Laplacian
|
||||
gray2clr Add a "gray" colormap to a grayscale image
|
||||
idiff (and udiff) convert raw byte stream into byte difference
|
||||
pbm2ps Convert PBM file to PostScript
|
||||
pbmtitle Add a title to a PBM file
|
||||
raw2fbm Convert raw file to FBM format (eg: Amiga Digiview files)
|
||||
tga2fbm Convert Targa file to FBM format
|
||||
tiff2fbm Convert tiff file to FBM format
|
||||
uunet2fbm Convert UseNet Facesaver file to FBM format
|
||||
|
||||
File Formats
|
||||
|
||||
FBM (-F) FBM file with 256 byte header (with title & credits)
|
||||
Sun (-S) Sun rasterfile with 32 byte header
|
||||
Tiff (-T) Aldus TIFF
|
||||
PBM (-P) Poskanzer format for 1bit files
|
||||
GIF (-G) CompuServe GIF format
|
||||
JPG (-J) JPEG JFIF format (cf The Independent JPEG Group)
|
||||
RLE (-R) Utah RLE format
|
||||
IFF (-I) Amiga IFF files (except HAM mode files)
|
||||
PCX (-Z) PC PaintBrush format for IBM
|
||||
Face (-B) Bennet Yee's 1bit files, used at CMU
|
||||
___________
|
||||
From the README file
|
||||
The FBM utilities handle these image formats: native FBM, UseNet Facesaver, raw
|
||||
(e.g. Amiga Digiview), Targa, Sun rasterfile with 32 byte header, Aldus TIFF,
|
||||
Poskanzer PBM format for 1-bit files, CompuServe GIF, JPEG JFIF, Utah RLE, Amiga
|
||||
IFF (except HAM mode), PC PaintBrush PCX, and Bennet Yee's 1-bit Face files.
|
||||
Amiga HAM, Diablo graphics, and PostScript output is available.
|
||||
|
||||
+11
-38
@@ -1,42 +1,15 @@
|
||||
GIFTool , a tool for GIF89a trasnparent option and interlace mode.
|
||||
GIFTool is a tool for GIF89a transparent option and interlace mode. For
|
||||
instance 'giftool -B -i *.gif' converts all images to interlaced GIF files.
|
||||
|
||||
Usage: giftool [options] [file]
|
||||
giftool (-p|-c|-B) [options] [files...]
|
||||
-B Batch Mode, read and write the same filename
|
||||
-i Set GIF Interlace mode ON
|
||||
+i Set GIF Interlace mode OFF
|
||||
-p Print information about file(s)
|
||||
-c Print comment information
|
||||
+c Add comments to file(s)
|
||||
-C Strip comment from file(s)
|
||||
-o file Send output to 'file'
|
||||
-rgb name Use 'name' as the transparent pixel
|
||||
-rgb ##,##,## Use rgb-value as the transparent pixel
|
||||
-### Used pixel index as transparent (1 == first colormap entry)
|
||||
|
||||
For instance you could say 'giftool -B -i *.gif' to convert all your images
|
||||
to interlaced GIF files in one easy step.
|
||||
|
||||
giftool version 1.0 is Copyright 1994 Home Pages, Inc and is shareware.
|
||||
Please, use the -info option to read the licensing information.
|
||||
|
||||
PORT BUILD OPTION
|
||||
=================
|
||||
|
||||
There are two useful options are suggested and available for this port of
|
||||
giftool. You can specify it following "make clean".
|
||||
GIFTool is shareware. Use the -info option to read the licensing information.
|
||||
|
||||
Two options are recommended. You can specify them after "make clean".
|
||||
make RETVALUE=yes
|
||||
-----------
|
||||
Giftool does not return value from main(), so it is impossible to use this
|
||||
tools in programs like make(1) or pipes.
|
||||
This option is suggested by Sergei Chechetkin <csl@whale.sunbay.crimea.ua>.
|
||||
|
||||
This option, suggested by Sergei Chechetkin
|
||||
<csl@whale.sunbay.crimea.ua>, causes GIFTool to provide a return value
|
||||
so may be used in pipes or with programs like make(1).
|
||||
make MALLOCSIZE=yes
|
||||
---------------
|
||||
Giftool 1.0 or some earlier version cause segmentation fault about some
|
||||
images. Something about pre-read seems to be bad, so make malloc size
|
||||
bigger to improve that.
|
||||
This option is suggested by Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>.
|
||||
|
||||
You can specify all options such as 'make RETVALUE=yes MALLOCSIZE=yes'.
|
||||
This option, suggested by Hidetoshi Shimokawa
|
||||
<simokawa@sat.t.u-tokyo.ac.jp>, increases the size of a malloc, to avoid
|
||||
a segmentation fault when pre-reading some images.
|
||||
You can specify both options such as 'make RETVALUE=yes MALLOCSIZE=yes'.
|
||||
|
||||
@@ -1,29 +1,21 @@
|
||||
Chart::PNGgraph is a perl5 module to create and display
|
||||
PNG output for a graph. The following classes for graphs
|
||||
with axes are defined:
|
||||
Chart::PNGgraph is a perl5 module to create and display PNG output for a graph.
|
||||
The following classes for graphs with axes are defined:
|
||||
|
||||
Chart::PNGgraph::lines
|
||||
Create a line chart.
|
||||
|
||||
Chart::PNGgraph::bars
|
||||
Create a bar chart.
|
||||
|
||||
Chart::PNGgraph::points
|
||||
Create an chart, displaying the data as points.
|
||||
|
||||
Chart::PNGgraph::linespoints
|
||||
Combination of lines and points.
|
||||
|
||||
Chart::PNGgraph::area
|
||||
Create a graph, representing the data as areas under a
|
||||
line.
|
||||
|
||||
Create a graph, representing the data as areas under a line.
|
||||
Chart::PNGgraph::mixed
|
||||
Create a mixed type graph, any combination of the
|
||||
above. At the moment this is fairly limited. Some of
|
||||
the options that can be used with some of the
|
||||
individual graph types won't work very well. Multiple
|
||||
bar graphs in a mixed graph won't display very nicely.
|
||||
Create a mixed type graph, any combination of the above. At the moment this
|
||||
is fairly limited. Some of the options that can be used with some of the
|
||||
individual graph types won't work very well. Multiple bar graphs in a mixed
|
||||
graph won't display very nicely.
|
||||
|
||||
Additional types:
|
||||
|
||||
|
||||
@@ -1,40 +1,24 @@
|
||||
pngquant is a simple tool with one purpose: convert 32-bit RGBA PNGs into
|
||||
8-bit RGBA-palette PNGs (or fewer than 8 bits, if you want), via quantization
|
||||
and either ordered or diffusion (Floyd-Steinberg) dithering. The fact that
|
||||
you can also use it on RGB or even palette images (e.g., to further color-
|
||||
reduce them to 16 colors or whatever) is just a nice little bonus.
|
||||
|
||||
The current version is fully functional in the sense that it can do:
|
||||
|
||||
The pngquant utility converts 32-bit RGBA PNGs to 8-bit RGBA-palette PNGs (or
|
||||
fewer than 8 bits, if you want), via quantization and ordered or diffusion
|
||||
(Floyd-Steinberg) dithering. You can also use it on RGB or even palette images
|
||||
(for example, to further color-reduce them to 16 colors). It does:
|
||||
- nice reduction of all PNG image types to 256-color (or smaller) palette
|
||||
- automatic optimization of tRNS chunks
|
||||
- batch conversion of multiple files (e.g., "pngquant 256 *.png")
|
||||
- Unix-style command-line filtering (e.g., "... | pngquant 16 | ...")
|
||||
|
||||
...on at least Unix and Win32. It should be pretty easy to port to almost
|
||||
any other platform with a command-line interface and unstructured (stream-
|
||||
oriented) files, including VMS but probably not VM or MVS.
|
||||
|
||||
It does still lack a few features:
|
||||
|
||||
- no ancillary chunk preservation (except gAMA)
|
||||
- no preservation of significant-bits info after rescaling (sBIT chunk)
|
||||
- no mapfile support
|
||||
- no "native" handling of 16-bit-per-sample files or gray+alpha files
|
||||
(i.e., all samples are truncated to 8 bits and all images are promoted
|
||||
(all samples are truncated to 8 bits and all images are promoted
|
||||
to RGBA before quantization)
|
||||
|
||||
These issues will be addressed in a post-1.0 release.
|
||||
|
||||
By the way, be sure to check "before" and "after" file sizes, preferably with
|
||||
pngcrush (http://pmt.sourceforge.net/pngcrush/); dithered palette images may
|
||||
be four times smaller to begin with, but they don't compress nearly as well
|
||||
be four times smaller to begin with, but they do not compress nearly as well
|
||||
as grayscale and truecolor images. Some images, such as Henri Sivonen's alpha
|
||||
button (http://www.pp.htv.fi/hsivone1/css-test/bitmapstyle.html), can be made
|
||||
smaller as full 32-bit RGBA images (4076 bytes in this case) than as either
|
||||
FS-dithered palette (4550 bytes) or ordered-dither palette (4482 bytes) images.
|
||||
|
||||
WWW: http://www.libpng.org/pub/png/apps/pngquant.html
|
||||
|
||||
Greg Roelofs
|
||||
newt@pobox.com
|
||||
Greg Roelofs <newt@pobox.com>
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
An interface between the Python programming language and the OpenGL library
|
||||
(and related libraries).
|
||||
|
||||
Synopsis
|
||||
|
||||
The PyOpenGL package provides interfaces to:
|
||||
PyOpenGL is an interface between the Python programming language and the OpenGL
|
||||
library (and related libraries). The package provides interfaces to:
|
||||
|
||||
- The OpenGL library itself, which is a three-dimensional graphical
|
||||
rendering interface. For more information, visit
|
||||
@@ -22,6 +18,4 @@ The Python bindings offer some value-added tools in addition to the
|
||||
standard API, including support for fast processing of arrays of
|
||||
coordinates, trackball support, etc.
|
||||
|
||||
The PyOpenGL web page is available at:
|
||||
|
||||
WWW: http://pyopengl.sourceforge.net/
|
||||
|
||||
+11
-28
@@ -1,13 +1,7 @@
|
||||
Mtools is a public domain collection of programs to allow Unix systems
|
||||
to read, write, and manipulate files on an MSDOS filesystem (typically
|
||||
a diskette). Each program attempts to emulate the MSDOS equivalent
|
||||
command as closely as practical.
|
||||
|
||||
The following MSDOS commands are emulated:
|
||||
|
||||
Mtool MSDOS
|
||||
name equivalent Description
|
||||
----- ---- -----------
|
||||
Mtools is a collection of programs for reading, writing, and manipulating files
|
||||
on an DOS FAT filesystem (usually a diskette). Each one closely emulates
|
||||
its DOS analog:
|
||||
_Mtool_ _DOS_command_ _Description_
|
||||
mattrib ATTRIB change MSDOS file attribute flags
|
||||
mcd CD change MSDOS directory
|
||||
mcopy COPY copy MSDOS files to/from Unix
|
||||
@@ -21,21 +15,10 @@ mread COPY low level read (copy) an MSDOS file to Unix
|
||||
mren REN/RENAME rename an existing MSDOS file
|
||||
mtype TYPE display contents of an MSDOS file
|
||||
mwrite COPY alias for mcopy, will be removed soon
|
||||
|
||||
You should be able to just close your eyes and pretend you're on an MSDOS
|
||||
system. Everything should work the same... except for the added 'm' at
|
||||
the beginning of each command.
|
||||
|
||||
MSDOS filenames are optionally composed of a drive letter followed by
|
||||
a colon, a subdirectory, and a filename. Sub- directory names can use
|
||||
either the '/' or '\' separator. The use of the '\' separator or
|
||||
wildcards will require the names to be enclosed in quotes to protect
|
||||
them from the shell.
|
||||
|
||||
The regular expression "pattern matching" routines follow the
|
||||
Unix-style rules. For example, '*' matches all MSDOS files in lieu of
|
||||
'*.*'. The archive, hidden, read-only and system attribute bits are
|
||||
ignored during pattern matching.
|
||||
|
||||
This is support 1232KB Floopy reading/writing for FreeBSD(98),
|
||||
SJIS Short File Name and Unicode Long File Name files.
|
||||
Filenames may include a drive letter, a colon, subdirectory, and filename, with
|
||||
either '/' or '\' directory separator. To use the '\' separator or wildcards,
|
||||
escape the filenames with quotes. The regular expression "pattern matching"
|
||||
routines follow Unix-style rules: '*' matches all files. Archive, hidden,
|
||||
read-only and system attributes are ignored in pattern matching. SJIS Short
|
||||
File Name and Unicode Long File Name files, and 1232 kB floppies, are supported.
|
||||
WWW: http://mtools.linux.lu/
|
||||
|
||||
+16
-43
@@ -1,51 +1,24 @@
|
||||
* ja-oleo-1.6
|
||||
Japanized Spreadsheet program, oleo.
|
||||
This is a port of the spreadsheet program oleo, with Japanese support by Kuniaki
|
||||
HAYASHIDA. Documentation in Japanese is in
|
||||
${PREFIX}/share/doc/oleo/ja_JP.EUC/USING.eucJP (usually
|
||||
/usr/local/share/doc/oleo/ja_JP.EUC/USING.eucJP).
|
||||
|
||||
This ports collection use japanized patch by Kuniaki HAYASHIDA.
|
||||
|
||||
* documentation in Japanese is:
|
||||
${PREFIX}/share/doc/oleo/ja_JP.EUC/USING.eucJP
|
||||
useally /usr/local/share/doc/oleo/ja_JP.EUC/USING.eucJP
|
||||
|
||||
* Known PROBLEMS
|
||||
o enviroment variable LANG is set to C under X11 client mode:
|
||||
(cf)
|
||||
If the environment variable LANG is set to C under X11 client mode, as:
|
||||
setenv LANG C
|
||||
setenv DISPLAY localhost:0.0
|
||||
when starting oleo, X11 will consume too much memory to operate X clients. To
|
||||
avoid this problem, you can either set LANG to ja_JP.EUC instead (in which case
|
||||
you also need the /usr/share/locale/ja_JP.EUC/LC_TIME,LC_COLLATE file), or unset
|
||||
the DISPLAY environment variable so oleo does not use X.
|
||||
|
||||
when start oleo, X11 is too heavy to operate X clients.
|
||||
Output to a PostScript file has some problems.
|
||||
|
||||
---- So, please use under.... -----
|
||||
A) set enviroment variable LANG ja_JP.EUC and also
|
||||
need /usr/share/locale/ja_JP.EUC/LC_TIME,LC_COLLATE
|
||||
file.
|
||||
If you use before 19971219-version of FreeBSD,
|
||||
1) get these file from current/releng SNAPSHOT
|
||||
or
|
||||
2) create symbolic-links as below:
|
||||
cd /usr/share/locale/ja_JP.EUC
|
||||
ln -s /usr/share/locale/lt_LN.ISO_8859-1/LC_COLLATE
|
||||
ln -s /usr/share/locale/en_US.ISO_8859-1/LC_TIME
|
||||
or
|
||||
B. non window client mode(unset DISPLAY variable)
|
||||
|
||||
o Output PostScript file has some problems.
|
||||
|
||||
* Tips
|
||||
Oleo default editing mode is like Emacs(Ctrl-h is call
|
||||
help mode).
|
||||
If you want to use Ctrl-h and BS key to delete-char,
|
||||
set to $HOME/.oleorc as below:
|
||||
|
||||
bind-key generic-main backward-delete-char ^H
|
||||
The default editing mode is like Emacs (Ctrl-h is call help mode). If you want
|
||||
to use Ctrl-h and BS key to delete-char, set to $HOME/.oleorc as below:
|
||||
bind-key generic-main backward-delete-char ^H
|
||||
|
||||
WWW: http://www.hh.iij4u.or.jp/%7Ehayasida/oleo/
|
||||
|
||||
** Acknowledgements to this ports file **
|
||||
Special thanks to:
|
||||
Kuniaki HAYASHIDA<hh.iij4u.or.jp>
|
||||
Takeshi MUTOH <mutoh@sentinel.info.nara-k.ac.jp>
|
||||
|
||||
Acknowledgments: Kuniaki HAYASHIDA<hh.iij4u.or.jp>
|
||||
Takeshi MUTOH <mutoh@sentinel.info.nara-k.ac.jp>
|
||||
---
|
||||
Yoshiro MIHIRA
|
||||
(sanpei@sanpei.org)
|
||||
Yoshiro MIHIRA (sanpei@sanpei.org)
|
||||
|
||||
+13
-17
@@ -1,10 +1,9 @@
|
||||
The OpenJIT project is an ongoing Java the programming language JIT compiler
|
||||
project as a collaborative effort between Tokyo Institute of Technology and
|
||||
Fujitsu Laboratory, partly sponsored by the Information Promotion Agency of
|
||||
The OpenJIT project is an ongoing Java the programming language JIT
|
||||
compiler project as a collaborative effort between Tokyo Institute of Technology
|
||||
and Fujitsu Laboratory, partly sponsored by the Information Promotion Agency of
|
||||
Japan.
|
||||
|
||||
OpenJIT is a "reflective" JIT compiler in that not only it is almost entirely
|
||||
written in Java, but also that it bootstraps and compiles itself during
|
||||
OpenJIT is a "reflective" JIT compiler in that not only it is almost
|
||||
entirely written in Java, but also that it bootstraps and compiles itself during
|
||||
execution of the user program, and compiler components coexist as first-class
|
||||
objects in user heap space. Thus, users can tailor and customize the compilation
|
||||
of classes at runtime for variety of purposes such as application-specific
|
||||
@@ -13,16 +12,13 @@ adaptation of programs, debugging, language extension and experimentation, and
|
||||
other types of advanced compiler-based research and applications. OpenJIT even
|
||||
allows full dynamic update of itself by loading the compiler classes on the fly
|
||||
from the network.
|
||||
|
||||
OpenJIT is fully JDK compliant, and plugs into standard JVMs several Unix
|
||||
platforms such as Solaris (Sparc), Linux (x86), and FreeBSD (x86).
|
||||
|
||||
On Linux/x86 platform, OpenJIT 1.1.14 is faster than the JDK 1.2 classic VM
|
||||
compiler, runs more or less the same speed as other commercial JIT compilers on
|
||||
classic VM.
|
||||
|
||||
OpenJIT is completely free so long as it is used for non-commercial purposes.
|
||||
Its source, binaries, etc. can be freely distributed and modified without
|
||||
restriction.
|
||||
OpenJIT is fully JDK compliant, and plugs into standard JVMs several
|
||||
Unix platforms such as Solaris (Sparc), Linux (x86), and FreeBSD (x86).
|
||||
On Linux/x86 platform, OpenJIT 1.1.14 is faster than the JDK 1.2 classic
|
||||
VM compiler, runs more or less the same speed as other commercial JIT compilers
|
||||
on classic VM.
|
||||
OpenJIT is completely free so long as it is used for non-commercial
|
||||
purposes. Its source, binaries, etc. can be freely distributed and modified
|
||||
without restriction.
|
||||
|
||||
WWW: http://www.openjit.org/
|
||||
|
||||
+10
-14
@@ -1,18 +1,15 @@
|
||||
The Common Language Infrastructure (CLI) is the ECMA standard that describes
|
||||
the core of the .NET Framework world. The Shared Source CLI is a a working
|
||||
implementation of the ECMA CLI and the ECMA C# language specification.
|
||||
|
||||
This implementation is released under a shared source initiative. Please see
|
||||
the accompanying license.
|
||||
|
||||
The Shared Source CLI goes beyond the printed specification of the ECMA
|
||||
standards, providing a working implementation for CLI developers to explore
|
||||
and understand. It will be of interest to academics and researchers wishing to
|
||||
teach and explore modern programming language concepts, and to .NET developers
|
||||
interested in how the technology works.
|
||||
The Common Language Infrastructure (CLI) is the ECMA standard that
|
||||
describes the core of the .NET Framework world. The Shared Source CLI is a a
|
||||
working implementation of the ECMA CLI and the ECMA C# language specification.
|
||||
This implementation is released under a shared source initiative. Please
|
||||
see the accompanying license.
|
||||
The Shared Source CLI goes beyond the printed specification of the ECMA
|
||||
standards, providing a working implementation for CLI developers to explore and
|
||||
understand. It will be of interest to academics and researchers wishing to teach
|
||||
and explore modern programming language concepts, and to .NET developers
|
||||
interested in how the technology works.
|
||||
|
||||
Features:
|
||||
|
||||
o An implementation of the runtime for the Common Language Infrastructure
|
||||
(ECMA-335);
|
||||
o Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript;
|
||||
@@ -24,5 +21,4 @@ o The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from
|
||||
o Build environment tools (nmake, build, and others);
|
||||
o Documentation for the implementation;
|
||||
o Test suites used to verify the implementation.
|
||||
|
||||
WWW: http://msdn.microsoft.com/net/sscli/
|
||||
|
||||
+11
-17
@@ -1,26 +1,20 @@
|
||||
The Tcl extension module gives access to the Tcl library
|
||||
with functionality and interface similar to the C
|
||||
functions of Tcl. In other words, you can
|
||||
The Tcl extension module gives access to the Tcl library with functionality and
|
||||
interface similar to the C functions of Tcl. In other words, you can:
|
||||
|
||||
create Tcl interpreters
|
||||
The Tcl interpreters so created are Perl objects
|
||||
whose destructors delete the interpreters cleanly
|
||||
when appropriate.
|
||||
The Tcl interpreters so created are Perl objects whose destructors
|
||||
delete the interpreters cleanly when appropriate.
|
||||
|
||||
execute Tcl code in an interpreter
|
||||
The code can come from strings, files or Perl
|
||||
filehandles.
|
||||
The code can come from strings, files or Perl filehandles.
|
||||
|
||||
bind in new Tcl procedures
|
||||
The new procedures can be either C code (with
|
||||
addresses presumably obtained using dl_open and
|
||||
dl_find_symbol) or Perl subroutines (by name,
|
||||
reference or as anonymous subs). The (optional)
|
||||
deleteProc callback in the latter case is another
|
||||
perl subroutine which is called when the command
|
||||
is explicitly deleted by name or else when the
|
||||
destructor for the interpreter object is
|
||||
explicitly or implicitly called.
|
||||
The new procedures can be either C code (with addresses presumably
|
||||
obtained using dl_open and dl_find_symbol) or Perl subroutines (by name,
|
||||
reference or as anonymous subs). The (optional) deleteProc callback in
|
||||
the latter case is another perl subroutine which is called when the
|
||||
command is explicitly deleted by name or else when the destructor for
|
||||
the interpreter object is explicitly or implicitly called.
|
||||
|
||||
Manipulate the result field of a Tcl interpreter
|
||||
|
||||
|
||||
+14
-22
@@ -1,32 +1,24 @@
|
||||
Scm conforms to Revised^5 Report on the Algorithmic Language Scheme
|
||||
and the IEEE P1178 specification. Scm is written in C and runs under
|
||||
Amiga, Atari-ST, MacOS, MS-DOS, OS/2, NOS/VE, Unicos, VMS, Unix and
|
||||
similar systems. ASCII and EBCDIC are supported.
|
||||
Scm conforms to Revised^5 Report on the Algorithmic Language Scheme and the IEEE
|
||||
P1178 specification. Scm is written in C and runs under Amiga, Atari-ST, MacOS,
|
||||
MS-DOS, OS/2, NOS/VE, Unicos, VMS, Unix and similar systems. ASCII and EBCDIC
|
||||
are supported.
|
||||
|
||||
Documentation is included explaining the many Scheme Language
|
||||
extensions in scm, the internal representation and how to extend or
|
||||
include scm in other programs.
|
||||
Documentation is included explaining the many Scheme Language extensions in scm,
|
||||
the internal representation and how to extend or include scm in other programs.
|
||||
|
||||
SLIB is a portable Scheme library which SCM uses.
|
||||
|
||||
SLIB-PSD is a portable debugger for Scheme (requires emacs editor).
|
||||
|
||||
-------------------Readme.FreeBSD------------------------
|
||||
The init file is hard-coded as /usr/local/share/scm/Init.scm. Alternatively,
|
||||
one can set the environment variable SCM_INIT_PATH to the pathname of Init.scm.
|
||||
|
||||
1. Pathname dependencies:
|
||||
The init file is hardcoded as /usr/local/share/scm/Init.scm.
|
||||
Alternatively, one can set the environment variable SCM_INIT_PATH to
|
||||
the pathname of Init.scm.
|
||||
The library files are in /usr/local/share/scm/slib. Alternatively, one can set
|
||||
the environment variable SCHEME_LIBRARY_PATH to the slib directory. Remember to
|
||||
use a trailing / on the pathname.
|
||||
|
||||
The library files are in /usr/local/share/scm/slib. Alternatively,
|
||||
one can set the environment variable SCHEME_LIBRARY_PATH to
|
||||
the slib directory. Remember to use a trailing / on the
|
||||
pathname.
|
||||
|
||||
2. I have -DSICP turn on by default, since I expect this to be the major
|
||||
reason for this port. This means test.scm will fail on 3 tests in section 6.1.
|
||||
If strict R4S compliance is important to you, recompile w/o the SICP flag.
|
||||
|
||||
Jeffrey Hsu
|
||||
By default -DSICP is turned on, with the expectation that this is the major
|
||||
reason for this port. This means test.scm will fail on three tests in section
|
||||
6.1. Where strict R4S compliance is important, recompile without the SICP flag.
|
||||
|
||||
WWW: http://swissnet.ai.mit.edu/~jaffer/SCM.html
|
||||
|
||||
@@ -1,34 +1,20 @@
|
||||
xpbiff-youbin: fancy biff program under X11 environment, supporting Japanese
|
||||
MIME extensions and youbin
|
||||
|
||||
<< xpbiff-youbin >>
|
||||
|
||||
Fancy biff program under X11 environment,
|
||||
and youbin.
|
||||
|
||||
*** Support MIME Japanese extension ***
|
||||
|
||||
This ports collection support Japanese strings in From,
|
||||
Subject field. Please set enviroment variable LANG to
|
||||
ja_JP.EUC.
|
||||
|
||||
This port supports Japanese strings in the From and Subject fields.
|
||||
Please set the LANG enviroment variable to ja_JP.EUC by doing:
|
||||
setenv LANG ja_JP.EUC
|
||||
There is experimental support for Sun audio. This port also supports
|
||||
XPM bitmap files.
|
||||
|
||||
*** Support xpm file for bit map ***
|
||||
|
||||
This ports collection support xpm file for bit map.
|
||||
|
||||
*** SUN_AUDIO is Experimental Supported ***
|
||||
|
||||
*** Known Problem ***
|
||||
|
||||
known problem:
|
||||
(1) HANKAKU-KANA
|
||||
Xpbiff dumps core, because code conversion routines jis2euc()
|
||||
assumes "the conversion does not makes the string longer". But
|
||||
when converting so-called 'hankaku-kana', this assumption breaks.
|
||||
|
||||
Thank you.
|
||||
|
||||
*** Acknowledgements to this ports file ***
|
||||
Special thanks to:
|
||||
Acknowledgements for this port:
|
||||
Makoto MATSUSHITA <matusita@ics.es.osaka-u.ac.jp>
|
||||
Satoshi TAOKA <taoka@infonets.hiroshima-u.ac.jp>
|
||||
Nozomu MATSUI <nozomu@yy.cs.keio.ac.jp>
|
||||
|
||||
+8
-21
@@ -1,33 +1,20 @@
|
||||
xpbiff: fancy biff program under X11 environment, supporting Japanese MIME
|
||||
extensions
|
||||
|
||||
<< xpbiff >>
|
||||
|
||||
Fancy biff program under X11 environment.
|
||||
|
||||
*** Support MIME Japanese extension ***
|
||||
|
||||
This ports collection support Japanese strings in From,
|
||||
Subject field. Please set enviroment variable LANG to
|
||||
ja_JP.EUC.
|
||||
|
||||
This port supports Japanese strings in the From and Subject fields.
|
||||
Please set the LANG enviroment variable to ja_JP.EUC by doing:
|
||||
setenv LANG ja_JP.EUC
|
||||
There is experimental support for Sun audio. This port also supports
|
||||
XPM bitmap files.
|
||||
|
||||
*** Support xpm file for bit map ***
|
||||
|
||||
This ports collection support xpm file for bit map.
|
||||
|
||||
*** SUN_AUDIO is Experimental Supported ***
|
||||
|
||||
*** Known Problem ***
|
||||
|
||||
known problem:
|
||||
(1) HANKAKU-KANA
|
||||
Xpbiff dumps core, because code conversion routines jis2euc()
|
||||
assumes "the conversion does not makes the string longer". But
|
||||
when converting so-called 'hankaku-kana', this assumption breaks.
|
||||
|
||||
Thank you.
|
||||
|
||||
*** Acknowledgements to this ports file ***
|
||||
Special thanks to:
|
||||
Acknowledgements for this port:
|
||||
Makoto MATSUSHITA <matusita@ics.es.osaka-u.ac.jp>
|
||||
Satoshi TAOKA <taoka@infonets.hiroshima-u.ac.jp>
|
||||
Nozomu MATSUI <nozomu@yy.cs.keio.ac.jp>
|
||||
|
||||
+7
-8
@@ -1,14 +1,13 @@
|
||||
Xgas, animated simulation of an ideal gas
|
||||
|
||||
Xgas is a physical simulation of an ideal gas in a heated box.
|
||||
Gas molecules move around the box with velocities dependent on
|
||||
their temperature. A chamber consisting of two boxes contains
|
||||
the gas molecules collide with the walls, their temperature
|
||||
approarches that of the box.
|
||||
Xgas is a physical simulation of an ideal gas in a heated box. Gas molecules
|
||||
move around the box with velocities dependent on their temperature. A chamber
|
||||
consisting of two boxes contains the gas molecules collide with the walls, their
|
||||
temperature approaches that of the box.
|
||||
|
||||
Use mouse button 1 to create molecules one at a time at
|
||||
the cursor position. Use mouse button 2 to create the
|
||||
maximum number of molecules at the cursor position.
|
||||
Use mouse button 1 to create molecules one at a time at the cursor position.
|
||||
Use mouse button 2 to create the maximum number of molecules at the cursor
|
||||
position.
|
||||
|
||||
Usage: xgas [ -options ]
|
||||
|
||||
|
||||
+4
-12
@@ -1,29 +1,21 @@
|
||||
PNS
|
||||
---
|
||||
Is a public domain Petri net simulation tool
|
||||
for Unix systems.
|
||||
PNS is a graphics tool and requires the X window system.
|
||||
|
||||
WWW: http://www.ee.uwa.edu.au/~braunl/pns/
|
||||
PNS is a public domain Petri net simulation tool for Unix systems. It requires
|
||||
the X Window System.
|
||||
|
||||
Examples:
|
||||
---------
|
||||
- simple.net
|
||||
3-2 Reduction
|
||||
|
||||
- add.net
|
||||
x = x + y
|
||||
|
||||
- sub1.net
|
||||
x >= y : x = x - y
|
||||
x < y : y = y - x
|
||||
|
||||
- sub2.net
|
||||
x = x - y
|
||||
NEGATIVE = 1 <=> x-y < 0
|
||||
|
||||
- mult.net
|
||||
z = x * y
|
||||
|
||||
- phil.net
|
||||
Dining Philosophers Problem
|
||||
|
||||
WWW: http://www.ee.uwa.edu.au/~braunl/pns/
|
||||
|
||||
@@ -1,66 +1,24 @@
|
||||
<< DHCP WIDE-Implementation, version 1.3.6 >>
|
||||
|
||||
April, 1997.
|
||||
|
||||
This package is a distribution kit of DHCP WIDE-Implementation
|
||||
version 1.3.6. DHCP (Dynamic Host Configuration Protocol) is a
|
||||
protocol which provides informations to computer when it boots.
|
||||
This release includes DHCP server, relay agent, and client.
|
||||
|
||||
|
||||
<License>
|
||||
|
||||
See "Copyright" included in this directory.
|
||||
|
||||
Also, portions of this software may fall under the copyrights which
|
||||
are included the end of this file. These are included corresponded
|
||||
source code files.
|
||||
|
||||
|
||||
<Package>
|
||||
|
||||
You can get the latest version from;
|
||||
ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/
|
||||
|
||||
------------------------------
|
||||
|
||||
** Attention for this ports file **
|
||||
|
||||
To use DHCP, your kernel must be rebuilt with the following
|
||||
line added to your kernel config file (/sys/i386/conf/<YourMachine>):
|
||||
|
||||
pseudo-device bpfilter 4 #Berkeley packet filter
|
||||
|
||||
and make bpf devices in your /dev directory: /dev/bpf[1-3].
|
||||
|
||||
cd /dev
|
||||
./MAKEDEV bpf1
|
||||
./MAKEDEV bpf2
|
||||
./MAKEDEV bpf3
|
||||
|
||||
** dhcpdb.relay file is need without relay agent **
|
||||
|
||||
Please read more information in
|
||||
/usr/local/share/doc/dhcp/intro.dhcp or intro.dhcp.jis.
|
||||
|
||||
** additional function **
|
||||
|
||||
DHCP client(dhcpc) in this port is supported "dynamic change
|
||||
/etc/resolv.conf and hostname via DHCP infomation".
|
||||
|
||||
This is the WIDE implementation of DHCP (Dynamic Host Configuration Protocol)
|
||||
server, relay agent, and client. DHCP, which is defined by RFCs 1534, 1542,
|
||||
2131, and 2132, provides information to a computer over a network about the
|
||||
configuration of that network.
|
||||
To use DHCP, configure your kernel with the following line added to your kernel
|
||||
configuration file (/usr/src/sys/i386/conf/<YourMachine>):
|
||||
pseudo-device bpfilter 4 #Berkeley packet filter
|
||||
and make bpf devices in your /dev directory: /dev/bpf[1-3]:
|
||||
cd /dev && ./MAKEDEV bpf1 bpf2 bpf3
|
||||
Without the relay agent, the dhcpdb.relay file is needed. The DHCP
|
||||
client(dhcpc) in this port supports dynamically changing /etc/resolv.conf and
|
||||
hostname via DHCP infomation.
|
||||
o `-r' is recreate /etc/resolv.conf
|
||||
(resolv.conf file is overwritten.)
|
||||
o `-n' is reset HOSTNAME
|
||||
|
||||
** Acknowledgements to this ports file **
|
||||
Special thanks to:
|
||||
Hirotaka TAKETA<taketa@csk.co.jp>
|
||||
Hajimu UMEMOTO<ume@calm.imasy.or.jp>
|
||||
Tamotsu KANOH<kanoh@kanoh.iijnet.or.jp>
|
||||
Junichi SATOH<junichi@astec.co.jp>
|
||||
Hisashi HIRAMOTO<hiramoto@phys.chs.nihon-u.ac.jp>
|
||||
Takeshi TAGUCHI<taguchi@tohoku.iij.ad.jp>
|
||||
Keisuke INOUE<keisuke@aa.cs.keio.ac.jp>
|
||||
|
||||
- Yoshiro MIHIRA
|
||||
(sanpei@yy.cs.keio.ac.jp)
|
||||
Please read more information in /usr/local/share/doc/dhcp/intro.dhcp or
|
||||
intro.dhcp.jis.
|
||||
Thanks to: Hirotaka TAKETA<taketa@csk.co.jp>,
|
||||
Hajimu UMEMOTO<ume@calm.imasy.or.jp>, Tamotsu KANOH<kanoh@kanoh.iijnet.or.jp>,
|
||||
Junichi SATOH <junichi@astec.co.jp>,
|
||||
Hisashi HIRAMOTO <hiramoto@phys.chs.nihon-u.ac.jp>,
|
||||
Takeshi TAGUCHI<taguchi@tohoku.iij.ad.jp> and
|
||||
Keisuke INOUE<keisuke@aa.cs.keio.ac.jp>
|
||||
- Yoshiro MIHIRA (sanpei@yy.cs.keio.ac.jp)
|
||||
|
||||
+23
-48
@@ -1,49 +1,24 @@
|
||||
rmsg contains a messaging system which can be used to send
|
||||
write-like messages to logged-on users. The system can cross machine
|
||||
boundaries, so if another machine has the rmsgd program running, you can
|
||||
send messages to users on it.
|
||||
|
||||
The system also allows bitnet virtual machine-like 'virtual users'
|
||||
to whom any user can send messages and they can answer the messages.
|
||||
The rmsgd server makes this possible by allowing a command 'exec' in a users
|
||||
.msgconf file, and whenever the user receives a message this command is
|
||||
executed and the message is piped to it.
|
||||
|
||||
It is also possible to log incoming and outgoing messages and resend previous
|
||||
sent message. You can specify a file to which the last (or every) incoming
|
||||
message will be stored.
|
||||
|
||||
Using the programs:
|
||||
-------------------
|
||||
|
||||
Rmsgd:
|
||||
|
||||
Rmsgd is the server program for the system. It should be started by root,
|
||||
but for now it works even if started by ordinary users, even though
|
||||
some capabilities are disabled for security reasons (that is, exec and
|
||||
logging of incoming messages, since that would be done by the user-id
|
||||
who started rmsgd and not the receiver).
|
||||
|
||||
At any time, there should be only one rmsgd running. It doesn't do any harm
|
||||
to have several rmsgds other than the newly-started servers unmap the
|
||||
previous and thus the previous servers are unusable.
|
||||
|
||||
The server should be named 'rmsgd' to have it start as a daemon.
|
||||
|
||||
|
||||
Rmsg:
|
||||
|
||||
Rmsg is the client end of the system. Rmsg is used by ordinary users
|
||||
to send messages. For example, rmsg foo@bar hello there ! ^D would
|
||||
send a message 'hello there !' to user foo at machine bar. By
|
||||
default, rmsg stores the last outgoing message in the user's home
|
||||
directory in the file .msgout. Then msg -r user@machine can be used
|
||||
to resend the message. Message is normally read from standard input
|
||||
until EOF.
|
||||
|
||||
Configuration:
|
||||
--------------
|
||||
|
||||
The messages system has many options which the user can set by making
|
||||
a file '.msgconf' in her home directory and placing various command in it.
|
||||
The rmsg messaging system can be used to send write(1)-like messages to
|
||||
logged-on users. The system can cross machine boundaries: if another machine
|
||||
has rmsgd running, you can send messages to users on it.
|
||||
The system allows bitnet virtual machine-like 'virtual users' to whom
|
||||
any user can send messages and they can answer the messages. The rmsgd server
|
||||
makes this possible by allowing a command 'exec' in a user's .msgconf file, and
|
||||
whenever the user receives a message this command is executed and the message is
|
||||
piped to it.
|
||||
It is possible to log incoming and outgoing messages. You can specify a
|
||||
file to which the last (or every) incoming message will be stored.
|
||||
Rmsgd is the server daemon for the system. It should be started by
|
||||
root, but for now it works even if started by ordinary users, even though some
|
||||
capabilities are disabled for security reasons (that is, exec and logging of
|
||||
incoming messages, since that would be done by the user-id who started rmsgd and
|
||||
not the receiver).
|
||||
The server should be named 'rmsgd' to have it start as a daemon. Rmsg
|
||||
is the client end of the system. Rmsg is used by ordinary users to send
|
||||
messages. For example, rmsg foo@bar hello there ! ^D would send a message
|
||||
'hello there !' to user foo at machine bar. By default, rmsg stores the last
|
||||
outgoing message in the user's home directory in the file .msgout. Then msg -r
|
||||
user@machine can be used to resend the message. Messages are normally read from
|
||||
standard input until EOF.
|
||||
There are many options which can be set in a user's ~/.msgconf' file.
|
||||
Read the manual page for rmsg for more information.
|
||||
|
||||
@@ -1,22 +1,18 @@
|
||||
AUC TeX is a comprehensive customizable integrated environment for
|
||||
writing input files for LaTeX using GNU Emacs.
|
||||
|
||||
AUC TeX lets you run TeX/LaTeX and other LaTeX-related tools, such
|
||||
as a output filters or post processor from inside Emacs. Especially
|
||||
`running LaTeX' is interesting, as AUC TeX lets you browse through the
|
||||
errors TeX reported, while it moves the cursor directly to the reported
|
||||
error, and displays some documentation for that particular error. This
|
||||
will even work when the document is spread over several files.
|
||||
|
||||
AUC TeX automatically indents your `LaTeX-source', not only as you
|
||||
write it -- you can also let it indent and format an entire document.
|
||||
It has a special outline feature, which can greatly help you `getting an
|
||||
overview' of a document.
|
||||
|
||||
Apart from these special features, AUC TeX provides a large range of
|
||||
handy Emacs macros, which in several different ways can help you write
|
||||
your LaTeX documents fast and painlessly.
|
||||
|
||||
All features of AUC TeX are documented using the GNU Emacs online
|
||||
documentation system. That is, documentation for any command is just
|
||||
a key click away! AUC TeX is written entirely in Emacs-Lisp, and hence
|
||||
|
||||
@@ -1,9 +1,5 @@
|
||||
Ghostview is an X11 interface for ghostscript 2.4 and later. It features:
|
||||
|
||||
Ghostview -- An X11 user interface for ghostscript.
|
||||
|
||||
Ghostview is full function user interface for ghostscript 2.4 and later.
|
||||
|
||||
Brief list of features:
|
||||
- Ghostview parses any known version of Adobe's Document Structuring
|
||||
Conventions.
|
||||
- Page size is automatically determined from the Document Structuring
|
||||
@@ -24,5 +20,5 @@ Brief list of features:
|
||||
- Can popup zoom windows at printer resolution
|
||||
(1 display dot = 1 printer dot).
|
||||
|
||||
The Ghostview distribution includes a Ghostview Widget that people
|
||||
are encouraged to use in other programs.
|
||||
The Ghostview distribution includes a Ghostview Widget that people are
|
||||
encouraged to use in other programs.
|
||||
|
||||
+19
-31
@@ -1,33 +1,21 @@
|
||||
This set of scripts addresses the need to get a non-postscript printer
|
||||
working quickly, so that documentation files and manual pages can be
|
||||
printed. The scripts work for printers using or compatible with PCL
|
||||
(Hewlett-Packard's Printer Command Language). A few printers (the
|
||||
Cannon Bubblejet, for example) use neither PCL nor postscript.
|
||||
|
||||
Some relatively simple scripts for printing a document (qp and qp.awk)
|
||||
are provided, as well as qpm for printing manual pages. Basically these
|
||||
short scripts convert unix line endings to ones PCL printers understand
|
||||
and select a font to use.
|
||||
|
||||
Two more complex awk scripts--pcl.awk and pagin.awk--understand PCL
|
||||
printer codes when encountered in a file, and thus it is possible,
|
||||
when using these scripts, to change fonts, apply bold, underline, or
|
||||
italic to a word or group of words, do footnotes, preserve a table,
|
||||
and number pages in a default font. The scripts automatically adjust
|
||||
for the font and size of type both horizontally (knowing how many
|
||||
letters to print on a line) and vertically (line spacing). Using
|
||||
pagin.awk it is also possible to double space, for example.
|
||||
|
||||
Files with printer codes are provided to make it easier to put printer
|
||||
codes into documents. It is awkward neverthless, but it does what it
|
||||
does in something like 32k of space instead of the multi-megabyte files
|
||||
of more elaborate programs, such as the excellent apsfilter, which
|
||||
enables the printer to emulate postscript. As WordPerfect becomes more
|
||||
available for Unix platforms and maintains its interoperability with
|
||||
Windows versions, it should become better and easier to use, as should
|
||||
other components of its office suit and that of others.
|
||||
|
||||
In the mean time pclprint is free, takes little space, and does
|
||||
a reasonably good job for many tasks.
|
||||
These scripts address the need to get a non-postscript printer working
|
||||
quickly so documentation files and manual pages can be printed. The scripts
|
||||
work for printers using or compatible with PCL (Hewlett-Packard's Printer
|
||||
Command Language). A few printers (the Canon Bubblejet, for example) use
|
||||
neither PCL nor postscript.
|
||||
Simple scripts for printing a document (qp and qp.awk) are provided, as
|
||||
well as qpm for printing manual pages. These scripts convert unix line endings
|
||||
to ones PCL printers understand and select a font to use.
|
||||
Two more complex awk scripts--pcl.awk and pagin.awk--understand PCL
|
||||
printer codes when encountered in a file, and thus it is possible, when using
|
||||
these scripts, to change fonts, apply bold, underline, or italic to a word or
|
||||
group of words, do footnotes, preserve a table, and number pages in a default
|
||||
font. The scripts adjust for the font and size of type horizontally (how many
|
||||
letters to print on a line) and vertically (line spacing). Using pagin.awk it
|
||||
is also possible to double space, for example.
|
||||
Files with printer codes are provided to make it easier to put printer
|
||||
codes into documents. It is still awkward, but it needs only about 32k of
|
||||
space instead of the multi-megabyte files of more elaborate programs, such as
|
||||
the excellent apsfilter, which enables the printer to emulate postscript.
|
||||
|
||||
-- Annelise Anderson <andrsn@andrsn.Stanford.EDU>
|
||||
|
||||
@@ -1,23 +1,19 @@
|
||||
DESCRIPTION
|
||||
from the man page:
|
||||
|
||||
gd is a graphics library. It allows your code to quickly draw images
|
||||
complete with lines, arcs, text, multiple colors, cut and paste from
|
||||
other images, and flood fills, and write out the result as a .PNG file.
|
||||
This is particularly useful in World Wide Web applications, where .PNG
|
||||
is the format used for inline images.
|
||||
is the format used for inline images.
|
||||
|
||||
gd is not a paint program. If you are looking for a paint program, try
|
||||
xpaint by David Koblas, available by anonymous FTP from ftp.netcom.com
|
||||
in pub/ko/koblas. (That package is for the X Window System; for the Mac
|
||||
and the PC, paint programs are considerably easier to find.)
|
||||
gd is not a paint program. [...]
|
||||
|
||||
gd does not provide for every possible desirable graphics operation. It
|
||||
is not necessary or desirable for gd to become a kitchen-sink graphics
|
||||
package, but version 1.3 incorporates most of the commonly requested
|
||||
features for an 8-bit 2D package. Support for scalable fonts, and
|
||||
truecolor images, JPEG and PNG is planned for version 2.0.
|
||||
|
||||
AUTHOR
|
||||
[...]
|
||||
gd was written by Thomas Boutell and is currently distributed by
|
||||
boutell.com, Inc.
|
||||
|
||||
|
||||
@@ -1,8 +1,7 @@
|
||||
EULER is a program for quickly and interactively computing with real and
|
||||
complex numbers and matrices, or with intervals, in the style of MatLab,
|
||||
Octave,... It can draw and animate your functions in two and three dimensions.
|
||||
|
||||
Euler features :
|
||||
It features:
|
||||
- real, complex and interval scalars and matrices,
|
||||
- a programming language, with local variables, default values for
|
||||
parameters, variable parameter number, passing of functions,
|
||||
|
||||
@@ -1,36 +1,21 @@
|
||||
The Cyrus SASL (Simple Authentication and Security Layer)
|
||||
|
||||
SASL is the Simple Authentication and Security Layer, a method
|
||||
for adding authentication support to connection-based protocols.
|
||||
To use SASL, a protocol includes a command for identifying and
|
||||
authenticating a user to a server and for optionally negotiating
|
||||
protection of subsequent protocol interactions. If its use is
|
||||
negotiated, a security layer is inserted between the protocol
|
||||
and the connection.
|
||||
|
||||
FEATURES
|
||||
--------
|
||||
The following mechanisms are included in this distribution:
|
||||
ANONYMOUS
|
||||
CRAM-MD5
|
||||
DIGEST-MD5
|
||||
GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5)
|
||||
KERBEROS_V4
|
||||
PLAIN
|
||||
|
||||
The library can use a Berkeley DB, gdbm or ndbm file on the server
|
||||
side to store per-user authentication secrets. The utility saslpasswd
|
||||
has been included for adding authentication secrets to the file.
|
||||
|
||||
PLAIN can either check /etc/passwd, Kerberos V4, use PAM, or the sasl
|
||||
secrets database. By default PAM is used if PAM is found, then
|
||||
Kerberos, finally /etc/passwd (non-shadow). This is tweakable in the
|
||||
configuration file. Please see
|
||||
"${PREFIX}/share/doc/sasl/sysadmin.html".
|
||||
|
||||
The sample directory contains two programs which provide a reference
|
||||
for using the library, as well as making it easy to test a mechanism
|
||||
on the command line. See "${PREFIX}/share/doc/sasl/programming.html"
|
||||
for more information.
|
||||
This is a port of Cyrus SASL (Simple Authentication and Security Layer).
|
||||
SASL is a method for adding authentication support to connection-based
|
||||
protocols. To use SASL, a protocol includes a command for identifying and
|
||||
authenticating a user to a server and for optionally negotiating protection of
|
||||
subsequent protocol interactions. If its use is negotiated, a security layer is
|
||||
inserted between the protocol and the connection.
|
||||
The following mechanisms are included in this distribution: ANONYMOUS,
|
||||
CRAM-MD5, DIGEST-MD5, GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5), KERBEROS_V4
|
||||
and PLAIN.
|
||||
The library can use a Berkeley DB, gdbm or ndbm file on the server side
|
||||
to store per-user authentication secrets. The utility saslpasswd has been
|
||||
included for adding authentication secrets to the file.
|
||||
PLAIN can either check /etc/passwd, Kerberos V4, use PAM, or the sasl
|
||||
secrets database. By default PAM is used if PAM is found, then Kerberos,
|
||||
finally /etc/passwd (non-shadow). This is tweakable in the configuration file.
|
||||
Please see "${PREFIX}/share/doc/sasl/sysadmin.html".
|
||||
The sample directory contains two programs which provide a reference for
|
||||
using the library, as well as making it easy to test a mechanism on the command
|
||||
line. See "${PREFIX}/share/doc/sasl/programming.html" for more information.
|
||||
|
||||
WWW: http://asg.web.cmu.edu/sasl/
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
This is an implementation of the Automated Password Generator standard,
|
||||
defined in FIPS Publication 181, "Standard for Automated Password Generator":
|
||||
http://www.itl.nist.gov/fipspubs/fip181.htm
|
||||
|
||||
WWW: http://www.itl.nist.gov/fipspubs/fip181.htm
|
||||
|
||||
+24
-40
@@ -1,40 +1,24 @@
|
||||
The MD5 module allows you to use the RSA Data Security
|
||||
Inc. MD5 Message Digest algorithm from within Perl
|
||||
programs.
|
||||
|
||||
A new MD5 context object is created with the new
|
||||
operation. Multiple simultaneous digest contexts can be
|
||||
maintained, if desired. The context is updated with the
|
||||
add operation which adds the strings contained in the LIST
|
||||
parameter. Note, however, that add('foo', 'bar'),
|
||||
add('foo') followed by add('bar') and add('foobar') should
|
||||
all give the same result.
|
||||
|
||||
The final message digest value is returned by the digest
|
||||
operation as a 16-byte binary string. This operation
|
||||
delivers the result of add operations since the last new
|
||||
or reset operation. Note that the digest operation is
|
||||
effectively a destructive, read-once operation. Once it
|
||||
has been performed, the context must be reset before being
|
||||
used to calculate another digest value.
|
||||
|
||||
Several convenience functions are also provided. The
|
||||
addfile operation takes an open file-handle and reads it
|
||||
until end-of file in 1024 byte blocks adding the contents
|
||||
to the context. The file-handle can either be specified by
|
||||
name or passed as a type-glob reference, as shown in the
|
||||
examples below. The hexdigest operation calls digest and
|
||||
returns the result as a printable string of hexdecimal
|
||||
digits. This is exactly the same operation as performed by
|
||||
the unpack operation in the examples below.
|
||||
|
||||
The hash operation can act as either a static member
|
||||
function (ie you invoke it on the MD5 class as in the
|
||||
synopsis above) or as a normal virtual function. In both
|
||||
cases it performs the complete MD5 cycle (reset, add,
|
||||
digest) on the supplied scalar value. This is convenient
|
||||
for handling small quantities of data. When invoked on the
|
||||
class a temporary context is created. When invoked through
|
||||
an already created context object, this context is used.
|
||||
The latter form is slightly more efficient. The hexhash
|
||||
operation is analogous to hexdigest.
|
||||
The MD5 module allows you to use the RSA Data Security Inc. MD5 Message
|
||||
Digest algorithm from within Perl programs.
|
||||
A new MD5 context object is created with the new operation. Multiple
|
||||
simultaneous digest contexts can be maintained, if desired. The context is
|
||||
updated with the add operation which adds the strings contained in the LIST
|
||||
parameter. Note, however, that add('foo', 'bar'), add('foo') followed by
|
||||
add('bar') and add('foobar') should all give the same result.
|
||||
The final message digest value is returned by the digest operation as a
|
||||
16-byte binary string. This operation delivers the result of add operations
|
||||
since the last new or reset operation. Note that the digest operation is
|
||||
effectively a destructive, read-once operation. Once it has been performed, the
|
||||
context must be reset before being used to calculate another digest value.
|
||||
Several convenience functions are also provided. The addfile operation
|
||||
takes an open file-handle and reads it until end-of file in 1024 byte blocks
|
||||
adding the contents to the context. The file-handle can either be specified by
|
||||
name or passed as a type-glob reference. The hexdigest operation calls digest
|
||||
and returns the result as a printable string of hexdecimal digits.
|
||||
The hash operation can act as either a static member function (you
|
||||
invoke it on the MD5 class) or as a normal virtual function. In both cases it
|
||||
performs the complete MD5 cycle (reset, add, digest) on the supplied scalar
|
||||
value. This is convenient for handling small quantities of data. When invoked on
|
||||
the class a temporary context is created. When invoked through an already
|
||||
created context object, this context is used. The latter form is slightly more
|
||||
efficient. The hexhash operation is analogous to hexdigest.
|
||||
|
||||
+12
-14
@@ -1,21 +1,19 @@
|
||||
dc42wrap was created several years ago to produce open-source
|
||||
operating system boot floppies for a PC that couldn't boot from
|
||||
CD-ROM, in an environment where the only physically accessible
|
||||
machines with floppy disk drives were Apple Macintoshes.
|
||||
Several years ago, dc42wrap was created to produce open-source operating
|
||||
system boot floppies for a PC that could not boot from CD-ROM, in an environment
|
||||
where the only physically accessible machines with floppy disk drives were Apple
|
||||
Macintoshes.
|
||||
|
||||
"raw" disk image -> FTP -> dc42wrap
|
||||
FTP -> [Macintosh OS 7/8/9] -> physical floppy
|
||||
|
||||
When Apple stopped including floppy drives in their hardware,
|
||||
this software fell into disuse ... until someone needed to copy
|
||||
the contents of an ancient pile of HFS-formatted floppies onto a
|
||||
floppy drive-less Macintosh running OS X, and the only physically
|
||||
accessible machines with floppy disk drives were PCs running an
|
||||
open-source operating system.
|
||||
|
||||
Even though Apple now uses NDIF as their preferred disk image
|
||||
format, modern software still understands DiskCopy 4.2 files ...
|
||||
and OS X will happily mount those old HFS images on the desktop.
|
||||
When Apple stopped including floppy drives in their hardware, this
|
||||
software fell into disuse, until someone needed to copy the contents of an
|
||||
ancient pile of HFS-formatted floppies onto a floppy drive-less Macintosh
|
||||
running OS X, and the only physically accessible machines with floppy disk
|
||||
drives were PCs running an open-source operating system.
|
||||
Even though Apple now uses NDIF as their preferred disk image format,
|
||||
modern software still understands DiskCopy 4.2 files, and OS X will happily
|
||||
mount those old HFS images on the desktop.
|
||||
|
||||
physical floppy -> dd -> dc42wrap
|
||||
SSH -> [Macintosh OS X] -> mounted filesystem
|
||||
|
||||
@@ -1,22 +1,16 @@
|
||||
Apache-FP
|
||||
Version 1.0 (and up)
|
||||
|
||||
What is it?
|
||||
-----------
|
||||
|
||||
Apache is an HTTP server designed as a plug-in replacement for the NCSA
|
||||
Apache is an HTTP server designed as a plug-in replacement for the NCSA
|
||||
server version 1.3 (or 1.4). It fixes numerous bugs in the NCSA server and
|
||||
includes many frequently requested new features, and has an API which
|
||||
Allows it to be extended to meet users' needs more easily.
|
||||
|
||||
Microsoft Frontpage module allows web administrators and authors to
|
||||
remotely manage, create, modify, or delete web pages on the Apache server
|
||||
using the Microsoft FrontPage Extentions.
|
||||
includes many frequently requested new features, and has an API which allows it
|
||||
to be extended to meet users' needs more easily.
|
||||
Microsoft Frontpage module allows web administrators and authors to
|
||||
remotely manage, create, modify, or delete web pages on the Apache server using
|
||||
the Microsoft FrontPage Extensions.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
All the documentation is on-line on the WWW, via the URL's:
|
||||
All the documentation is on-line on the WWW, via the URLs:
|
||||
|
||||
Apache - http://www.apache.org/httpd.html
|
||||
FrontPage - http://www.microsoft.com/frontpage
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
FxHTML adds an additional layer of extremely powerful HTML commands to
|
||||
your web server.
|
||||
|
||||
HTML Has the following features:-
|
||||
FxHTML has the following features:
|
||||
|
||||
+ Automatic session/context handling
|
||||
+ Method POST & Method GET automatically handled
|
||||
+ Choice of Content Types (HTML,TEXT,...)
|
||||
+ Floating point expression handling
|
||||
+ Text handling including search and replace, splitting, substrings and arrays.
|
||||
+ Text handling including search and replace, splitting, substrings and
|
||||
arrays.
|
||||
+ Variable subsitution
|
||||
+ Disk based variable handling
|
||||
+ Procedure calls including recursion capabilities
|
||||
@@ -18,4 +19,4 @@ HTML Has the following features:-
|
||||
+ Interface to shell commands
|
||||
+ Bitmap handling and GIF generation
|
||||
+ Full error tracking system with formatted HTML output
|
||||
+ Common interface to handle files, sockets, devices and pipes. (*)
|
||||
+ Common interface to handle files, sockets, devices and pipes.
|
||||
|
||||
@@ -1,6 +1,5 @@
|
||||
This utility notably decreases the startup time of your X sessions, provided
|
||||
that you start a number of X clients automatically during the X session
|
||||
startup.
|
||||
that you start a number of X clients automatically during the X session startup.
|
||||
Most people, for instance, start X clients like xterm, xclock, xconsole and
|
||||
xosview from their .xinitrc, .openwin-init, .xtoolplaces or .xsession file.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user