for those who care about Vicare: Seizon Senryaku!!!

[Marco Maggi]

[Posting here because it appears the ikarus-users Google Group does
not work.]

I am pushing on the "devel" branch of Github's repository[1] revisions
of series 0.2, code named Seizon Senryaku; there is also a tarball[2].
These revisions are really in need of some testing.

Here is a summary of changes:

* Some but not all bugs have been fixed.

* Test files have been reorganised, see the README.

* Some documentation has been written[3].

* The web page[4] has seen small updates. If you are the maintainer
of a collection of R6 Scheme libraries supporting Vicare and want to
be listed there, drop me an email[5].

* I passed my comb through most but not all of "ikarus.io.ss":

- Features outside of R6RS have changed in a backwards incompatible
way.

- The following codecs have been added: utf-16le-codec,
utf-16be-codec, utf-16n-codec, utf-bom-codec. There is room for
more.

- NATIVE-TRANSCODER is now a parameter.

- The default endianness of utf-16-codec is now big.

- EOL style conversion has been implemented.

- The functions OPEN-STRING-INPUT-PORT and OPEN-STRING-OUTPUT-PORT
accept an additional optional argument specifying an EOL style.

- Buffer modes have been implemented.

- Missing R6RS functions have been implemented.

- Network socket functions are probably not working, I still have to
review them.

* When a textual input port is configured in "#!vicare" mode, the
following additional syntaxes are supported to read bytevectors:

#vs8
#vu16l #vu16b #vu16n
#vs16l #vs16b #vs16n
#vu32l #vu32b #vu32n
#vs32l #vs32b #vs32n
#vu64l #vu64b #vu64n
#vs64l #vs64b #vs64n

* The following bytevector/list conversion functions have been
implemented:

s8-list->bytevector bytevector->s8-list

u16l-list->bytevector bytevector->u16l-list
u16b-list->bytevector bytevector->u16b-list
u16n-list->bytevector bytevector->u16n-list
s16l-list->bytevector bytevector->s16l-list
s16b-list->bytevector bytevector->s16b-list
s16n-list->bytevector bytevector->s16n-list

u32l-list->bytevector bytevector->u32l-list
u32b-list->bytevector bytevector->u32b-list
u32n-list->bytevector bytevector->u32n-list
s32l-list->bytevector bytevector->s32l-list
s32b-list->bytevector bytevector->s32b-list
s32n-list->bytevector bytevector->s32n-list

u64l-list->bytevector bytevector->u64l-list
u64b-list->bytevector bytevector->u64b-list
u64n-list->bytevector bytevector->u64n-list
s64l-list->bytevector bytevector->s64l-list
s64b-list->bytevector bytevector->s64b-list
s64n-list->bytevector bytevector->s64n-list

* There is an ugly bug causing a controlled crash ("invalid frame
size"), probably caused by something wrong in the I/O module after
my changes. Unfortunatly it is not reliably reproducible; if by
chance someone triggers it with a small amount of code, I appreciate
a bug report.

* I am aware about the problems in converting strings to numbers and
about the missing numerics operations for some combination of
operand types, I will work on these after having fixed the fact that
native endianness is hard coded to little here and there (Aziz!?!).


Side note for those who care about Nausicaa[6]: I am meditating on
focusing it on Vicare and putting on hold support for other Scheme
implementations; if nobody steps out to do support for other
implementations, such support will be lost. I want to do more work on
Vicare and this means less time for other stuff.

I promised to myself to make at least one serious attempt at
supporting every R6 implementation I could put on my computer, and I
did, but:

* I had to drop Larceny because it is too slow for my powerless
computer.

* Ypsilon looks abandoned for the time being (Fujita is rightly
focusing on its business).

* Mosh development is languishing and it is unfortunately slow for
reasons not amendable with simple optimisations (GC).

* Racket is going its own way and it is slow on my powerless computer.

* I dunno if Guile will ever support the full R6RS and it appears to
be slower than Racket (according to some recent post on their
mailing list); the byte-compiler is for sure slow on my powerless
computer.

* Petite Chez Scheme is a fast interpreter, but there is no free FFI.

Happy Autumn.

[1] <http://github.com/marcomaggi/vicare/tree/devel>
[2] <http://github.com/marcomaggi/vicare/downloads>
[3] <http://marcomaggi.github.com/docs/vicare.html>
[4] <http://marcomaggi.github.com/vicare.html>
[5] <http://github.com/marcomaggi>
[6] <http://marcomaggi.github.com/nausicaa.html>
--
Marco Maggi

[Ludovic Courtès]

Hi Marco,

Marco Maggi <ma...@maggi.it> skribis:

> * I dunno if Guile will ever support the full R6RS

I think it supports a very large subset of R6RS. Which R6 feature
relied on by Nausicaa is missing from Guile? We’d be happy to hear it.

> and it appears to be slower than Racket (according to some recent post
> on their mailing list); the byte-compiler is for sure slow on my
> powerless computer.

Compiling Guile itself is slow, because Guile uses itself for
bootstrapping purposes (there’s a bootstrap interpreter written in C,
which is used to run the compiler to compile another interpreter written
in Scheme, which is then used to start compiling the compiler.)

However the compiler isn’t slow in general AFAICT. It could be that you
found a pathological case, which we’d be happy to investigate.

Thanks,
Ludo’.

[Grant Rettke]

On Oct 20, 7:13 am, Marco Maggi <ma...@maggi.it> wrote:
> Happy Autumn.

Awesome work Marco.