[Evolution-hackers] unix_getname buglet - 2.5.4(?)
Hi there,
Evolution is non-functioning on recent 2.5.X kernels, due to
mal-performance in getpeername = net/unix/af_unix.c (unix_getname),
where it seems we switch 'sk' on 'peer', but not the (previously)
typecast pointer to it; this fixes it.
--- af_unix.c.old Tue Jan 7 11:59:09 2003
+++ af_unix.c Tue Jan 7 12:00:45 2003
@@ -1097,7 +1097,7 @@
static int unix_getname(struct socket *sock, struct sockaddr *uaddr,
int *uaddr_len, int peer)
{
struct sock *sk = sock-sk;
- struct unix_sock *u = unix_sk(sk);
+ struct unix_sock *u;
struct sockaddr_un *sunaddr=(struct sockaddr_un *)uaddr;
int err = 0;
@@ -1112,6 +1112,7 @@
sock_hold(sk);
}
+ u = unix_sk(sk);
unix_state_rlock(sk);
if (!u-addr) {
sunaddr-sun_family = AF_UNIX;
Thanks Joaquim Fellmann (AFAIR) who chased this down to bitkeeper
changeset 1.262.2.2. Sadly I didn't have time to read the rest of that
changeset to see if the mistake pops up elsewhere as well. Please CC me
with replies, not on linux-kernel.
HTH,
Michael Meeks.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
___
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: Composer failure ...
On Fri, 2002-10-18 at 10:48, Michael Meeks wrote: I'm still having repeated problems with Gconf / evolution, and it's interaction with Gconf 2.0. Essentially - after a time of quiescence I try to compose a message - and it fails to activate the composer. ... The reason for this is that gconfd-2 is still running away merrily - thinking it has /tmp/orbit-michael/linc-foo open and listening for connections ( holding the XML tree lock ) But when you examine /tmp/orbit-michael/linc-foo you discover that the (originally existing) file has been unlinked somehow. It turns out that I'm vying for the prize for world's biggest dofus. I got this again just now, and lent some thought to what I was doing beforehand; and I _imagine_ the reason I see this and [typically] no-one else does, is that I run the ORBit2 regression tests a fair bit, which include the wonderful line: rm -Rf /tmp/orbit-$USER ;-) so there is no problem, or at least - there is in that test, I'll try and re-work it shortly. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Help on Using version 1.2
Hi Hyo-Je, On Wed, 2002-11-27 at 10:51, Hyo-Je Choi wrote: The result is like below : GConf Error: Failed to contact configuration server (a likely cause of this is that you have an existing configuration server (gconfd) running, but it isn't reachable from here - if you're logged in from two machines at once, you may need to enable TCP networking for ORBit) Put this in ~/.orbitrc: ORBIIOPIPv4=1 _Then_ you need to find the other machine you're logged on-to and kill the gconfd that's holding the lock; when you've killed that ensure you're firewall is nice and beefy ;-) Is this problem occurred because of using NFS-mounted home directory ? Yes, and you're logged in twice on two different machines ( or have tried that in fairly quick succession ). Is there anybody who met this problem? Yes; there are various other solutions, see the gconf list though. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Strange bug?
Hi Ronald,
I'm dead confused now; it seems in the plain (default) state, without
poking 'test' at runtime we have:
On Tue, 2002-10-29 at 15:28, Ronald Kuetemeier wrote:
int test = 0;
...
if(!strcmp(sockpath, tmp-u.usock.sun_path)) {
cnx = test ? tmp : NULL;
if(!test) continue;
break;
}
which is:
if (!strcmp (sockpath, tmp-u.usock.sun_path)) {
cnx = NULL;
continue;
break;
}
ie. this rather radically alters things from:
if(!strcmp(sockpath, tmp-u.usock.sun_path)) {
cnx = tmp;
break;
}
So 'test' is always 0, and thus you always make a new Unix domain
socket connection ? :-) wow - that's not going to be too efficient. I
imagine you'll allocate 1-2 file descriptors per object and blow your fd
limit pretty soon ;-) I'd be interested in the results of an:
...
Soorry should have explained, you read to much into the variable. It's just
for my debug, so I can set it from the debugger while in the function and get
a different behavior. It's not meant to fix anything, just gives another glue
in the behavior on what is going on.
Presumably if you set test to non-zero you'll still get the bug, and
will stop chewing file descriptors ? :-)
Regards,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
___
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Strange bug?
Hi Ronald, Firstly - thanks for looking into this. On Fri, 2002-10-25 at 17:42, Ronald Kuetemeier wrote: Ok, let's see if I can explain this. Look at file ORBit-0.5.1[5,6]/src/IIOP/connection.c:(IIOPConnection * iiop_connection_unix_get:923) Ok. In 2.4 all test in the for loop will fail since none is set to GIOP_CONNECTION_CLIENT therefore the variable cnx is not set and the socket, btw existing and if the strcmp would ever be reached would also succeed (that's why I call it a server), is opened. ... In 2.5 the connection is set to be of class GIOP_CONNECTION_CLIENT the strcmp succeeds variable is set and the connection is never opened. Ok - this is quite likely just down to a race condition in who gets timesliced first, and thus who connects to wherever when - presumably. There is also some strange difference in the number or ordering in the list. In 2.5 it's the first socket in the list (I didn't check if there are more or just that one), in 2.4 it's the last one (there are more before it, just look at the socket path from the sockets tested during the loop execution) Ok - this is really down to the order in which what process communicates with what other process - so ... it's rather hard to tell whether that's meaningful really. BTW. My definition of server is, I call you to serve me something. If you call me I become the server for you. If I call you to put my UI on the screen you're the server. The screwed up definition from Oracle, Microsoft and Sun from the 80's never worked for me anyway. Yes - but you realise that the ORB has no interest in putting the UI on the screen; and as such it's 'client/server' distinction is just a matter of who is listening for connections and who is not; ie a server has many clients, a client has a single server. [ although a process clearly has ~1 Unix socket server, and multiple clients to other processes ]. HTH keep digging, Thanks, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Strange bug?
Hi Ronald, I don't know quite what you're seeing, but AFAIR there should be a client and a server in each direction; so 2x fd's per bi-directional communication. Does that make sense ? there's really no firm concept of any application as 'server' in the CORBA model. Regards, Michael. On Thu, 2002-10-24 at 16:42, Ronald Kuetemeier wrote: This is actually an interesting problem, the GIOP_CONNECTION(tmp)-connection_class in ORBIT is set be a GIOP_CONNECTION_CLIENT for the Unix socket server (evolution) Therefore the connection to the server will not be opened and evolution seems to hang to the user. Anyway this is WHAT is happening, WHY I don't know yet. I will wait after Linus is back and has done the final merge before spending more time on this. But if this rings a bell with anybody, let me know why this is happening. Ronald On Wed, 2002-10-23 at 13:26, Jeffrey Stedfast wrote: This has been known for quite some time now, but it is unclear as to whether the bug is in the kernel or evolution. For now, it is suggested that users stay away from kernel 2.5.x Jeff On Wed, 2002-10-23 at 15:16, Craig Knox wrote: Hi, I booted into a 2.5.44 kernel to test it, and everything thing seems to work no problems except for evolution. Evolution hangs when replying/creating a new email. Appears to be in the addressbook part of it. Back in a 2.4.x kernel to write this. Its very weird as I wouldn't have thought changing the kernel would effect evolution. Cheers Craig ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Composer failure ...
On Fri, 2002-10-18 at 10:48, Michael Meeks wrote: I'm still having repeated problems with Gconf / evolution ... to no avail. Does anyone have any idea (short of strace 'world', wait for hours) that I could work out who / how that file gets unlinked ? Well - in the end I did just that; and 200Mb of strace log later I got it to misbehave; I caught everything (including gconfd-2) that was execve'd for evolution correctly. Imagine my suprise then to discover that no-one unlinked anything in /tmp/orbit, and yet - the socket node is indeed gone, and the problem shows it's ugly head. [ and gconfd-2 still has it bound / open etc. of course ]. So - can anyone suggest how that file can disappear without it being unlinked by anything forked from evolution ? perhaps I'm missing a 'delete' syscall or something ;-) Really perplexed here, short of stracing every process somehow I don't know how to catch the culprit. Is there any cunning kernel debugging that would do something useful here ? of course - not having any way to predict when it will happen is not helpful either. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How to update GAL?
Hi Ettore, On Wed, 2002-10-02 at 16:08, Ettore Perazzoli wrote: The right value for GNOME_PATH is something like /opt/evolution:/usr I don't remember if this ever got fixed; but as I recollect, the gnome-config script [ highly cunningly ], parsed the 'path' backwards last time I checked. Thus possibly: /usr:/opt/evolution would be better - that is, unless it's been fixed ;-) [ I forget whether oaf parses it the right way round or not ]. for an installation in /opt/evolution. Note that you have to set the GNOME_PATH before starting the GNOME session and autogenning (otherwise gnome-config, and hence EVO_CHECK_LIB, won't pick up the *Conf.sh files from the right place). I imagine doing development on a different prefix with the -devel RPMs for the same packages installed is rather an optimistic suggestion. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] gtkhtml startup speed ...
Hi there,
Just trying to work out exactly why my composer occasionaly decides it
just won't launch [ in the past related to thinking it can't contact
gconf ]. I did:
export ORBIT2_DEBUG=traces:timings
killall -9 gconfd-2
gconftool-2 --spawn
To get gconfd-2 to run with the orbit debugging, I append the trace I
got.
Either way; why it does it twice I don't know; perhaps there is some
over-conservative GConf client handling going on; either way - even if
it only happens once, we seem to take ~300ms to get the keys, seemingly
because we do lots of roundtrips.
I believe we want to use:
void gconf_client_add_dir (GConfClient* client,
const gchar* dir,
GConfClientPreloadType
preload,
GError** err);
with GCONF_CLIENT_PRELOAD_ONELEVEL, which should mean that all
subsequent accesses to this directory result in pure in-process calls,
and that it does coherency via notifications [ which I assume we catch
anyway ].
Should knock a chunk of time off startup, and thus C-n - composer
latency.
HTH,
Michael.
p17700 1033387674.612996 : ([0x805a268])-ping () =; 0x4524
1033387674.613078
p17700 1033387674.614156 : ([0x805a268])-add_client ([0x8060e10], )
1033387674.614632
p17700 1033387674.615689 : ([0x805a268])-get_default_database () =;
[0x80601c0] 1033387674.615804
p17700 1033387674.617274 : ([0x80601c0])-add_listener
('/GNOME/Documents/HTML_Editor', [0x8060e10], ) =; 0x2501
1033387674.617915
p17700 1033387674.619207 : ([0x80601c0])-all_dirs
('/GNOME/Documents/HTML_Editor', ) out: (seq[0]={ } ) 1033387674.621523
p17700 1033387674.622891 : ([0x80601c0])-all_entries_with_schema_name
('/GNOME/Documents/HTML_Editor', 'C', , , , , ) out: (seq[1]={
'keybindings_theme' }, seq[1]={ { d=2 v='emacs' } }, seq[1]={ '' },
seq[1]={ 0 }, seq[1]={ 1 } ) 1033387674.623484
p17700 1033387674.625387 : ([0x80601c0])-add_listener ('/GNOME/Spell',
[0x8060e10], ) =; 0x2602 1033387674.625821
p17700 1033387674.626869 : ([0x80601c0])-all_dirs ('/GNOME/Spell', )
out: (seq[0]={ } ) 1033387674.628064
p17700 1033387674.629268 : ([0x80601c0])-all_entries_with_schema_name
('/GNOME/Spell', 'C', , , , , ) out: (seq[1]={ 'language' }, seq[1]={ {
d=2 v='' } }, seq[1]={ '' }, seq[1]={ 0 }, seq[1]={ 1 } )
1033387674.629721
p17700 1033387674.631052 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/magic_links', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.631480
p17700 1033387674.632741 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/magic_smileys', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.633143
p17700 1033387674.634243 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/animations', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.634636
p17700 1033387674.635784 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.636182
p17700 1033387674.637285 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_fixed', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.637679
p17700 1033387674.640223 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable_size', 'C', 0, , , ) =; {
d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.644192
p17700 1033387674.645121 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_fixed_size', 'C', 0, , , ) =; { d=0
v=0x0 } out: ('', 0, 1 ) 1033387674.649066
p17700 1033387674.649981 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable_points', 'C', 0, , , ) =;
{ d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.653872
p17700 1033387674.654790 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_fixed_points', 'C', 0, , , ) =; {
d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.65
p17700 1033387674.659855 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable_print', 'C', 0, , , ) =; {
d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.663773
p17700 1033387674.664690 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_fixed_print', 'C', 0, , , ) =; {
d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.667852
p17700 1033387674.668613 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable_size_print', 'C', 0, , , )
=; { d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.669100
p17700 1033387674.670150 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_fixed_size_print', 'C', 0, , , ) =;
{ d=0 v=0x0 } out: ('', 0, 1 ) 1033387674.670628
p17700 1033387674.671668 : ([0x80601c0])-lookup_with_schema_name
('/GNOME/Documents/HTML_Editor/font_variable_print_points', 'C', 0, , ,
) =; { d=0 v=0x0 } out: ('', 0, 1 )
Re: [Evolution-hackers] Feedback Evolution 1.1.1
On Sun, 2002-09-22 at 22:22, Jeffrey Stedfast wrote: changed to mimic Outlook's functionality which uses alphebtic keys for searching which meant that we had to use ',' and '.' or '[' and ']' Does ',' '.' work again ? Last check only '' and '' worked, which I believe are also assigned to this next / prev mail function. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: multihead support in evolution
Hi Ettore, On Thu, 2002-08-01 at 23:42, Ettore Perazzoli wrote: On Wed, 2002-07-31 at 05:22, Michael Meeks wrote: CORBA_exception_init (ev); CORBA_Context_set_one_value ( context, display, DisplayString (gdk_display), ev); CORBA_exception_free (ev); Note that DisplayString() is not guarranteed to be unique on the same display so this hack isn't completely reliable. It's pretty good; and ultimately people tend to do their DNS lookups on the same machine that they're launching the components on, with the DISPLAY inherited from b-a-s anyway so ... * The shell and the mail component don't expect to be run multiple times on the same set of files -- so two Evolution instances running at the same time on different displays can easily cause trouble and cause ugly misbehaviors. Hmm - that's more problematic, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: multihead support in evolution
Hi Shahms,
On Tue, 2002-07-30 at 16:19, Shahms E. King wrote:
I'd be happy to look into it if you could give me a jumping off point
so to speak.
Ok; there are 2 things you need to do:
a) Ensure that the DISPLAY context parameter passed on each oaf
request is correct, to do this you need to back-port this:
/* FIXME: nasty contractual bonobo-activation issues here */
context = bonobo_activation_context_get ();
CORBA_exception_init (ev);
CORBA_Context_set_one_value (
context, display,
DisplayString (gdk_display),
ev);
CORBA_exception_free (ev);
To oaf; [ make this a function in some evolution library shared across
components ].
Then you need to make sure that whenever a component is registered with
oaf; that you do something like:
/* Create the factory. */
registration_id = eel_bonobo_make_registration_id (factory_iid);
factory = bonobo_generic_factory_new (registration_id,
make_object,
callback_data);
g_free (registration_id);
Which makes it a per display IID: where the eel_..._ is defined as:
char *
eel_bonobo_make_registration_id (const char *iid)
{
return bonobo_activation_make_registration_id (
iid, DisplayString (gdk_display));
}
[ you need to include gdkx.h to make that work ].
Then to test it you just need to run evolution, run xnest:
Xnest -ac :2.0
export DISPLAY=:2.0
and run evolution again - when it works you won :-)
It'd be great to get this tested and working in evolution, since we'll
be stuck with a Gtk 1.2 / Gnome 1.4 version for the next few months.
Regards,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
___
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] The future of 2.5 kernels and Evolution
On Mon, 2002-06-24 at 00:57, Not Zed wrote: As Miles says, _if_ this is an ORBit bug, and while that wouldn't be that surprising, it is rather strange that ORBit now seems to be behaving relatively well on Solaris, and the aforementioned Linux versions. So you're saying its surprising that ORBit works at all, with anything? Only people I don't know get kidnapped by aliens, = if I don't know you you're being kidnapped by aliens - but hey, that's abduction for you. [ queue applause, groans and rotten egg throwing =]. I'm saying, that it wouldn't be that surprising if it was an ORBit bug. Why am i not surprised. I think it must have been all those seg faults in ORBit/bonobo screwing with the perfect code you wrote in the mailer - those ones where it crashed in the 'select' sys-call - do you remember ? they must have ruined your surprisedness circuitry. ;-) But yes - the crud that crawls out of ORBit 1 never ceases to amaze me - I plead ignorance (convincingly it seems). Great flying goats, Michael. [1] - someone once said never finish anything you start, nor start anything you finish - sounds like free software indeed, but the rational is to beautifully blur the blame horizon. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] GtkHtml (E-mail composer startup) failure #24829
Hi there, Having spent some considerable time debugging this, and being moderately plagued by it - I was hoping, that this bug would be dealt with promptly. Particularly since the patch attached is small, transparently correct, and the root cause of the problem. It would be really good to fix this annoying one, I understand it's not just me, but QA that get this problem reported. I've suffered another 10 days of composer problems, and no end in sight :-) Larry, Radek, anyone; may I commit ? but don't wait for me, I just want it in there, in snapshots that I can use, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml - composer not starting ...
Hello Mark, On Thu, 2002-05-23 at 02:17, Mark McLoughlin wrote: I won't address the problem you're trying to solve, because I haven't had much experience of it, but the way you plan to implement the solution is just plain wrong. It's a real shame that you didn't understand the problem before considering the efficacy of the solution I proposed. Let me re-state it more simply; we need the following: a) Stubs that during invocation will not re-enter b) Stubs that during invocation will re-enter We also would like to be able to delay server side request processing until idle, here the requirements fit closer to an extra POA policy as you suggest - but for the fact that we do not want the policy to apply to all methods ( eg. ref / unref / queryInterface ) - but to a sub-set of methods. I imagine it might be possible to do something grotesque that would lookup methods by name, and provide a custom OA ( with a big API, a secondary method lookup, or somesuch ) to achieve the latter goal - but it seems unnecessarily complicated to me. The idea behind IDL is that you specify the details of the interface to the service i.e. you seperate the details of the implementation from the interface. The way in which requests are processed is an implementation issue. Well - there is no need for the request processing data to be in the IDL per-se, I'm more interested that it's in the generated IMethod data so we can get at it quickly. If you want to be a purist, we can have a separate file ( perhaps an XML:panacea file ), that marks up the generated C -common.c source, but it's going to be a pain. At the end of the day, we need to associate processing data with each method, and it makes lots of sense (to me) to do this at compile time, rather than execution time. I will however alter the ORBit2 ABI before releasing, so that we push the index into the IMethod data into the stub invoke, so we can try and associate such things on a per client basis - but this is just futile. We need to be able to control stub invocation re-enterancy, and this is just not possible (nor desirable) to do on a per CORBA_Object handle basis [ not to mention that all the CORBA_Object handles are shared amongst clients necessarily; selecting amongst the different options on incoming object references is just impossible blah blah. ]. Not only that, but its a detail of the POA. And the way the POA behaviour is configured is through the use of POA policies. Think about it - how different from the RequestProcessingPolicy, the LifespanPolicy or the ThreadPolicy is this? So really, if you want to make to make this behaviour configurable, you should do so by adding another POA policy. A POA policy is not really powerful enough to do what we want to do IMHO, possibly we could make it good enough - perhaps conditional idle processing for oneway methods. But again this only solves half the problem. In conclusion - no I'm not suggesting binning CORBA, adding some #pragmas or other method annotation either in or parallel to the IDL to describe how we want the processing to occur seems not unreasonable, nor wrong to me. Furthermore, other ORBs will ignore this information, leaving us CORBA compatible on the wire, CORBA compatible at the IDL and API level - but without uncontrolled re-entrancy in our implementations. I hope this helps explain what I propose, Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: gnome 1.x bonobo components in gnome 2.0
Hi Jacob, On Fri, 2002-05-17 at 16:28, jacob berkman wrote: didn't the bonobo control interfaces change from gnome 1 - gnome 2? Yes, but that's only half of it we do embedding in a different way at the Gtk+ level with the arrival of the XEmbed protocol. and how do you get a reference to the component? do you have to do code to talk to oafd rather than bonobo-activation-server? Yes - you would have to use something like: /usr/bin/oaf-client -s iid == 'OAFIID:Bonobo_Sample_Entry' Forked, which would return the IOR to you [ and some junk you'd have to parse out ]. Then you could talk via CORBA. Using controls is pretty much a lost cause, but using some of the evolution interfaces for various bits should be doable. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gnome 1.x bonobo components in gnome 2.0
Michael, On Fri, 2002-05-17 at 16:19, Not Zed wrote: you mean like 'mail foo@blah text', right? Oh no, I guess you mean to execute a billion lines of mostly pointless code that does the same thing instead? But wait, I think you missed a billion lines in the above example, including escaping foo@blah, 2 forks, a wait4pid, a sane error detection / reporting scheme, a set of fcntls, some pipes, signal handling, '_exit' blah blah blah blah. Seems to me that having a re-usable 'billion line' code section with a nice interface might be a good idea. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] still no snapshots ... (2+ weeks)
Hi guys, I'd really like to help testing HEAD evolution - indeed, some might say that without testing it's never going to stabilize. Problem is, the last snapshot I have is dated: evolution-1.1.0.99-snap.ximian.200205031001 And it's pretty hellishly buggy. Given that it's now 20020520, some 17 days later, it would be really nice to have new snaps. I understand a chunk of the problem is that is hasn't built at snapshot time ( for 17 days in a run !? ) - which I find quite incredible. Any hope ? Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml - composer not starting ...
Hi Havoc, On Wed, 2002-05-15 at 22:58, Havoc Pennington wrote: Of course the underengineered, simple solution that works fine most of the time would be a a cheesy explicitly-async message-passing API. Can be implemented in a week. And of course ORBit2 does asynchronous invocations for you - there is a (fairly nice) API for it, that is missing direct IDL compiler support; but it's easily possible to construct stub/skel pairs that do async invocations, (without the need for oneway calls), that are fully non-blocking [ oneway with ORBit1 is not fully non-blocking ]. I have a slightly more elaborate design for this that also addresses activation, broadcast messages, lifecycle, and messages from system/root users to the desktop. No one to implement it though. Wow - you want to re-write the whole lot, and bin standards altogether ? anyone can do that, trivially. If you have a magic bullet for cross process lifecycle management though I'm gagging to hear your suggestion - please expand. Anyway, yeah long term I would rather see threads than hacks that fix the problem most of the time when you don't _need_ reentrancy, Doh, why does everyone say it's a hack. Examine for example the X protocol, which is essentially a transport (say CORBA) and a load of non-reentering calls, and an idle event processing loop. Well, with the [ no_reenter, handle_at_idle ] markup, we have - precicely that model, with the additional flexibility of handing some things re-enterantly if we think we can cope with the gob-smacking complexity of that. but then again I admit I don't see why we're spending years of effort on making remote methods/objects look like local methods/objects (modulo different type systems) in the first place. Dude; you begin to piss me off. This mantra of repeating brokenly that remote and local objects look the same is just silly. It's certainly not what I'm aiming at, and it's not what anyone is programming to - it's a straw man argument. Perhaps you want to read my talk here: http://www.gnome.org/~michael/guadec-2002/ to get some things to argue against. There are also some interesting things for you to consider there. For example the 'write' syscall 'transparently' provides an API for remote and local method/object interaction. It's hardly a new idea. I'd say by all means, add a way to make methods non-reentrant, we need the workaround for now. Threads are probably out until GNOME 3. I do believe the solution is simple, elegant, efficient, provides us with what we need, and removes a no. 1 favorite gripe of peoples. It'll also stop gconf_get_value () being a re-entrancy point - I hope. [ Oh, and ensure that gconf value changed notifications come in at idle ]. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml - composer not starting ...
On Wed, 2002-05-15 at 14:17, Ettore Perazzoli wrote: Thus people can invoke methods, no re-entrancy will occur on that method invoke, and we can queue methods execution until idle. It's really quite easy to do in the ORB - but needs some IDL extensions / poking. Possibly some evil #pragma or something. Isn't it much easier to just *always* disallow re-entrancy, and queue incoming calls in the idle loop? (With the possible exception of calls performed within the implementation of the CORBA method you are invoking, just to have the same behavior as local calls?) Essentially no. Consider: Process Mailer: Shell_getComponent_id (shell, ev); Shell: id = Component_get_id (mailer, ev); return id; We have deadlock. And this is 100% the problem. It is not incredibly obvious what to do about this. [ this is in fact a relatively common occurence with 'ref / unref' ]. Some people moan on and on about threads. So - in the above case, you add a load of threading, which means that every time you want to access anything that a CORBA method accesses you have to take / release a lock - and guess what - you still get deadlock, unless every time you do a CORBA invoke, you carefully release any locks that an incoming call might need to take to fulfill your CORBA method invoke. So essentially you turn your relatively simple re-enterancy issue into a more interesting locking interaction problem. I am not sure I understand why we need this fine-grained degree of control on the method's behavior. It just looks really messy to me. As above; but yes for lots of methods in evolution - we'd want to stop re-enterancy I imagine, and queue a chunk of others until idle. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml - composer not starting ...
Hi Ettore,
On Wed, 2002-05-15 at 18:48, Ettore Perazzoli wrote:
BTW, if we want to add extensions to work around the lack of decent
support for threaded apps, something that would be really useful is a
general mechanism for doing async calls.
Ok; this is in ORBit2/include/orbit/orb-core/orbit-small.h
As I say, currently there is no IDL compiler support for this, so you
need to be slightly clueful to produce your own pseudo-stubs. I
understand there is a specified binding for async stuff in the latest
CORBA release, I havn't looked at it yet, hopefully we can support it
trivially.
Either way for this you have:
typedef void (*ORBitAsyncInvokeFunc) (CORBA_Object object,
ORBit_IMethod*m_data,
ORBitAsyncQueueEntry *aqe,
gpointer user_data,
CORBA_Environment*ev);
/* Various bits for Async work */
void ORBit_small_invoke_async(CORBA_Object obj,
ORBit_IMethod *m_data,
ORBitAsyncInvokeFunc fn,
gpointer user_data,
gpointer *args,
CORBA_Context ctx,
CORBA_Environment *ev);
void ORBit_small_demarshal_async (ORBitAsyncQueueEntry *aqe,
gpointer ret,
gpointer *args,
CORBA_Environment *ev);
The ORBit_IMethod is the method / argument description, containing all
the types etc. neccessary to marshal the stuff. The invoke_async is much
like the existing invoke method; here's a use of it:
Unknown resolve (in ResolveOptions options,
in string requestedInterface);
invocation:
resolve_async_ctx_t *ctx;
/* this argument indirection is what all the stubs / skels
* already use, documented in
* ORBit2/doc/internals/interface-indirection.gnumeric */
gpointer args [] = { options, interface_name };
ctx = g_new0 (resolve_async_ctx_t, 1);
...
if (!resolve_method)
setup_methods (); /* This sets up resolve_method to
point to the the right IMethod
method description */
ORBit_small_invoke_async (
ctx-moniker, resolve_method,
resolve_async_cb, ctx, args, NULL, ev);
resolve_async_cb:
static void
resolve_async_cb (CORBA_Object object,
ORBit_IMethod*m_data,
ORBitAsyncQueueEntry *aqe,
gpointer user_data,
CORBA_Environment*ev)
{
resolve_async_ctx_t *ctx = user_data;
if (BONOBO_EX (ev))
/* the resolve failed for some reason */ ;
else {
Bonobo_Unknown object;
/* no out arguments, 'Unknown' return type */
ORBit_small_demarshal_async (aqe, object, NULL, ev);
if (BONOBO_EX (ev))
object = CORBA_OBJECT_NIL;
/* chain on to some other user callback ? */
}
g_free (ctx);
}
As I say, hopefully we can do most of that automatically in future.
Right now it's a mess of
oneway void doSomethingAsynchronously (in Bonobo::Listener result_listener);
Yes.
Problems with this are:
* You have to set up the listener yourself, connect the
callback, kill the listener. Annoying and somewhat
error-prone.
And inefficient.
* There is no way to document what type the listener expects, so
you can easily mess up the types.
:-) that sucks.
* You have to use CORBA::anys (yuck).
* All in all, it's pretty damn ugly. ;-)
Yes.
Instead, it would be nice to just normally say:
SomeResultType doSomethingAsynchronously ();
and have ORBit provide me with a parameter to specify the callback for
the result when I invoke the function, i.e.
Blah_doSomethingAsynchronously_async (objref, callback, ev);
Yes; as I say we don't auto-generate that yet, but the guts are there.
I must say I quite like Miguel's .Net approach of having two methods, so
you can choose to block for the return value if it hasn't arrived yet [
and of course the fully async callback approach is important too ].
I hope that gives you some hope :-)
Regards,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
Re: [Evolution-hackers] gtkhtml - composer not starting ...
Hi Michael, On Wed, 2002-05-15 at 03:07, Not Zed wrote: It's not possible to attach gdb to a process that lives for only a few handfuls of milliseconds, and dies without giving a user visible message. Bug buddy would help to get this error handled, that is unless you know something I don't. gdb program-name I'm missing how that solves the problem of attach[ing] gdb to a process that lives for only a few handfuls of milliseconds ? can you expand. Running the process by itself works fine, for some reason when oafd forks it, it aborts almost instantly. How does that sound ? Honestly - like a big hack. My solutions are hacks, and your hacks are solutions ? :-) But, given the nature of orbit, i dont see any other solution, since nobody wants to use threads. Of course no-one wants to use threads, the infrastructure isn't there. The above scheme would have the benefit of removing a chunk of queueing code in evolution [ AFAIR lots of incoming CORBA calls are just defered to idle manually - and we could do that automatically ], and stop calls re-entering. And naturally there are a number of other solutions [ a push / pop re-enterancy guard, named method re-enterancy ... ], this solution just occured to me as being a somewhat elegant, efficient and fool-proof one. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gtkhtml - composer not starting ...
Hi Michael, On Tue, 2002-05-14 at 01:26, Not Zed wrote: They wont be able to do anythign about it anyway, so it doesn't matter. If they care enough they can use gdb manually. It's not possible to attach gdb to a process that lives for only a few handfuls of milliseconds, and dies without giving a user visible message. Bug buddy would help to get this error handled, that is unless you know something I don't. b) It looks like a CORBA method is being called from a class_init method, this has caused some serious grief in Gnome 2.0, where re-enterancy is more likely due to a lot less blocking going on. So you're saying the reentrancy problem isn't addressed and has gotten worse? I'm saying that there are no more places where re-enterancy is theoreticaly possible, simply that it seems that fewer of these re-entered in Gnome 1.4 - for reasons unexplained. We really ought to add a 'manic re-entrancy' mode, where it attempts to allow methods to re-enter as much as possible for testing I suppose - fairly easy to do. ORBit2 does a lot less blocking, which gives better performance, but yes - one consequence of handling more CORBA calls more quickly is that you get more re-enterancy. What a total nightmare. Well - since evolution will be porting to Gnome 2.1, I have a couple of somewhat trivial ideas to help your re-enterancy problems ( and cut a swathe of code out of evolution ) that we can get into the platform in that timescale. My re-entrancy 'fix' is also also rather simple, so I'll explain it to you: [ thanks for provoking me into sharing this, since I'm supposed to write a formal proposal or somesuch and havn't got round to it ]: For each corba method we add an IDL [or other] annotation that describes the method behavior and (re-)ordering constraints. Thus: + oneway foo (in string baa) [ handle_at_idle, no_re_enter ]; Or perhaps - for people who like blocking: + string getMyName () [ no_re_enter ] Thus people can invoke methods, no re-entrancy will occur on that method invoke, and we can queue methods execution until idle. It's really quite easy to do in the ORB - but needs some IDL extensions / poking. Possibly some evil #pragma or something. Then we are at least at the X level - where incoming events are processed in an idle loop, and outgoing events don't re-enter [ but of course can do if we think we can cope with writing some re-entrancy safe code ]. How does that sound ? Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Scripting in evolution
Hi Michael, On Fri, 2002-05-10 at 01:16, Not Zed wrote: Despite what others are saying, you can't just use the corba interfaces for this. This is presumably, because these interfaces were not designed for scripting at all. Despite the fact the mailer just doens't have them, there are certain things you couldn't do with it, and besides, the interfaces are painful and awful to use. Painful and awful ? perhaps from C, but not from an object oriented scripting language, with exception handling. What things could you not do with them, that somehow you could do with any other method ? I don't understand that objection. It needs to be something that ORDINARY people can use. You shouldn't need to understand what an orb is, or how to write scheme or lisp, etc. You have no need to understand what an ORB is with a properly written CORBA language binding - there really is no need. Nor do you need to use scheme / lisp. You can use eg. Johan's Python binding which I understand is very clean. It would have to be powerful enough to code all those annoying features nobody wants to implement. Even 'core' functionality like 'mark all as read' or 'goto next unread folder, jump to first unread message', could be done as a 'script'. Well - that's should be fairly trivial to execute as a verb on the UIContainer; 'SelectAll' or whatever - sadly scripts don't have a method to execute verbs remotely - until Gnome 2.0. I'd almost rather evolution-mail was more of a skeletal engine and most of the functionality a user saw (i.e. menu items) was a script (e.g. like emacs). Sounds good to me. I'd like to add multi-press keystroke handling to the Bonobo UI handler so we could bind to C-x 4-a etc. ;-) but then I'll never have the time. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] gtkhtml - composer not starting ...
Hi there, I just had another spate of this - and imagine my suprise to find that gtkhtml-1.1 seems to be using gconf [ and gconf for whatever reason was screwed ]: gtkhtml-ERROR **: gconf error: Configuration server couldn't be contacted: Adding client to server's list failed, CORBA error: IDL:CORBA/COMM_FAILURE:1.0 aborting... Program received signal SIGABRT, Aborted. 0x40cb58d1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x40cb58d1 in __kill () from /lib/libc.so.6 #1 0x40cb564d in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x40cb6cb8 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40c006ce in g_logv (log_domain=0x4009820e gtkhtml, log_level=G_LOG_LEVEL_ERROR, format=0x4009861d gconf error: %s\n, args1=0xb43c) at gmessages.c:391 #4 0x40c0076f in g_log (log_domain=0x4009820e gtkhtml, log_level=G_LOG_LEVEL_ERROR, format=0x4009861d gconf error: %s\n) at gmessages.c:408 #5 0x40049ed8 in init_properties (klass=0x80ae920) at gtkhtml.c:1962 #6 0x4004aad8 in class_init (klass=0x80ae920) at gtkhtml.c:2465 #7 0x409a7c15 in gtk_type_class_init (type=50197) at gtktypeutils.c:598 #8 0x409a7336 in gtk_type_class (type=50197) at gtktypeutils.c:342 #9 0x409a7425 in gtk_type_new (type=50197) at gtktypeutils.c:362 #10 0x4004af11 in gtk_html_new () at gtkhtml.c:2598 #11 0x0805c183 in editor_control_construct (control=0x80ae680, vbox=0x80ae518) at editor-control-factory.c:481 #12 0x0805ca6b in editor_control_factory (factory=0x80a8a90, closure=0x0) at editor-control-factory.c:769 #13 0x40676702 in bonobo_generic_factory_new_multi () from /usr/lib/libbonobo.so.2 #14 0x40676172 in bonobo_directory_get_name_service () from /usr/lib/libbonobo.so.2 #15 0x40b98019 in _ORBIT_skel_GNOME_ObjectFactory_create_object (_ORBIT_servant=0x80a8ae0, _ORBIT_recv_buffer=0x80ab900, ev=0xb650, _impl_create_object=0x40676108 bonobo_directory_get_name_service+120) at oaf-factory-skels.c:160 #16 0x40bcb200 in ORBit_POA_handle_request (recv_buffer=0x80ab900, poa=0x807f2b0) at orbit_poa.c:513 #17 0x40bcd46a in ORBit_handle_incoming_request (recv_buffer=0x80ab900) at server.c:90 #18 0x40bcd691 in ORBit_handle_incoming_message (recv_buffer=0x80ab900) at server.c:160 #19 0x40be2ce4 in giop_main_handle_connection (connection=0x80ad508) at connection.c:1214 #20 0x40b96aa9 in orb_handle_connection (source=0x80abb00, cond=G_IO_IN, cnx=0x80ad508) at oaf-mainloop.c:70 #21 0x40bfca7a in g_io_unix_dispatch (source_data=0x80abb18, current_time=0xb7e0, user_data=0x80ad508) at giounix.c:137 #22 0x40bfe055 in g_main_dispatch (dispatch_time=0xb7e0) at gmain.c:656 #23 0x40bfe659 in g_main_iterate (block=1, dispatch=1) at gmain.c:877 #24 0x40bfe7e8 in g_main_run (loop=0x80aba20) at gmain.c:935 #25 0x409502ab in gtk_main () at gtkmain.c:524 #26 0x4067753b in bonobo_main () from /usr/lib/libbonobo.so.2 #27 0x0805cbf5 in main (argc=1, argv=0xb8d4) at editor-control-factory.c:855 #28 0x40ca3306 in __libc_start_main (main=0x805cb24 main, argc=1, ubp_av=0xb8d4, init=0x80514e4 _init, fini=0x806c6f0 _fini, rtld_fini=0x4000d2dc _dl_fini, stack_end=0xb8cc) at ../sysdeps/generic/libc-start.c:129 (gdb) up 6 I couldn't care less about the gconf usage, but there are a couple of problems here: a) The 'abort' is not trapped by bug-buddy, leaving the user with just a frustrating CORBA_COMM_ERROR back from oafd - since gnome-gtkthml-blah crashed while it was starting up and before it returned it's OAFIID correctly. So, it's virtually impossible for the user to tell what went wrong. [ I can't think of any possible way to make debugging that any easier - creative ideas, better than re-directing a child's stderr on fork trying to grok it on exception welcome - or 100% robust code to do that even ;-]. b) It looks like a CORBA method is being called from a class_init method, this has caused some serious grief in Gnome 2.0, where re-enterancy is more likely due to a lot less blocking going on. It's possible for something to re-enter, and instantiate the same class, which will not yet be initialized, causing much type system / locking grief. you might want to move this gconf-ness out of the class init into the instance init bit. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GtkTree vs. ETable in the GNOME 2 port
Hi Ettore, On Thu, 2002-04-11 at 17:52, Ettore Perazzoli wrote: Last time I looked the estimate was about two man-months. My feeling is that porting Evolution to use GtkTreeView would take less time, and is also a more easily parallelizable task. Two man months was to make all of gal accessible key-navigable, + some error margin so we could hit the deadline. The E-table part of that I anticipate being somewhat quicker. That's why have to start listing the features that we want now, and make sure that they get into GTK+. Fair enough, I have no problem with improving GtkTree :-) Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GtkTree vs. ETable in the GNOME 2 port
Hi Ettore / Jonathan, On Wed, 2002-04-10 at 22:37, Ettore Perazzoli wrote: * 100% accessible. (If we port Evolution to GNOME 2, we have to add accessibility support to all the widgets, and making ETree accessible is a very non-trivial task.) I don't particularly concur here; in fact it's unlikely that adding accessibility to E-table is going to be _that_ hard. Certainly compared with the hassle of switching, the pain of using a big chunk of complex code over which we have no control, and cannot add features to ( due to the disparate Gtk+ release cycle ), it's a trivial thing. * Maintainability. ETable is a very complex codebase, and we still find bugs in it. Ditto GtkTree :-) and that's without adding the new code to implement the features we need. Ultimately if you want features you get complexity - surely ? The tree accessibility code is ~7000 lines of code (in gail), much of it relatively trivial. 'Gal' is already substantially ported to Gnome 2.0 modulo pangoization and E-table works fine modulo converting some glade files. So, it all depends on when we want to port, whether we can get the features we need into Gtk+, when we port relative to the Gtk+ freeze etc. My concern would be that we could get ourselves into an extremely inflexible situation between an immovable Gtk+ freeze schedule and a lack of critical features / API in GtkTree*. While I'm sure that Chris would like to work on a unified, de-canvasized, table widget with Jonathan. It would seem that the safest, quickest, easiest and most maintainable course would be to continue the ETable port - given that currently it compiles and runs fine, needing only pangoization and a11y support adding. Of course, if we have time, and Jonathan / whomever can add the things we need in time, and we get some commitment to holding Gtk+ X.Y until it's right for us perhaps it makes sense to switch to the Gtk+ way. Whatever happens the switch looks like a major timescale risk. Just some random blatherings, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] composer startup speed ...
Hi Larry, Just chasing down the (evil) composer startup problem, and I notice that the gtkhtml component activates the spell component before returning it's factory: #6 0x40bad80c in oaf_activate_from_id (aid=0x806eea0 OAFIID:GNOME_Spell_Dictionary:0.1, flags=0, ret_aid=0x0, ev=0xb550) at oaf-activate.c:300 #7 0x40676f88 in bonobo_object_activate (iid=0x806eea0 OAFIID:GNOME_Spell_Dictionary:0.1, oaf_flags=0) at bonobo-object-client.c:75 #8 0x08066336 in spell_new_dictionary () at spell.c:189 #9 0x0805b5a9 in gtk_html_control_data_new (html=0x809ff98, vbox=0x809bbd8) at control-data.c:39 #10 0x0805c47a in editor_control_construct (control=0x809d308, vbox=0x809bbd8) at editor-control-factory.c:526 #11 0x0805cca7 in editor_control_factory (factory=0x80973e8, closure=0x0) at editor-control-factory.c:799 #12 0x4066ecf8 in bonobo_generic_factory_new_generic (factory=0x80973e8, oaf_iid=0x80988c8 OAFIID:GNOME_GtkHTML_Editor) at bonobo-generic-factory.c:263 #13 0x4066e4af in impl_Bonobo_ObjectFactory_create_object (servant=0x8097438, obj_oaf_iid=0x80988c8 OAFIID:GNOME_GtkHTML_Editor, params=0xb690, ev=0xb6f0) at bonobo-generic-factory.c:56 Is it feasible to delay that to an idle handler / demand activate it ? clearly the faster you return from the factory method the faster the rest of the system can get on with life. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] strace of composer failure ...
Hi Guys, I havn't had time to analyse what's going wrong; but an strace fragment of the composer creation problem is here: http://primates.ximian.com/~michael/evo-composer-issue.log HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] More on 2.5.5 kernel and calendar
Hi Milan,
On Fri, 2002-03-08 at 23:44, Milan Hodoscek wrote:
The problem is a CORBA call to getType with a property of entry_changed.
The final bit of the call (which the debug spits out as being Sending
request getType id ... to ...) is different for this call only - it
appears to be normally null, but for this call is '\1'.
Interesting - the bytes after 'GIOP' are the version of GIOP that is
being used - of course, it should be the same for both. The 2 octets
should be one of:
const char giop_version_ids [GIOP_NUM_VERSIONS][2] = {
{1,0},
{1,1},
{1,2}
}
where the index is:
typedef enum {
GIOP_1_0,
GIOP_1_1,
GIOP_1_2,
GIOP_NUM_VERSIONS
} GIOPVersion;
Which seems slightly odd.
Poking at it, under older kernels, the addressbook sends this query via
a socket that is looped back to itself, and all is fine. Under newer
kernels, the addressbook process sends it via a socket connected to the
wombat process, which says something like:
I'm very suprised the addressbook sends a query that is looped back to
itself - that rather shocks me. If it is calling in-process then it
should do a direct C call, there should never (AFAIK) be a socket that
is looped back into the same process. That sounds like a shocker bug,
that would be really great to trace - [ I'm paranoid about missing
FD_CLOEXECs but we seem to use them everywhere correctly in ORBit ... ].
write(2, WARNING **: , 12)= 12
write(2, No POA found for operation getType [-1073752364], 48) = 48
write(2, \n, 1) = 1
...and is deaf, dumb and blind to the addressbook from that point
onwards.
Quite possibly if we fail to find a skel to de-marshal the data, then
the pipe gets full of corrupt / badly ordered data and subsequently
nothing will work - which sucks, but it's difficult to know how to fix
that really. I'd also imagine that the process will crash pretty rapidly
after getting (what it percieves as) out of order data on the socket.
I'm presuming that the newer kernels exhibit some behaviour that makes
orbit (or evolution?) set itself up differently, but... does anyone have
any idea of what it might be? Or where to start looking? Thanks in
advance.
Could be an FD_CLOEXEC problem - at the deep outside, any further
investigation would be most interesting helpful,
Regards,
Michael.
--
[EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot
___
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Mouse grabs ...
Hi Jeff, On Thu, 2002-03-07 at 16:00, Jeffrey Stedfast wrote: Has anyone been able to reproduce with the current development branch? I've so far only tried it 4 or 5 times, but so far have not encountered this problem. I'm beggining to think it's a sawfish problem, inasmuch that sawfish seems to behave very oddly on my machine at the moment, I'm using sawfish-2 so I'm going to blame that for a while. I'd be interest to know if other people suffering are using the stable sawfish. However - evolution snapshots are still not available - which is quite amazing to me, and no one seems to want to own up as responsible. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: Bonobo-moniker problem?
Hi Jonas, On Sat, 2002-03-02 at 16:42, Jonas Aaberg wrote: Thanks alot for answering so quick! No problem. It's a general error - it's not necessarily the same sadly. Yeah, but the probability that it is the same, is quite high I guess. Nope; your error is unique to your system, the general error is that it couldn't start the named component. oaf-slay kills my oafd nicely. bonobo-moniker-xmldb says: $ bonobo-moniker-xmldb Message: Successfully registered `OAFIID:Bonobo_Moniker_xmldb_Factory' Gtk-WARNING **: invalid cast from (NULL) pointer to `BonoboObject' Bonobo-CRITICAL **: file bonobo-running-context.c: line 413 (bonobo_running_context_auto_exit_unref): assertion `object != NULL' failed. Ok - you need to debug these issues - they do not occur on my system - it looks like the bonobo-moniker-xmldb is already running by the time you run that application. Are you sure that is the first time you ran it after an oaf-slay ? And stops there forever. Well; it should prolly have quit here - feel free to patch it - the generic factory should return NULL if already registered and the app should quit in response. A patch (to me) would be appreciated. and make sure that runs, also run wombat by itself and verify that runs, $ wombat wombat-Message: Starting wombat Message: Successfully registered `OAFIID:GNOME_Evolution_Wombat_ServerFactory' wombat-pas-Message: Error registering the PAS factory: not listed wombat-Message: main(): could not initialize Wombat service PAS; terminating $ Ok - this is just totally broken then - assuming again this was the first time you ran it. It looks like oafd can't find the oafinfo file describing the factory. This is most likely because your GNOME_PATH does not include the prefix in which you have installed evolution. Like I did with oaf and bonobo. Bonobo went to /usr/local/Libs/bonobo. Well, actually to bonobo-1.0.19 since bonbo is symlinked to bonobo-1.0.19. (ln -s /usr/local/Libs/bonobo-1.0.19 /usr/local/Libs/bonobo) (notice that I do configure --prefix=/usr/local/bonobo to simplify upgrades.) This is almost certainly the root of your problems, you need to setup GNOME_PATH to point to every prefix you use or you will get nothing that works. I've never set up any GNOME_PATH, but all gnome programs except Evolution run well. (Yeah, I have add libraries and paths and such things manually in gnome-config) Well - setup your GNOME_PATH it should be of the order of: export GNOME_PATH=/usr:/usr/local And then you don't have to hack gnome-config, it will 'just work'. A multiple prefix setup is highly unlikely to work for Gnome beginners - sorry. I've written kernel modules for some hardware, but making Evolution with bonobo to work beats me. ;-) The daemon has to be able to find the component descriptions, or nothing will be activated. As for compiling software into a single image - it's significantly easier than have a rather complex set of interlocking components that need activating ;-) (It is a slackware 7 or 8 based system with alot of modifications.) Sigh. :-) Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Mouse grabs ...
On Fri, 2002-03-01 at 20:41, Ettore Perazzoli wrote: Hm, I don't know anything about this bug, but I don't think it's fixed in the snapshots. Fejj is the one to bug about it... I'm beggining to think it might be related to the mail being marked 'read' in mid DD, But that might be nonsense, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Mouse grabs ...
Hi Guys, A nasty moan - I have had to kill evolution 3 times today because of leaked mouse grabs DD mails from evolution-mail to the shell tree view. The leak appears to be in evolution-mail inasmuch that killing that process frees up the system. I'd love to fix it, but it's not worth my time to consume an hour re-building evolution and bug hunting only to find that it's already fixed. So - what is the status / problem with the snapshots ? who is responsible for this ? I'm very happy to do the work - but I need some support. Regards, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
