unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Thien-Thi Nguyen <ttn@gnuvola.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: subbytevectors
Date: Sat, 09 Jun 2012 19:07:15 +0200	[thread overview]
Message-ID: <87vcj0e7ng.fsf@pobox.com> (raw)
In-Reply-To: <87obosbjnx.fsf@gnuvola.org> (Thien-Thi Nguyen's message of "Sat, 09 Jun 2012 17:16:02 +0200")

Hello,

On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> If you want to make a case for such a facility, why not
> show some code, both without (status quo) and with (proposed)?
> It should be clear what expressiveness is gained, and how.

For example, let's say I mmap a big file.

  (define x (mmap-file "/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.13.so"))

I did some computation and have figured out that there is a region of
interest between bytes 121241 and 121263 that interests me.  I would
like to be able to pass off that region to some other piece of code,
without giving it access to the entire bytevector.  I would also like to
be able to pass around  

> Guile 1.4.x has ‘make-shared-substring’

Guile 1.8, released in 2005, has substring/shared.  So does Guile 2.0.
IIRC -- and this was a looooooooong time ago -- Marius wanted to remove
it, for ease of implementation, but users were using it, so he had to
put it back in.

Strings and bytevectors are fundamentally different, though.

> IIRC, SRFI 13 suggests that its support for substrings would
> not be necessary if programmers wrote code using "range" style.
> Could the client code you have in mind be rephrased like that?

These are complementary strategies.  Using ranges is usually more
efficient, but more at times it is too cumbersome.  Sometimes also you
really want to restrict authority to only a certain window of the
bytevector.

For example, I am currently working on a problem that involves lots of
work on a shared bytevector.  I have to be careful to avoid printing out
the bytevector because it takes a few seconds and trashes my terminal
history.  If I had subbytevectors, this wouldn't be as acute a problem.

Andy
-- 
http://wingolog.org/



  reply	other threads:[~2012-06-09 17:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-09 11:07 subbytevectors Andy Wingo
2012-06-09 15:16 ` subbytevectors Thien-Thi Nguyen
2012-06-09 17:07   ` Andy Wingo [this message]
2012-06-11 11:55     ` subbytevectors Ludovic Courtès
2012-06-11 14:01       ` subbytevectors Andy Wingo
2012-06-11 15:35         ` subbytevectors Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vcj0e7ng.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=guile-devel@gnu.org \
    --cc=ttn@gnuvola.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).