Archives/phetch
2
0
Fork 0
mirror of https://github.com/xvxx/phetch synced 2024-11-05 00:00:58 +00:00
Code Issues Releases Wiki Activity

add some criterion benchmarks

Browse Source
This commit is contained in:
chris west 2020-01-27 23:08:16 -08:00
parent fa8f1d4a27
commit 8f7a9cedc3
8 changed files with 2606 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
benches/parse_gopher.rs Normal file
View File

@ -0,0 +1,27 @@
#[macro_use]
extern crate criterion;
use criterion::Criterion;
use phetch::menu;
use std::fs;
fn parse(txt: &str) -> menu::Menu {
menu::parse("benchmark", txt.to_string())
}
fn criterion_benchmark(c: &mut Criterion) {
if let Ok(raw) = fs::read_to_string("benches/sdf.txt") {
c.bench_function("parse sdf.org", |b| b.iter(|| parse(&raw)));
}
if let Ok(raw) = fs::read_to_string("benches/rpod.txt") {
c.bench_function("parse RPoD", |b| b.iter(|| parse(&raw)));
}
if let Ok(raw) = fs::read_to_string("benches/unix.txt") {
c.bench_function("parse UNIX docs", |b| b.iter(|| parse(&raw)));
}
}
criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);

25
benches/render_menu.rs Normal file
View File

@ -0,0 +1,25 @@
#[macro_use]
extern crate criterion;
use criterion::Criterion;
use phetch::{menu, ui::View};
use std::fs;
fn parse(file: &str) -> menu::Menu {
let raw = fs::read_to_string(file).unwrap();
menu::parse("benchmark", raw)
}
fn criterion_benchmark(c: &mut Criterion) {
let mut menu = parse("benches/sdf.txt");
c.bench_function("render sdf.org", |b| b.iter(|| menu.render()));
let mut menu = parse("benches/rpod.txt");
c.bench_function("render RPoD", |b| b.iter(|| menu.render()));
let mut menu = parse("benches/unix.txt");
c.bench_function("render UNIX doc", |b| b.iter(|| menu.render()));
}
criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);

22
benches/render_text.rs Normal file
View File

@ -0,0 +1,22 @@
#[macro_use]
extern crate criterion;
use criterion::Criterion;
use phetch::{config::Config, text, ui::View};
use std::fs;
fn parse(cfg: &Config, txt: String) -> text::Text {
text::Text::from("benchmark", txt, cfg, false)
}
fn criterion_benchmark(c: &mut Criterion) {
let cfg = Config::default();
if let Ok(raw) = fs::read_to_string("benches/rfc1436.txt") {
let mut txt = parse(&cfg, raw);
c.bench_function("render rfc text", |b| b.iter(|| txt.render()));
}
}
criterion_group!(benches, criterion_benchmark);
criterion_main!(benches);

895
benches/rfc1436.txt Normal file
View File

