[vivace-graph-devel] Recent Babel changes - discussion from github

[MON KEY]

Hello,

I recently commented on github w/r/t a recent commit which creates a
new dependency on Babel:

(URL `https://github.com/mon-key/vivace-graph-v2/commit/8a91ff8c52b87411bb9a816b3094c12d15ea69ed#commitcomment-568271')

As the devel-mailing list is the more appropriate forum for this I
figure i should forward my comments here and any follow up should
occur here. Following is a transcript of the initial exchange:

,----
| mon-key added a note to 8a91ff8 repo owner
|
| Was there a specific reason for the change to
| babel:string-to-octets?Was there a specific reason for the change to
| babel:string-to-octets?
`----

,----
| kraison added a note to 8a91ff8
|
| portability. some day, when I actually get around to finishing this
| application, I would like it to be portable across Lisps. are you
| using vivace-graph? did this change cause any troubles?
`----

I don't find any immediate trouble :)

I understand that the the move to Babel is one step towards removing
reliances on SBCL internals.

This said, I would think `flexi-streams:octets-to-string' might be a
better choice esp. in so much as the longterm goals / requirements of
vivace-graph-v2 are likely to eventually require some use of a
portable streams library...

At the very least, in so much as the callers of BABEL:OCTETS-TO-STRING
BABEL:STRING-TO-OCTETS are (de)serializers immediately associated with
salza2 and chipz compression, it may be worth considering that both
salza2 and chipz can frob to/from octet stream directly and that
flexi-streams more immediately capable of taking advantage of this
than Babel's babel-streams. A quick glance at the file header of
babel/src/streams.lisp may convince you that Babel is an inferior
substitute for Flexi-Streams. ;-}

FWIW I'm fooling around with a forked v2 - the mon_key branch holds
the current changes. My intent is to explore ways in which
vivace-graph might benefit from incorporation of my uuid system
Unicly: https://github.com/mon-key/unicly

The Unicly system has a dependency on flexi-streams's
`string-to-octets'.  Likwise, the uuid system has a dependency on
trivial-utf-8's `string-to-octets'.  To that end, my immediate concern
is that there is little need in providing an additional UTF-8
portability package.

Following are the respective signatures of three functions each of
which satisfy nearly identical requirements:

 flexi-streams:octets-to-string
 babel:octets-to-string
 trivial-utf-8:utf-8-bytes-to-string

;; sb-ext:octets-to-string
(vector &key
        (start 0)
        end
        (external-format default))

;; flexi-streams:octets-to-string
(sequence &key
          (start 0)
          (end (length sequence))
          (external-format :latin1))

;; babel:octets-to-string
(vector &key
        (start 0)
        end
        (encoding *default-character-encoding*)
        (errorp (not *suppress-character-coding-errors*)))

;; trivial-utf-8:utf-8-bytes-to-string
(bytes-in &key
          (start 0)
          (end (length bytes-in)))

Also, note that where both the Unicly and uuid systems have a
dependency on ironclad, it might be possible to shoehorn an
octet-to-string function using the stuff in octet-streams.lisp
esp. where Ironclad _appears_ to provide have a fairly portable and
self-contained implementation of Gray Stream binary streams already.