bytevector-copy creates srfi-4 vector with greater length

bytevector-copy creates srfi-4 vector with greater length

[tantalum]

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

Re: bytevector-copy creates srfi-4 vector with greater length

[Mark H Weaver]

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

Re: bytevector-copy creates srfi-4 vector with greater length

[Taylan Ulrich Bayırlı/Kammer]

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

Re: bytevector-copy creates srfi-4 vector with greater length

[tantalum]

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

Re: bytevector-copy creates srfi-4 vector with greater length

[Mark H Weaver]

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