@ -0,0 +1,895 @@
Network Working Group F. Anklesaria
Request for Comments: 1436 M. McCahill
P. Lindner
D. Johnson
D. Torrey
B. Alberti
University of Minnesota
March 1993
The Internet Gopher Protocol
(a distributed document search and retrieval protocol)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
The Internet Gopher protocol is designed for distributed document
search and retrieval. This document describes the protocol, lists
some of the implementations currently available, and has an overview
of how to implement new client and server applications. This
document is adapted from the basic Internet Gopher protocol document
first issued by the Microcomputer Center at the University of
Minnesota in 1991.
Introduction
gopher n. 1. Any of various short tailed, burrowing mammals of the
family Geomyidae, of North America. 2. (Amer. colloq.) Native or
inhabitant of Minnesota: the Gopher State. 3. (Amer. colloq.) One
who runs errands, does odd-jobs, fetches or delivers documents for
office staff. 4. (computer tech.) software following a simple
protocol for burrowing through a TCP/IP internet.
The Internet Gopher protocol and software follow a client-server
model. This protocol assumes a reliable data stream; TCP is assumed.
Gopher servers should listen on port 70 (port 70 is assigned to
Internet Gopher by IANA). Documents reside on many autonomous
servers on the Internet. Users run client software on their desktop
systems, connecting to a server and sending the server a selector (a
line of text, which may be empty) via a TCP connection at a well-
known port. The server responds with a block of text terminated by a
period on a line by itself and closes the connection. No state is
retained by the server.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 1]
RFC 1436 Gopher March 1993
While documents (and services) reside on many servers, Gopher client
software presents users with a hierarchy of items and directories
much like a file system. The Gopher interface is designed to
resemble a file system since a file system is a good model for
organizing documents and services; the user sees what amounts to one
big networked information system containing primarily document items,
directory items, and search items (the latter allowing searches for
documents across subsets of the information base).
Servers return either directory lists or documents. Each item in a
directory is identified by a type (the kind of object the item is),
user-visible name (used to browse and select from listings), an
opaque selector string (typically containing a pathname used by the
destination host to locate the desired object), a host name (which
host to contact to obtain this item), and an IP port number (the port
at which the server process listens for connections). The user only
sees the user-visible name. The client software can locate and
retrieve any item by the trio of selector, hostname, and port.
To use a search item, the client submits a query to a special kind of
Gopher server: a search server. In this case, the client sends the
selector string (if any) and the list of words to be matched. The
response yields "virtual directory listings" that contain items
matching the search criteria.
Gopher servers and clients exist for all popular platforms. Because
the protocol is so sparse and simple, writing servers or clients is
quick and straightforward.
1. Introduction
The Internet Gopher protocol is designed primarily to act as a
distributed document delivery system. While documents (and services)
reside on many servers, Gopher client software presents users with a
hierarchy of items and directories much like a file system. In fact,
the Gopher interface is designed to resemble a file system since a
file system is a good model for locating documents and services. Why
model a campus-wide information system after a file system? Several
reasons:
(a) A hierarchical arrangement of information is familiar to many
users. Hierarchical directories containing items (such as
documents, servers, and subdirectories) are widely used in
electronic bulletin boards and other campus-wide information
systems. People who access a campus-wide information server will
expect some sort of hierarchical organization to the information
presented.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 2]
RFC 1436 Gopher March 1993
(b) A file-system style hierarchy can be expressed in a simple
syntax. The syntax used for the internet Gopher protocol is
easily understandable, and was designed to make debugging servers
and clients easy. You can use Telnet to simulate an internet
Gopher client's requests and observe the responses from a server.
Special purpose software tools are not required. By keeping the
syntax of the pseudo-file system client/server protocol simple, we
can also achieve better performance for a very common user
activity: browsing through the directory hierarchy.
(c) Since Gopher originated in a University setting, one of the
goals was for departments to have the option of publishing
information from their inexpensive desktop machines, and since
much of the information can be presented as simple text files
arranged in directories, a protocol modeled after a file system
has immediate utility. Because there can be a direct mapping from
the file system on the user's desktop machine to the directory
structure published via the Gopher protocol, the problem of
writing server software for slow desktop systems is minimized.
(d) A file system metaphor is extensible. By giving a "type"
attribute to items in the pseudo-file system, it is possible to
accommodate documents other than simple text documents. Complex
database services can be handled as a separate type of item. A
file-system metaphor does not rule out search or database-style
queries for access to documents. A search-server type is also
defined in this pseudo-file system. Such servers return "virtual
directories" or list of documents matching user specified
criteria.
2. The internet Gopher Model
A detailed BNF rendering of the internet Gopher syntax is available
in the appendix...but a close reading of the appendix may not be
necessary to understand the internet Gopher protocol.
In essence, the Gopher protocol consists of a client connecting to a
server and sending the server a selector (a line of text, which may
be empty) via a TCP connection. The server responds with a block of
text terminated with a period on a line by itself, and closes the
connection. No state is retained by the server between transactions
with a client. The simple nature of the protocol stems from the need
to implement servers and clients for the slow, smaller desktop
computers (1 MB Macs and DOS machines), quickly, and efficiently.
Below is a simple example of a client/server interaction; more
complex interactions are dealt with later. Assume that a "well-
known" Gopher server (this may be duplicated, details are discussed
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 3]
RFC 1436 Gopher March 1993
later) listens at a well known port for the campus (much like a
domain-name server). The only configuration information the client
software retains is this server's name and port number (in this
example that machine is rawBits.micro.umn.edu and the port 70). In
the example below the F character denotes the TAB character.
Client: {Opens connection to rawBits.micro.umn.edu at port 70}
Server: {Accepts connection but says nothing}
Client: <CR><LF> {Sends an empty line: Meaning "list what you have"}
Server: {Sends a series of lines, each ending with CR LF}
0About internet GopherFStuff:About usFrawBits.micro.umn.eduF70
1Around University of MinnesotaFZ,5692,AUMFunderdog.micro.umn.eduF70
1Microcomputer News & PricesFPrices/Fpserver.bookstore.umn.eduF70
1Courses, Schedules, CalendarsFFevents.ais.umn.eduF9120
1Student-Staff DirectoriesFFuinfo.ais.umn.eduF70
1Departmental PublicationsFStuff:DP:FrawBits.micro.umn.eduF70
{.....etc.....}
. {Period on a line by itself}
{Server closes connection}
The first character on each line tells whether the line describes a
document, directory, or search service (characters '0', '1', '7';
there are a handful more of these characters described later). The
succeeding characters up to the tab form a user display string to be
shown to the user for use in selecting this document (or directory)
for retrieval. The first character of the line is really defining
the type of item described on this line. In nearly every case, the
Gopher client software will give the users some sort of idea about
what type of item this is (by displaying an icon, a short text tag,
or the like).
The characters following the tab, up to the next tab form a selector
string that the client software must send to the server to retrieve
the document (or directory listing). The selector string should mean
nothing to the client software; it should never be modified by the
client. In practice, the selector string is often a pathname or
other file selector used by the server to locate the item desired.
The next two tab delimited fields denote the domain-name of the host
that has this document (or directory), and the port at which to
connect. If there are yet other tab delimited fields, the basic
Gopher client should ignore them. A CR LF denotes the end of the
item.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 4]
RFC 1436 Gopher March 1993
In the example, line 1 describes a document the user will see as
"About internet Gopher". To retrieve this document, the client
software must send the retrieval string: "Stuff:About us" to
rawBits.micro.umn.edu at port 70. If the client does this, the
server will respond with the contents of the document, terminated by
a period on a line by itself. A client might present the user with a
view of the world something like the following list of items:
About Internet Gopher
Around the University of Minnesota...
Microcomputer News & Prices...
Courses, Schedules, Calendars...
Student-Staff Directories...
Departmental Publications...
In this case, directories are displayed with an ellipsis and files
are displayed without any. However, depending on the platform the
client is written for and the author's taste, item types could be
denoted by other text tags or by icons. For example, the UNIX
curses-based client displays directories with a slash (/) following
the name; Macintosh clients display directories alongside an icon of
a folder.
The user does not know or care that the items up for selection may
reside on many different machines anywhere on the Internet.
Suppose the user selects the line "Microcomputer News & Prices...".
This appears to be a directory, and so the user expects to see
contents of the directory upon request that it be fetched. The
following lines illustrate the ensuing client-server interaction:
Client: (Connects to pserver.bookstore.umn.edu at port 70)
Server: (Accepts connection but says nothing)
Client: Prices/ (Sends the magic string terminated by CRLF)
Server: (Sends a series of lines, each ending with CR LF)
0About PricesFPrices/AboutusFpserver.bookstore.umn.eduF70
0Macintosh PricesFPrices/MacFpserver.bookstore.umn.eduF70
0IBM PricesFPrices/IckFpserver.bookstore.umn.eduF70
0Printer & Peripheral PricesFPrices/PPPFpserver.bookstore.umn.eduF70
(.....etc.....)
. (Period on a line by itself)
(Server closes connection)
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 5]
RFC 1436 Gopher March 1993
3. More details
3.1 Locating services
Documents (or other services that may be viewed ultimately as
documents, such as a student-staff phonebook) are linked to the
machine they are on by the trio of selector string, machine domain-
name, and IP port. It is assumed that there will be one well-known
top-level or root server for an institution or campus. The
information on this server may be duplicated by one or more other
servers to avoid a single point of failure and to spread the load
over several servers. Departments that wish to put up their own
departmental servers need to register the machine name and port with
the administrators of the top-level Gopher server, much the same way
as they register a machine name with the campus domain-name server.
An entry which points to the departmental server will then be made at
the top level server. This ensures that users will be able to
navigate their way down what amounts to a virtual hierarchical file
system with a well known root to any campus server if they desire.
Note that there is no requirement that a department register
secondary servers with the central top-level server; they may just
place a link to the secondary servers in their own primary servers.
They may indeed place links to any servers they desire in their own
server, thus creating a customized view of thethe Gopher information
universe; links can of course point back at the top-level server.
The virtual (networked) file system is therefore an arbitrary graph
structure and not necessarily a rooted tree. The top-level node is
merely one convenient, well-known point of entry. A set of Gopher
servers linked in this manner may function as a campus-wide
information system.
Servers may of course point links at other than secondary servers.
Indeed servers may point at other servers offering useful services
anywhere on the internet. Viewed in this manner, Gopher can be seen
as an Internet-wide information system.
3.2 Server portability and naming
It is recommended that all registered servers have alias names
(domain name system CNAME) that are used by Gopher clients to locate
them. Links to these servers should use these alias names rather
than the primary names. If information needs to be moved from one
machine to another, a simple change of domain name system alias
(CNAME) allows this to occur without any reconfiguration of clients
in the field. In short, the domain name system may be used to re-map
a server to a new address. There is nothing to prevent secondary
servers or services from running on otherwise named servers or ports
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 6]
RFC 1436 Gopher March 1993
other than 70, however these should be reachable via a primary
server.
3.3 Contacting server administrators
It is recommended that every server administrator have a document
called something like: "About Bogus University's Gopher server" as
the first item in their server's top level directory. In this
document should be a short description of what the server holds, as
well as name, address, phone, and an e-mail address of the person who
administers the server. This provides a way for users to get word to
the administrator of a server that has inaccurate information or is
not running correctly. It is also recommended that administrators
place the date of last update in files for which such information
matters to the users.
3.4 Modular addition of services
The first character of each line in a server-supplied directory
listing indicates whether the item is a file (character '0'), a
directory (character '1'), or a search (character '7'). This is the
base set of item types in the Gopher protocol. It is desirable for
clients to be able to use different services and speak different
protocols (simple ones such as finger; others such as CSO phonebook
service, or Telnet, or X.500 directory service) as needs dictate.
CSO phonebook service is a client/server phonebook system typically
used at Universities to publish names, e-mail addresses, and so on.
The CSO phonebook software was developed at the University of
Illinois and is also sometimes refered to as ph or qi. For example,
if a server-supplied directory listing marks a certain item with type
character '2', then it means that to use this item, the client must
speak the CSO protocol. This removes the need to be able to
anticipate all future needs and hard-wire them in the basic Internet
Gopher protocol; it keeps the basic protocol extremely simple. In
spite of this simplicity, the scheme has the capability to expand and
change with the times by adding an agreed upon type-character for a
new service. This also allows the client implementations to evolve
in a modular fashion, simply by dropping in a module (or launching a
new process) for some new service. The servers for the new service
of course have to know nothing about Internet Gopher; they can just
be off-the shelf CSO, X.500, or other servers. We do not however,
encourage arbitrary or machine-specific proliferation of service
types in the basic Gopher protocol.
On the other hand, subsets of other document retrieval schemes may be
mapped onto the Gopher protocol by means of "gateway-servers".
Examples of such servers include Gopher-to-FTP gateways, Gopher-to-
archie gateways, Gopher-to-WAIS gateways, etc. There are a number of
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 7]
RFC 1436 Gopher March 1993
advantages of such mechanisms. First, a relatively powerful server
machine inherits both the intelligence and work, rather than the more
modest, inexpensive desktop system that typically runs client
software or basic server software. Equally important, clients do not
have to be modified to take advantage of a new resource.
3.5 Building clients
A client simply sends the retrieval string to a server if it wants to
retrieve a document or view the contents of a directory. Of course,
each host may have pointers to other hosts, resulting in a "graph"
(not necessarily a rooted tree) of hosts. The client software may
save (or rather "stack") the locations that it has visited in search
of a document. The user could therefore back out of the current
location by unwinding the stack. Alternatively, a client with
multiple-window capability might just be able to display more than
one directory or document at the same time.
A smart client could cache the contents of visited directories
(rather than just the directory's item descriptor), thus avoiding
network transactions if the information has been previously
retrieved.
If a client does not understand what a say, type 'B' item (not a core
item) is, then it may simply ignore the item in the directory
listing; the user never even has to see it. Alternatively, the item
could be displayed as an unknown type.
Top-level or primary servers for a campus are likely to get more
traffic than secondary servers, and it would be less tolerable for
such primary servers to be down for any long time. So it makes sense
to "clone" such important servers and construct clients that can
randomly choose between two such equivalent primary servers when they
first connect (to balance server load), moving to one if the other
seems to be down. In fact, smart client implementations do this
clone server and load balancing. Alternatively, it may make sense to
have the domain name system return one of a set of redundant of
server's IP address to load balance betwen redundant sets of
important servers.
3.6 Building ordinary internet Gopher servers
The retrieval string sent to the server might be a path to a file or
directory. It might be the name of a script, an application or even
a query that generates the document or directory returned. The basic
server uses the string it gets up to but not including a CR-LF or a
TAB, whichever comes first.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 8]
RFC 1436 Gopher March 1993
All intelligence is carried by the server implementation rather than
the protocol. What you build into more exotic servers is up to you.
Server implementations may grow as needs dictate and time allows.
3.7 Special purpose servers
There are two special server types (beyond the normal Gopher server)
also discussed below:
1. A server directory listing can point at a CSO nameserver (the
server returns a type character of '2') to allow a campus
student-staff phonebook lookup service. This may show up on the
user's list of choices, perhaps preceded by the icon of a phone-
book. If this item is selected, the client software must resort
to a pure CSO nameserver protocol when it connects to the
appropriate host.
2. A server can also point at a "search server" (returns a first
character of '7'). Such servers may implement campus network (or
subnet) wide searching capability. The most common search servers
maintain full-text indexes on the contents of text documents held
by some subset of Gopher servers. Such a "full-text search
server" responds to client requests with a list of all documents
that contain one or more words (the search criteria). The client
sends the server the selector string, a tab, and the search string
(words to search for). If the selector string is empty, the client
merely sends the search string. The server returns the equivalent
of a directory listing for documents matching the search criteria.
Spaces between words are usually implied Boolean ANDs (although in
different implementations or search types, this may not
necessarily be true).
The CSO addition exists for historical reasons: at time of design,
the campus phone-book servers at the University of Minnesota used the
CSO protocol and it seemed simplest to just engulf them. The index-
server is however very much a Gopher in spirit, albeit with a slight
twist in the meaning of the selector-string. Index servers are a
natural place to incorperate gateways to WAIS and WHOIS services.
3.7.1 Building CSO-servers
A CSO Nameserver implementation for UNIX and associated documentation
is available by anonymous ftp from uxa.cso.uiuc.edu. We do not
anticipate implementing it on other machines.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 9]
RFC 1436 Gopher March 1993
3.7.2 Building full-text search servers
A full-text search server is a special-purpose server that knows
about the Gopher scheme for retrieving documents. These servers
maintain a full-text index of the contents of plain text documents on
Gopher servers in some specified domain. A Gopher full-text search
server was implemented using several NeXTstations because it was easy
to take advantage of the full-text index/search engine built into the
NeXT system software. A search server for generic UNIX systems based
on the public domain WAIS search engine, is also available and
currently an optional part of the UNIX gopher server. In addition,
at least one implementation of the gopher server incorperates a
gateway to WAIS servers by presenting the WAIS servers to gopherspace
as full-text search servers. The gopher<->WAIS gateway servers does
the work of translating from gopher protocol to WAIS so unmodified
gopher clients can access WAIS servers via the gateway server.
By using several index servers (rather than a monolithic index
server) indexes may be searched in parallel (although the client
software is not aware of this). While maintaining full-text indexes
of documents distributed over many machines may seem a daunting task,
the task can be broken into smaller pieces (update only a portion of
the indexes, search several partial indexes in parallel) so that it
is manageable. By spreading this task over several small, cheap (and
fast) workstations it is possible to take advantage of fine-grain
parallelism. Again, the client software is not aware of this. Client
software only needs to know that it can send a search string to an
index server and will receive a list of documents that contain the
words in the search string.
3.8 Item type characters
The client software decides what items are available by looking at
the first character of each line in a directory listing. Augmenting
this list can extend the protocol. A list of defined item-type
characters follows:
0 Item is a file
1 Item is a directory
2 Item is a CSO phone-book server
3 Error
4 Item is a BinHexed Macintosh file.
5 Item is DOS binary archive of some sort.
Client must read until the TCP connection closes. Beware.
6 Item is a UNIX uuencoded file.
7 Item is an Index-Search server.
8 Item points to a text-based telnet session.
9 Item is a binary file!
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 10]
RFC 1436 Gopher March 1993
Client must read until the TCP connection closes. Beware.
+ Item is a redundant server
T Item points to a text-based tn3270 session.
g Item is a GIF format graphics file.
I Item is some kind of image file. Client decides how to display.
Characters '0' through 'Z' are reserved. Local experiments should
use other characters. Machine-specific extensions are not
encouraged. Note that for type 5 or type 9 the client must be
prepared to read until the connection closes. There will be no
period at the end of the file; the contents of these files are binary
and the client must decide what to do with them based perhaps on the
.xxx extension.
3.9 User display strings and server selector strings
User display strings are intended to be displayed on a line on a
typical screen for a user's viewing pleasure. While many screens can
accommodate 80 character lines, some space is needed to display a tag
of some sort to tell the user what sort of item this is. Because of
this, the user display string should be kept under 70 characters in
length. Clients may truncate to a length convenient to them.
4. Simplicity is intentional
As far as possible we desire any new features to be carried as new
protocols that will be hidden behind new document-types. The
internet Gopher philosophy is:
(a) Intelligence is held by the server. Clients have the option
of being able to access new document types (different, other types
of servers) by simply recognizing the document-type character.
Further intelligence to be borne by the protocol should be
minimized.
(b) The well-tempered server ought to send "text" (unless a file
must be transferred as raw binary). Should this text include
tabs, formfeeds, frufru? Probably not, but rude servers will
probably send them anyway. Publishers of documents should be
given simple tools (filters) that will alert them if there are any
funny characters in the documents they wish to publish, and give
them the opportunity to strip the questionable characters out; the
publisher may well refuse.
(c) The well-tempered client should do something reasonable with
funny characters received in text; filter them out, leave them in,
whatever.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 11]
RFC 1436 Gopher March 1993
Appendix
Paul's NQBNF (Not Quite BNF) for the Gopher Protocol.
Note: This is modified BNF (as used by the Pascal people) with a few
English modifiers thrown in. Stuff enclosed in '{}' can be
repeated zero or more times. Stuff in '[]' denotes a set of
items. The '-' operator denotes set subtraction.
Directory Entity
CR-LF ::= ASCII Carriage Return Character followed by Line Feed
character.
Tab ::= ASCII Tab character.
NUL ::= ASCII NUL character.
UNASCII ::= ASCII - [Tab CR-LF NUL].
Lastline ::= '.'CR-LF.
TextBlock ::= Block of ASCII text not containing Lastline pattern.
Type ::= UNASCII.
RedType ::= '+'.
User_Name ::= {UNASCII}.
Selector ::= {UNASCII}.
Host ::= {{UNASCII - ['.']} '.'} {UNASCII - ['.']}.
Note: This is a Fully Qualified Domain Name as defined in RFC 1034.
(e.g., gopher.micro.umn.edu) Hosts that have a CR-LF
TAB or NUL in their name get what they deserve.
Digit ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' .
DigitSeq ::= digit {digit}.
Port ::= DigitSeq.
Note: Port corresponds the the TCP Port Number, its value should
be in the range [0..65535]; port 70 is officially assigned
to gopher.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 12]
RFC 1436 Gopher March 1993
DirEntity ::= Type User_Name Tab Selector Tab Host Tab Port CR-LF
{RedType User_Name Tab Selector Tab Host Tab Port CR-LF}
Notes:
It is *highly* recommended that the User_Name field contain only
printable characters, since many different clients will be using
it. However if eight bit characters are used, the characters
should conform with the ISO Latin1 Character Set. The length of
the User displayable line should be less than 70 Characters; longer
lines may not fit across some screens.
The Selector string should be no longer than 255 characters.
Menu Entity
Menu ::= {DirEntity} Lastline.
Menu Transaction (Type 1 item)
C: Opens Connection
S: Accepts Connection
C: Sends Selector String
S: Sends Menu Entity
Connection is closed by either client or server (typically server).
Textfile Entity
TextFile ::= {TextBlock} Lastline
Note: Lines beginning with periods must be prepended with an extra
period to ensure that the transmission is not terminated early.
The client should strip extra periods at the beginning of the line.
TextFile Transaction (Type 0 item)
C: Opens Connection.
S: Accepts connection
C: Sends Selector String.
S: Sends TextFile Entity.
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 13]
RFC 1436 Gopher March 1993
Connection is closed by either client or server (typically server).
Note: The client should be prepared for the server closing the
connection without sending the Lastline. This allows the
client to use fingerd servers.
Full-Text Search Transaction (Type 7 item)
Word ::= {UNASCII - ' '}
BoolOp ::= 'and' | 'or' | 'not' | SPACE
SearchStr ::= Word {{SPACE BoolOp} SPACE Word}
C: Opens Connection.
C: Sends Selector String, Tab, Search String.
S: Sends Menu Entity.
Note: In absence of 'and', 'or', or 'not' operators, a SPACE is
regarded as an implied 'and' operator. Expression is evaluated
left to right. Further, not all search engines or search
gateways currently implemented have the boolean operators
implemented.
Binary file Transaction (Type 9 or 5 item)
C: Opens Connection.
S: Accepts connection
C: Sends Selector String.
S: Sends a binary file and closes connection when done.
Syntactic Meaning for Directory Entities
The client should interpret the type field as follows:
0 The item is a TextFile Entity.
Client should use a TextFile Transaction.
1 The item is a Menu Entity.
Client should use a Menu Transaction.
2 The information applies to a CSO phone book entity.
Client should talk CSO protocol.
3 Signals an error condition.
4 Item is a Macintosh file encoded in BINHEX format
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 14]
RFC 1436 Gopher March 1993
5 Item is PC-DOS binary file of some sort. Client gets to decide.
6 Item is a uuencoded file.
7 The information applies to a Index Server.
Client should use a FullText Search transaction.
8 The information applies to a Telnet session.
Connect to given host at given port. The name to login as at this
host is in the selector string.
9 Item is a binary file. Client must decide what to do with it.
+ The information applies to a duplicated server. The information
contained within is a duplicate of the primary server. The primary
server is defined as the last DirEntity that is has a non-plus
"Type" field. The client should use the transaction as defined by
the primary server Type field.
g Item is a GIF graphic file.
I Item is some kind of image file. Client gets to decide.
T The information applies to a tn3270 based telnet session.
Connect to given host at given port. The name to login as at this
host is in the selector string.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Farhad Anklesaria
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: fxa@boombox.micro.umn.edu
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 15]
RFC 1436 Gopher March 1993
Mark McCahill
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu
Paul Lindner
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: lindner@boombox.micro.umn.edu
David Johnson
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: dmj@boombox.micro.umn.edu
Daniel Torrey
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: daniel@boombox.micro.umn.edu
Bob Alberti
Computer and Information Services, University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: alberti@boombox.micro.umn.edu
Anklesari, McCahill, Lindner, Johnson, Torrey & Alberti [Page 16]

