GNU bug report logs - #54718
28.0.92; rcirc channel-vs-log buffer confusion

Previous Next

Package: emacs;

Reported by: Ken Raeburn <raeburn <at> redhat.com>

Date: Mon, 4 Apr 2022 22:35:01 UTC

Severity: normal

Tags: moreinfo, patch

Found in version 28.0.92

Done: Philip Kaludercic <philipk <at> posteo.net>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54718 in the body.
You can then email your comments to 54718 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Mon, 04 Apr 2022 22:35:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ken Raeburn <raeburn <at> redhat.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 04 Apr 2022 22:35:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> redhat.com>
To: bug-gnu-emacs <at> gnu.org
Cc: philipk <at> posteo.net
Subject: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Mon, 04 Apr 2022 18:34:37 -0400
I’m using rcirc, and have logging turned on.   When I started up 
rcirc, I already had one of the log files 
(~/.emacs.d/rcirc-log/#gnucash <at> irc.gnome.org) being viewed in a 
buffer. That buffer, sensibly enough, was named 
“#gnucash <at> irc.gnome.org”.   Once rcirc connected to irc.gnome.org, 
and joined my channels, it looked for a buffer named 
“#gnucash <at> irc.gnome.org”, assumed that that was its own buffer for 
showing channel messages, switched it to rcirc mode, and started 
adding to it. So now, the buffer starts off: 

   2022-04-04T18:01:18 *** raeburn JOIN
   2022-04-04T18:01:18 *** ChanServ MODE +v raeburn
   2022-04-04T18:01:18 *** TOPIC Free GPL Personal and Small Business 
Accounting…
   2022-04-04T18:01:18 *** NAMES …
   2021-11-01T13:49:16 *** sbluhm JOIN 
   2021-11-01T13:50:25 *** Mechtilde QUIT Ping timeout: 180 seconds
   2021-11-01T14:10:13 *** jervin QUIT Quit: jervin

There hasn’t been any new message traffic since I joined, but it appears
that if I use a command like C-c C-n, the NAMES output gets appended to
the block at the beginning of the buffer. (I’m wary of trying to send a
message myself, as I’m not sure how much of the buffer will be taken as
my message in this weird state — just the line I type, or everything
after the apparent insertion point?)

I think I got into this state after restarting Emacs a couple of times
today, because I had been looking at the #gnucash log in a buffer, and
am using desktop save mode.  The .emacs.desktop file doesn’t save the
uniquified buffer name, apparently.  (My current .emacs.desktop has two
entries for buffers to be called “workQueue.c” for files by that name in
different directories.)  After the takeover of the buffer for use by
rcirc mode, the buffer-file-name is still set, so that info can be saved
away.

This also resulted in a message logged at startup time — the saved info
on the #gnucash buffer said it was in rcirc-mode, which causes
rcirc-mode to be invoked in the “restored” buffer with no arguments, but
rcirc-mode requires exactly two arguments, unlike normal mode functions.

Load the desktop file the first time, even if rcirc is running, and the
saved desktop will add the file buffer to the buffers to restore. Quit,
restart, and load the desktop file the second time, and the file buffer
will be loaded before rcirc gets started, causing the buffer “takeover”
and resulting in a new desktop save file showing the log file buffer as
being in rcirc-mode. Quit, restart, and load the desktop file a third
time, and a message will be logged about an error trying to set the
buffer mode.

With the issues I’ve described before about not reliably getting back
into channels when quitting and restarting, the simplest fix once I’m in
the situation seems to be quitting Emacs, starting up again, making sure
any “restored” rcirc log buffers are killed, then starting rcirc.

I can probably work around this by tweaking desktop-files-not-to-save so
I don’t accidentally hit this when restarting Emacs, but (1) I do want
to be able to look at a log file and preserve my position in it from
session to session, and (2) manually pulling up a log file before
starting rcirc would still trigger the same lossage.


In GNU Emacs 28.0.92 (build 1, x86_64-redhat-linux-gnu, X toolkit, cairo version 1.17.4, Xaw3d scroll bars)
of 2022-03-20 built on 5bed50ec23174a34b43f6166b598ee0b
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
'configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
--with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=lucid
--with-gpm=no --with-modules --with-harfbuzz --with-cairo --with-json
--with-native-compilation build_alias=x86_64-redhat-linux-gnu
host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-DMAIL_USE_LOCKF -O2
-flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
LDFLAGS=-Wl,-z,relro
PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
 value of $LANG: en_US.UTF-8
 value of $XMODIFIERS: @im=ibus
 locale-coding-system: utf-8-unix

Major mode: rcirc

Minor modes in effect:
 buffer-face-mode: t
 rcirc-track-minor-mode: t
 display-time-mode: t
 desktop-save-mode: t
 global-edit-server-edit-mode: t
 smart-quotes-mode: t
 which-function-mode: t
 icomplete-mode: t
 shell-dirtrack-mode: t
 global-hi-lock-mode: t
 hi-lock-mode: t
 tooltip-mode: t
 global-eldoc-mode: t
 show-paren-mode: t
 electric-indent-mode: t
 mouse-wheel-mode: t
 use-hard-newlines: t
 tab-bar-mode: t
 file-name-shadow-mode: t
 global-font-lock-mode: t
 font-lock-mode: t
 blink-cursor-mode: t
 auto-composition-mode: t
 auto-encryption-mode: t
 auto-compression-mode: t
 line-number-mode: t
 visual-line-mode: t
 indent-tabs-mode: t
 transient-mark-mode: t

Load-path shadows:
/home/raeburn/.emacs.d/elpa/systemtap-mode-20151122.1940/systemtap-mode hides /usr/share/emacs/site-lisp/systemtap-mode
/home/raeburn/.emacs.d/elpa/p4-20150721.1937/p4 hides /usr/share/emacs/site-lisp/perforce/p4
/home/raeburn/.emacs.d/elpa/transient-20211101.2251/transient hides /usr/share/emacs/28.0.92/lisp/transient

Features:
(shadow sort mail-extr emacsbug sendmail shortdoc help-fns radix-tree
gnutls network-stream nsm misearch multi-isearch cl-print ielm pp
add-log markdown-mode reveal face-remap dired-aux python tramp-sh
mule-util dockerfile-mode mhtml-mode css-mode color js sgml-mode
facemenu ruby-mode texinfo texinfo-loaddefs rst compile perl-mode
sh-script smie executable bug-reference conf-mode vc-git diff-mode
vc-dispatcher cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs org-element avl-tree generator ol-eww
eww xdg url-queue thingatpt mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
ol-docview doc-view jka-compr image-mode exif ol-bibtex ol-bbdb ol-w3m
ol-doi org-link-doi yaml-mode ob-shell comp comp-cstr warnings cl-extra
help-mode rcirc gnus-art mm-uu mml2015 mm-view mml-smime smime dig
gnus-sum shr kinsoku svg dom gnus-group gnus-undo gnus-start gnus-dbus
dbus xml gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec
gnus-int gnus-range message rmc puny dired dired-loaddefs rfc822 mml
mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
text-property-search mail-utils mm-util mail-prsvr wid-edit time desktop
frameset cus-load kr-init docker-tramp tramp-cache vagrant-tramp dash
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
parse-time ls-lisp org-protocol org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-footnote org-src ob-comint org-pcomplete org-list
org-faces org-entities noutline outline org-version ob-emacs-lisp
ob-core ob-eval org-table oc-basic bibtex iso8601 time-date ol org-keys
oc org-compat org-macs org-loaddefs format-spec find-func cal-menu
calendar cal-loaddefs edit-server advice smart-quotes easy-mmode
which-func imenu icomplete server term disp-table shell pcomplete ehelp
comint ansi-color ring hi-lock finder-inf rx info package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 601460 80132)
(symbols 48 34155 0)
(strings 32 136844 6717)
(string-bytes 1 4343776)
(vectors 16 66007)
(vector-slots 8 1241450 56375)
(floats 8 520 450)
(intervals 56 11548 4504)
(buffers 992 197))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Tue, 05 Apr 2022 10:05:02 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Ken Raeburn <raeburn <at> redhat.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Tue, 05 Apr 2022 10:03:49 +0000
[Message part 1 (text/plain, inline)]
Ken Raeburn <raeburn <at> redhat.com> writes:

