- 04 Apr, 2022 1 commit
-
-
- 10 Feb, 2022 1 commit
-
-
Rico Tzschichholz authored
-
- 30 Jan, 2022 1 commit
-
-
Rico Tzschichholz authored
-
- 30 Nov, 2021 1 commit
-
-
Include Makefile.introspection instead of using a custom rule which will result in the following build failure when cross-compiling on buildroot because of missing --includedir: /home/giuliobenetti/autobuild/run/instance-1/output-1/host/bin/../riscv32-buildroot-linux-gnu/sysroot/usr/bin/g-ir-compiler -l `/usr/bin/sed -nE "s/^dlname='([A-Za-z0-9.+-]+)'/\1/p" libgee-0.8.la` -o Gee-0.8.typelib Gee-0.8.gir libgee-0.8.la Could not find GIR file 'GObject-2.0.gir'; check XDG_DATA_DIRS or use --includedir error parsing file Gee-0.8.gir: Failed to parse included gir GObject-2.0 Fixes: - http://autobuild.buildroot.org/results/884faa0f84c8dc43ed1ca6cde9caf21c731a4b35 Signed-off-by:
Fabrice Fontaine <fontaine.fabrice@gmail.com>
-
- 15 Oct, 2021 1 commit
-
-
Rico Tzschichholz authored
-
- 17 Mar, 2021 1 commit
-
-
Rico Tzschichholz authored
-
- 07 Mar, 2021 1 commit
-
-
Rico Tzschichholz authored
-
- 05 Feb, 2021 1 commit
-
-
Rico Tzschichholz authored
-
- 23 Oct, 2020 1 commit
-
-
- 09 Feb, 2020 1 commit
-
-
Rico Tzschichholz authored
-
- 25 Nov, 2019 1 commit
-
-
Rico Tzschichholz authored
-
- 05 Oct, 2019 1 commit
-
-
Rico Tzschichholz authored
It is possible that a spurious or stolen wakeup could occur. For that reason, waiting on a condition variable should always be in a loop, based on an explicitly-checked predicate. Fixes #34
-
- 25 Sep, 2019 1 commit
-
-
Rico Tzschichholz authored
-
- 05 Aug, 2019 1 commit
-
-
Rico Tzschichholz authored
-
- 01 Apr, 2019 3 commits
-
-
Rico Tzschichholz authored
-
Rico Tzschichholz authored
-
Rico Tzschichholz authored
-
- 14 Mar, 2019 1 commit
-
-
Rico Tzschichholz authored
-
- 16 Dec, 2018 3 commits
-
-
Andre Klapper authored
-
Andre Klapper authored
-
Andre Klapper authored
-
- 11 Feb, 2018 2 commits
-
-
Maciej (Matthew) Piechotka authored
-
Maciej (Matthew) Piechotka authored
This reverts commit da95e830.
-
- 11 Dec, 2017 2 commits
-
-
* one_match (Predicate<G>) check if exactly one element matches * count_match (Predicate<G>) returns the count of items that matches https://bugzilla.gnome.org/show_bug.cgi?id=781641
-
Rico Tzschichholz authored
-
- 12 Sep, 2017 1 commit
-
-
Rico Tzschichholz authored
-
- 21 Mar, 2017 1 commit
-
-
Maciej (Matthew) Piechotka authored
-
- 23 Feb, 2017 2 commits
-
-
Maciej (Matthew) Piechotka authored
-
Maciej (Matthew) Piechotka authored
-
- 17 Jan, 2017 1 commit
-
-
* first_match (Predicate<G>) returns the first item that matches * any_match (Predicate<G>) checks if any element matches * all_match (Predicate<G>) checks if all elements match * max/min returns max/min value * order_by to perform ordering on any Traversable https://bugzilla.gnome.org/show_bug.cgi?id=776558
-
- 14 Dec, 2016 1 commit
-
-
Rico Tzschichholz authored
-
- 23 Nov, 2016 1 commit
-
-
Enumerations and flags are classed types for Vala, not integers, so they don't fall in the `typeof(G) == typeof(int)` kind of tests. This leads to using the generic code in which Vala assumes pointer-sized elements, which is often not true for enumerations and flags. Add special case for those to use the `int` converters for enumerations and flags. This is most generally correct, but not always: the compiler will likely chose a larger type for a specific enumeration if one of its value is larger than `int`. It would be tempting to use the enumeration's class minimum and maximum values to determine the appropriate type, but unfortunately the API for this uses int itself, so doesn't help. https://bugzilla.gnome.org/show_bug.cgi?id=774669
-
- 12 Oct, 2016 2 commits
-
-
Maciej (Matthew) Piechotka authored
-
Discussed this briefly with upstream on IRC, and it was concluded that this should probably have been forbidden by the Vala compiler in the first place. https://bugzilla.gnome.org/show_bug.cgi?id=772417
-
- 11 Oct, 2016 1 commit
-
-
Same issue in HashMap and TreeMap: ``` ==3251==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000000870 at pc 0x000108be666b bp 0x7fff571e62b0 sp 0x7fff571e62a8 WRITE of size 8 at 0x604000000870 thread T0 #0 0x108be666a in g_nullify_pointer gutils.c:2051 #1 0x108b8c906 in weak_refs_notify gobject.c:2638 #2 0x108bbb17c in g_data_set_internal gdataset.c:407 #3 0x108b887db in g_object_unref gobject.c:3148 #4 0x108a4b0ec in map_tests_test_entry_weak_pointer_lifetime testmap.c:1358 0x604000000870 is located 32 bytes inside of 40-byte region [0x604000000850,0x604000000878) freed by thread T0 here: #0 0x1090f0e29 in wrap_free (libclang_rt.asan_osx_dynamic.dylib+0x4ae29) #1 0x108ace566 in gee_hash_map_unset_helper hashmap.c:1692 #2 0x108acc534 in gee_hash_map_real_unset hashmap.c:1520 #3 0x108a4b0df in map_tests_test_entry_weak_pointer_lifetime testmap.c:1357 previously allocated by thread T0 here: #0 0x1090f0c60 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib+0x4ac60) #1 0x108bce848 in g_malloc gmem.c:95 #2 0x108bd6585 in g_slice_alloc gslice.c:1012 #3 0x108bd6bee in g_slice_alloc0 gslice.c:1038 #4 0x108acdc27 in gee_hash_map_node_new hashmap.c:2084 #5 0x108acc277 in gee_hash_map_real_set hashmap.c:1494 #6 0x108a4b032 in map_tests_test_entry_weak_pointer_lifetime testmap.c:1311 https://bugzilla.gnome.org/show_bug.cgi?id=772418
-
- 29 Sep, 2016 2 commits
- 27 Sep, 2016 2 commits
-
-
Jürg Billeter authored
-
Jürg Billeter authored
-
- 14 Sep, 2016 1 commit
-
-
Rico Tzschichholz authored
-