283
benches/rpod.txt Normal file
View File

@ -0,0 +1,283 @@
i===================================================================== ERR err.host 0
i RPoD Phlog ERR err.host 0
i "No one wants a disarmed population more than entrenched capital ERR err.host 0
i with access to the means of counterfeit." - anon ERR err.host 0
i===================================================================== ERR err.host 0
iCurrent phlog entry also available at: finger phlog@1436.ninja ERR err.host 0
0Phlog atom feed /phlog.atom 1436.ninja 70
0Nokia N810 Review (20200125.post) /Phlog/20200125.post 1436.ninja 70
0Gitlab Updates (20200120.post) /Phlog/20200120.post 1436.ninja 70
0RPoD Rewrite Complete (20200117.post) /Phlog/20200117.post 1436.ninja 70
0Various Updates (20200114.post) /Phlog/20200114.post 1436.ninja 70
0Stickers (20200113.post) /Phlog/20200113.post 1436.ninja 70
0More vim fun! (20200109.post) /Phlog/20200109.post 1436.ninja 70
0Adventures in modifying vim plugins (20200106.post) /Phlog/20200106.post 1436.ninja 70
0Friendship ended with emacs, vim is my true friend (20200104.post) /Phlog/20200104.post 1436.ninja 70
0New Portable Music Player Setup Review (20200102.post) /Phlog/20200102.post 1436.ninja 70
0More on rewrites (20200101b.post) /Phlog/20200101b.post 1436.ninja 70
0Happy New Decade (20200101.post) /Phlog/20200101.post 1436.ninja 70
0On a gopherhole rewrite (20191227.post) /Phlog/20191227.post 1436.ninja 70
0Emacs (20191226.post) /Phlog/20191226.post 1436.ninja 70
0Laptop adventures (20191214.post) /Phlog/20191214.post 1436.ninja 70
0On mellow (20191205.post) /Phlog/20191205.post 1436.ninja 70
0Catch up (20191122.post) /Phlog/20191122.post 1436.ninja 70
0Projects!! (20191116.post) /Phlog/20191116.post 1436.ninja 70
0On Free Time (20191105.post) /Phlog/20191105.post 1436.ninja 70
0Mechanicin' (20191104.post) /Phlog/20191104.post 1436.ninja 70
0Not much (20191026.post) /Phlog/20191026.post 1436.ninja 70
0Yep, it happened (20191017.post) /Phlog/20191017.post 1436.ninja 70
0Not RE: s-word (cat) (20191015.post) /Phlog/20191015.post 1436.ninja 70
0Ratpoison, layoffs, inversion (20191012.post) /Phlog/20191012.post 1436.ninja 70
0RE: ratfactor vimwiki (20191002.post) /Phlog/20191002.post 1436.ninja 70
0On PIM (RE: jirka and xiled) (20190930.post) /Phlog/20190930.post 1436.ninja 70
0On the Palm Ultra Thin Keyboard (20190923.post) /Phlog/20190923.post 1436.ninja 70
0RE: Jirka, Palm OS questions (20190922b.post) /Phlog/20190922b.post 1436.ninja 70
0RE: visiblink - I'm going thru your stuff (20190922.post) /Phlog/20190922.post 1436.ninja 70
0On the 90 percent of gopher... (20190914.post) /Phlog/20190914.post 1436.ninja 70
0Gnu direvent (20190910.post) /Phlog/20190910.post 1436.ninja 70
0Shunning (20190909.post) /Phlog/20190909.post 1436.ninja 70
0Received the Tungsten C (20190907.post) /Phlog/20190907.post 1436.ninja 70
0ROOPHLOCH 2019 (20190831.post) /Phlog/20190831.post 1436.ninja 70
0Received the first of two new devices (20190826.post) /Phlog/20190826.post 1436.ninja 70
0Cleaned up HTTPS->HTTP proxy code (20190824.post) /Phlog/20190824.post 1436.ninja 70
0HTTPS->HTTP Proxy for Plucker (20190823.post) /Phlog/20190823.post 1436.ninja 70
0On Plucker (20190819.post) /Phlog/20190819.post 1436.ninja 70
0Fun with Palm doc format (20190818.post) /Phlog/20190818.post 1436.ninja 70
0On comp.unix.shell (20190816.post) /Phlog/20190816.post 1436.ninja 70
0Treo 90 Arrived (20190815.post) /Phlog/20190815.post 1436.ninja 70
0New Palm Device Coming (20190810.post) /Phlog/20190810.post 1436.ninja 70
0On a satisfying lazy day (20190803.post) /Phlog/20190803.post 1436.ninja 70
0Re: visiblink (camping gear) (20190801.post) /Phlog/20190801.post 1436.ninja 70
0On Camping (20190731.post) /Phlog/20190731.post 1436.ninja 70
0Catch up (20190721.post) /Phlog/20190721.post 1436.ninja 70
0On a balmy Sunday (20190630.post) /Phlog/20190630.post 1436.ninja 70
0On being social (20190623.post) /Phlog/20190623.post 1436.ninja 70
0On this weekend (20190622.post) /Phlog/20190622.post 1436.ninja 70
0Warm weather (20190618.post) /Phlog/20190618.post 1436.ninja 70
0On reinventing Gopher (20190611.post) /Phlog/20190611.post 1436.ninja 70
0Music Update (20190607.post) /Phlog/20190607.post 1436.ninja 70
0On activities of late (20190601.post) /Phlog/20190601.post 1436.ninja 70
0The last month (20190516.post) /Phlog/20190516.post 1436.ninja 70
0On Isolation (20190414.post) /Phlog/20190414.post 1436.ninja 70
0Solo RPG Ideas (20190329.post) /Phlog/20190329.post 1436.ninja 70
0On changes (20190317.post) /Phlog/20190317.post 1436.ninja 70
0On North Dakota in February (20190302.post) /Phlog/20190302.post 1436.ninja 70
0Changing schedule (20190224.post) /Phlog/20190224.post 1436.ninja 70
0On further messing with the Lifebook P1120 (20190220.post) /Phlog/20190220.post 1436.ninja 70
0On old Windows (20190214.post) /Phlog/20190214.post 1436.ninja 70
0Apple Newton eMate 300 Battery Mod Complete (20190209.post) /Phlog/20190209.post 1436.ninja 70
0On upcoming retrocomputing projects (20190208.post) /Phlog/20190208.post 1436.ninja 70
0Acquisitions (20190130.post) /Phlog/20190130.post 1436.ninja 70
0On phlog revisions and the small internet (RE: visiblink) (20190125.post) /Phlog/20190125.post 1436.ninja 70
0On joy (20190124.post) /Phlog/20190124.post 1436.ninja 70
0On the OmniBook 800ct Restoration - pt. 1 (20190120.post) /Phlog/20190120.post 1436.ninja 70
0On attachment to equipment (RE: sysdharma) (20190119.post) /Phlog/20190119.post 1436.ninja 70
0PocketChip flashing in 2019 (20190118b.post) /Phlog/20190118b.post 1436.ninja 70
0Computer Timeline (20190118.post) /Phlog/20190118.post 1436.ninja 70
0On tmux awesomeness (20190117.post) /Phlog/20190117.post 1436.ninja 70
0On Old Stuff (20190113.post) /Phlog/20190113.post 1436.ninja 70
0Writing Progress (20190112.post) /Phlog/20190112.post 1436.ninja 70
0Days off / eMate 300 (20190111.post) /Phlog/20190111.post 1436.ninja 70
0The projects are rolling in (20190107.post) /Phlog/20190107.post 1436.ninja 70
0Finger! (20190104.post) /Phlog/20190104.post 1436.ninja 70
0Happy New Year! (20190101.post) /Phlog/20190101.post 1436.ninja 70
0Bone Conduction Headphones (20181231.post) /Phlog/20181231.post 1436.ninja 70
0On further device segmentation (20181228.post) /Phlog/20181228.post 1436.ninja 70
0On the Vance Fry Dana Batt Hack (20181227.post) /Phlog/20181227.post 1436.ninja 70
0Alphasmart Fonts (20181224.post) /Phlog/20181224.post 1436.ninja 70
0AlphaSmart Dana fun (20181223.post) /Phlog/20181223.post 1436.ninja 70
0On darkness and mood (20181221.post) /Phlog/20181221.post 1436.ninja 70
0On bringing back the blog (20181219.post) /Phlog/20181219.post 1436.ninja 70
0In between dejavu (20181218.post) /Phlog/20181218.post 1436.ninja 70
0On the in between (20181217.post) /Phlog/20181217.post 1436.ninja 70
0Re: tfurrows :: Handera 300 (20181211.post) /Phlog/20181211.post 1436.ninja 70
0The 1436 Files (part deux) (20181209.post) /Phlog/20181209.post 1436.ninja 70
0Handera 330 (20181206.post) /Phlog/20181206.post 1436.ninja 70
0On the adventure of retro devices (20181202.post) /Phlog/20181202.post 1436.ninja 70
0fail (20181130.post) /Phlog/20181130.post 1436.ninja 70
0On Projects [Nov2018] (20181129.post) /Phlog/20181129.post 1436.ninja 70
0So much cool stuff going on (20181128.post) /Phlog/20181128.post 1436.ninja 70
0On restlessness (20181126.post) /Phlog/20181126.post 1436.ninja 70
0On a pattern of delay (20181119.post) /Phlog/20181119.post 1436.ninja 70
0On WinCE devices - RE: Visiblink (20181118.post) /Phlog/20181118.post 1436.ninja 70
0On the last week (20181113.post) /Phlog/20181113.post 1436.ninja 70
0Travel tomorrow -- a week gone (20181105.post) /Phlog/20181105.post 1436.ninja 70
0On the much maligned Sony Clie PEG-UX50 (20181104.post) /Phlog/20181104.post 1436.ninja 70
0Delays with the UX50 (20181031.post) /Phlog/20181031.post 1436.ninja 70
0Got my Palm IIIxe today (20181022.post) /Phlog/20181022.post 1436.ninja 70
0Re: Jirka (UX50) (20181020.post) /Phlog/20181020.post 1436.ninja 70
0I have a problem (20181019.post) /Phlog/20181019.post 1436.ninja 70
0On Plucker (20181018.post) /Phlog/20181018.post 1436.ninja 70
0On trips (20181017.post) /Phlog/20181017.post 1436.ninja 70
0On the last week (20181014.post) /Phlog/20181014.post 1436.ninja 70
0On tags (20181006.post) /Phlog/20181006.post 1436.ninja 70
0Randomness (20181005.post) /Phlog/20181005.post 1436.ninja 70
0Checking out (20181004.post) /Phlog/20181004.post 1436.ninja 70
0More on the palm os stuff (20181001.post) /Phlog/20181001.post 1436.ninja 70
0Adventures in chroot! (20180930.post) /Phlog/20180930.post 1436.ninja 70
0On Palm Devices (20180928.post) /Phlog/20180928.post 1436.ninja 70
0re: enforced anonymity [tomasino] (20180925b.post) /Phlog/20180925b.post 1436.ninja 70
0Installing Ubuntu on an RCA Cambio 2-in-1 (20180925.post) /Phlog/20180925.post 1436.ninja 70
0Inspiration (20180923.post) /Phlog/20180923.post 1436.ninja 70
0On vim as damn near anything (20180921.post) /Phlog/20180921.post 1436.ninja 70
0On Void Linux fun (20180918.post) /Phlog/20180918.post 1436.ninja 70
0On WSL and General Nerdery (20180914.post) /Phlog/20180914.post 1436.ninja 70
0Personal Computing Ecosystem (20180912.post) /Phlog/20180912.post 1436.ninja 70
0On the www (20180909.post) /Phlog/20180909.post 1436.ninja 70
0On so much to do, so little time (20180830.post) /Phlog/20180830.post 1436.ninja 70
0On Memory (20180826.post) /Phlog/20180826.post 1436.ninja 70
0On Raspberry Pi (20180824.post) /Phlog/20180824.post 1436.ninja 70
0On Work (20180817.post) /Phlog/20180817.post 1436.ninja 70
0Gopher stuff (20180804.post) /Phlog/20180804.post 1436.ninja 70
0On happiness in the face of massive disagreement (20180802.post) /Phlog/20180802.post 1436.ninja 70
0On web as newspeak: limiting features to corral people (20180726.post) /Phlog/20180726.post 1436.ninja 70
0Good to be home (20180725.post) /Phlog/20180725.post 1436.ninja 70
0On the last day of freedom (20180716.post) /Phlog/20180716.post 1436.ninja 70
0On where I find myself today (20180712.post) /Phlog/20180712.post 1436.ninja 70
0On life segmentation and happiness (20180709.post) /Phlog/20180709.post 1436.ninja 70
0Old-man observation and Wiki progress (20180706.post) /Phlog/20180706.post 1436.ninja 70
0On Pursuits (20180626.post) /Phlog/20180626.post 1436.ninja 70
0On the Internet Archive as Backup (20180623.post) /Phlog/20180623.post 1436.ninja 70
0RE: Tomasino - moleskines (20180621b.post) /Phlog/20180621b.post 1436.ninja 70
0Curveballs and Stamina (20180621.post) /Phlog/20180621.post 1436.ninja 70
0Well that didn't last long (20180618b.post) /Phlog/20180618b.post 1436.ninja 70
0On setting up a graphical user interface on the Raspberry Pi of Anguish (20180618.post) /Phlog/20180618.post 1436.ninja 70
0On the joy of simplicty (20180616.post) /Phlog/20180616.post 1436.ninja 70
0On vimwiki and the merger of 1436 and http (20180610.post) /Phlog/20180610.post 1436.ninja 70
0On abuse of the language -- "adulting" (20180608.post) /Phlog/20180608.post 1436.ninja 70
0On Death and Uncertainty (RE: alexschroeder) (20180606.post) /Phlog/20180606.post 1436.ninja 70
0On miniature books -- Pocketmod as RPG Tool (20180603.post) /Phlog/20180603.post 1436.ninja 70
0Responses to txminth (20180530.post) /Phlog/20180530.post 1436.ninja 70
0On bicycles (20180528a.post) /Phlog/20180528a.post 1436.ninja 70
0Funeral Next Weekend (20180528.post) /Phlog/20180528.post 1436.ninja 70
0On mind free to roam (20180525.post) /Phlog/20180525.post 1436.ninja 70
0On fun rpg tools (20180520.post) /Phlog/20180520.post 1436.ninja 70
0On a mobile pencil and paper gaming setup (20180519.post) /Phlog/20180519.post 1436.ninja 70
0On Multiplexing A Phlog (20180517.post) /Phlog/20180517.post 1436.ninja 70
0Rain (20180510.post) /Phlog/20180510.post 1436.ninja 70
0World creation progress (Ice Age Campaign) (20180506.post) /Phlog/20180506.post 1436.ninja 70
0On playing with actual people (20180505.post) /Phlog/20180505.post 1436.ninja 70
0On the ice age RPG project (20180429.post) /Phlog/20180429.post 1436.ninja 70
0On all-in-vim + git (pt 2) (20180428.post) /Phlog/20180428.post 1436.ninja 70
0On vim (20180427.post) /Phlog/20180427.post 1436.ninja 70
0On world creation (20180423.post) /Phlog/20180423.post 1436.ninja 70
0On gaming progress (20180419.post) /Phlog/20180419.post 1436.ninja 70
0On the third week (20180409.post) /Phlog/20180409.post 1436.ninja 70
0On my take on a note and task app (20180331.post) /Phlog/20180331.post 1436.ninja 70
0On gopher proxies and search engines (again), hoarders, and gnu screen (20180325.post) /Phlog/20180325.post 1436.ninja 70
0On interviews (re kichimi) (20180324a.post) /Phlog/20180324a.post 1436.ninja 70
0On My Game Master Assistant Script (20180324.post) /Phlog/20180324.post 1436.ninja 70
0RE zlg - Refactor or Rewrite (20180322.post) /Phlog/20180322.post 1436.ninja 70
0Hey, sysdharma - There are feeds on 1436 (20180318.post) /Phlog/20180318.post 1436.ninja 70
0On RPGs (20180317a.post) /Phlog/20180317a.post 1436.ninja 70
0I Need To Change Gopher Servers (20180317.post) /Phlog/20180317.post 1436.ninja 70
0Calendar Solution (20180315.post) /Phlog/20180315.post 1436.ninja 70
0On Server Reduction + Vim Tip (20180312a.post) /Phlog/20180312a.post 1436.ninja 70
0Phlog Rewrite - Part the Next (20180312.post) /Phlog/20180312.post 1436.ninja 70
0On my console experiment (20180311.post) /Phlog/20180311.post 1436.ninja 70
0On gopher self-sufficiency and RFCs (20180310a.post) /Phlog/20180310a.post 1436.ninja 70
0On SDF, Also Music (20180310.post) /Phlog/20180310.post 1436.ninja 70
0On the RPoD Phlog Rewrite (20180308b.post) /Phlog/20180308b.post 1436.ninja 70
0On tcsh and more troff (20180308a.post) /Phlog/20180308a.post 1436.ninja 70
0On Redoing My Linux Android Tablet (20180308.post) /Phlog/20180308.post 1436.ninja 70
0On Freetime (20180306a.post) /Phlog/20180306a.post 1436.ninja 70
0On Layout (20180306.post) /Phlog/20180306.post 1436.ninja 70
0On the specialness of gopher (reply to ckeen) (20180305.post) /Phlog/20180305.post 1436.ninja 70
0On the interesting stuff you can learn on gopher (20180304.post) /Phlog/20180304.post 1436.ninja 70
0SDF sticker (20180228.post) /Phlog/20180228.post 1436.ninja 70
0On defeat (20180226.post) /Phlog/20180226.post 1436.ninja 70
0More on music website progress (20180225.post) /Phlog/20180225.post 1436.ninja 70
0On my music website and VPS (20180224.post) /Phlog/20180224.post 1436.ninja 70
0On learning shells (20180222.post) /Phlog/20180222.post 1436.ninja 70
0Reply to Ulcer (20180220.post) /Phlog/20180220.post 1436.ninja 70
0On music and weather (20180219a.post) /Phlog/20180219a.post 1436.ninja 70
0On moku-pona (20180219.post) /Phlog/20180219.post 1436.ninja 70
0Maybe?? (20180217b.post) /Phlog/20180217b.post 1436.ninja 70
0More on SDF listing (20180217a.post) /Phlog/20180217a.post 1436.ninja 70
0On the weekend (20180217.post) /Phlog/20180217.post 1436.ninja 70
0SDF listing update (20180214a.post) /Phlog/20180214a.post 1436.ninja 70
0On the work week (20180214.post) /Phlog/20180214.post 1436.ninja 70
0On SDF phlog listing (20180212a.post) /Phlog/20180212a.post 1436.ninja 70
0On laptop cleanup and the Energy Sector (20180212.post) /Phlog/20180212.post 1436.ninja 70
0On EDC (20180211b.post) /Phlog/20180211b.post 1436.ninja 70
0On catching up (20180211.post) /Phlog/20180211.post 1436.ninja 70
0On the difference of age, or it ain't a big deal (20180129.post) /Phlog/20180129.post 1436.ninja 70
0On project progress (20180127.post) /Phlog/20180127.post 1436.ninja 70
0Computer Inventory (20180121.post) /Phlog/20180121.post 1436.ninja 70
0On Gutenberg... redo (20180120.post) /Phlog/20180120.post 1436.ninja 70
0On hats (20180119.post) /Phlog/20180119.post 1436.ninja 70
0On the Thinkpad project (20180117.post) /Phlog/20180117.post 1436.ninja 70
0On entropy and the randomness of life (20180111.post) /Phlog/20180111.post 1436.ninja 70
0On uptime (20180107.post) /Phlog/20180107.post 1436.ninja 70
0On software (reply to Solderpunk) and laptops (20180106.post) /Phlog/20180106.post 1436.ninja 70
0On the new year and laptop sadness (20180101.post) /Phlog/20180101.post 1436.ninja 70
0On comments (20171230.post) /Phlog/20171230.post 1436.ninja 70
0On phlog replies 20171229 (20171229.post) /Phlog/20171229.post 1436.ninja 70
0On the Raspberry Pi of Anguish (20171226.post) /Phlog/20171226.post 1436.ninja 70
0On capitulation (20171222.post) /Phlog/20171222.post 1436.ninja 70
0On further simplication (20171217.post) /Phlog/20171217.post 1436.ninja 70
0Phlog replies (pet84rik, tfurrows, slugmax, tomasino) (20171216.post) /Phlog/20171216.post 1436.ninja 70
0On a simple pastebin (20171215.post) /Phlog/20171215.post 1436.ninja 70
0On backups (20171211.post) /Phlog/20171211.post 1436.ninja 70
0On my favorite software (20171210.post) /Phlog/20171210.post 1436.ninja 70
0On the beauty of Unix (20171209.post) /Phlog/20171209.post 1436.ninja 70
0Sent to my department on 20171124, a nice write up on imposter syndrome: (20171205b.post) /Phlog/20171205b.post 1436.ninja 70
0On email (part 3) (20171205.post) /Phlog/20171205.post 1436.ninja 70
0On gopher to http proxies (20171204b.post) /Phlog/20171204b.post 1436.ninja 70
0On Arch on Android (20171204.post) /Phlog/20171204.post 1436.ninja 70
0On email UPDATE (20171203.post) /Phlog/20171203.post 1436.ninja 70
0On email (20171202b.post) /Phlog/20171202b.post 1436.ninja 70
0On life enrichment thru lurking (20171202.post) /Phlog/20171202.post 1436.ninja 70
0On the coming new RPi (20171201.post) /Phlog/20171201.post 1436.ninja 70
0On site updating (some more) (20171129.post) /Phlog/20171129.post 1436.ninja 70
0On the between times (20171126.post) /Phlog/20171126.post 1436.ninja 70
0On the past (20171125.post) /Phlog/20171125.post 1436.ninja 70
0On a memory of web past (20171124b.post) /Phlog/20171124b.post 1436.ninja 70
0On some todos for RPoD (20171124.post) /Phlog/20171124.post 1436.ninja 70
0On thanksgiving (20171122.post) /Phlog/20171122.post 1436.ninja 70
0On mobile gopher (20171120.post) /Phlog/20171120.post 1436.ninja 70
0On resonance (20171119.post) /Phlog/20171119.post 1436.ninja 70
0On gopher, lynx, and UTF-8 (20171115.post) /Phlog/20171115.post 1436.ninja 70
0On a ~$65 Linux box (20171113.post) /Phlog/20171113.post 1436.ninja 70
0On the RPoD DocumentStore (20171106.post) /Phlog/20171106.post 1436.ninja 70
0On device (20171104.post) /Phlog/20171104.post 1436.ninja 70
0On music (20171103.post) /Phlog/20171103.post 1436.ninja 70
0On temptation (20171102.post) /Phlog/20171102.post 1436.ninja 70
0On git and gopher (20171029c.post) /Phlog/20171029c.post 1436.ninja 70
0On Politics (20171029b.post) /Phlog/20171029b.post 1436.ninja 70
0On Project Gutenberg (20171029.post) /Phlog/20171029.post 1436.ninja 70
0On electronics and music (20171028.post) /Phlog/20171028.post 1436.ninja 70
0On sustainable hobbies (20171027.post) /Phlog/20171027.post 1436.ninja 70
0On RPoD Phlog (20171026.post) /Phlog/20171026.post 1436.ninja 70
0On technology and personal honesty (20171022.post) /Phlog/20171022.post 1436.ninja 70
0On Asceticism (20171020.post) /Phlog/20171020.post 1436.ninja 70
0On life, Music, PPC, GopherProxy, Kindle (20171014.post) /Phlog/20171014.post 1436.ninja 70
0On Relating (20171008.post) /Phlog/20171008.post 1436.ninja 70
0On gopherbook (20170929b.post) /Phlog/20170929b.post 1436.ninja 70
0On the dream setup (20170929.post) /Phlog/20170929.post 1436.ninja 70
0On Social Networks (20170924.post) /Phlog/20170924.post 1436.ninja 70
0On Archives (20170923.post) /Phlog/20170923.post 1436.ninja 70
0On Git (20170921b.post) /Phlog/20170921b.post 1436.ninja 70
0On GG Alin (20170921.post) /Phlog/20170921.post 1436.ninja 70
0On the Project Gutenberg Gopher Frontend (20170920.post) /Phlog/20170920.post 1436.ninja 70
0On Victories (20170917.post) /Phlog/20170917.post 1436.ninja 70
0On odd forum bugs and laptops (20170910.post) /Phlog/20170910.post 1436.ninja 70
0Dammit (20170909.post) /Phlog/20170909.post 1436.ninja 70
0On the RPoD Gopher Proxy (20170907b.post) /Phlog/20170907b.post 1436.ninja 70
0On email (20170907.post) /Phlog/20170907.post 1436.ninja 70
0On the RPoD Discussion forum (20170902.post) /Phlog/20170902.post 1436.ninja 70
0On Projects (20170830.post) /Phlog/20170830.post 1436.ninja 70
0On searching for content (20170828.post) /Phlog/20170828.post 1436.ninja 70
0On figuring out wifi (20170826b.post) /Phlog/20170826b.post 1436.ninja 70
0Omnibook 800ct Project Update (20170826.post) /Phlog/20170826.post 1436.ninja 70
0More on the Eclipse and Why CSS Ruins the Web (20170821.post) /Phlog/20170821.post 1436.ninja 70
0OmniBook Project Update (20170819.post) /Phlog/20170819.post 1436.ninja 70
0On False-Flag Ops and the Solar Eclipse (20170817.post) /Phlog/20170817.post 1436.ninja 70
0Nostalgia Tripping (20170814.post) /Phlog/20170814.post 1436.ninja 70
0Trampoline park, my music, etc. (20170813.post) /Phlog/20170813.post 1436.ninja 70
0on the rejoining of sdf (20170812.post) /Phlog/20170812.post 1436.ninja 70
0No days off for you (20170810.post) /Phlog/20170810.post 1436.ninja 70
i____________________________________________________________________________ null.host 1
i Gophered by Gophernicus/101 on NetBSD/amd64 8.1_STABLE null.host 1
.

