Hi,
Andy Wingo 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 idea.
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 aliasin
Hi,
Andy Wingo skribis:
> On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen 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 example, let's say I
ing on a problem that involves lots 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/
() Andy Wingo
() 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 for such a facil
e e.g. 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 opin
