unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Steve Juranich <sjuranic@gmail.com>
Subject: Re: Bug in make-shared-array.
Date: Thu, 04 May 2006 10:55:49 -0700	[thread overview]
Message-ID: <e3df78$71c$1@sea.gmane.org> (raw)
In-Reply-To: 8764kppcnz.fsf@minimini.mvo.home

Marius Vollmer wrote:

> The checking done by make-shared-array will never allow accesses
> outside of the storage vector, but it might allow accesses to elements
> that are not part of the original array passed to make-shared-array.
> 
> This behavior might or might not be a feature, but if you really want
> it, it is probably better to use array-contents explicitely.
> 
> I'm inclined not to do anything about this until starting a bigger,
> more general cleanup of the code.  Thoughts?

Okay.  So maybe I missed something here.  Is there a workaround in place so
that the examples in the info page work?  Because right now, not all of
them do:

>From the info page:
<info>
     Dimensions can be increased by for instance considering portions
     of a one dimensional array as rows in a two dimensional array.
     (`array-contents' below can do the opposite, flattening an array.)

          (make-shared-array #1(a b c d e f g h i j k l)
                             (lambda (i j) (list (+ (* i 3) j)))
                             4 3)
          => #2((a b c) (d e f) (g h i) (j k l))
</info>

But in a guile process...
<process>
guile> (make-shared-array #1(a b c d e f g h i j k l)
                             (lambda (i j) (list (+ (* i 3) j)))
                             4 3)

Backtrace:
In standard input:
   8: 0* [make-shared-array #(a b c d e f g h i ...) #<procedure #f (i j)> 4
3]

standard input:8:1: In procedure make-shared-array in expression
(make-shared-array (quote #) (lambda # #) ...):
standard input:8:1: mapping out of range
ABORT: (misc-error)
</process>

My opinion would be that this would be higher priority as long as the info
page examples don't work (then again, I'm not a developer).  I guess an
easier fix would be to change the info page examples. ;-)

Thanks for making sure this doesn't slip through the cracks.

Gratefully,
-- 
Steve Juranich
Tucson, AZ
USA



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile


  parent reply	other threads:[~2006-05-04 17:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27 23:12 Bug in make-shared-array Steve Juranich
2006-03-03 23:52 ` Kevin Ryde
2006-03-11  0:07   ` Neil Jerram
2006-05-01 21:48     ` Marius Vollmer
2006-05-01 22:13     ` Marius Vollmer
2006-05-01 23:07     ` Marius Vollmer
2006-05-03 23:29       ` Kevin Ryde
2006-05-04 17:55       ` Steve Juranich [this message]
2006-05-04 21:27         ` Marius Vollmer
2006-06-14  0:45       ` Neil Jerram
  -- strict thread matches above, loose matches on Subject: below --
2006-02-27 18:16 Steve Juranich
2006-02-27 16:16 Steve Juranich

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='e3df78$71c$1@sea.gmane.org' \
    --to=sjuranic@gmail.com \
    /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).