1161
benches/sdf.txt Normal file
View File

File diff suppressed because it is too large Load Diff

192
benches/unix.txt Normal file
View File

@ -0,0 +1,192 @@
i __ ___ _______ __ null.host 1
i / / / / | / / _/ |/ / null.host 1
i / / / / |/ // / | / null.host 1
i/ /_/ / /| // / / | null.host 1
i\____/_/ |_/___//_/|_| null.host 1
i null.host 1
iI love the GNU tools. While GNU might not be UNIX, it's certainly null.host 1
icomparable with UNIX. That makes literature about UNIX relevant null.host 1
ito the GNU tools we use today. There are a lot of GNU-specific null.host 1
imanuals and writing out there, but I still think these books and null.host 1
imemos contain interesting and inspirational writing that is null.host 1
iapplicable today. null.host 1
i null.host 1
i null.host 1
iORIGINS null.host 1
i======= /users/dbucklin/UNIX/======= sdf.org 70
i null.host 1
iDennis M. Ritchie, Ken Thompson, 'The UNIX Time-Sharing System', null.host 1
iAssociation for Computing Machinery, Inc., 1974 null.host 1
i null.host 1
9unix.pdf /users/dbucklin/UNIX/unix.pdf sdf.org 70
i null.host 1
iDennis M. Ritchie, 'The Evolution of the Unix Time-sharing System', null.host 1
iBell Laboratories, Murray Hill, NJ, 1984 null.host 1
i null.host 1
9ritchie84evolution.pdf /users/dbucklin/UNIX/ritchie84evolution.pdf sdf.org 70
i null.host 1
i null.host 1
iARTICLES null.host 1
i======== /users/dbucklin/UNIX/======== sdf.org 70
i null.host 1
iBrian W. Kernighan, 'UNIX for Beginners', Bell Laboratories, null.host 1
iMurray Hill, N. J., 1974 null.host 1
i null.host 1
9beg.pdf /users/dbucklin/UNIX/beg.pdf sdf.org 70
i null.host 1
iRob Pike, Brian W. Kernighan, 'Program design in the UNIX environment' null.host 1
i null.host 1
9unix_prog_design.pdf /users/dbucklin/UNIX/unix_prog_design.pdf sdf.org 70
i null.host 1
iDennis M. Ritchie, 'A Stream Input-Output System', AT&T Bell null.host 1
iLaboratories Technical Journal 63, No. 8 Part 2 (October, 1984), null.host 1
ipp. 1897-1910. null.host 1
i null.host 1
9st.pdf /users/dbucklin/UNIX/st.pdf sdf.org 70
i null.host 1
iM. Douglas McIlroy, 'A Research UNIX Reader: Annotated Excerpts null.host 1
ifrom the Programmer's Manual, 1971-1986' null.host 1
i null.host 1
9reader.pdf /users/dbucklin/UNIX/reader.pdf sdf.org 70
i null.host 1
iJoe Condon, Brian Kernighan, Ken Thompson, 'Experience with the null.host 1
iMergenthaler Linotron 202 Phototypesetter, or, How We Spent Our null.host 1
iSummer Vacation', Bell Laboratories, 1980 null.host 1
i null.host 1
9summer.reconstructed.pdf /users/dbucklin/UNIX/summer.reconstructed.pdf sdf.org 70
i null.host 1
i null.host 1
iUNIX REFERENCE null.host 1
i============== /users/dbucklin/UNIX/============== sdf.org 70
i null.host 1
iBrian W. Kernighan, Rob Pike, 'The UNIX Programming Environment', Prentice-H null.host 1
i null.host 1
9upe.pdf /users/dbucklin/UNIX/upe.pdf sdf.org 70
i null.host 1
iJoseph F. Osanna, Brian W. Kernighan, 'Troff User's Manual', AT&T null.host 1
iBell Laboratories, 1992 null.host 1
i null.host 1
954.pdf /users/dbucklin/UNIX/54.pdf sdf.org 70
i null.host 1
iBrian W. Kernighan, Dennis M. Ritchie, 'C Programming Language, null.host 1
i2nd Edition', Prentice Hall, 1978 null.host 1
i null.host 1
9C Programming Language, 2nd Edition by Brian W. Kernighan, Dennis M. Ritchie.pdf /users/dbucklin/UNIX/C Programming Language, 2nd Edition by Brian W. Kernighan, Dennis M. Ritchie.pdf sdf.org 70
i null.host 1
iAlfred V. Aho, Brian W. Kernighan, Peter J. Weinberger, 'The AWK null.host 1
iProgramming Language', Addison-Wesley, 1988 null.host 1
i null.host 1
9The_AWK_Programming_Language.pdf /users/dbucklin/UNIX/The_AWK_Programming_Language.pdf sdf.org 70
i null.host 1
i'UNIX System V Documentors Workbench Reference Manual', Prentice null.host 1
iHall, 1989 null.host 1
i null.host 1
9UNIX_System_V_Documentors_Workbench_Reference_Manual_1989.pdf /users/dbucklin/UNIX/UNIX_System_V_Documentors_Workbench_Reference_Manual_1989.pdf sdf.org 70
i null.host 1
iDale Dougherty, Tim O'Reilly, 'UNIX Text Processing', Hayden null.host 1
iBooks, 1987 null.host 1
i null.host 1
9utp_book-1.1.pdf /users/dbucklin/UNIX/utp_book-1.1.pdf sdf.org 70
i null.host 1
iK. Thompson, D. M. Ritchie, 'UNIX Programmer's Manual, Fourth null.host 1
iEdition', Bell Telephone Laboratories, Inc., 1973 null.host 1
i null.host 1
9v4man.pdf /users/dbucklin/UNIX/v4man.pdf sdf.org 70
i null.host 1
i'UNIX Programmer's Manual, Seventh Edition, Volume 1', Bell null.host 1
iTelephone Laboratories, Inc., 1979 null.host 1
i null.host 1
9v7vol1.pdf /users/dbucklin/UNIX/v7vol1.pdf sdf.org 70
i null.host 1
i'UNIX Programmer's Manual, Seventh Edition, Volume 2A', Bell null.host 1
iTelephone Laboratories, Inc., 1979 null.host 1
i null.host 1
9v7vol2a.pdf /users/dbucklin/UNIX/v7vol2a.pdf sdf.org 70
i null.host 1
i'UNIX Programmer's Manual, Seventh Edition, Volume 2B', Bell null.host 1
iTelephone Laboratories, Inc., 1979 null.host 1
i null.host 1
9v7vol2b.pdf /users/dbucklin/UNIX/v7vol2b.pdf sdf.org 70
i null.host 1
i null.host 1
iRELATED TOOLS null.host 1
i============= /users/dbucklin/UNIX/============= sdf.org 70
i null.host 1
iMark McDonnell, 'Pro Vim', Apress, 2014 null.host 1
i null.host 1
9Pro Vim.pdf /users/dbucklin/UNIX/Pro Vim.pdf sdf.org 70
i null.host 1
i'Bash Notes for Professionals' null.host 1
i null.host 1
9BashNotesForProfessionals.pdf /users/dbucklin/UNIX/BashNotesForProfessionals.pdf sdf.org 70
i null.host 1
iPeter Schaffter, 'Groff and mom: an overview', 2017 null.host 1
i null.host 1
9groff-and-mom.pdf /users/dbucklin/UNIX/groff-and-mom.pdf sdf.org 70
i null.host 1
iTrent A. Fisher, Werner Lemberg, 'groff: The GNU implementation of null.host 1
itroff', Free Software Foundation, Inc., 2014 null.host 1
i null.host 1
9groff.pdf /users/dbucklin/UNIX/groff.pdf sdf.org 70
i null.host 1
iWilliam Joy, Mark Horton, 'An Introduction to Display Editing with null.host 1
iVi' Computer Science Division, Department of Electrical null.host 1
iEngineering and Computer Science, University of California, null.host 1
iBerkeley null.host 1
i null.host 1
9vi-intro.pdf /users/dbucklin/UNIX/vi-intro.pdf sdf.org 70
i null.host 1
i'help.txt for Vim 7.4', 2016 null.host 1
i null.host 1
9vimhelp.pdf /users/dbucklin/UNIX/vimhelp.pdf sdf.org 70
i null.host 1
iDean Allen Provins, 'The Groff and Friends HOWTO', University of null.host 1
iCalgary, 2001 null.host 1
i null.host 1
9TheGroffFriendsHowto.pdf /users/dbucklin/UNIX/TheGroffFriendsHowto.pdf sdf.org 70
i null.host 1
iClifford E. Rhoades, Jr., 'Roff - A Manuscript Printing Program: null.host 1
iUser's Manual', Air Force Weapons Laboratory, Kirtland Air Force null.host 1
iBase, New Mexico, 1972 null.host 1
i null.host 1
9roff-manual-rhoades-1972.pdf /users/dbucklin/UNIX/roff-manual-rhoades-1972.pdf sdf.org 70
i null.host 1
i null.host 1
iDISSENT null.host 1
i======= /users/dbucklin/UNIX/======= sdf.org 70
i null.host 1
iSimson Garfinkel, Daniel Weise, Steven Straussman, 'The UNIX-Haters null.host 1
iHandbook', IDG Books Worldwide, Inc., 1994 null.host 1
i null.host 1
9ugh.pdf /users/dbucklin/UNIX/ugh.pdf sdf.org 70
i null.host 1
i null.host 1
iHARDCOPY null.host 1
i======== /users/dbucklin/UNIX/======== sdf.org 70
i null.host 1
iAlfred V. Aho, Brian W. Kernighan, Peter J. Weinberger, 'The AWK null.host 1
iProgramming Language', Addison-Wesley Publishing Company, 1988 null.host 1
i null.host 1
iArnold Robbins, 'Effective awk Programming', O'Reilly Media Inc., null.host 1
i2015 null.host 1
i null.host 1
iB. Srinivasan, 'Unix Document Processing and Typesetting', World null.host 1
iScientific Publishing Co., 1993 null.host 1
i null.host 1
iBrian Kernighan, P. J. Plauger, 'Software Tools', Addison-Wesley null.host 1
iPublishing Company, 1976 null.host 1
i null.host 1
iEric Raymond, 'The Art of Unix Programming' ,Addison-Wesley Publishing null.host 1
iCompany, 2004 null.host 1
i null.host 1
iNarain Gehani, 'Document Formatting and Typesetting on the UNIX null.host 1
iSystem', Silicon Press, 1987 null.host 1
i null.host 1
iNarain Gehani, Steven Lally, 'Document Formatting and Typesetting null.host 1
ion the UNIX System Volume II', Silicon Press, 1988 null.host 1
i null.host 1
iPeter H. Salus, 'A Quarter Century of UNIX', Addison-Wesley Publishing null.host 1
iCompany, 1994 null.host 1
i null.host 1
.

1
src/text.rs
View File

@ -173,6 +173,7 @@ impl Text {
pub fn from(url: &str, response: String, config: &Config, tls: bool) -> Text {
let mut lines = 0;
let mut longest = 0;
for line in response.split_terminator('\n') {
lines += 1;
let count = line.chars().count();