Hi,
Andy Wingo wi...@pobox.com skribis:
On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen t...@gnuvola.org writes:
If you want to make a case for such a facility, why not
show some code, both without (status quo) and with (proposed)?
It should be clear what expressiveness is gained, and how.
For
On Mon 11 Jun 2012 13:55, l...@gnu.org (Ludovic Courtès) writes:
What about using copying (or rather, copy-on-write) sub-bytevectors to
start with? That would avoid the aliasing issue; OTOH COW would make
the implementation more complex.
Not a bad idea. The FFI can still introduce aliasing,
Hi,
Andy Wingo wi...@pobox.com skribis:
On Mon 11 Jun 2012 13:55, l...@gnu.org (Ludovic Courtès) writes:
What about using copying (or rather, copy-on-write) sub-bytevectors to
start with? That would avoid the aliasing issue; OTOH COW would make
the implementation more complex.
Not a bad
. a
(bytevector-u32-ref bv 12 (native-endianness)) to an efficient access,
knowing that it is aligned. If we offer subbytevectors, this won't be
possible in general.
Again, the gain in expressiveness is probably worth it, but I wanted to
put the question out there to see if anyone has an opinion.
Regards
() Andy Wingo wi...@pobox.com
() Sat, 09 Jun 2012 13:07:15 +0200
Again, the gain in expressiveness is probably worth it
Overall, i am concerned about quick fixes and slow suffering
in the Guile design. To break it down from different angles:
Thinking positively:
If you want to make a case
of
work on a shared bytevector. I have to be careful to avoid printing out
the bytevector because it takes a few seconds and trashes my terminal
history. If I had subbytevectors, this wouldn't be as acute a problem.
Andy
--
http://wingolog.org/
