The point is to work with binary data, of which the most common type of C
strings are one kind.
If you are using libguile in your C code you can use guile strings in your C
code and pass them around to avoid the encoding/decoding overhead. Or, the
other way around, expose the procedures that
Hello guile users,
I am writing a library mixing some scheme code and C code, and I have
two options for interfacing C strings:
1. Use bytevectors;
2. Use strings with byte access semantics (so-called latin-1, which is
really a misleading name since it will most certainly contain utf-8-
encoded
Hi,
I am the author of python-on-guile and I just took out the scheme
infrastructure for python and put it is a self contained project of not too
large size. It does not have a python compiler and cannot use python code.
So scheme only.
You can find the project at
docs for the interfaces is
The source is at, https://gitlab.com/tampe/scheme-python
On Sat, Sep 12, 2020 at 3:51 AM divoplade wrote:
> From the scheme side, however:
> 1. The bytevector library needs to be imported;
>
If a single line is a serious overhead, then your program is tiny and you
can do whatever you want: it will be obvious to whoever maintains the
program next
Dear John Cowan,
Le samedi 12 septembre 2020 à 12:48 -0400, John Cowan a écrit :
> > 3. The bytevector library is missing a lot of text functions (like
> > join, split, trim, pad, searching...).
>
> That is indeed an issue. Fortunately SRFI 207, though not yet final,
> comes to your rescue. You
You're welcome!
On Sat, Sep 12, 2020 at 1:14 PM divoplade wrote:
> Dear John Cowan,
>
> Le samedi 12 septembre 2020 à 12:48 -0400, John Cowan a écrit :
> > > 3. The bytevector library is missing a lot of text functions (like
> > > join, split, trim, pad, searching...).
> >
> > That is indeed an
