From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Pushing the `gnus-range-*' functions down into the C layer Date: Sat, 11 Sep 2010 14:52:09 +0900 Message-ID: <87hbhw25fa.fsf@uwakimon.sk.tsukuba.ac.jp> References: <8739ti68sz.fsf@lifelogs.com> <87pqwm1dsl.fsf@uwakimon.sk.tsukuba.ac.jp> <87iq2d4sd5.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1284184698 24695 80.91.229.12 (11 Sep 2010 05:58:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 11 Sep 2010 05:58:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 11 07:58:17 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OuJ6P-0000uV-68 for ged-emacs-devel@m.gmane.org; Sat, 11 Sep 2010 07:58:17 +0200 Original-Received: from localhost ([127.0.0.1]:47530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OuJ6O-0006hn-Cr for ged-emacs-devel@m.gmane.org; Sat, 11 Sep 2010 01:58:16 -0400 Original-Received: from [140.186.70.92] (port=56394 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OuJ6F-0006gS-7n for emacs-devel@gnu.org; Sat, 11 Sep 2010 01:58:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OuJ6D-00072r-Rv for emacs-devel@gnu.org; Sat, 11 Sep 2010 01:58:07 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:59704) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OuJ6D-00072j-HX for emacs-devel@gnu.org; Sat, 11 Sep 2010 01:58:05 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 60164F4003; Sat, 11 Sep 2010 14:58:04 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 50566F4002; Sat, 11 Sep 2010 14:58:04 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 4AE123FA0479; Sat, 11 Sep 2010 14:58:04 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 68A051A266F; Sat, 11 Sep 2010 14:52:09 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129951 Archived-At: Lars Magne Ingebrigtsen writes: > Ted Zlatanov writes: > > 64-bit int support in Emacs should not require a 64-bit system. > > If they are natively available it's faster, that's all. It's not > > like you'd be packing and unpacking the bits directly. > Yeah. Bignum support in Emacs would totally rock. Indeed, it rocks in XEmacs and SXEmacs. :-) > No more manual conversions to floating point numbers to do safe-ish > computations on numbers that might be too big would be needed. > > But I suspect that it's a kinda big project. :-) Not really. Somewhat bigger than "linking in libxml2", but not that much. For all computations except buffer and string support, it's already been done in XEmacs and SXEmacs, and the original implementation has needed very little in the way of bugfixing -- I suspect it's a real SMOP. The hard/tedious part would be large buffer support on 32-bit systems, because for efficiency you probably don't want to use bignums, but rather 64-bit fixnums. (But nobody has actually tried, because the real problem with big buffers is variable-width representations of characters.)