GNU bug report logs - #18520
string ports should not have an encoding

Previous Next

Full log

Message #20 received at 18520 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Kastrup <dak <at> gnu.org>
Cc: 18520 <at> debbugs.gnu.org
Subject: Re: bug#18520: string ports should not have an encoding
Date: Mon, 22 Sep 2014 19:08:16 +0200

David Kastrup <dak <at> gnu.org> skribis:

> I'm currently migrating LilyPond over to GUILE 2.0.  LilyPond has its
> own UTF-8 verification, error flagging, processing and indexing.

Do I understand correctly that LilyPond expects Guile strings to be byte
vectors, which it can feed with UTF-8 byte sequences that it built by
itself?

> If you take a look at
> <URL:http://git.savannah.gnu.org/cgit/lilypond.git/tree/scm/parser-ly-from-scheme.scm>,
> ftell on a string port is here used for correlating the positions of
> parsed subexpressions with the original data.  Reencoding strings in
> utf-8 is not going to make this work with string indexing since ftell
> does not bear a useful relation to string positions.

AIUI the result of ‘ftell’ is used in only one place, while ‘port-line’
and ‘port-column’ are used in other places.  The latter seems more
appropriate to me when it comes to tracking source location.

How is the result of ‘ftell’ used by callers of ‘read-lily-expression’?

> I have more than enough crashes and obscure errors to contend with as
> it stands,

Could you open a separate bug with the backtrace of such crashes, if you
think it may be Guile’s fault?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.