> I’m using rcirc, and have logging turned on.   When I started up
> rcirc, I already had one of the log files
> (~/.emacs.d/rcirc-log/#gnucash <at> irc.gnome.org) being viewed in a
> buffer. That buffer, sensibly enough, was named
> “#gnucash <at> irc.gnome.org”.   Once rcirc connected to irc.gnome.org, and
> joined my channels, it looked for a buffer named
> “#gnucash <at> irc.gnome.org”, assumed that that was its own buffer for
> showing channel messages, switched it to rcirc mode, and started
> adding to it. So now, the buffer starts off:      2022-04-04T18:01:18
> *** raeburn JOIN
>    2022-04-04T18:01:18 *** ChanServ MODE +v raeburn
>    2022-04-04T18:01:18 *** TOPIC Free GPL Personal and Small Business
>    Accounting…
>    2022-04-04T18:01:18 *** NAMES …
>    2021-11-01T13:49:16 *** sbluhm JOIN     2021-11-01T13:50:25 ***
>   Mechtilde QUIT Ping timeout: 180 seconds
>    2021-11-01T14:10:13 *** jervin QUIT Quit: jervin
>

[...]

> I can probably work around this by tweaking desktop-files-not-to-save so
> I don’t accidentally hit this when restarting Emacs, but (1) I do want
> to be able to look at a log file and preserve my position in it from
> session to session, and (2) manually pulling up a log file before
> starting rcirc would still trigger the same lossage.

It might help to add rcirc-mode to desktop-modes-not-to-save, but you
are right the fundamental issue still is that rcirc can get confused by
specific buffer names.

One solution might just be to wrap the body of
rcirc-generate-new-buffer-name in a generate-new-buffer call, so as to
avoid these issue.  IIRC there should be no issue if the buffer name for
a rcirc chat buffer has a modified name, as the buffer objects all
managed via rcirc-buffer-alist and rcirc-get-buffer.

Could you try applying this patch to see if this improves the situation,
or if some other issues arise:

[Message part 2 (text/plain, inline)]
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 859dc175e5..1f82924d98 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -1556,10 +1556,11 @@ rcirc-clean-up-buffer
 (defun rcirc-generate-new-buffer-name (process target)
   "Return a buffer name based on PROCESS and TARGET.
 This is used for the initial name given to IRC buffers."
-  (substring-no-properties
-   (if target
-       (concat target "@" (process-name process))
-     (concat "*" (process-name process) "*"))))
+  (generate-new-buffer
+   (substring-no-properties
+    (if target
+        (concat target "@" (process-name process))
+      (concat "*" (process-name process) "*")))))
 
 (defun rcirc-get-buffer (process target &optional server)
   "Return the buffer associated with the PROCESS and TARGET.
[Message part 3 (text/plain, inline)]
-- 
	Philip Kaludercic

Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 06 Apr 2022 10:01:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Tue, 06 Sep 2022 11:23:02 GMT) Full text and rfc822 format available.

