From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: lloda Newsgroups: gmane.lisp.guile.user Subject: Re: bytevector-string-ref Date: Thu, 22 Dec 2022 13:24:21 +0100 Message-ID: <8DBDD8C0-8C7D-4431-83E7-6702078FEB6A@sarc.name> References: <9761cf20-07b5-8c01-35a2-f9cb250e4f34@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user@gnu.org To: Sascha Ziemann Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Thu Dec 22 13:25:10 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p8KdJ-0006l4-Pj for guile-user@m.gmane-mx.org; Thu, 22 Dec 2022 13:25:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p8Kco-0006fw-U1; Thu, 22 Dec 2022 07:24:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8Kcn-0006fY-BF for guile-user@gnu.org; Thu, 22 Dec 2022 07:24:37 -0500 Original-Received: from mta-13-4.privateemail.com ([198.54.127.109]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p8Kcl-0007ae-MP for guile-user@gnu.org; Thu, 22 Dec 2022 07:24:37 -0500 Original-Received: from mta-13.privateemail.com (localhost [127.0.0.1]) by mta-13.privateemail.com (Postfix) with ESMTP id DEDBB18000B5; Thu, 22 Dec 2022 07:24:25 -0500 (EST) Original-Received: from [192.168.1.105] (unknown [51.154.167.214]) by mta-13.privateemail.com (Postfix) with ESMTPA id 53CBC18000A5; Thu, 22 Dec 2022 07:24:24 -0500 (EST) In-Reply-To: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Virus-Scanned: ClamAV using ClamSMTP Received-SPF: pass client-ip=198.54.127.109; envelope-from=lloda@sarc.name; helo=MTA-13-4.privateemail.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:18796 Archived-At: > On 22 Dec 2022, at 09:58, Sascha Ziemann wrote: >=20 >>> (define str "Hello, World!") >>> (define bv (string->utf8 str)) >>> (define sa (make-shared-array bv (lambda (i) (list (+ i 7))) '(0 = 4))) >>=20 >> I think this should be >>=20 >> (define sa (make-shared-array bv (lambda (i) (list (+ i 7))) 4)) >=20 > This seems to be the same (equal?): > (make-shared-array bv (lambda (i) (list (+ i 7))) '(0 4)) > (make-shared-array bv (lambda (i) (list (+ i 7))) 5) >=20 > And it does not work either: > In procedure utf8->string: Wrong type argument in position 1 > (expecting bytevector): #1vu8(87 111 114 108) >=20 > #1vu8() and #vu8() seem to be diverse. Btw what is the difference? #vu8() are containers. These objects consist of a piece of storage and = its size. #1vu8() are views (specifically, rank-1 views). These are more = complicated objects that contain a pointer to a container plus size, = start location, and stride. Internally, views are their own type = ('arrays') and not bytevectors. In Guile, functions that have 'array' in their name take either = containers or views of any type, so array-ref for example will accept = #1vu8() or #vu8() or #f32() or even #(). However this generality makes = them slower than type-specific functions such as bytevector-ref or = f32vector-ref and so on. If you make a shared array of a bytevector that isn't the bytevector = itself (start at 0, end at end, stride 1) you'll get a view and not a = bytevector, because the bytevector object cannot represent such a shared = array. Once you use make-shared-array, you're limited to the array-xxx = functions. It used to be the case that some typed vector functions worked on views = was well. For example, we used to have vector-ref which worked on #1() = and #(), and simple-vector-ref that worked only on #(). It was a bit of = a mess. That was never the case of the bytevector functions, which were = added later and only ever worked on bytevector objects. I suppose it's possible to extend utf8 to accept a bytevector view = (internally, an array of rank 1 and type vu8) since utf8 isn't itself a = type (in the way you'd expect something called bytevector->xxx should be = constrained to arguments that satisfy bytevector?). It also helps that = there aren't a lot of functions utf8->xxx that you'd need to fix. I hope this makes sense. Daniel