unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* bytevector-copy creates srfi-4 vector with greater length
@ 2014-10-26 14:49 tantalum
  2014-10-27  8:49 ` Mark H Weaver
  0 siblings, 1 reply; 5+ messages in thread
From: tantalum @ 2014-10-26 14:49 UTC (permalink / raw)
  To: guile-devel

with guile version 2.1.0.89-c5ea7 on an x86_64 GNU/Linux system
and the following code
  (use-modules (srfi srfi-4) (rnrs bytevectors))
  (define a (make-f32vector 2 0))
  (define b (bytevector-copy a))
  (write (list a b))



"b" turns out to be an f32vector with length 8, 4 times the length of "a".
i expected the result to have the same length as the argument and this
looks like a bug to me



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bytevector-copy creates srfi-4 vector with greater length
  2014-10-26 14:49 bytevector-copy creates srfi-4 vector with greater length tantalum
@ 2014-10-27  8:49 ` Mark H Weaver
  2014-10-27 11:00   ` Taylan Ulrich Bayırlı/Kammer
  2014-11-12  6:15   ` Mark H Weaver
  0 siblings, 2 replies; 5+ messages in thread
From: Mark H Weaver @ 2014-10-27  8:49 UTC (permalink / raw)
  To: tantalum; +Cc: guile-devel

tantalum <sph@posteo.eu> writes:

> with guile version 2.1.0.89-c5ea7 on an x86_64 GNU/Linux system
> and the following code
>   (use-modules (srfi srfi-4) (rnrs bytevectors))
>   (define a (make-f32vector 2 0))
>   (define b (bytevector-copy a))
>   (write (list a b))
>
> "b" turns out to be an f32vector with length 8, 4 times the length of "a".
> i expected the result to have the same length as the argument and this
> looks like a bug to me

Yes, this is definitely a bug, introduced in 2009, commit
e286c973fcd63c0930d9302cc5f1a280b9b22615.

Can you please send an email to bug-guile@gnu.org about it, so that it
will be assigned a bug number and ticket?  That's the proper place to
send bug reports.

I'm not sure whether 'bytevector-copy' should produce a SRFI-4 vector
with the same element type as its argument, or if it should produce a
normal bytevector with 8-bit elements.  The argument for the latter
would be that 'bytevector-copy' is a standard procedure that portable
code might reasonably expect to produce bytevectors that print as
vectors of 8-bit bytes.  I don't see a compelling argument for the
former, other than to provide a convenient way to copy SRFI-4 vectors.

Thoughts?

       Mark



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bytevector-copy creates srfi-4 vector with greater length
  2014-10-27  8:49 ` Mark H Weaver
@ 2014-10-27 11:00   ` Taylan Ulrich Bayırlı/Kammer
  2014-10-27 12:36     ` tantalum
  2014-11-12  6:15   ` Mark H Weaver
  1 sibling, 1 reply; 5+ messages in thread
From: Taylan Ulrich Bayırlı/Kammer @ 2014-10-27 11:00 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: tantalum, guile-devel

Mark H Weaver <mhw@netris.org> writes:

> Thoughts?

I have no experience with SRFI-4 so don't know what would be most
pragmatic, but reading the specification, I see s8vector, u8vector,
s16vector, etc. are all distinct data types, though u8vector corresponds
to u8vector from SRFI-66, bytevectors from R6RS, and bytevectors from
R7RS.  Thus I would expect those four to be the same data type, and
distinct from the other SRFI-4 types.  Correspondingly, I'd expect the
SRFI-4/66 u8vector and R6/7RS bytevector APIs all to work on that type
and only that type.  Other types from SRFI-4 should have their dedicated
APIs, including a copy procedure.

That seems like the relatively obvious Right Way to me, unless I'm
missing something.

If useful, there could be a separate API of procedures that work on both
u8vector (i.e. bytevector) and other SRFI-4 data types, but otherwise
I'm of the opinion that any distinct data type exposed to Scheme users
should also have its dedicated API that works on no other types.

Taylan



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bytevector-copy creates srfi-4 vector with greater length
  2014-10-27 11:00   ` Taylan Ulrich Bayırlı/Kammer
@ 2014-10-27 12:36     ` tantalum
  0 siblings, 0 replies; 5+ messages in thread
From: tantalum @ 2014-10-27 12:36 UTC (permalink / raw)
  To: taylanbayirli; +Cc: Mark H Weaver, guile-devel