Message #13 received at 54718 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718 <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Tue, 06 Sep 2022 13:21:50 +0200
Philip Kaludercic <philipk <at> posteo.net> writes:

> Could you try applying this patch to see if this improves the situation,
> or if some other issues arise:

Ken, did you try Philip's patch?




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 06 Sep 2022 11:23:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Tue, 04 Oct 2022 11:47:02 GMT) Full text and rfc822 format available.

Message #18 received at 54718 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718 <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Tue, 04 Oct 2022 13:46:40 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> Could you try applying this patch to see if this improves the situation,
>> or if some other issues arise:
>
> Ken, did you try Philip's patch?

This was a month ago.  Philip, I think your patch looks "obviously
correct", so feel free to push it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Wed, 05 Oct 2022 17:32:02 GMT) Full text and rfc822 format available.

Message #21 received at 54718 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718 <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Wed, 05 Oct 2022 17:31:34 +0000
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>>> Could you try applying this patch to see if this improves the situation,
>>> or if some other issues arise:
>>
>> Ken, did you try Philip's patch?
>
> This was a month ago.  Philip, I think your patch looks "obviously
> correct", so feel free to push it.

It appears the patch was not correct, as the function was used in a few
other spots.  One unintended side-effect was that logging creates a new
buffer for apparently every *received message*.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Thu, 06 Oct 2022 11:33:02 GMT) Full text and rfc822 format available.

