kc3-lang/libxkbcommon/src/xkbcomp/rules.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
42b2c934 | 2012-08-03 03:22:48 | Print failed include paths on failure to find rules Thus giving a hint as to which directory we're trying to find. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
 |
89723b7c | 2012-07-24 19:54:14 | utils: add/replace string equality macros It's more tidy and less error prone, since we use strcasecmp == 0 a lot. We replace strcmp == 0 by streq, strcasecmp == 0 by istreq, uStrCasePrefix by istreq_prefix and uDupString by strdup_safe. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3bb3e9c3 | 2012-07-21 15:19:27 | rules: use new log functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9308a460 | 2012-07-17 10:20:15 | Run source tree through uncrustify .uncrustify.cfg committed for future reference also, but had to manually fix up a few things: it really likes justifying struct initialisers. Signed-off-by: Daniel Stone <daniel@fooishbar.org> | |
|
19f814f9 | 2012-07-11 14:08:28 | rules: fix parsing of multiple options This was broken by commit 18d331b86b4942ba54fe087ca07e47c9383d768b (where only the first option out of a comma-separated string was matched). Do it correctly this time and add a test. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
37f43849 | 2012-06-30 00:49:41 | rules: remove support for keymap rule This commit removes the ability to specify a keymap *in a rules file*, e.g. in /usr/share/X11/xkb/rules/evdev or somesuch. This is unused in xkeyboard-data, and the current code has never even supported it, because xkb_map_new_from_kccgst (which is no longer exposed in the API) checks to see that one of the usual components (e.g. symbols, types, ..) has been filled, while the rules parser, on the other hand, doesn't allow to specify a keymap and other stuff at the same time. ( The idea was to remove xkb_map_new_from_kccgst entirely, but it's used by a test so it can stay. ) tl;dr: dead code. Of course passing a keymap file to xkb_map_new_from_file still works. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
48b4d30a | 2012-06-29 17:05:33 | Use enum for file types enums are nice for some type safety and readability. This one also removes the distinction between file type mask / file type index and some naming consistency. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bc50cdd4 | 2012-06-05 18:46:24 | darray: some changes for convenience - Make darray_free also initialize the array back to an empty state, and stop worrying about it everywhere. - Add darray_mem, to access the underlying memory, which we do manually now using &darray_item(arr, 0). This makes a bit more clear when we actually mean to take the address of a specific item. - Add darray_copy, to make a deep copy of a darray. - Add darray_same, to test whether two darrays have the same underlying memory (e.g. if the struct itself was value copied). This should used where previously two arrays were compared for pointer equality. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
57f184e2 | 2012-05-30 15:55:21 | darray: tweak parameters a bit for better memory usage Here are some quick numbers from valgrind, running rulescomp only with a simple, common "us,de" rule set: before darray: cb047bb total heap usage: 44,924 allocs, 44,924 frees, 3,162,342 bytes allocated after darray: c87468e total heap usage: 52,670 allocs, 52,670 frees, 2,844,517 bytes allocated tweaking specific inital allocation sizes: total heap usage: 52,652 allocs, 52,652 frees, 2,841,814 bytes allocated changing initial alloc = 2 globally total heap usage: 47,802 allocs, 47,802 frees, 2,833,614 bytes allocated changing initial alloc = 3 globally total heap usage: 47,346 allocs, 47,346 frees, 3,307,110 bytes allocated changing initial alloc = 4 globally total heap usage: 44,643 allocs, 44,643 frees, 2,853,646 bytes allocated [ Changing the geometric progression constant from 2 only made things worse. I tried the golden ratio - not so golden :) ] The last one is obviously the best, so it was chosen, with the specific tweaks thrown in as well (these were there before but don't make much difference). Overall it seems to do better than the previous manual allocations which is a bit surprising. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0c271e09 | 2012-05-22 00:14:34 | rules: use darray for input line Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
28bbb7dc | 2012-05-21 23:47:44 | rules: use darray for rules and groups Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
68edd5f0 | 2012-05-19 12:50:47 | rules: allow wildcard match against "" layout/varaint Currently, if you pass in an rmlvo with an empty string for layout or variant, it would not match layout and variant rules even with wildcards. But if the rules file had set an appropriate default, and someone passes in the empty string, than he should get the default. NULL in this case signifies not wanting to match against the layout or variant at all, and so the rule should still fail to match NULLs. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c900c417 | 2012-05-19 01:00:52 | rules: remove struct var_defs We can just use struct xkb_rule_names which we already receive as an argument. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3d28b6d1 | 2012-05-19 00:53:57 | rules: reformat components_from_rules Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
7895eeb8 | 2012-05-18 19:39:25 | rules: reformat LoadRules and XkbRF_Free Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d18cf315 | 2012-05-18 19:37:01 | rules: remove unused struct describe_vars It's not actually used for anything. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
56b125fc | 2012-05-18 18:38:06 | rules: reformat AddRule and AddGroup Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f790257f | 2012-05-18 18:34:47 | rules: reformat GetComponents Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
52939d4b | 2012-05-18 18:25:59 | rules: reformat SubstituteVars Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a9477b57 | 2012-05-18 12:02:29 | rules: reformat CheckApplyRules and ApplyPartialMatches Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a47dd252 | 2012-05-18 10:43:24 | rules: reformat CheckGroup and CheckApplyRule Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
18d331b8 | 2012-05-18 11:01:20 | rules: rewrite MatchOneOf Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c02c9ab2 | 2012-05-18 10:33:38 | rules: reformat ApplyRule Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
06205717 | 2012-05-18 02:53:29 | rules: reformat MakeMultiDefs Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f7de6286 | 2012-05-18 02:20:14 | rules: use asprintf instead of _Concat function Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5f54764d | 2012-05-17 16:15:46 | rules: reformat CheckLine and break into several functions And remove struct file_spec which is really unneeded. Should be slightly more clear now. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2df35895 | 2012-05-17 14:18:31 | rules: reformat SetUpRemap and struct remap_spec Rename to more descriptive names and reformat. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b8ae68c2 | 2012-05-17 13:55:38 | rules: rewrite get_index to use sscanf Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
ef76ba97 | 2012-05-16 10:09:03 | rules: don't typedef the structs and rename them The long prefix is unnecessary now that they are all private. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
478a6a31 | 2012-05-16 09:49:32 | rules: reformat input line handling Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
72d1f2ed | 2012-05-16 09:39:01 | rules: don't use custom logging functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b73bd676 | 2012-05-13 09:49:08 | rules: only export a single function Really all we need from this file is a way to get xkb_component_names from an xkb_rule_names, which is now the only thing being exposed. This should allow for some much needed refactoring of this code. Since this is only used by xkbcomp.c and uses xkbcomp functions, also move rules.{c,h} under the xkbcomp dir. Signed-off-by: Ran Benita <ran234@gmail.com> |