Skip to content

GitLab

Commit a933dad1 authored by Dave Love's avatar Dave Love
Browse files

#

parent a7bfd66f
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 22225 additions and 0 deletions
etc/3B-MAXMEM 0 → 100644
View file @ a933dad1
Date: Mon, 16 Feb 87 15:04:41 EST
From: katinsky@gauss.rutgers.edu (David Katinsky)
To: rms@prep.ai.mit.edu
Subject: 3b2 procedure to raise MAXMEM
Below is the procedure I followed to allow enough memory for GnuEmacs to run
on my 3b2/400. The end result of this is that a process can snarf up to 2Mb
of memory. This can be a bit dangerous on a 2Mb machine, but I tried it and
it worked ok.
-------------------------------------------------------------------------------
In the simplest case, these are the procedures to reconfigure a 3bx kernel.
1] cd /etc/master.d
`ls` shows the files to be:
README ctc* hdelog idisk ipc iuart kernel mau
mem msg ports* prf sem shm stubs sxt
sys xt
2] Edit the file which contains the parameter[s] you wish to change.
In the following excerpt from /etc/master.d/kernel the value MAXMEM
was raised from 256 to 1024.
In V.3.0 and later releases, the parameter in question is MAXUMEM
instead of MAXMEM.
*
* The following entries form the tunable parameter table.
*
NCALL = 30
NPROC = 60
NTEXT = 58
NCLIST = 188
* maxmem is number of pages (2K) was 256 --dmk
MAXMEM = 1024
MAXUP = 25
* hashbuf must be a power of 2
NHBUF = 128
NPBUF = 8
3] cd /boot
4] mkboot -k KERNEL
5] shutdown -i5 -g0 -y
This will take the machine down and bring it back up into firmware
mode. When you see that the machine has reached this state, type the
firmware password (default=mcp). The machine will ask for the name of
a program to execute. At this prompt enter /etc/system . The machine
should start to boot and display its configuration data.
8701271222 dmk
[katinsky@topaz.rutgers.edu]
-------------------------------------------------------------------------------
I do not feel that having the default firmware password is a
problem... but if you wish to edit it out, feel free.
dmk

