[Evolution-hackers] Programmatically configure an Evolution account
Hi all, I'm writing a program that will allow a user to generate two certificates, one for authentication and one for encryption. This program is also supposed to configure the user's Evolution account to use these certificates (ie s/mime settings). I found on the web site (http://library.gnome.org/devel/libedataserver/stable/EAccount.html) a couple of interesting things like e_account_(get|set)_string. Both takes an EAccount_t and e_account_item_t. It seems e_account_item_t contains what I want (E_ACCOUNT_SMIME_SIGN_KEY, E_ACCOUNT_SMIME_ENCRYPT_KEY). Those are the two fields I want to set in the EAccount_t struct. So I wonder how do I get the user's EAccount_t struct filled in in the first place and does e_account_set_string work for setting the sign and encrypt key? Regards, Johan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
Paul Smith wrote: On Mon, 2010-02-01 at 11:52 -0500, Jeffrey Stedfast wrote: This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc would mistakenly optimize out important sections of code when it encountered a particular trick used in a ton of places inside Evolution (EDList and pretty much everywhere custom single-linked lists are used inside at least Camel and likely other places as well). A temporary solution is to pass the -fno-strict-aliasing argument to gcc. Unfortunately, the gcc developers claim that this is not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 It is not a bug in GCC: GCC will compile a program that conforms to the C standard 100% correctly. Evolution is relying on behavior that is left as undefined by the standard. Optimizations often cause undefined code to behave incorrectly, defined as contrary to the author's intent, where non-optimized versions of the code work. That doesn't mean that the compiler has a bug. s/C standard/C99 standard/ In C89, a type-cast was a type-cast and had well understood and defined behavior. And in C89, aliasing was legal and widely used. So while it might not /technically/ be a bug in gcc now that it's focusing on c99, it can be argued it's a bug since it broke previous behavior. It can also easily be argued that, in the case of undefined behavior, a compiler should default to doing what the other (and/or older versions of the same) compilers do. In this case, other compilers (and older versions of gcc) handle aliasing the same, but the new gcc 4.4 behavior changed. Hence why I call it a bug ;-) Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 11:05 -0500, Jeffrey Stedfast wrote: Paul Smith wrote: On Mon, 2010-02-01 at 11:52 -0500, Jeffrey Stedfast wrote: This weekend I discovered a particularly nasty bug in gcc 4.4 where gcc would mistakenly optimize out important sections of code when it encountered a particular trick used in a ton of places inside Evolution (EDList and pretty much everywhere custom single-linked lists are used inside at least Camel and likely other places as well). A temporary solution is to pass the -fno-strict-aliasing argument to gcc. Unfortunately, the gcc developers claim that this is not a bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42907 It is not a bug in GCC: GCC will compile a program that conforms to the C standard 100% correctly. Evolution is relying on behavior that is left as undefined by the standard. Optimizations often cause undefined code to behave incorrectly, defined as contrary to the author's intent, where non-optimized versions of the code work. That doesn't mean that the compiler has a bug. s/C standard/C99 standard/ Well, if you try adding -std=c89 to your compiles and GCC still uses this optimization, I guess I would agree that's a bug :-). In C89, a type-cast was a type-cast and had well understood and defined behavior. And in C89, aliasing was legal and widely used. Aliasing is still legal in C99, of course: it would be a completely different language if it weren't legal. However, there are restrictions on how it can be used (and result in defined behavior) that weren't present before, that's true. So while it might not /technically/ be a bug in gcc now that it's focusing on c99, it can be argued it's a bug since it broke previous behavior. Well, new optimizations OFTEN break previous behavior, if that behavior took advantage of aspects of the language that weren't defined. I'm not sure that means we should never attempt any new optimizations. It can also easily be argued that, in the case of undefined behavior, a compiler should default to doing what the other (and/or older versions of the same) compilers do. In this case, other compilers (and older versions of gcc) handle aliasing the same, but the new gcc 4.4 behavior changed. Sure, all things being equal that's obviously the right answer. The problem comes when there are actually very good reasons to change the behavior. C is actually surprisingly difficult to optimize and one of the big reasons this is so is C's aliasing requirements. You have to forgo all kinds of useful optimizations if you have to treat almost every pointer as if it could possibly alias almost every other pointer (if any two pointers might point to the same memory). This leads to very inefficient load/store behaviors, severe restrictions on the types of code hoisting you can do, etc. etc. This hurts especially on register-starved architectures like the x86. The aliasing rules introduced in C99 are not that strong (compared to other languages), but nevertheless they allow a whole new class of optimization opportunities that otherwise would not exist. For some code, the difference in the quality of the assembly produced can be stark. I'm pretty confident the GCC developers didn't add this optimization just to screw over developers for the sake of the letter of the standard. They genuinely feel that the advantages outweigh the drawbacks, and they added the -fno-strict-alias flag so that people who disagree have a solution as well. It may have been better to leave it off in -O2 and have people turn it on if they wanted it, rather than vice versa; I don't know. That's why I say it's really a QOI issue. Hence why I call it a bug ;-) Potayto, potahto! :-) Anyway, I agree with you that if Evo makes use of this type of aliasing then we should definitely add that flag to the default makefile flags. Configure can check for it and use it if present. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 18:13 +, Matthew Barnes wrote: On Tue, 2010-02-02 at 12:27 -0500, Paul Smith wrote: Anyway, I agree with you that if Evo makes use of this type of aliasing then we should definitely add that flag to the default makefile flags. Configure can check for it and use it if present. Done. Although, I imagine many distros have already disabled strict aliasing optimization due to all the compiler warnings we used to have about it. If GCC or even LLVM ever learns to detect cases like what Jeff ran into and -warn- about them, I'd love to know about it so I can it to our already lengthy list of warning flags we build with by default now. I don't know ... Jeff's demonstration was using obviously wrong C code, so I'm on GCC side for that one. Xav ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 14:30 -0500, Jeffrey Stedfast wrote: Matthew Barnes wrote: On Tue, 2010-02-02 at 12:27 -0500, Paul Smith wrote: Anyway, I agree with you that if Evo makes use of this type of aliasing then we should definitely add that flag to the default makefile flags. Configure can check for it and use it if present. Done. Although, I imagine many distros have already disabled strict aliasing optimization due to all the compiler warnings we used to have about it. If GCC or even LLVM ever learns to detect cases like what Jeff ran into and -warn- about them, I'd love to know about it so I can it to our already lengthy list of warning flags we build with by default now. If you want to get warnings about the aliasing stuff, it seems that -Wstrict-aliasing=2 is the one you want. Yep, as Jeff points out GCC does provide warnings; in fact, -Wall already includes -Wstrict-aliasing=3 which is the least aggressive level. Note this is another of those warnings (like variables used before initialized) which only can be seen when you build with optimization on. You should check the GCC docs for details before choosing a particular value. The problem is that these warnings can be false positives, that's why there are different levels of aggressiveness. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gcc 4.4 may be causing a number of bugs in Evolution
On Tue, 2010-02-02 at 15:00 -0500, Paul Smith wrote: On Tue, 2010-02-02 at 14:30 -0500, Jeffrey Stedfast wrote: If you want to get warnings about the aliasing stuff, it seems that -Wstrict-aliasing=2 is the one you want. Yep, as Jeff points out GCC does provide warnings; in fact, -Wall already includes -Wstrict-aliasing=3 which is the least aggressive level. Note this is another of those warnings (like variables used before initialized) which only can be seen when you build with optimization on. You should check the GCC docs for details before choosing a particular value. The problem is that these warnings can be false positives, that's why there are different levels of aggressiveness. Ah, good, thank you both. I'll see what the different levels produce and maybe file some cleanup bugs about it. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Build failures with latest git in evolution-mapi
Hi all; Since the openchange project recently added a new feature, I think there are compile problems in evolution-mapi. Doing a full git upgrade (and svn upgrade of openchange) an hour or two ago, then a complete clean build, I get these warnings (the warnings MIGHT have been there before, I can't remember) and then the compile errors, which definitely were not there before. Hopefully this can be resolved soon so I can continue my testing of Evo 2.29. Cheers! CC exchange-mapi-utils.lo In file included from /opt/evo-master/include/util.h:26, from /opt/evo-master/include/ndr.h:32, from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/charset.h:125: warning: redundant redeclaration of 'strchr_m' /opt/evo-master/include/charset.h:104: note: previous declaration of 'strchr_m' was here In file included from /opt/evo-master/include/dcerpc.h:33, from /opt/evo-master/include/libmapi/libmapi.h:50, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/ndr.h:517: warning: redundant redeclaration of 'ndr_print_bitmap_flag' /opt/evo-master/include/ndr.h:516: note: previous declaration of 'ndr_print_bitmap_flag' was here In file included from /opt/evo-master/include/gen_ndr/exchange.h:9, from /opt/evo-master/include/libmapi/libmapi.h:57, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-connection.h:31, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.h:28, from ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:29: /opt/evo-master/include/gen_ndr/ndr_misc.h:12: warning: redundant redeclaration of 'ndr_print_GUID' /opt/evo-master/include/ndr.h:375: note: previous declaration of 'ndr_print_GUID' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:17: warning: redundant redeclaration of 'ndr_push_policy_handle' /opt/evo-master/include/ndr.h:493: note: previous declaration of 'ndr_push_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:18: warning: redundant redeclaration of 'ndr_pull_policy_handle' /opt/evo-master/include/ndr.h:492: note: previous declaration of 'ndr_pull_policy_handle' was here /opt/evo-master/include/gen_ndr/ndr_misc.h:19: warning: redundant redeclaration of 'ndr_print_policy_handle' /opt/evo-master/include/ndr.h:494: note: previous declaration of 'ndr_print_policy_handle' was here ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c: In function 'utf8tolinux': ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: error: implicit declaration of function 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: nested extern declaration of 'windows_to_utf8' ../../../../evolution-mapi/src/libexchangemapi/exchange-mapi-utils.c:71: warning: assignment makes pointer from integer without a cast make[4]: *** [exchange-mapi-utils.lo] Error 1 make[4]: Leaving directory `/opt/src/evo/evo-master/obj/evolution-mapi/src/libexchangemapi' ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failures with latest git in evolution-mapi
On Tue, 2010-02-02 at 16:57 -0500, Paul Smith wrote: Hi all; Since the openchange project recently added a new feature, I think there are compile problems in evolution-mapi. Doing a full git upgrade (and svn upgrade of openchange) an hour or two ago, then a complete clean build, I get these warnings (the warnings MIGHT have been there before, I can't remember) and then the compile errors, which definitely were not there before. Do you have the right Samba alpha? OTOH, you are better of sticking with the released version of openchange and samba. 0.9 and alpha10 respectively. I don't think evo-mapi uses the latest svn revision of openchange anymore. Johnny would know better. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failures with latest git in evolution-mapi
On Tue, 2010-02-02 at 17:45 -0500, Paul Smith wrote: OTOH, you are better of sticking with the released version of openchange and samba. 0.9 and alpha10 respectively. I don't think evo-mapi uses the latest svn revision of openchange anymore. Johnny would know better. I've been using the very latest from the openchange SVN server, just like the very latest from the Evo git server. If that's not right, do the various downstream folks know that there's a version dependency here? Or, do we just not anticipate a new openchange release? Distros should be sticking to official releases, and I don't anticipate an OpenChange 0.10 release before GNOME 2.30. If distros push packages into unreleased territory, it's up to them to apply patches. That said, if we -can- accommodate unreleased API churn in external dependencies without breaking anything, great. But I wouldn't call it a showstopper. Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] How to wirte a Contacts Python Plugin to call external program with arguments?
Hi: I would like to write an evolution plugin (preferabily in python) to add a very simple extension: When looking at the contacts list in the addressbook, I want to add a button, toolbar button, menu or contextual menu (what ever is easier), that will call an external python progrm and will pass as arguments the FullName and the Organization of the currently viewd contact. I don't need the external program to return some kind of data back to evolution. Is this possible? Can anyone point me to the right direction? Thanks, Miguel ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