Message #24 received at 54718 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718 <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Thu, 06 Oct 2022 11:32:24 +0000
Philip Kaludercic <philipk <at> posteo.net> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>>> Could you try applying this patch to see if this improves the situation,
>>>> or if some other issues arise:
>>>
>>> Ken, did you try Philip's patch?
>>
>> This was a month ago.  Philip, I think your patch looks "obviously
>> correct", so feel free to push it.
>
> It appears the patch was not correct, as the function was used in a few
> other spots.  One unintended side-effect was that logging creates a new
> buffer for apparently every *received message*.

Another idea might be to modify `rcirc-generate-log-filename' to add a
".log" to the end of each filename.




Reply sent to Philip Kaludercic <philipk <at> posteo.net>:
You have taken responsibility. (Fri, 14 Oct 2022 18:14:01 GMT) Full text and rfc822 format available.

Notification sent to Ken Raeburn <raeburn <at> redhat.com>:
bug acknowledged by developer. (Fri, 14 Oct 2022 18:14:02 GMT) Full text and rfc822 format available.

Message #29 received at 54718-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718-done <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Fri, 14 Oct 2022 18:13:18 +0000
Philip Kaludercic <philipk <at> posteo.net> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>>
>>>>> Could you try applying this patch to see if this improves the situation,
>>>>> or if some other issues arise:
>>>>
>>>> Ken, did you try Philip's patch?
>>>
>>> This was a month ago.  Philip, I think your patch looks "obviously
>>> correct", so feel free to push it.
>>
>> It appears the patch was not correct, as the function was used in a few
>> other spots.  One unintended side-effect was that logging creates a new
>> buffer for apparently every *received message*.
>
> Another idea might be to modify `rcirc-generate-log-filename' to add a
> ".log" to the end of each filename.

I have pushed a patch that does this, as there have been no objections.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54718; Package emacs. (Fri, 04 Nov 2022 22:54:02 GMT) Full text and rfc822 format available.

Message #32 received at 54718 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Ken Raeburn <raeburn <at> redhat.com>, 54718 <at> debbugs.gnu.org
Subject: Re: bug#54718: 28.0.92; rcirc channel-vs-log buffer confusion
Date: Fri, 04 Nov 2022 22:53:22 +0000
Philip Kaludercic <philipk <at> posteo.net> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>>
>>>>> Could you try applying this patch to see if this improves the situation,
>>>>> or if some other issues arise:
>>>>
>>>> Ken, did you try Philip's patch?
>>>
>>> This was a month ago.  Philip, I think your patch looks "obviously
>>> correct", so feel free to push it.
>>
>> It appears the patch was not correct, as the function was used in a few
>> other spots.  One unintended side-effect was that logging creates a new
>> buffer for apparently every *received message*.
>
> Another idea might be to modify `rcirc-generate-log-filename' to add a
> ".log" to the end of each filename.

This approach was implemented with db69681759991d5403552682706accd6218b731f.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 03 Dec 2022 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 138 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.