Re: grub-install crash on GNU/Hurd
Am Sonntag, den 29.11.2009, 04:36 +0100 schrieb Samuel Thibault: Here is the patch agains, with -w Samuel Looks fine to me. -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: savannah Browse Sources Repository
Am Sonntag, den 29.11.2009, 04:30 +0100 schrieb Robert Millan: On Sun, Nov 29, 2009 at 01:49:02AM +, Carles Pina i Estany wrote: Hello, From this webpage: https://savannah.gnu.org/projects/grub/ Clicking on Browse Sources Repository (Bazaar one) appears: http://bzr.savannah.gnu.org/lh/grub I remember that last Sunday worked fine but not during the week. Maybe restoring the backup on Sunday after the incorrect merge something is not working? Or just a coincidence? Hi, The web frontend tends to break often. Anyway, there isn't much we can do about it. If you think it's necessary, you could file a problem report on Savannah admin project. I already did that but no reply from them :( https://savannah.gnu.org/support/?107133 -- Felix Zielcke Proud Debian Maintainer and GNU GRUB developer ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Just a cosmetic question about grub_vprintf()?
On Sat, Nov 28, 2009 at 06:21:20PM +, rubisher wrote:
Robert Millan wrote:
On Sun, Nov 22, 2009 at 01:10:11PM +, rubisher wrote:
But as far as the 1st parameter of grub_vsprintf is a pointer,
wouldn't it be better to write:
--- kern/misc.c.orig2009-11-22 13:07:22.0 +
+++ kern/misc.c 2009-11-22 13:07:51.0 +
@@ -160,7 +160,7 @@
{
int ret;
- ret = grub_vsprintf (0, fmt, args);
+ ret = grub_vsprintf (NULL, fmt, args);
return ret;
}
Yes. But we have many of those, so we don't go huntin' them. If you'd
like to help us, a patch that does this change in bulk would be welcome.
It will be of great pleasure for me, but I didn't foreseen so much (the
most difficult to me are 'opaque pointer') but I hoppe that such 'sparse'
would help me for the most ;)
If you do this, make sure you understand why it makes no difference in
standards-compliant C. In particular, this understanding matters when
functions with variable-length argument lists are concerned.
(See the C FAQ for more details.)
--
Colin Watson [cjwat...@ubuntu.com]
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext: --no-hash in msgmft
On Sat, Nov 28, 2009 at 08:02:47PM +0100, Robert Millan wrote: On Thu, Nov 26, 2009 at 01:52:38PM +0100, Jordi Mallach wrote: On Thu, Nov 26, 2009 at 12:31:45PM +, Colin Watson wrote: If nothing else, one could use something like 'msgunfmt - | msgfmt --no-hash -'; but I'd expect that we'd want to generate separate .mo files for /boot/grub anyway, since we don't need strings from util/ in there. Yes, we'd probably want to make two domains: grub and grub-kernel or whatever. Are you sure we want that? Some strings are shared. Having two domains for the output .mo files doesn't necessarily mean that you have to have separate .po files. I agree that we ought to have a single domain for the .po files. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext.c patch: reuse memory
Hello, On Nov/29/2009, Robert Millan wrote: On Sun, Nov 29, 2009 at 12:49:50AM +, 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.41root=gettextview=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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext.c patch: reuse memory
Hi,
Find attached a new version of the same patch (same approach).
Cheers,
--
Carles Pina i Estany
http://pinux.info
2009-11-29 Carles Pina i Estany car...@pina.cat
* gettext/gettext.c: Include `grub/list.h'. Define grub_gettext_msg,
grub_gettext_msg_list.
(grub_gettext_gettranslation_from_position): Return static const char *
and not static char *
(grub_gettext_translate): Add the translated strings into a list,
returns from the list if existing there.
(grub_gettext_delete_list): Delete the list.
(grub_gettext_env_write_lang): Call grub_gettext_delete_list changes
the language.
(GRUB_MOD_FINI): Delete the list.
=== modified file 'gettext/gettext.c'
--- gettext/gettext.c 2009-11-24 21:42:14 +
+++ gettext/gettext.c 2009-11-29 10:34:01 +
@@ -17,6 +17,7 @@
* along with GRUB. If not, see http://www.gnu.org/licenses/.
*/
+#include grub/list.h
#include grub/types.h
#include grub/misc.h
#include grub/mm.h
@@ -33,7 +34,6 @@
http://www.gnu.org/software/autoconf/manual/gettext/MO-Files.html .
*/
-
static grub_file_t fd_mo;
static int grub_gettext_offsetoriginal;
@@ -41,6 +41,16 @@ static int grub_gettext_max;
static const char *(*grub_gettext_original) (const char *s);
+struct grub_gettext_msg
+{
+ struct grub_gettext_msg *next;
+ const char *name;
+
+ const char *translated;
+};
+
+struct grub_gettext_msg *grub_gettext_msg_list = NULL;
+
#define GETTEXT_MAGIC_NUMBER 0
#define GETTEXT_FILE_FORMAT 4
#define GETTEXT_NUMBER_OF_STRINGS 8
@@ -79,7 +89,7 @@ grub_gettext_getstring_from_offset (grub
translation[length] = '\0';
}
-static char *
+static const char *
grub_gettext_gettranslation_from_position (int position)
{
int offsettranslation;
@@ -130,9 +140,18 @@ static const char *
grub_gettext_translate (const char *orig)
{
char *current_string;
- char *ret;
+ const char *ret;
int min, max, current;
+ int found = 0;
+
+ struct grub_gettext_msg *cur;
+
+ cur = grub_named_list_find (GRUB_AS_NAMED_LIST (grub_gettext_msg_list),
+ orig);
+
+ if (cur)
+return cur-translated;
if (fd_mo == 0)
return orig;
@@ -142,7 +161,7 @@ grub_gettext_translate (const char *orig
current = (max + min) / 2;
- while (current != min current != max)
+ while (current != min current != max found == 0)
{
current_string = grub_gettext_getstring_from_position (current);
@@ -160,13 +179,31 @@ grub_gettext_translate (const char *orig
else if (grub_strcmp (current_string, orig) == 0)
{
grub_free (current_string);
- return grub_gettext_gettranslation_from_position (current);
+ found = 1;
}
current = (max + min) / 2;
}
- ret = grub_malloc (grub_strlen (orig) + 1);
- grub_strcpy (ret, orig);
+ ret = found ? grub_gettext_gettranslation_from_position (current) : orig;
+
+ if (found)
+{
+ cur = grub_zalloc (sizeof (*cur));
+
+ if (cur)
+ {
+ cur-name = grub_strdup (orig);
+ if (cur-name)
+ {
+ cur-translated = ret;
+ grub_list_push (GRUB_AS_LIST_P (grub_gettext_msg_list),
+ GRUB_AS_LIST (cur));
+ }
+ }
+ else
+ grub_errno = GRUB_ERR_NONE;
+}
+
return ret;
}
@@ -259,12 +296,26 @@ grub_gettext_init_ext (const char *lang)
}
}
+static void
+grub_gettext_delete_list ()
+{
+ struct grub_gettext_msg *item;
+
+ while ((item =
+ grub_list_pop (GRUB_AS_LIST_P (grub_gettext_msg_list))) != 0)
+{
+ // Don't delete the translated message because could be in use.
+}
+}
+
static char *
grub_gettext_env_write_lang (struct grub_env_var *var
__attribute__ ((unused)), const char *val)
{
grub_gettext_init_ext (val);
+ grub_gettext_delete_list ();
+
return grub_strdup (val);
}
@@ -307,5 +358,7 @@ GRUB_MOD_FINI (gettext)
if (fd_mo != 0)
grub_file_close (fd_mo);
+ grub_gettext_delete_list ();
+
grub_gettext = grub_gettext_original;
}
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
2009/11/28 Qianqian Fang fan...@gmail.com: Michal Suchanek wrote: Given the 1-bit bitmap limitation most glyphs look pretty good but the 灱 glyph just above the UmingCN title in the taskbar is particularly ugly. Is this an expected limitation of this rendering method that some glyphs simply turn out ugly or is this a bug in the font? ok, now I see which glyph you were talking about. No, to me, 灱 is not particularly ugly. It has comparable quality to others. They are definitely sub-optimal compared with the manually hinted bitmaps, but they are usable for this size. It's good enough to read the character but if I designed a theme with this character in some large caption I would immediately start looking for a font that has a decent glyph for this character. It's far from nice to look at. Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
gettext: install the *.mo files
Hello,
Find attached a patch to install the *.mo files.
I've tested grub-mkrescue.in but not grub-install.in (yet)
Using for + if + cp and not cp with wildcards to really check that the
files exists and so on (like other parts of the file).
Comments?
Thanks,
--
Carles Pina i Estany
http://pinux.info
2009-11-29 Carles Pina i Estany car...@pina.cat
* util/grub-install.in: Install the gettext .mo files.
* util/grub-mkrescue.in (process_input_dir): Copy the gettext .mo
files
=== modified file 'util/grub-install.in'
--- util/grub-install.in 2009-11-12 12:23:11 +
+++ util/grub-install.in 2009-11-29 11:21:46 +
@@ -247,6 +247,14 @@ if [ ${target_cpu}-${platform} = i386
done
fi
+# Copy gettext files
+mkdir -p ${grubdir}/locale/
+for file in ${grubdir}/locale/*.mo ${pkglibdir}/locale/*.mo; do
+if test -f $file; then
+cp -f $file ${grubdir}/locale/
+fi
+done
+
# Write device to a variable so we don't have to traverse /dev every time.
grub_device=`$grub_probe --target=device ${grubdir}`
=== modified file 'util/grub-mkrescue.in'
--- util/grub-mkrescue.in 2009-11-21 16:40:55 +
+++ util/grub-mkrescue.in 2009-11-29 11:17:46 +
@@ -100,6 +100,13 @@ process_input_dir ()
cp -f $file ${iso9660_dir}/boot/grub/${target_cpu}-${platform}/
fi
done
+
+mkdir -p ${iso9660_dir}/boot/grub/locale
+for file in ${input_dir}/po/*.mo; do
+if test -f $file; then
+ cp -f $file ${iso9660_dir}/boot/grub/locale/
+ fi
+done
}
if [ ${override_dir} = ] ; then
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
New Chinese (simplified) PO file for 'grub' (version 1.97+20091122)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'grub' has been submitted by the Chinese (simplified) team of translators. The file is available at: http://translationproject.org/latest/grub/zh_CN.po (This file, 'grub-1.97+20091122.zh_CN.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/grub/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/grub.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Contents of PO file 'grub-1.97+20091122.zh_CN.po'
grub-1.97+20091122.zh_CN.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Faster glyph lookup by BMP index
Hello. Basic Multilingual Plane is range of Unicode characters in
0-65535 and it contains most of the characters needed by most of the
languages of the world. By keeping an array with pointers to such
characters at the cost of 128KiB per font we can almost instantenously
lookup characters which are likely to be used in grub. Available in
experimental
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
=== added file 'ChangeLog.bmpidx'
--- ChangeLog.bmpidx 1970-01-01 00:00:00 +
+++ ChangeLog.bmpidx 2009-11-29 14:17:03 +
@@ -0,0 +1,9 @@
+2009-11-29 Vladimir Serbinenko phco...@gmail.com
+
+ Optimise glyph lookup by Basic Multilingual Plane lookup array.
+
+ * font/font.c (struct grub_font): New member 'bmp_idx'.
+ (font_init): Initialise 'bmp_idx'.
+ (load_font_index): Fill 'bmp_idx'.
+ (find_glyph): Make inline. Use bmp_idx for BMP characters.
+
=== modified file 'font/font.c'
--- font/font.c 2009-07-20 17:37:37 +
+++ font/font.c 2009-11-29 13:24:58 +
@@ -58,6 +58,7 @@ struct grub_font
short leading;
grub_uint32_t num_chars;
struct char_index_entry *char_index;
+ grub_uint16_t *bmp_idx;
};
/* Definition of font registry. */
@@ -180,6 +181,7 @@ font_init (grub_font_t font)
font-descent = 0;
font-num_chars = 0;
font-char_index = 0;
+ font-bmp_idx = 0;
}
/* Open the next section in the file.
@@ -273,6 +275,14 @@ load_font_index (grub_file_t file, grub_
* sizeof (struct char_index_entry));
if (! font-char_index)
return 1;
+ font-bmp_idx = grub_malloc (0x1 * sizeof (grub_uint16_t));
+ if (! font-bmp_idx)
+{
+ grub_free (font-char_index);
+ return 1;
+}
+ grub_memset (font-bmp_idx, 0xff, 0x1 * sizeof (grub_uint16_t));
+
#if FONT_DEBUG = 2
grub_printf(num_chars=%d)\n, font-num_chars);
@@ -299,6 +309,9 @@ load_font_index (grub_file_t file, grub_
return 1;
}
+ if (entry-code 0x1)
+ font-bmp_idx[entry-code] = i;
+
last_code = entry-code;
/* Read storage flags byte. */
@@ -594,7 +607,7 @@ read_be_int16 (grub_file_t file, grub_in
/* Return a pointer to the character index entry for the glyph corresponding to
the codepoint CODE in the font FONT. If not found, return zero. */
-static struct char_index_entry *
+static inline struct char_index_entry *
find_glyph (const grub_font_t font, grub_uint32_t code)
{
struct char_index_entry *table;
@@ -602,8 +615,17 @@ find_glyph (const grub_font_t font, grub
grub_size_t hi;
grub_size_t mid;
- /* Do a binary search in `char_index', which is ordered by code point. */
table = font-char_index;
+
+ /* Use BMP index if possible. */
+ if (code 0x1)
+{
+ if (font-bmp_idx[code] == 0x)
+ return 0;
+ return table[font-bmp_idx[code]];
+}
+
+ /* Do a binary search in `char_index', which is ordered by code point. */
lo = 0;
hi = font-num_chars - 1;
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Michal Suchanek wrote: It's good enough to read the character but if I designed a theme with this character in some large caption I would immediately start looking for a font that has a decent glyph for this character. It's far from nice to look at. I was talking about rasterization quality, do you mean the aesthetics of the glyph topology/structure? However, I am pretty sure you don't need to worry about 灱 because it is an extremely rarely used character and was only used in ancient literatures. As a matter of fact, in the over 20,000 Han char. included in the fonts I mentioned, the top 3,000~4,000 covers 99.6% of the use in modern Chinese [1]. [1] http://www.jiyili.net/thread-27521-1-1.html (based on a national survey in 1980s) Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Qianqian Fang wrote: Michal Suchanek wrote: It's good enough to read the character but if I designed a theme with this character in some large caption I would immediately start looking for a font that has a decent glyph for this character. It's far from nice to look at. I was talking about rasterization quality, do you mean the aesthetics of the glyph topology/structure? However, I am pretty sure you don't need to worry about 灱 because it is an extremely rarely used character and was only used in ancient literatures. As a matter of fact, in the over 20,000 Han char. included in the fonts I mentioned, the top 3,000~4,000 covers 99.6% of the use in modern Chinese [1]. Is it possible to have a font with only these characters plus if necessary some computer-specific characters? I don't expect users to write poems in grub and so such reduced font would be well-suited for applications when size matters (e.g. embedding grub2 into flash rom) Another question: are glyphs imported into unifont from ttf fonts are vector-based? And also I would like to thank you and Michal that you answered most of the questions I had about Chinese support even without me asking them :) [1] http://www.jiyili.net/thread-27521-1-1.html (based on a national survey in 1980s) Thanks Michal ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Faster glyph lookup by BMP index
Is this table stored in the file or built during font load? 128KiB in memory is no issue at all on modern systems, 128KiB in a file is somewhat more troublesome since it won't fit in a boot sector, is a big chunk of a rescue diskette, and the I/O cost is noticeable. These glyphs are stored in sorted order in the file, correct? May I suggest that only every Nth index be stored in the file header (where N = 16 for example) and the intermediate ones discovered at runtime, in those subranges containing a character actually used (and the indexes and character data for those glyphs are then cached in memory)? This also means block reads from the file (block length is easily calculated as the difference of two adjacent indices) instead of extraction of individual characters, most languages tend to have good locality so this should also be a win. Or is the entire font file cached in memory anyway? 2009/11/29 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Hello. Basic Multilingual Plane is range of Unicode characters in 0-65535 and it contains most of the characters needed by most of the languages of the world. By keeping an array with pointers to such characters at the cost of 128KiB per font we can almost instantenously lookup characters which are likely to be used in grub. Available in experimental -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Faster glyph lookup by BMP index
richardvo...@gmail.com wrote: Is this table stored in the file or built during font load? This table is generated on file load 2009/11/29 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com: Hello. Basic Multilingual Plane is range of Unicode characters in 0-65535 and it contains most of the characters needed by most of the languages of the world. By keeping an array with pointers to such characters at the cost of 128KiB per font we can almost instantenously lookup characters which are likely to be used in grub. Available in experimental -- Regards Vladimir 'φ-coder/phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Vladimir 'φ-coder/phcoder' Serbinenko wrote: Is it possible to have a font with only these characters plus if necessary some computer-specific characters? I don't expect users to write poems in grub and so such reduced font would be well-suited for applications when size matters (e.g. embedding grub2 into flash rom) certainly we can. However the problem is I don't have char-frequency statistics for Japanese Kanji/Korean Hanja, also even for Chinese, it's from 1980s. We can try IICore [1], which has about 10,000 char. [1] http://www.ogcio.gov.hk/ccli/eng/structure/iicorecompare.html Another question: are glyphs imported into unifont from ttf fonts are vector-based? no, they are manually drawn, similar for WenQuanYi's bitmaps. Only that way, you can ensure the clearest look in small glyph sizes (and it took years). ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext.c patch: reuse memory
Hi,
On Nov/29/2009, Carles Pina i Estany wrote:
Find attached a new version of the same patch (same approach).
new one. Original strings can be free-ed.
Just some numbers: if there are 1000 strings used (far too much! Grub
loader will not have so much or users will not use in the same session)
and each string is 50 characters (far too much too :-) ) strings are
usually shorter) and the translation is 50 characters the list will use
aprox. 100 KB.
(50 + 50) * 1000 / 1024 = 97.65 KB
(very rough numbers discarting 1000 pointers to next and 2000 pointers
to the original and translation strings, this would be aprox. 11.71 KB
more)
Cheers,
--
Carles Pina i Estany
http://pinux.info
=== modified file 'gettext/gettext.c'
--- gettext/gettext.c 2009-11-24 21:42:14 +
+++ gettext/gettext.c 2009-11-29 18:29:02 +
@@ -17,6 +17,7 @@
* along with GRUB. If not, see http://www.gnu.org/licenses/.
*/
+#include grub/list.h
#include grub/types.h
#include grub/misc.h
#include grub/mm.h
@@ -33,7 +34,6 @@
http://www.gnu.org/software/autoconf/manual/gettext/MO-Files.html .
*/
-
static grub_file_t fd_mo;
static int grub_gettext_offsetoriginal;
@@ -41,6 +41,16 @@ static int grub_gettext_max;
static const char *(*grub_gettext_original) (const char *s);
+struct grub_gettext_msg
+{
+ struct grub_gettext_msg *next;
+ const char *name;
+
+ const char *translated;
+};
+
+struct grub_gettext_msg *grub_gettext_msg_list = NULL;
+
#define GETTEXT_MAGIC_NUMBER 0
#define GETTEXT_FILE_FORMAT 4
#define GETTEXT_NUMBER_OF_STRINGS 8
@@ -79,7 +89,7 @@ grub_gettext_getstring_from_offset (grub
translation[length] = '\0';
}
-static char *
+static const char *
grub_gettext_gettranslation_from_position (int position)
{
int offsettranslation;
@@ -130,9 +140,18 @@ static const char *
grub_gettext_translate (const char *orig)
{
char *current_string;
- char *ret;
+ const char *ret;
int min, max, current;
+ int found = 0;
+
+ struct grub_gettext_msg *cur;
+
+ cur = grub_named_list_find (GRUB_AS_NAMED_LIST (grub_gettext_msg_list),
+ orig);
+
+ if (cur)
+return cur-translated;
if (fd_mo == 0)
return orig;
@@ -142,7 +161,7 @@ grub_gettext_translate (const char *orig
current = (max + min) / 2;
- while (current != min current != max)
+ while (current != min current != max found == 0)
{
current_string = grub_gettext_getstring_from_position (current);
@@ -160,13 +179,31 @@ grub_gettext_translate (const char *orig
else if (grub_strcmp (current_string, orig) == 0)
{
grub_free (current_string);
- return grub_gettext_gettranslation_from_position (current);
+ found = 1;
}
current = (max + min) / 2;
}
- ret = grub_malloc (grub_strlen (orig) + 1);
- grub_strcpy (ret, orig);
+ ret = found ? grub_gettext_gettranslation_from_position (current) : orig;
+
+ if (found)
+{
+ cur = grub_zalloc (sizeof (*cur));
+
+ if (cur)
+ {
+ cur-name = grub_strdup (orig);
+ if (cur-name)
+ {
+ cur-translated = ret;
+ grub_list_push (GRUB_AS_LIST_P (grub_gettext_msg_list),
+ GRUB_AS_LIST (cur));
+ }
+ }
+ else
+ grub_errno = GRUB_ERR_NONE;
+}
+
return ret;
}
@@ -259,12 +296,29 @@ grub_gettext_init_ext (const char *lang)
}
}
+static void
+grub_gettext_delete_list ()
+{
+ struct grub_gettext_msg *item;
+
+ while ((item =
+ grub_list_pop (GRUB_AS_LIST_P (grub_gettext_msg_list))) != 0)
+{
+ char* original = (char*) ((struct grub_gettext_msg *) item)-name;
+ grub_free (original);
+
+ // Don't delete the translated message because could be in use.
+}
+}
+
static char *
grub_gettext_env_write_lang (struct grub_env_var *var
__attribute__ ((unused)), const char *val)
{
grub_gettext_init_ext (val);
+ grub_gettext_delete_list ();
+
return grub_strdup (val);
}
@@ -307,5 +361,7 @@ GRUB_MOD_FINI (gettext)
if (fd_mo != 0)
grub_file_close (fd_mo);
+ grub_gettext_delete_list ();
+
grub_gettext = grub_gettext_original;
}
2009-11-29 Carles Pina i Estany car...@pina.cat
* gettext/gettext.c: Include `grub/list.h'. Define grub_gettext_msg,
grub_gettext_msg_list.
(grub_gettext_gettranslation_from_position): Return static const char *
and not static char *
(grub_gettext_translate): Add the translated strings into a list,
returns from the list if existing there.
(grub_gettext_delete_list): Delete the list.
(grub_gettext_env_write_lang): Call grub_gettext_delete_list changes
the language.
(GRUB_MOD_FINI): Delete the list.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
var=foo should be valid?
Hello, Right now in Grub2 a user could do: name=john set name=john both are valid. (first one has a bug but very easy to fix, even thought I would maybe refactor this code to implement in other way) Question that arised in IRC: should be support the first one or not? Two interfaces for the same thing? -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: var=foo should be valid?
Hi, On Nov/29/2009, Carles Pina i Estany wrote: Right now in Grub2 a user could do: name=john set name=john both are valid. (first one has a bug but very easy to fix, even thought I would maybe refactor this code to implement in other way) Question that arised in IRC: should be support the first one or not? Two interfaces for the same thing? my opinion: doesn't matter (a lot) And because doesn't matter: we can only accept set name=john. So we avoid bugs like it happened now, more simple and users wondering if there are two ways means that set is doing something that it's not happening in name=foo, maybe setting a reference and not copying the string*? maybe exporting**?. *: happens in VBA **: someone could think that if we accept without and with set it's exporting like export name=foo in Bash -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: var=foo should be valid?
Hi, On Nov/29/2009, Carles Pina i Estany wrote: And because doesn't matter: we can only accept set name=john. s/we can/we should/ (more clear) -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Qianqian Fang wrote: Vladimir 'φ-coder/phcoder' Serbinenko wrote: Is it possible to have a font with only these characters plus if necessary some computer-specific characters? I don't expect users to write poems in grub and so such reduced font would be well-suited for applications when size matters (e.g. embedding grub2 into flash rom) certainly we can. However the problem is I don't have char-frequency statistics for Japanese Kanji/Korean Hanja, AFAIK Hanja isn't used a lot and in GRUB2 particularly I see only names which could possibly use Hanja. Also quick look into ko.po of glibc doesn't reveal any Hanja (even that I can't read either they have different appearence). But due to nature of Hangul of being basically arranged syllables out of Jamo we need to include whole 111712 precomposed Hangul. And since even important font rendering engines prefered to stay away from Jamo composing except when with historical Jamo I feel like it would be inappropriate to make it in GRUB. As for Kanji we could stick to Jōyō kanji [http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji] (I think we can reasonably suppose that all kanji needed for grub2 are within the school scope) However I don't pretend to be expert in either Kanji, Hanja, Hangul or Hanzi, so feel free to correct me. also even for Chinese, it's from 1980s. Are there any reasons to believe more sinograms came into general usage and may be used by grub since then? Will have anyway to have computer-specific glyphs too. Is the list you provided about Traditional or Simplified Chinese? What about the other variant? We can try IICore [1], which has about 10,000 char. General-usage fonts are good since they are likely to contain all useful (for GRUB) glyphs. It just starts to look that we can't significantly reduce the size of unifont by removing not-so-useful glyphs. 1 for Simplified Chinese, 1 for Traditional Chinese and 1 for Hangul and we already have half of BMP/unifont [1] http://www.ogcio.gov.hk/ccli/eng/structure/iicorecompare.html Another question: are glyphs imported into unifont from ttf fonts are vector-based? no, they are manually drawn, similar for WenQuanYi's bitmaps. Only that way, you can ensure the clearest look in small glyph sizes (and it took years). Wow as a coder I would never have supposed that rasterisation would take so much time and human intervention ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: gettext.c patch: reuse memory
Hi, On Nov/29/2009, Carles Pina i Estany wrote: Just some numbers: if there are 1000 strings used (far too much! Grub loader will not have so much or users will not use in the same session) and each string is 50 characters (far too much too :-) ) strings are usually shorter) and the translation is 50 characters the list will use aprox. 100 KB. (50 + 50) * 1000 / 1024 = 97.65 KB I think that this is more like (7 + 7) * 60 = 840 bytes, less than 1 KB. One approach is that we use the list for now and I prepare a benchmark code (it's very easy). When more things are translated we can reconsider it with some numbers and not guesses and I think. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
handling mount points in grub-mkrelpath
Vladimir wanted to have this discussed on ML
The old shell function make_system_path_relative_to_its_root outputed /
if you gave it /boot and it was on a seperate partition.
grub-mkrelpath currently outputs /boot
This breaks booting at least with the 10_linux generated entries.
Attached is my fix for that, which I'll update today to Debian.
We already broke backward compatibility with the commandline for Xen.
IMO in this grub-mkrelpath case there's no need to break compatibility.
But maybe I can find a good way to handle this inside
util/grub-mkconfig_lib.in just for compatibility.
--
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer
2009-11-29 Felix Zielcke fziel...@z-51.de
* util/misc.c (make_system_path_relative_to_its_root): Correctly cope with
mount points.
=== modified file 'util/misc.c'
--- util/misc.c 2009-11-25 23:10:02 +
+++ util/misc.c 2009-11-29 19:19:28 +
@@ -500,7 +500,17 @@ make_system_path_relative_to_its_root (c
/* buf is another filesystem; we found it. */
if (st.st_dev != num)
- break;
+ {
+ /* offset == 0 means path given is the mount point. */
+ if (offset == 0)
+ {
+ free (buf);
+ free (buf2);
+ return strdup (/);
+ }
+ else
+ break;
+ }
offset = p - buf;
/* offset == 1 means root directory. */
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: fonts for gfxmenu, help needed
Vladimir 'φ-coder/phcoder' Serbinenko wrote: AFAIK Hanja isn't used a lot and in GRUB2 particularly I see only names which could possibly use Hanja. Also quick look into ko.po of glibc doesn't reveal any Hanja (even that I can't read either they have different appearence). But due to nature of Hangul of being basically arranged syllables out of Jamo we need to include whole 111712 precomposed Hangul. And since even important font rendering engines prefered to stay away from Jamo composing except when with historical Jamo I feel like it would be inappropriate to make it in GRUB. As for Kanji we could stick to Jōyō kanji [http://en.wikipedia.org/wiki/J%C5%8Dy%C5%8D_kanji] (I think we can reasonably suppose that all kanji needed for grub2 are within the school scope) However I don't pretend to be expert in either Kanji, Hanja, Hangul or Hanzi, so feel free to correct me. I am pretty sure there are a lot of options. But at this point, I think I need a clear plan on 1) what pixel sizes, 2) what the number of Hanzi characters and 3) what font styles (song/hei) does grub project need. In my previous emails, I summarized the resources that I know of, including 1) free pan-unifont vector fonts that cover most CJK/nonCJK scripts 2) bitmap fonts that have CJK coverage at smaller font sizes 3) a procedure to produce better quality rasterization from vector fonts using fontforge With these, I think you can pretty much do any combination/slicing you want. I would be glad help to make these bitmap fonts once you decide the specs on the fonts (listed above) Are there any reasons to believe more sinograms came into general usage and may be used by grub since then? Will have anyway to have computer-specific glyphs too. no, I don't think so. Ideographic characters are quite stable now. For general usage, the charset is fixed. What get evolved are their combinations, which we called words, for example, 电脑，手机. All these characters are ancient, but the combinations represent something new. Is the list you provided about Traditional or Simplified Chinese? What about the other variant? IICore is a combination of simplified/traditional/japanese/korean. http://translate.googleusercontent.com/translate_c?hl=enie=UTF-8sl=zh-CNtl=enu=http://zh.wikipedia.org/wiki/%25E5%259C%258B%25E9%259A%259B%25E8%25A1%25A8%25E6%2584%258F%25E6%2596%2587%25E5%25AD%2597%25E6%25A0%25B8%25E5%25BF%2583prev=_trurl=translate.google.comtwu=1usg=ALkJrhiQIu8BQBujT7zze99y_BlwfOCxZQ General-usage fonts are good since they are likely to contain all useful (for GRUB) glyphs. It just starts to look that we can't significantly reduce the size of unifont by removing not-so-useful glyphs. 1 for Simplified Chinese, 1 for Traditional Chinese and 1 for Hangul and we already have half of BMP/unifont Maybe start with full BMP and see if you have any particular difficulties coming up. Re-slice a BDF file is quite eazy. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
