[9fans] s_putc and Runes

[9fans] s_putc and Runes

[Joel Salomon]

I’ve been appending single Runes to Strings, so I checked
/n/sources/plan9/sys/src/libString/s_putc.c to see if it handled
Runes.  Is there a reason it doesn’t, or that s_putrune doesn’t exist?

Here’s my implementation, using none of String internals:

void
s_putrune(String *s, Rune r)
{
	char rbuf[UTFmax];
	s_nappend(s, rbuf, runetochar(rbuf, &r));
}

or as part of the library (where I’m a bit shakier on the semantics):

void
s_putrune(String *s, Rune r)
{
	char rbuf[UTFmax];
	int n;
	if(s->ref > 1)
		sysfatal("can't s_putc a shared string");
	if (s->ptr >= s->end - n=runelen(r))
		s_grow(s, n+1);
	(s->ptr) += runetochar(s->ptr, &r);
}

--Joel

Re: [9fans] s_putc and Runes

[Russ Cox]

> void
> s_putrune(String *s, Rune r)
> {
>         char rbuf[UTFmax];
>         s_nappend(s, rbuf, runetochar(rbuf, &r));
> }

This is fine.

> or as part of the library (where I'm a bit shakier on the semantics):
>
> void
> s_putrune(String *s, Rune r)
> {
>         char rbuf[UTFmax];
>         int n;
>         if(s->ref > 1)
>                 sysfatal("can't s_putc a shared string");
>         if (s->ptr >= s->end - n=runelen(r))
>                 s_grow(s, n+1);
>         (s->ptr) += runetochar(s->ptr, &r);
> }

Why bother with these details?  The above is fine.  If it ever
became too slow, the right thing to do would be to fix s_nappend,
not code around everything here.  Further, this code is *very*
unlikely to be the bottleneck -- you're calling it once per at most
3 bytes, so the extra little bit you might or might not be saving
this way pales in comparison to the added complexity.

The main reason there is no Rune support in the String
library is that it is not widely used.  It was written for upas
and later extracted, but the interface is a bit clunky.

I confess that most of the time, when I need to write to a
growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
It's just easier, and you get all the print verbs!

Russ

Re: [9fans] s_putc and Runes

[Bruce Ellis]

exactly.  time spent optimizing something that uses 3% of the CPU
by 10% is better spent going to the beach, or almost anything.

On 2/5/07, Russ Cox <rsc@swtch.com> wrote:
> > void
> > s_putrune(String *s, Rune r)
> > {
> >         char rbuf[UTFmax];
> >         s_nappend(s, rbuf, runetochar(rbuf, &r));
> > }
>
> This is fine.
>
> > or as part of the library (where I'm a bit shakier on the semantics):
> >
> > void
> > s_putrune(String *s, Rune r)
> > {
> >         char rbuf[UTFmax];
> >         int n;
> >         if(s->ref > 1)
> >                 sysfatal("can't s_putc a shared string");
> >         if (s->ptr >= s->end - n=runelen(r))
> >                 s_grow(s, n+1);
> >         (s->ptr) += runetochar(s->ptr, &r);
> > }
>
> Why bother with these details?  The above is fine.  If it ever
> became too slow, the right thing to do would be to fix s_nappend,
> not code around everything here.  Further, this code is *very*
> unlikely to be the bottleneck -- you're calling it once per at most
> 3 bytes, so the extra little bit you might or might not be saving
> this way pales in comparison to the added complexity.
>
> The main reason there is no Rune support in the String
> library is that it is not widely used.  It was written for upas
> and later extracted, but the interface is a bit clunky.
>
> I confess that most of the time, when I need to write to a
> growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
> It's just easier, and you get all the print verbs!
>
> Russ
>

Re: [9fans] s_putc and Runes

[erik quanstrom]

i think this is a very powerful idea.  although the
interface is high-level, and if you need to format a
structure, you need to write a print format, it results 
in a good old char*, not a String*.  the code that uses
String*s tends to have a fair percentage of code converting
between char* and String*.  in a few cases i've removed
30 or 40 lines of code by converting from a String* to a 
char*/*print because the conversion goo and String helper 
functions and conversion goo were no longer needed.

- erik

On Sun Feb  4 22:25:53 EST 2007, rsc@swtch.com wrote:
> I confess that most of the time, when I need to write to a
> growable string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.
> It's just easier, and you get all the print verbs!
> 
> Russ

Re: [9fans] s_putc and Runes

[Joel Salomon]

> I confess that most of the time, when I need to write to a growable
> string buffer, I just use fmtstrinit, fmtprint, and fmtstrflush.  It's
> just easier, and you get all the print verbs!

A unification of String and Fmt would be an interesting project, if I
had the time.  Maybe if someone needs/wants to implement a language
with a built-in string type…

--Joel

Re: [9fans] s_putc and Runes

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 5-Feb-07, at 11:52 AM, Joel Salomon wrote:
> Maybe if someone needs/wants to implement a language
> with a built-in string type…

That's crazy-talk.

;-)

Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFx6SrpJeHo/Fbu1wRAhGnAKCPibBrE9WPP38TT7aV9cbFyoxOKACfe68A
DfPmHYkqeDPGx5Z0HukrtGg=
=s/8V
-----END PGP SIGNATURE-----

Re: [9fans] s_putc and Runes

[Joel Salomon]

> > Maybe if someone needs/wants to implement a language
> > with a built-in string type…
> 
> That's crazy-talk.

“Then let’s talk crazy.” — Simon Tam

I’m taking a compilers course now.  All sorts of terrible ideas are
floating past my mind.  ☺

--Joel

Re: [9fans] s_putc and Runes

[Bruce Ellis]

well all of this was "solved" ten years ago, because limbo
has a well performing string type.  it's so convenient.

brucee

On 2/6/07, Joel Salomon <JoelCSalomon@gmail.com> wrote:
> > > Maybe if someone needs/wants to implement a language
> > > with a built-in string type…
> >
> > That's crazy-talk.
>
> "Then let's talk crazy." — Simon Tam
>
> I'm taking a compilers course now.  All sorts of terrible ideas are
> floating past my mind.  ☺
>
> --Joel
>
>