before continuing execution. When you create an asynchronous
subprocess, it can run in parallel with the Lisp program. This kind of
subprocess is represented within Emacs by a Lisp object which is also
-called a ``process''. Lisp programs can use this object to communicate
+called a ``process.'' Lisp programs can use this object to communicate
with the subprocess or to control it. For example, you can send
signals, obtain status information, receive output from the process, or
send input to it.
@end defun
@defun process-running-child-p process
-@tindex process-running-child-p process
This function will tell you whether a subprocess has given control of
its terminal to its own child process. The value is @code{t} if this is
true, or if Emacs cannot tell; it is @code{nil} if Emacs can be certain
The argument @var{seconds} need not be an integer. If it is a floating
point number, this function waits for a fractional number of seconds.
+If @var{seconds} is 0, the function accepts whatever output is
+pending but does not wait.
@c Emacs 22.1 feature
If @var{process} is a process, and the argument @var{just-this-one} is
exiting and thus killing that process. The default for the query flag
is @code{t}, meaning @emph{do} query.
-@tindex process-query-on-exit-flag
@defun process-query-on-exit-flag process
This returns the query flag of @var{process}.
@end defun
-@tindex set-process-query-on-exit-flag
@defun set-process-query-on-exit-flag process flag
This function sets the query flag of @var{process} to @var{flag}. It
returns @var{flag}.
machine.
@end defun
-@defun tq-enqueue queue question regexp closure fn
+@defun tq-enqueue queue question regexp closure fn &optional delay-question
This function sends a transaction to queue @var{queue}. Specifying the
queue has the effect of specifying the subprocess to talk to.
text at the end of the entire answer, but nothing before; that's how
@code{tq-enqueue} determines where the answer ends.
+If the argument @var{delay-question} is non-nil, delay sending this
+question until the process has finished replying to any previous
+questions. This produces more reliable results with some processes.
+
The return value of @code{tq-enqueue} itself is not meaningful.
@end defun
@code{make-network-process}.
@menu
-* Make Network:: Using @code{make-network-process}.
-* Network Options:: Further control over network connections.
-* Network Feature Testing:: Determining which network features work on
+* Proc: Network Processes. Using @code{make-network-process}.
+* Options: Network Options. Further control over network connections.
+* Features: Network Feature Testing.
+ Determining which network features work on
the machine you are using.
@end menu
-@node Make Network
+@node Network Processes
@subsection @code{make-network-process}
The basic function for creating network connections and network
@item :host @var{host}
Specify the host to connect to. @var{host} should be a host name or
-internet address, as a string, or the symbol @code{local} to specify
+Internet address, as a string, or the symbol @code{local} to specify
the local host. If you specify @var{host} for a server, it must
specify a valid address for the local host, and only clients
connecting to that address will be accepted.
@item (:type datagram)
Non-@code{nil} if datagrams are supported.
@item (:family local)
-Non-@code{nil} if local (aka ``UNIX domain'') sockets are supported.
+Non-@code{nil} if local (a.k.a.@: ``UNIX domain'') sockets are supported.
@item (:family ipv6)
Non-@code{nil} if IPv6 is supported.
@item (:service t)
@table @var
@item addr
-The internet protocol address.
+The Internet protocol address.
@item bcast
The broadcast address.
@item netmask
To control unpacking and packing, you write a @dfn{data layout
specification}, a special nested list describing named and typed
@dfn{fields}. This specification controls length of each field to be
-processed, and how to pack or unpack it.
+processed, and how to pack or unpack it. We normally keep bindat specs
+in variables whose names end in @samp{-bindat-spec}; that kind of name
+is automatically recognized as ``risky.''
@cindex endianness
@cindex big endian
that the field represents and, in the case of multibyte fields, how
the bytes are ordered within the field. The two possible orderings
are ``big endian'' (also known as ``network byte ordering'') and
-``little endian''. For instance, the number @code{#x23cd} (decimal
+``little endian.'' For instance, the number @code{#x23cd} (decimal
9165) in big endian would be the two bytes @code{#x23} @code{#xcd};
and in little endian, @code{#xcd} @code{#x23}. Here are the possible
type values:
@var{form} can access and update these dynamically bound variables:
@table @code
-@item raw-data
+@item bindat-raw
The data as a byte array.
-@item pos
-Current position of the unpacking or packing operation.
+@item bindat-idx
+Current index into bindat-raw of the unpacking or packing operation.
@item struct
Alist.
@var{tag} matches unconditionally if it is @code{t}.
@end itemize
-@item repeat @var{count} @var{field-spec}@dots{}
-@var{count} may be an integer, or a list of one element naming a
-previous field. For correct operation, each @var{field-spec} must
-include a name.
-@c ??? What does it MEAN?
+@item repeat @var{count} @var{field-specs}@dots{}
+Process the @var{field-specs} recursively, in order, then repeat
+starting from the first one, processing all the specs @var{count}
+times overall. @var{count} may be an integer, or a list of one
+element that names a previous field. For correct operation, each spec
+in @var{field-specs} must include a name.
@end table
@node Bindat Functions
@subsection Functions to Unpack and Pack Bytes
In the following documentation, @var{spec} refers to a data layout
-specification, @code{raw-data} to a byte array, and @var{struct} to an
+specification, @code{bindat-raw} to a byte array, and @var{struct} to an
alist representing unpacked field data.
-@defun bindat-unpack spec raw-data &optional pos
-This function unpacks data from the byte array @code{raw-data}
+@defun bindat-unpack spec bindat-raw &optional bindat-idx
+This function unpacks data from the unibyte string or byte
+array @code{bindat-raw}
according to @var{spec}. Normally this starts unpacking at the
-beginning of the byte array, but if @var{pos} is non-@code{nil}, it
+beginning of the byte array, but if @var{bindat-idx} is non-@code{nil}, it
specifies a zero-based starting position to use instead.
The value is an alist or nested alist in which each element describes
@code{a}. (This corresponds to @code{struct.a.b[2].c} in C.)
@end defun
+ Although packing and unpacking operations change the organization of
+data (in memory), they preserve the data's @dfn{total length}, which is
+the sum of all the fields' lengths, in bytes. This value is not
+generally inherent in either the specification or alist alone; instead,
+both pieces of information contribute to its calculation. Likewise, the
+length of a string or array being unpacked may be longer than the data's
+total length as described by the specification.
+
@defun bindat-length spec struct
-@c ??? I don't understand this at all -- rms
-This function returns the length in bytes of @var{struct}, according
-to @var{spec}.
+This function returns the total length of the data in @var{struct},
+according to @var{spec}.
@end defun
-@defun bindat-pack spec struct &optional raw-data pos
+@defun bindat-pack spec struct &optional bindat-raw bindat-idx
This function returns a byte array packed according to @var{spec} from
the data in the alist @var{struct}. Normally it creates and fills a
-new byte array starting at the beginning. However, if @var{raw-data}
-is non-@code{nil}, it specifies a pre-allocated string or vector to
-pack into. If @var{pos} is non-@code{nil}, it specifies the starting
-offset for packing into @code{raw-data}.
+new byte array starting at the beginning. However, if @var{bindat-raw}
+is non-@code{nil}, it specifies a pre-allocated unibyte string or vector to
+pack into. If @var{bindat-idx} is non-@code{nil}, it specifies the starting
+offset for packing into @code{bindat-raw}.
-@c ??? Isn't this a bug? Shouldn't it always be unibyte?
-Note: The result is a multibyte string; use @code{string-make-unibyte}
-on it to make it unibyte if necessary.
+When pre-allocating, you should make sure @code{(length @var{bindat-raw})}
+meets or exceeds the total length to avoid an out-of-range error.
@end defun
@defun bindat-ip-to-string ip
(with-temp-buffer
(set-buffer-multibyte nil)
(insert
- (string-make-unibyte
- (bindat-pack
- fcookie-index-spec
- `((:version . 2)
- (:count . ,count)
- (:longest . ,max)
- (:shortest . ,min)
- (:flags . 0)
- (:delim . ,delim)
- (:offset . ,(mapcar (lambda (o)
- (list (cons :foo o)))
- (nreverse offsets)))))))
+ (bindat-pack
+ fcookie-index-spec
+ `((:version . 2)
+ (:count . ,count)
+ (:longest . ,max)
+ (:shortest . ,min)
+ (:flags . 0)
+ (:delim . ,delim)
+ (:offset . ,(mapcar (lambda (o)
+ (list (cons :foo o)))
+ (nreverse offsets))))))
(let ((coding-system-for-write 'raw-text-unix))
(write-file (or index (concat cookies ".dat")))))))
@end lisp