On Wed, 2013-12-11 at 13:40 +0100, Maciej Piechotka wrote: > On Wed, 2013-12-11 at 05:14 -0600, Daniel Espinosa wrote: > > I have pushed some commits to 0.8 branch, in order to remove most of > > warnings. > > > > Thanks, but 0.8 branch is no longer maintained. Current stable release > is 0.12 and possibly 0.10 would get the backports of fixes. > > > > > This is a work in progress and try to help Gee to remove most build > > warnings, while tries to keep C API unchanged. > > > > Thanks. I believe many of the warnings might got fixed in newer releases > - possibly including ones you fixed (see for example commit cbc209 or > ff6b2d). > > In general _PLEASE_ submit the patch through bugzilla, ML or > Jürg/Didier/me instead of commiting right away. > > For example the Context are unused for PURPOSE (I don't have time to > check it ATM but I believe it might even crash the tests now or run the > 'GC' much more frequently). > > > > > I'm trying to remove warnings about delegate copying, but seems I need > > to change some functions properties to unowned, but again I don't want > > to change C API. > > > > The best way would be to have GClosure support in Vala. Second best > would be to emulate it by creating a refcounted private class to keep > the delegate and copy the reference to it. > > I belive I have started it somewhere but fix for it keeps being pushed > away (real life constrains). > > > > > Does Gee needs to add gee.h to repository in order to track C chages > > and keep 0.8 and other stable branches with no changes? > > > > No. gee.h is autogenerated. Unfortunately >
Missing end of sentence - unfortunately the API/ABI compatibility needs to be checked manually or by external tool. You can see that we do rather well (all incompatibles but 2 are in unstable releases and those 2 are removed internal symbols): http://upstream-tracker.org/versions/libgee.html > > > > Does Gee needs to force to use one version of Vala in order to Keep C > > API unchanged? > > > > Yes. Not only we guarantee the C API stability but also ABI stability. > It's even easier to break the latter without noticing. > > > > > I found lot of warnings at build time I'll try to remove carefully > > with out change C API. > > > > I'm trying to remove as many warnings as possible but sometimes the > problem is in warning itself not the code (much, much more critical > example of cleaning warnings[1]). Also it would be preferable to remove > code the comment it out (it's fine - it's in vcs so it's possible to > revert). > > > > > Any comment recommendation? > > Maciej > > [1] > http://anonscm.debian.org/viewvc/pkg-openssl/openssl/trunk/rand/md_rand.c?p2=%2Fopenssl%2Ftrunk%2Frand%2Fmd_rand.c&p1=openssl%2Ftrunk%2Frand%2Fmd_rand.c&r1=141&r2=140&view=diff&pathrev=141 > Sorry if I was a bit too harsh - libgee is (as all projects) understaffed and I'd love to make the code review for all changes (I reverted the HazardPointer.Context change but I'd have question about others as well). The problem is that sometimes I ignore warnings for purpose and sometimes people make mistakes even modifying their own code. Maciej _______________________________________________ libgee-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/libgee-list
