From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@inria.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509 Date: Fri, 19 Jun 2009 10:20:48 +0200 Message-ID: <86d490ocrj.fsf@inria.fr> References: <878wk577s2.fsf@gnu.org> <861vph1e3o.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1245399795 15155 80.91.229.12 (19 Jun 2009 08:23:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Jun 2009 08:23:15 +0000 (UTC) Cc: guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jun 19 10:23:12 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MHZNP-0008Sm-Bm for guile-devel@m.gmane.org; Fri, 19 Jun 2009 10:23:11 +0200 Original-Received: from localhost ([127.0.0.1]:32864 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHZNO-0005IX-84 for guile-devel@m.gmane.org; Fri, 19 Jun 2009 04:23:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MHZNM-0005IO-0F for guile-devel@gnu.org; Fri, 19 Jun 2009 04:23:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MHZNH-0005Hn-Dq for guile-devel@gnu.org; Fri, 19 Jun 2009 04:23:07 -0400 Original-Received: from [199.232.76.173] (port=53216 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MHZNH-0005Hk-AB for guile-devel@gnu.org; Fri, 19 Jun 2009 04:23:03 -0400 Original-Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:38208) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1MHZNG-000192-TD for guile-devel@gnu.org; Fri, 19 Jun 2009 04:23:03 -0400 X-IronPort-AV: E=Sophos;i="4.42,250,1243807200"; d="scan'208";a="28374687" Original-Received: from unknown (HELO forest) ([193.50.110.50]) by mail2-relais-roc.national.inria.fr with ESMTP; 19 Jun 2009 10:23:01 +0200 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 1 Messidor an 217 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: i486-pc-linux-gnu In-Reply-To: (Andy Wingo's message of "Fri, 19 Jun 2009 09:50:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8709 Archived-At: Hi, Andy Wingo writes: > On Thu 18 Jun 2009 22:28, ludo@gnu.org (Ludovic Court=E8s) writes: > >> Andy Wingo writes: >> >>>>> + uniform-array->bytevector >>>> >>>> I would not export it from `(rnrs bytevector)' given that it has nothi= ng >>>> to do with RnRS. >>> >>> No, but it does have to with bytevectors... Where would you put it? >> >> Dunno, maybe not anywhere public? > > Er, I wrote it so I could use it in my code... Not being able to get at > the bits of uniform arrays from Scheme has been a sorely missing feature > for a long time now... I understand it's needed by the compiler to serialize uniform arrays, which is a good reason to keep it public. My concern is that IMO we should avoid encouraging applications to mix uniform vectors and bytevectors, when the latter should be the main way to do binary I/O. >>>> Also, I would make the new C functions private, given that they are not >>>> intended for general use AIUI. >>> >>> Dunno. I could imagine calling both of them from C. Would there be a >>> problem with leaving them to be public? >> >> Yes, while we're not more confident wrt. shared arrays and similar. > > What do you mean? I think that shared arrays will be attempted to be > linearized via scm_array_contents, which will throw an error for a > non-contiguous array. That's as good as we can do, no? That's right (it wasn't all that clear to me from our discussion). Thanks, Ludo'.