Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509
Howdy, On Thu 18 Jun 2009 22:28, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@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
Hi, Andy Wingo wi...@pobox.com writes: On Thu 18 Jun 2009 22:28, l...@gnu.org (Ludovic Courtès) writes: Andy Wingo wi...@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'.
Re: [Guile-commits] GNU Guile branch, master, updated. 782a82eed13abb64393f7acad92758ae191ce509
Hey, Andy Wingo wi...@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
Heya,
On Sat 06 Jun 2009 16:31, l...@gnu.org (Ludovic Courtès) writes:
Hello,
Andy Wingo wi...@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/
