[Evolution-hackers] Programmatically configure an Evolution account

2010-02-02 Thread Johan Groth
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

2010-02-02 Thread Jeffrey Stedfast
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

2010-02-02 Thread Paul Smith
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

2010-02-02 Thread Xavier Bestel
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

2010-02-02 Thread Jeffrey Stedfast
Xavier Bestel wrote:
 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.
   

It's only wrong if you are targeting c99 (evolution was written to
target c89 - that may have changed a bit since I've left the project,
but the demonstration code is perfectly legal in c89 and works on all of
the big-name compilers).

This type of trick is used all over the place.

In any case, the workaround is to just specify -fno-strict-aliasing.

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

2010-02-02 Thread Paul Smith
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

2010-02-02 Thread Matthew Barnes
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

2010-02-02 Thread Paul Smith
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

2010-02-02 Thread Suman Manjunath
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

2010-02-02 Thread Matthew Barnes
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?

2010-02-02 Thread Miguel Angel CaƱedo
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