From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Code for converting between Elisp and Calc floats Date: Sun, 25 Oct 2009 09:57:49 -0400 Message-ID: References: <200910082047.n98KlkAB020482@godzilla.ics.uci.edu> <87aazj2r7d.fsf_-_@vh213601.truman.edu> <87ws2kmuez.fsf@gmail.com> <87hbto11d8.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1256479093 25536 80.91.229.12 (25 Oct 2009 13:58:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Oct 2009 13:58:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 25 14:58:06 2009 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.50) id 1N23bh-0000aV-MW for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2009 14:58:06 +0100 Original-Received: from localhost ([127.0.0.1]:58698 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N23bh-0007nr-9T for ged-emacs-devel@m.gmane.org; Sun, 25 Oct 2009 09:58:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N23bZ-0007nI-Rl for emacs-devel@gnu.org; Sun, 25 Oct 2009 09:57:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N23bV-0007m2-S5 for emacs-devel@gnu.org; Sun, 25 Oct 2009 09:57:57 -0400 Original-Received: from [199.232.76.173] (port=38270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N23bV-0007lt-Ix for emacs-devel@gnu.org; Sun, 25 Oct 2009 09:57:53 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:9436 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N23bS-0007Lo-LP; Sun, 25 Oct 2009 09:57:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEAEb240pLd/xb/2dsb2JhbACBUNMEhD8EiDQ X-IronPort-AV: E=Sophos;i="4.44,620,1249272000"; d="scan'208";a="48129227" Original-Received: from 75-119-252-91.dsl.teksavvy.com (HELO pastel.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 25 Oct 2009 09:57:49 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 87F1C8225; Sun, 25 Oct 2009 09:57:49 -0400 (EDT) In-Reply-To: <87hbto11d8.fsf@lola.goethe.zz> (David Kastrup's message of "Sun, 25 Oct 2009 06:36:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:116392 Archived-At: > There are few areas of importance. One would be buffer_size. Putting bignums for buffer size is a bad idea. It would require an enormous amount of code changes and a very significant slow down (buffer positions are used extensively everywhere in the C code, including performance critical code such as the rendering engine, and changing them from scalar values to something else would slow things down tremendously). > The buffer size problem would likely be less radically addressed by > adding another bit of tagging, and then use half of the possible > values for integers, giving a range of -2^30 .. 2^30-1. Currently we have -2^28..2^28-1 and we can easily extend it to 2^29..2^29-1 without any noticeable downside (I have been using such a change for a while now). > That's what XEmacs does, and it goes a far way of extending the point > of nuisance. Not far enough, AFAICT: if you regularl edit files somewhere between 512M and 1G, then it's quite likely that you'll also want to edit files larger than 1G. Currently in 64bit mode, you supposedly can edit files larger but in practice when I tried it, I bumped into other bugs when reaching the 2G limit (or maybe even earlier) IIRC. Stefan