Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

[Ludovic Courtès]

Hello,

"Andy Wingo" <wingo@pobox.com> writes:

> +SCM_DEFINE (scm_uniform_array_to_bytevector, "uniform-array->bytevector",
> +            1, 0, 0, (SCM array),
> +	    "Return a newly allocated bytevector whose contents\n"
> +            "will be copied from the uniform array @var{array}.")
> +#define FUNC_NAME s_scm_uniform_array_to_bytevector
> +{
> +  SCM contents, ret;
> +  size_t len;
> +  scm_t_array_handle h;
> +  const void *base;
> +  size_t sz;
> +  
> +  contents = scm_array_contents (array, SCM_BOOL_T);
> +  if (scm_is_false (contents))
> +    scm_wrong_type_arg_msg (FUNC_NAME, 0, array, "uniform contiguous array");
> +
> +  scm_array_get_handle (contents, &h);
> +
> +  base = scm_array_handle_uniform_elements (&h);
> +  len = h.dims->inc * (h.dims->ubnd - h.dims->lbnd + 1);
> +  sz = scm_array_handle_uniform_element_size (&h);
> +
> +  ret = make_bytevector (len * sz);
> +  memcpy (SCM_BYTEVECTOR_CONTENTS (ret), base, len * sz);

Is this memcpy valid in the case of shared arrays?  Looks like we end up
copying more elements than needed, but maybe it's better this way.

> +           uniform-array->bytevector

I would not export it from `(rnrs bytevector)' given that it has nothing
to do with RnRS.

Also, I would make the new C functions private, given that they are not
intended for general use AIUI.

What d'ya think?

Thanks,
Ludo'.

Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

[Andy Wingo]

Heya,

On Sat 06 Jun 2009 16:31, ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> "Andy Wingo" <wingo@pobox.com> writes:
>
>> +SCM_DEFINE (scm_uniform_array_to_bytevector, "uniform-array->bytevector",
>> +            1, 0, 0, (SCM array),
>> +	    "Return a newly allocated bytevector whose contents\n"
>> +            "will be copied from the uniform array @var{array}.")
>> +#define FUNC_NAME s_scm_uniform_array_to_bytevector
>> +{
>> +  SCM contents, ret;
>> +  size_t len;
>> +  scm_t_array_handle h;
>> +  const void *base;
>> +  size_t sz;
>> +  
>> +  contents = scm_array_contents (array, SCM_BOOL_T);
>> +  if (scm_is_false (contents))
>> +    scm_wrong_type_arg_msg (FUNC_NAME, 0, array, "uniform contiguous array");
>> +
>> +  scm_array_get_handle (contents, &h);
>> +
>> +  base = scm_array_handle_uniform_elements (&h);
>> +  len = h.dims->inc * (h.dims->ubnd - h.dims->lbnd + 1);
>> +  sz = scm_array_handle_uniform_element_size (&h);
>> +
>> +  ret = make_bytevector (len * sz);
>> +  memcpy (SCM_BYTEVECTOR_CONTENTS (ret), base, len * sz);
>
> Is this memcpy valid in the case of shared arrays?  Looks like we end up
> copying more elements than needed, but maybe it's better this way.

I'm not entirely sure. I thought that scm_array_contents will give me a
contiguous array, though trolling around in srfi-4.[ch] and unif.[ch]
makes me grumpy ;)

>> +           uniform-array->bytevector
>
> I would not export it from `(rnrs bytevector)' given that it has nothing
> to do with RnRS.

No, but it does have to with bytevectors... Where would you put it?

> Also, I would make the new C functions private, given that they are not
> intended for general use AIUI.

Dunno. I could imagine calling both of them from C. Would there be a
problem with leaving them to be public?

Cheers,

Andy
-- 
http://wingolog.org/

Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

[Ludovic Courtès]

Hey,

Andy Wingo <wingo@pobox.com> writes:

>>> +           uniform-array->bytevector
>>
>> I would not export it from `(rnrs bytevector)' given that it has nothing
>> to do with RnRS.
>
> No, but it does have to with bytevectors... Where would you put it?

Dunno, maybe not anywhere public?

>> Also, I would make the new C functions private, given that they are not
>> intended for general use AIUI.
>
> Dunno. I could imagine calling both of them from C. Would there be a
> problem with leaving them to be public?

Yes, while we're not more confident wrt. shared arrays and similar.

Ludo'.

Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

[Andy Wingo]

Howdy,

On Thu 18 Jun 2009 22:28, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>>>> +           uniform-array->bytevector
>>>
>>> I would not export it from `(rnrs bytevector)' given that it has nothing
>>> to do with RnRS.
>>
>> No, but it does have to with bytevectors... Where would you put it?
>
> Dunno, maybe not anywhere public?

Er, I wrote it so I could use it in my code... Not being able to get at
the bits of uniform arrays from Scheme has been a sorely missing feature
for a long time now...

>>> Also, I would make the new C functions private, given that they are not
>>> intended for general use AIUI.
>>
>> Dunno. I could imagine calling both of them from C. Would there be a
>> problem with leaving them to be public?
>
> Yes, while we're not more confident wrt. shared arrays and similar.

What do you mean? I think that shared arrays will be attempted to be
linearized via scm_array_contents, which will throw an error for a
non-contiguous array. That's as good as we can do, no?

Andy
-- 
http://wingolog.org/

Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> On Thu 18 Jun 2009 22:28, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>>>> +           uniform-array->bytevector
>>>>
>>>> I would not export it from `(rnrs bytevector)' given that it has nothing
>>>> to do with RnRS.
>>>
>>> No, but it does have to with bytevectors... Where would you put it?
>>
>> Dunno, maybe not anywhere public?
>
> Er, I wrote it so I could use it in my code... Not being able to get at
> the bits of uniform arrays from Scheme has been a sorely missing feature
> for a long time now...

I understand it's needed by the compiler to serialize uniform arrays,
which is a good reason to keep it public.

My concern is that IMO we should avoid encouraging applications to mix
uniform vectors and bytevectors, when the latter should be the main way
to do binary I/O.

>>>> Also, I would make the new C functions private, given that they are not
>>>> intended for general use AIUI.
>>>
>>> Dunno. I could imagine calling both of them from C. Would there be a
>>> problem with leaving them to be public?
>>
>> Yes, while we're not more confident wrt. shared arrays and similar.
>
> What do you mean? I think that shared arrays will be attempted to be
> linearized via scm_array_contents, which will throw an error for a
> non-contiguous array. That's as good as we can do, no?

That's right (it wasn't all that clear to me from our discussion).

Thanks,
Ludo'.