etc/AIX.DUMP 0 → 100644
View file @ a933dad1
The following text was written by someone at IBM to describe an older
version of the code for dumping on AIX. It does NOT apply to
the current version of Emacs. It is included in case someone
is curious.
I (rms) couldn't understand the code, and I can't fully understand
this text either. I rewrote the code to use the same basic
principles, as far as I understood them, but more cleanly. This
rewritten code does not always work. In fact, the basic method
seems to be intrinsically flawed.
Since then, someone else implemented a different way of dumping on
the RS/6000, which does seem to work. None of the following
applies to the way Emacs now dumps on the 6000. However, the
current method fails to use shared libraries. Anyone who might be
interested in trying to resurrect the previous method might still
find the following information useful.
It seems that the IBM dumping code was simply set up to detect when
the dumped data cannot be used, and in that case to act approximately
as if CANNOT_DUMP had been defined all along. (This is buried in
paragraph 1.) It seems simpler just to define CANNOT_DUMP, since
Emacs is not set up to decide at run time whether there is dumping or
not, and doing so correctly would be a lot of work.
Note that much of the other information, such as the name and format
of the dumped data file, has been changed.
--rms
A different approach has been taken to implement the
"dump/load" feature of GNU Emacs for AIX 3.1. Traditionally the
unexec function creates a new a.out executable file which contains
preloaded Lisp code. Executing the new a.out file (normally called
xemacs) provides rapid startup since the standard suite of Lisp code
is preloaded as part of the executable file.
AIX 3.1 architecture precludes the use of this technique
because the dynamic loader cannot guarantee a fixed starting location
for the process data section. The loader loads all shared library
data BEFORE process data. When a shared library changes its data
space, the process initial data section address (_data) will change
and all global process variables are automatically relocated to new
addresses. This invalidates the "dumped" Emacs executable which has
data addresses which are not relocatable and now corrupt. Emacs would
fail to execute until rebuilt with the new libraries.
To circumvent the dynamic loader feature of AIX 3.1, the dump process
has been modified as follows:
1) A new executable file is NOT created. Instead, both pure and
impure data are saved by the dump function and automatically
reloaded during process initialization. If any of the saved data
is unavailable or invalid, loadup.el will be automatically loaded.
2) Pure data is defined as a shared memory segment and attached
automatically as read-only data during initialization. This
allows the pure data to be a shared resource among all Emacs
processes. The shared memory segment size is PURESIZE bytes.
If the shared memory segment is unavailable or invalid, a new
shared memory segment is created and the impure data save file
is destroyed, forcing loadup.el to be reloaded.
3) The ipc key used to create and access Emacs shared memory is
SHMKEY and can be overridden by the environment symbol EMACSSHMKEY.
Only one ipc key is allowed per system. The environment symbol
is provided in case the default ipc key has already been used.
4) Impure data is written to the ../bin/.emacs.data file by the
dump function. This file contains the process' impure data
at the moment of load completion. During Emacs initialization,
the process' data section is expanded and overwritten
with the .emacs.data file contents.
The following are software notes concerning the GNU Emacs dump function under AIX 3.1:
1) All of the new dump/load code is activated by the #ifdef SHMKEY
conditional.
2) The automatic loading of loadup.el does NOT cause the dump function
to be performed. Therefore once the pure/impure data is discarded,
someone must remake Emacs to create the saved data files. This
should only be necessary when Emacs is first installed or whenever
AIX is upgraded.
3) Emacs will exit with an error if executed in a non-X environment
and the dump function was performed within a X window. Therefore
the dump function should always be performed in a non-X
environment unless the X environment will ALWAYS be available.
4) Emacs only maintains the lower 24 bits of any data address. The
remaining upper 8 bits are reset by the XPNTR macro whenever any
Lisp object is referenced. This poses a serious problem because
pure data is stored in segment 3 (shared memory) and impure data
is stored in segment 2 (data). To reset the upper 8 address bits
correctly, XPNTR must guess as to which type of data is represented
by the lower 24 address bits. The technique chosen is based upon
the fact that pure data offsets in segment 3 range from
0 -> PURESIZE-1, which are relatively small offsets. Impure data
offsets in segment 2 are relatively large (> 0x40000) because they
must follow all shared library data. Therefore XPNTR adds segment
3 to each data offset which is small (below PURESIZE) and adds
segment 2 to all other offsets. This algorithm will remain valid
as long as a) pure data size remains relatively small and b) process
data is loaded after shared library data.
To eliminate this guessing game, Emacs must preserve the 32-bit
address and add additional data object overhead for the object type
and garbage collection mark bit.
5) The data section written to .emacs.data is divided into three
areas as shown below. The file header contains four character
pointers which are used during automatic data loading. The file's
contents will only be used if the first three addresses match
their counterparts in the current process. The fourth address is
the new data segment address required to hold all of the preloaded
data.
.emacs.data file format
+---------------------------------------+ \
| address of _data | \
+---------------------------------------+ \
| address of _end | \
+---------------------------------------+ file header
| address of initial sbrk(0) | /
+---------------------------------------+ /
| address of final sbrk(0) | /
+---------------------------------------+ /
\ \
\ \
all data to be loaded from
_data to _end
\ \
\ \
+---------------------------------------+
\ \
\ \
all data to be loaded from
initial to final sbrk(0)
\ \
+---------------------------------------+
Sections two and three contain the preloaded data which is
restored at locations _data and initial sbrk(0) respectively.
The reason two separate sections are needed is that process
initialization allocates data (via malloc) prior to main()
being called. Therefore _end is several kbytes lower than
the address returned by an initial sbrk(0). This creates a
hole in the process data space and malloc will abort if this
region is overwritten during the load function.
One further complication with the malloc'd space is that it
is partially empty and must be "consumed" so that data space
malloc'd in the future is not assigned to this region. The malloc
function distributed with Emacs anticipates this problem but the
AIX 3.1 version does not. Therefore, repeated malloc calls are
needed to exhaust this initial malloc space. How do you know
when malloc has exhausted its free memory? You don't! So the
code must repeatedly call malloc for each buffer size and
detect when a new memory page has been allocated. Once the new
memory page is allocated, you can calculate the number of free
buffers in that page and request exactly that many more. Future
malloc requests will now be added at the top of a new memory page.
One final point - the initial sbrk(0) is the value of sbrk(0)
after all of the above malloc hacking has been performed.
The following Emacs dump/load issues need to be addressed:
1) Loadup.el exits with an error message because the xemacs and
emacs-xxx files are not created during the dump function.
Loadup.el should be changed to check for the new .emacs.data
file.
2) Dump will only support one .emacs.data file for the entire
system. This precludes the ability to allow each user to
define his/her own "dumped" Emacs.
Add an environment symbol to override the default .emacs.data
path.
3) An error message "error in init file" is displayed out of
startup.el when the dumped Emacs is invoked by a non-root user.
Although all of the preloaded Lisp code is present, the important
purify-flag has not been set back to Qnil - precluding the
loading of any further Lisp code until the flag is manually
reset.
The problem appears to be an access violation which will go
away if the read-write access modes to all of the files are
changed to rw-.
4) In general, all file access modes should be changed from
rw-r--r-- to rw-rw-rw-. They are currently setup to match
standard AIX access modes.
5) The dump function is not invoked when the automatic load of
loadup.el is performed.
Perhaps the command arguments array should be expanded with
"dump" added to force an automatic dump.
6) The automatic initialization function alloc_shm will delete
the shared memory segment and .emacs.data file if the "dump"
command argument is found in ANY argument position. The
dump function will only take place in loadup.el if "dump"
is the third or fourth command argument.
Change alloc_shm to live by loadup.el rules.
etc/BABYL 0 → 100644
View file @ a933dad1
Format of Version 5 Babyl Files:
Warning:
This was written Tuesday, 12 April 1983 (by Eugene Ciccarelli),
based on looking at a particular Babyl file and recalling various
issues. Therefore it is not guaranteed to be complete, but it is a
start, and I will try to point the reader to various Babyl functions
that will serve to clarify certain format questions.
Also note that this file will not contain control-characters,
but instead have two-character sequences starting with Uparrow.
Unless otherwise stated, an Uparrow <character> is to be read as
Control-<character>, e.g. ^L is a Control-L.
Versions:
First, note that each Babyl file contains in its BABYL OPTIONS
section the version for the Babyl file format. In principle, the
format can be changed in any way as long as we increment the format
version number; then programs can support both old and new formats.
In practice, version 5 is the only format version used, and the
previous versions have been obsolete for so long that Emacs does not
support them.
Overall Babyl File Structure:
A Babyl file consists of a BABYL OPTIONS section followed by
0 or more message sections. The BABYL OPTIONS section starts
with the line "BABYL OPTIONS:". Message sections start with
Control-Underscore Control-L Newline. Each section ends
with a Control-Underscore. (That is also the first character
of the starter for the next section, if any.) Thus, a three
message Babyl file looks like:
BABYL OPTIONS:
...the stuff within the Babyl Options section...
^_^L
...the stuff within the 1st message section...
^_^L
...the stuff within the 2nd message section...
^_^L
...the stuff within the last message section...
^_
Babyl is tolerant about some whitespace at the end of the
file -- the file may end with the final ^_ or it may have some
whitespace, e.g. a newline, after it.
The BABYL OPTIONS Section:
Each Babyl option is specified on one line (thus restricting
string values these options can currently have). Values are
either numbers or strings. The format is name, colon, and the
value, with whitespace after the colon ignored, e.g.:
Mail: ~/special-inbox
Unrecognized options are ignored.
Here are those options and the kind of values currently expected:
MAIL Filename, the input mail file for this
Babyl file. You may also use several file names
separated by commas.
Version Number. This should always be 5.
Labels String, list of labels, separated by commas.
Message Sections:
A message section contains one message and information
associated with it. The first line is the "status line", which
contains a bit (0 or 1 character) saying whether the message has
been reformed yet, and a list of the labels attached to this
message. Certain labels, called basic labels, are built into
Babyl in a fundamental way, and are separated in the status line
for convenience of operation. For example, consider the status
line:
1, answered,, zval, bug,
The 1 means this message has been reformed. This message is
labeled "answered", "zval", and "bug". The first, "answered", is
a basic label, and the other two are user labels. The basic
labels come before the double-comma in the line. Each label is
preceded by ", " and followed by ",". (The last basic label is
in fact followed by ",,".) If this message had no labels at all,
it would look like:
1,,
Or, if it had two basic labels, "answered" and "deleted", it
would look like:
1, answered, deleted,, zval, bug,
The & Label Babyl Message knows which are the basic labels.
Currently they are: deleted, unseen, recent, and answered.
After the status line comes the original header if any.
Following that is the EOOH line, which contains exactly the
characters "*** EOOH ***" (which stands for "end of original
header"). Note that the original header, if a network format
header, includes the trailing newline. And finally, following the
EOOH line is the visible message, header and text. For example,
here is a complete message section, starting with the message
starter, and ending with the terminator:
^_^L
1,, wordab, eccmacs,
Date: 11 May 1982 21:40-EDT
From: Eugene C. Ciccarelli <ECC at MIT-AI>
Subject: notes
To: ECC at MIT-AI
*** EOOH ***
Date: Tuesday, 11 May 1982 21:40-EDT
From: Eugene C. Ciccarelli <ECC>
To: ECC
Re: notes
Remember to pickup check at cashier's office, and deposit it
soon. Pay rent.
^_
;;; Babyl File BNF:
;;; Overall Babyl file structure:
Babyl-File ::= Babyl-Options-Section (Message-Section)*
;;; Babyl Options section:
Babyl-Options-Section
::= "BABYL OPTIONS:" newline (Babyl-Option)* Terminator
Babyl-Option ::= Option-Name ":" Horiz-Whitespace BOptValue newline
BOptValue ::= Number | 1-Line-String
;;; Message section:
Message-Section ::= Message-Starter Status-Line Orig-Header
EOOH-Line Message Terminator
Message-Starter ::= "^L" newline
Status-Line ::= Bit-Char "," (Basic-Label)* "," (User-Label)* newline
Basic-Label ::= Space BLabel-Name ","
User-Label ::= Space ULabel-Name ","
EOOH-Line ::= "*** EOOH ***" newline
Message ::= Visible-Header Message-Text
;;; Utilities:
Terminator ::= "^_"
Horiz-Whitespace
::= (Space | Tab)*
Bit-Char ::= "0" | "1"
etc/CENSORSHIP 0 → 100644
View file @ a933dad1
Censoring my Software
Richard Stallman
[From Datamation, 1 March 1996]
Last summer, a few clever legislators proposed a bill to "prohibit
pornography" on the Internet. Last fall, right-wing Christians made
this cause their own. Last week, President Clinton signed the bill,
and we lost the freedom of the press for the public library of the
future. This week, I'm censoring GNU Emacs.
No, GNU Emacs does not contain pornography. It is a software package,
an award-winning extensible and programmable text editor. But the law
that was passed applies to far more than pornography. It prohibits
"indecent" speech, which can include anything from famous poems, to
masterpieces hanging in the Louvre, to advice about safe sex...to
software.
Naturally, there was a lot of opposition to this bill. Not only from
people who use the Internet, and people who appreciate erotica, but
from everyone who cares about freedom of the press.
But every time we tried to tell the public what was at stake, the
forces of censorship responded with a lie: they told the public that
the issue was simply pornography. By embedding this lie as a
presupposition in their statements about the issue, they succeeded in
misinforming the public. So here I am, censoring my software.
You see, Emacs contains a version of the famous "doctor program",
a.k.a. Eliza, originally developed by Professor Weizenbaum at MIT.
This is the program that imitates a Rogerian psychotherapist. The
user talks to the program, and the program responds--by playing back
the user's own statements, and by recognizing a long list of
particular words.
The Emacs doctor program was set up to recognize many common curse
words, and respond with an appropriately cute message such as, "Would
you please watch your tongue?" or "Let's not be vulgar." In order to
do this, it had to have a list of curse words. That means the source
code for the program was indecent.
Because of the censorship law, I had to remove this feature. (I
replaced it with a message announcing that the program has been
censored for your protection.) The new version of the doctor doesn't
recognize the indecent words. If you curse at it, it curses right
back to you--for lack of knowing better.
Now that people are facing the threat of two years in prison for
indecent network postings, it would be helpful if they could access
precise rules via the Internet for how to avoid imprisonment.
However, this is impossible. The rules would have to mention the
forbidden words, so posting them on the Internet would be against the
rules.
Of course, I'm making an assumption about just what "indecent" means.
I have to do this, because nobody knows for sure. The most obvious
possibile meaning is the meaning it has for television, so I'm using
that as a tentative assumption. However, there is a good chance that
our courts will reject that interpretation of the law as
unconstitutional.
We can hope that the courts will recognize the Internet as a medium of
publication like books and magazines. If they do, they will entirely
reject any law prohibiting "indecent" publications on the Internet.
What really worries me is that the courts might take a muddled
in-between escape route--by choosing another interpretation of
"indecent", one that permits the doctor program or a statement of the
decency rules, but prohibits some of the books that children can
browse through in the public library and the bookstore. Over the
years, as the Internet replaces the public library and the bookstore,
some of our freedom of the press will be lost.
Just a few weeks ago, another country imposed censorship on the
Internet. That was China. We don't think well of China in this
country--its government doesn't respect basic freedoms. But how well
does our government respect them? And do you care enough to preserve
them here?
If you care, stay in touch with the Voters Telecommunications Watch.
Look in their Web site http://www.vtw.org/ for background information
and political action recommendations. Censorship won in February, but
we can beat it in November.
Copyright 1996 Richard Stallman
Verbatim copying and distribution is permitted in any medium
provided this notice is preserved.
etc/CHARSETS 0 → 100644
View file @ a933dad1
#########################
## LIST OF CHARSETS
## Each line corresponds to one charset.
## The following attributes are listed in this order
## separated by a colon `:' in one line.
## CHARSET-SYMBOL-NAME,
## CHARSET-ID,
## DIMENSION (1 or 2)
## CHARS (94 or 96)
## BYTES (of multibyte form: 1, 2, 3, or 4),
## WIDTH (occupied column numbers: 1 or 2),
## DIRECTION (0:left-to-right, 1:right-to-left),
## ISO-FINAL-CHAR (character code of ISO-2022's final character)
## ISO-GRAPHIC-PLANE (ISO-2022's graphic plane, 0:GL, 1:GR)
## DESCRIPTION (describing string of the charset)
tibetan-1-column:241:2:94:4:1:0:56:0:Tibetan 1 column glyph
tibetan:252:2:94:4:2:0:55:0:Tibetan characters
lao:167:1:94:3:1:0:49:0:Lao characters (ISO10646 0E80..0EDF)
indian-1-column:240:2:94:4:1:0:54:0:Indian charset for 2-column width glypps
indian-2-column:251:2:94:4:2:0:53:0:Indian charset for 2-column width glyphs
indian-is13194:225:1:94:3:2:0:53:1:Generic Indian charset for data exchange with IS 13194
ascii-right-to-left:166:1:94:3:1:1:66:0:ASCII (left half of ISO8859-1) with right-to-left direction
chinese-cns11643-7:250:2:94:4:2:0:77:0:CNS11643 Plane 7 Chinese Traditional
chinese-cns11643-6:249:2:94:4:2:0:76:0:CNS11643 Plane 6 Chinese Traditional
chinese-cns11643-5:248:2:94:4:2:0:75:0:CNS11643 Plane 5 Chinese Traditional
chinese-cns11643-4:247:2:94:4:2:0:74:0:CNS11643 Plane 4 Chinese Traditional
chinese-cns11643-3:246:2:94:4:2:0:73:0:CNS11643 Plane 3 Chinese Traditional
ethiopic:245:2:94:4:2:0:51:0:Ethiopic characters
arabic-2-column:224:1:94:3:2:1:52:0:Arabic 2-column
arabic-1-column:165:1:94:3:1:1:51:0:Arabic 1-column
arabic-digit:164:1:94:3:1:0:50:0:Arabic digit
vietnamese-viscii-upper:163:1:96:3:1:0:50:1:VISCII1.1 upper-case
vietnamese-viscii-lower:162:1:96:3:1:0:49:1:VISCII1.1 lower-case
ipa:161:1:96:3:1:0:48:1:IPA (International Phonetic Association)
chinese-sisheng:160:1:94:3:1:0:48:0:SiSheng characters for PinYin/ZhuYin
chinese-big5-2:153:2:94:3:2:0:49:0:Big5 Level-2 Chinese traditional
chinese-big5-1:152:2:94:3:2:0:48:0:Big5 Level-1 Chinese traditional
chinese-cns11643-2:150:2:94:3:2:0:72:0:CNS11643 Plane 2 Chinese traditional
chinese-cns11643-1:149:2:94:3:2:0:71:0:CNS11643 Plane 1 Chinese traditional
japanese-jisx0212:148:2:94:3:2:0:68:0:JISX0212 Japanese supplement
korean-ksc5601:147:2:94:3:2:0:67:0:KSC5601 Korean Hangul and Hanja
japanese-jisx0208:146:2:94:3:2:0:66:0:JISX0208.1983/1990 Japanese Kanji
chinese-gb2312:145:2:94:3:2:0:65:0:GB2312 Chinese simplified
japanese-jisx0208-1978:144:2:94:3:2:0:64:0:JISX0208.1978 Japanese Kanji (so called "old JIS")
latin-iso8859-9:141:1:96:2:1:0:77:1:ISO8859-9 (Latin-5)
cyrillic-iso8859-5:140:1:96:2:1:0:76:1:ISO8859-5 (Cyrillic)
latin-jisx0201:138:1:94:2:1:0:74:0:JISX0201.1976 Japanese Roman
katakana-jisx0201:137:1:94:2:1:0:73:1:JISX0201.1976 Japanese Kana
hebrew-iso8859-8:136:1:96:2:1:1:72:1:ISO8859-8 (Hebrew)
arabic-iso8859-6:135:1:96:2:1:1:71:1:ISO8859-6 (Arabic)
greek-iso8859-7:134:1:96:2:1:0:70:1:ISO8859-7 (Greek)
thai-tis620:133:1:96:2:1:0:84:1:TIS620.2529 (Thai)
latin-iso8859-4:132:1:96:2:1:0:68:1:ISO8859-4 (Latin-4)
latin-iso8859-3:131:1:96:2:1:0:67:1:ISO8859-3 (Latin-3)
latin-iso8859-2:130:1:96:2:1:0:66:1:ISO8859-2 (Latin-2)
latin-iso8859-1:129:1:96:2:1:0:65:1:ISO8859-1 (Latin-1)
ascii:000:1:94:1:1:0:66:0:ASCII (ISO646 IRV)
etc/CODINGS 0 → 100644
View file @ a933dad1
#########################
## LIST OF CODING SYSTEMS
## Each line corresponds to one coding system
## Format of a line is:
## NAME:TYPE:MNEMONIC:EOL:FLAGS:DOCSTRING,
## where
## TYPE = nil (no conversion), t (auto conversion),
## 0 (Mule internal), 1 (SJIS), 2 (ISO2022), 3 (BIG5), or 4 (CCL)
## EOL = 0 (LF), 1 (CRLF), 2 (CR), or 3 (Automatic detection)
## FLAGS =
## if TYPE = 2 then
## comma (`,') separated data of the followings:
## G0, G1, G2, G3, SHORT-FORM, ASCII-EOL, ASCII-CNTL, SEVEN,
## LOCKING-SHIFT, SINGLE-SHIFT, USE-ROMAN, USE-OLDJIS, NO-ISO6429
## else if TYPE = 4 then
## comma (`,') separated CCL programs for read and write
## else
## 0
##
no-conversion:nil:=:0:0:Do no conversion
undecided:t:+:3:0:Detect coding-system automatically
hz:0:z:3:0:Codins-system of Hz/ZW used for Chinese (GB).
emacs-mule:0:=:3:0:Internal coding system used in a buffer.
shift_jis:1:S:3:0:Coding-system of Shift-JIS used in Japan.
sjis:1:S:3:0:Coding-system of Shift-JIS used in Japan.
euc-japan-1990:2:E:3:ascii,japanese-jisx0208,katakana-jisx0201,japanese-jisx0212,1,1,1,0,0,1,0,0,0:Coding-system of Japanese EUC (Extended Unix Code).
iso-2022-lock:2:i:3:(ascii,t),-2,-1,-1,0,1,1,1,0,0,0,0,0:ISO-2022 coding system using Locking-Shift for 96-charset.
iso-2022-ss2-7:2:I:3:(ascii,t),-1,-2,-1,1,1,1,1,0,1,0,0,0:ISO-2022 coding system using SS2 for 96-charset in 7-bit code.
iso-2022-ss2-8:2:I:3:(ascii,t),-1,-2,-1,0,1,1,0,0,1,0,0,0:ISO-2022 coding system using SS2 for 96-charset in 8-bit code.