All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carles Pina i Estany <carles@pina.cat>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: gettext.c patch: reuse memory
Date: Sun, 29 Nov 2009 09:36:33 +0000	[thread overview]
Message-ID: <20091129093632.GA13778@pina.cat> (raw)
In-Reply-To: <20091129032801.GA2329@thorin>


Hello,

On Nov/29/2009, Robert Millan wrote:
> On Sun, Nov 29, 2009 at 12:49:50AM +0000, Carles Pina i Estany wrote:

[...]

> > With the attached patch, gettext module saves in a list the
> > translations.  So if a user asks again for the same translation it
> > returns the same pointer to the already allocated string instead of a
> > new one.

[...]

> How does GNU gettext handle this?  I suspect it could be simpler.

The part of code about is here:
http://cvs.savannah.gnu.org/viewvc/gettext/gettext-runtime/intl/dcigettext.c?revision=1.41&root=gettext&view=markup

(search for the line that contains "Since tfind/tsearch manage a
balanced tree")

I hope that I'm not mistaken: they use a balanced tree to re-use the
translations. Now we are using a list.

> For example, is it practical to allocate a big chunk of memory for the whole
> .mo, then return pointers to it?

I have thought to return a pointer to a const char* that gets reused on
the next _("XX"); (like QByteArray.data() in Qt). But this is not the
standard behaviour of gettext utils and one can have mistakes like:

const char* msg = _("hello %s");
grub_printf(_("Welcome..."));

grub_printf(msg,%user);

Where msg in the grub_printf has been already reused.

We can agree that gettext in Grub behaves in this way and force the
users to copy the strings (Solution B)

If I understood correctly Vladimir in the IRC suggested to translate on
the same char* that it's passed to _( ) (resize if needed), but I don't
like since it's not the standard behaviour and it's by definition a
const char* (for the cases that it's _("hello") , etc.)

In IRC we thought to implement the same behaviour with a hash table but
at the moment this doesn't look necessary at all and too complex for
what we need. But I'm open to keep discussing it.

I suspect that a Grub2 use will handle about 10 or 15 strings in memory.
And more strings if the user uses the Grub console, like maybe 100 or
200. The magnitude of the problem is to have 200 strings in memory that
are or are not being used. I have some functions to debug it, when I
will gettexttize more files I will the exact number.

So, the only thing that I would do is the first behaviour and force the
users the duplicate the strings. If we prefer so tell me and I will
implement it as soon as possible.

-- 
Carles Pina i Estany
	http://pinux.info



  reply	other threads:[~2009-11-29  9:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-29  0:49 gettext.c patch: reuse memory Carles Pina i Estany
2009-11-29  3:28 ` Robert Millan
2009-11-29  9:36   ` Carles Pina i Estany [this message]
2009-11-29 10:36 ` Carles Pina i Estany
2009-11-29 18:36   ` Carles Pina i Estany
2009-11-29 19:40     ` Carles Pina i Estany

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091129093632.GA13778@pina.cat \
    --to=carles@pina.cat \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.