from the explanations in the manual i interpret the definition of the 
srfi-4 compatibility to be "can work on srfi-4 vectors because the 
storage is the same, even though it regards the data as 8-bit values"
i looked at the code and it seems to work just like this for the read 
and write part of the copy. for the creation part it uses 
make-bytevector with the input type copied in a generic way - i think 
this is sound so far because it does not include any special cases for 
working with srfi-4 types.
the main problem may be that SCM_BYTEVECTOR_LENGTH returns the wrong 
length - that it does not follow 8-bit interpretation
if bytevector-copy would have a input/output type discrepancy, then the 
general bytevector/srfi-4 compatibility as i understand it would be in 
question - read supported, but not create or write.

bytevector-copy! has the same issues

On 27.10.2014 12:00, taylanbayirli@gmail.com wrote:
> Mark H Weaver <mhw@netris.org> writes:
> 
>> Thoughts?
> 
> I have no experience with SRFI-4 so don't know what would be most
> pragmatic, but reading the specification, I see s8vector, u8vector,
> s16vector, etc. are all distinct data types, though u8vector 
> corresponds
> to u8vector from SRFI-66, bytevectors from R6RS, and bytevectors from
> R7RS.  Thus I would expect those four to be the same data type, and
> distinct from the other SRFI-4 types.  Correspondingly, I'd expect the
> SRFI-4/66 u8vector and R6/7RS bytevector APIs all to work on that type
> and only that type.  Other types from SRFI-4 should have their 
> dedicated
> APIs, including a copy procedure.
> 
> That seems like the relatively obvious Right Way to me, unless I'm
> missing something.
> 
> If useful, there could be a separate API of procedures that work on 
> both
> u8vector (i.e. bytevector) and other SRFI-4 data types, but otherwise
> I'm of the opinion that any distinct data type exposed to Scheme users
> should also have its dedicated API that works on no other types.
> 
> Taylan



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: bytevector-copy creates srfi-4 vector with greater length
  2014-10-27  8:49 ` Mark H Weaver
  2014-10-27 11:00   ` Taylan Ulrich Bayırlı/Kammer
@ 2014-11-12  6:15   ` Mark H Weaver
  1 sibling, 0 replies; 5+ messages in thread
From: Mark H Weaver @ 2014-11-12  6:15 UTC (permalink / raw)
  To: tantalum; +Cc: guile-devel

Mark H Weaver <mhw@netris.org> writes:

> tantalum <sph@posteo.eu> writes:
>
>> with guile version 2.1.0.89-c5ea7 on an x86_64 GNU/Linux system
>> and the following code
>>   (use-modules (srfi srfi-4) (rnrs bytevectors))
>>   (define a (make-f32vector 2 0))
>>   (define b (bytevector-copy a))
>>   (write (list a b))
>>
>> "b" turns out to be an f32vector with length 8, 4 times the length of "a".
>> i expected the result to have the same length as the argument and this
>> looks like a bug to me
>
> Yes, this is definitely a bug, introduced in 2009, commit
> e286c973fcd63c0930d9302cc5f1a280b9b22615.
>
> Can you please send an email to bug-guile@gnu.org about it, so that it
> will be assigned a bug number and ticket?  That's the proper place to
> send bug reports.
>
> I'm not sure whether 'bytevector-copy' should produce a SRFI-4 vector
> with the same element type as its argument, or if it should produce a
> normal bytevector with 8-bit elements.  The argument for the latter
> would be that 'bytevector-copy' is a standard procedure that portable
> code might reasonably expect to produce bytevectors that print as
> vectors of 8-bit bytes.  I don't see a compelling argument for the
> former, other than to provide a convenient way to copy SRFI-4 vectors.

I ended up fixing this in 10679f4c59fcffb0657219e28e38d15df8ad09a0 by
making 'bytevector-copy' always produce standard bytevectors with
unsigned 8-bit elements.  FYI, the bug ticket for this was
<http://bugs.gnu.org/18866>.

If there's demand for a convenient way to copy SRFI-4 vectors, let's
give it a different name.

    Thanks,
      Mark



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-11-12  6:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-26 14:49 bytevector-copy creates srfi-4 vector with greater length tantalum
2014-10-27  8:49 ` Mark H Weaver
2014-10-27 11:00   ` Taylan Ulrich Bayırlı/Kammer
2014-10-27 12:36     ` tantalum
2014-11-12  6:15   ` Mark H Weaver

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).