From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: The future: accessing vectors, arrays, etc from C Date: Tue, 11 Jan 2005 19:01:44 +0100 Message-ID: References: <87acrvq1h5.fsf@zagadka.de> <41DB2F0C.9050304@ossau.uklinux.net> <41E06A7B.8050106@ossau.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1105467472 329 80.91.229.6 (11 Jan 2005 18:17:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 Jan 2005 18:17:52 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Jan 11 19:17:45 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CoQaP-0001Ez-00 for ; Tue, 11 Jan 2005 19:17:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CoQlx-0006zC-Vj for guile-user@m.gmane.org; Tue, 11 Jan 2005 13:29:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CoQgm-0005fL-0u for guile-user@gnu.org; Tue, 11 Jan 2005 13:24:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CoQgU-0005bN-J5 for guile-user@gnu.org; Tue, 11 Jan 2005 13:24:04 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CoQgU-0005TM-GA for guile-user@gnu.org; Tue, 11 Jan 2005 13:24:02 -0500 Original-Received: from [129.217.163.1] (helo=mail.dt.e-technik.uni-dortmund.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CoQKw-00057J-FI for guile-user@gnu.org; Tue, 11 Jan 2005 13:01:46 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id E45EB4E9F7; Tue, 11 Jan 2005 19:01:45 +0100 (CET) Original-Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03909-01-3; Tue, 11 Jan 2005 19:01:45 +0100 (CET) Original-Received: from troy.dt.e-technik.uni-dortmund.de (troy.dt.e-technik.uni-dortmund.de [129.217.163.17]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 5AB8A4E8F1; Tue, 11 Jan 2005 19:01:45 +0100 (CET) Original-Received: by troy.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id E70D8B99B; Tue, 11 Jan 2005 19:01:44 +0100 (CET) Original-To: Neil Jerram In-Reply-To: <41E06A7B.8050106@ossau.uklinux.net> (Neil Jerram's message of "Sat, 08 Jan 2005 23:19:23 +0000") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:4049 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4049 Neil Jerram writes: >> A change in representation of an array might happen when the copy for >> a copy-on-write array takes place, or when the first 16-bit Unicode >> character is stored in a 8-bit string. > > Just to check understanding: is it correct that: > > - all such changes have to be driven from Scheme code? Hmm, I'm not sure what you are getting at. Certainly C code can trigger these changes as well, but they do not happen spontaneously. For example, you might get an error about not being allowed to change a reserved array when you try to grow a vector while it is being sorted in another thread. The thing to do then is to use some synchronization (such as a mutex) to prevent this situation. > - such changes do not affect the arrays obtained by C code through the > scm_*_array_handle_*_elements functions? Right. Those arrays are 'reserved' while C code accesses them and you can't change them in a way that would invalidate the pointers that C code is using. >> It will be more tedious to use than the old one mainly because it is >> more general, something which has nothing to do with allowing >> representations to change: When using the new API, your code must be >> able to deal with non-contiguously stored vectors, while previously >> you could just assume that all vectors are stored contiguously. > > This worried me when I first read it, but in fact I think the only > increase in tediousness is that the increment from one element to the > next may not always be 1. But it will always be some constant. Is > that right, or am I missing some other kinds of tediousness? :-) That is exactly right. (There are any number of schemes to store arrays in memory, just think about sparse or band matrices, and we can't offer them all. I think the current compromise by Guile is the right one.) > I think this delta is OK, personally. And in practice many > applications will be able to get away with asserting that the > increment is 1, by simplying avoiding array mapping in more than one > dimension. Hmm, no, even vectors can have increments != 1. The diagonal of a matrix would be an example. > Even so, I think we could usefully make a public statement (perhaps by > adding it to the manual) reflecting the apparent consensus from this > discussion, namely... Yours is a very good summary, but I myself wouldn't want to put it in the manual... just let reality speak for itself. But it should be recorded somewhere. Maybe in the FAQ? >> [...] > > Sounds good and sufficiently motivated to me. I presume SCM_VECTORP, > SCM_VECTOR_REF and SCM_VECTOR_SET will remain available as deprecated > macros, won't they? Yes, but their performance sucks. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user