From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Change module interface to no longer use GMP objects directly. Date: Sat, 14 Dec 2019 11:54:02 -0800 Organization: UCLA Computer Science Department Message-ID: <781a5edd-de5a-a4bc-cca4-e744c23d90f1@cs.ucla.edu> References: <3d727645-911e-fc71-1f86-364aa82d06ba@cs.ucla.edu> <287b5f71-75eb-bae2-4f6e-01cce6f07b02@cs.ucla.edu> <87sgmdmxn9.fsf@hase.home> <3479c610-17b7-579c-8109-f7f5d237dcc2@cs.ucla.edu> <83k17aj0je.fsf@gnu.org> <83wob6ch6n.fsf@gnu.org> <83muc0b2bf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="265030"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Cc: Philipp Stephani , Andreas Schwab , Stefan Monnier , Emacs developers To: Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 14 22:19:25 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1igEov-0016kx-7r for ged-emacs-devel@m.gmane.org; Sat, 14 Dec 2019 22:19:25 +0100 Original-Received: from localhost ([::1]:33204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igEot-0004dK-CU for ged-emacs-devel@m.gmane.org; Sat, 14 Dec 2019 16:19:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35668) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1igEgY-00037V-L9 for emacs-devel@gnu.org; Sat, 14 Dec 2019 16:10:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1igEgX-0007OS-59 for emacs-devel@gnu.org; Sat, 14 Dec 2019 16:10:46 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:50098) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1igEgV-0006qE-5e; Sat, 14 Dec 2019 16:10:43 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B909B1605A6; Sat, 14 Dec 2019 11:54:07 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JX72FL53wB2R; Sat, 14 Dec 2019 11:54:07 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 07F321605B7; Sat, 14 Dec 2019 11:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZG7ABMle5BrT; Sat, 14 Dec 2019 11:54:06 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B5BEA1605A6; Sat, 14 Dec 2019 11:54:06 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243390 Archived-At: On 12/14/19 8:06 AM, Philipp Stephani wrote: >> Fine with me, thanks. > Another random idea: What about adding parameters for the limb size, > order and endinanness instead, like mpz_export/import? It would make > the interface a bit more complicated, but would allow users to decide > which limb type to use. I'd leave it alone for now, and see what users want. It's possible the current interface is fine. It's also possible users will want something quite different than a fancier import/export facility.