[Evolution-hackers] Problems with Outlook and iCalendar
I discovered on Friday that although Outlook was parsing our VTIMEZONE data, it wasn't actually using it correctly. It turns out that Outlook only seems to look at the first 2 RRULEs or the first RDATE in the VTIMEZONE (i.e. you can have 2 RRULEs specifying standard & daylight time forever, or you can have 1 UTC offset forever.) So I've spent the weekend trying to work around this problem. I've rearranged our VTIMEZONEs so the current RRULEs or RDATEs come first, so Outlook will use those. I also wrote a script to create an iCalendar file with events in all of our 372 timezones, and imported that into Outlook. It looks like the zones are handled OK now. (These aren't in CVS yet, though.) Damon PS. Some good news - I found a few more bugs in the timezone code, and we now agree with mktime()/localtime() in all 372 zones from 1990-2009, except in Asia/Bishkek for 1 hour in 1992! (The bad news is I had to break 7 timezones slightly so that Outlook would parse them OK.) ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: Another oaf race condition
> > > I looked at trying to fix this, but it's going to require some not-tiny > > > code reorganization, I think. (If it turns out to be too annoying to fix > > > quickly for oaf 0.x, a simple hacky solution would be to return a > > > "TryAgain" exception and have liboaf loop until it doesn't get that...) > > > > That sounds like a passable workaround. > > Well, I'll leave you to do that if you want, since it looks now like we > can "fix" evolution without even needing an oaf release by just making > wombat always try to register every interface before exiting. Well, I tried kludging wombat, and that wasn't working, and then I tried adding the TryAgain hack to oafd and that wasn't working either. Someone who understands this stuff better than I do is going to have to deal. -- Dan ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Hard freeze warning!
On Mon, 2001-10-15 at 13:00, Ettore Perazzoli wrote: > So, everyone will be working hard this week to isolate and fix all the > major and most common bugs. Bugs that actually prevent usability of the > application will take precedence over the usual nit-picking. No > crashing bug shall be left alive. It's not the crashing bugs which concern me. :-/ It's the ones which completely corrupt and screw my mailboxes, and lose thousands of stored messages. Please see my earlier message for details. It's easy to work around these, but it's also easy to reproduce them. It's also the sort of thing that I can easily trip over when creating a new Evolution setup and importing a big collection of mail. (Actually, I've found lots of one-shot, hard-to-reproduce bugs in 0.15, too. Just now, when I was editing this message, a line of text--right where this paragraph is--appeared in grey for no good reason. I put a cursor on it, hit delete until I reached the "mail." above, and my cursor disappeared. Then the entire edit window (below the size/style toolbar) turned grey, and Evo told me that the editor was gone. If I see it again, I'll feed a screenshot and reproduction details to bugzilla. Oh, for instant replay.) Bugs aside, however, Evolution is the best mail client I've ever used, seen or heard of. ;-) Cheers, Eric ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Hard freeze warning!
Hello all, this is just a warning to let everyone know that we are aiming for a total "hard" code freeze in exactly two weeks from now. That's right, in two weeks we are supposed to come up with a 1.0 Release Candidate. From that point, the code will only be changed in case of extreme brokenness. This means that all code refactoring should now stop. No code optimization or major code cleanup is allowed from this point. No behavior will be changed. All the requests for features and featurettes are going to be kindly redirected to /dev/null. :-) So, everyone will be working hard this week to isolate and fix all the major and most common bugs. Bugs that actually prevent usability of the application will take precedence over the usual nit-picking. No crashing bug shall be left alive. Of course, we would greatly appreciate help from you, our user base. If you find a serious bug, please don 't hesitate report it. If you don't report the bug, there are high chances that 1.0 will ship with that bug. Also, Bug Days are going to happen normally on Thursday 9am - 9pm EDT (1pm - 1am UTC) on irc.gnome.org, channel #evobugs. See you there! -- Ettore
[Evolution-hackers] Re: [Evolution] Watch out for the new editor changes!
On Fri, 2001-10-12 at 09:24, Miles Lane wrote: > There are other things, like URLs not turning blue when I paste > them. The turn blue when I place the cursor at the end of the > URL and hit Enter. If you paste just link, it should turn into HTML link auto-magically now. (CVS) Other cases could be handled once 1.0 is out. Fell free to add feature request to bugzilla. Radek Radek Doulík [EMAIL PROTECTED] Hacker Monkey Ximian, Inc.
Re: [Evolution-hackers] Bug? To-do list freezes X
In Bugzilla against the GAL/Etable component. Luis On Mon, 2001-10-15 at 08:49, Eric Kidd wrote: > Evolution 0.15, installed using Red Carpet. > > To reproduce: > > Go to the summary view. Click on "Tasks". This brings up the > full-screen display. Double-click on the text of a specific task. > > What happens: > > X refuses all further input until Evolution is killed from another > console. This is consitently reproducible on my machine. > > What should happen: > > I presume evolution should pop up a dialog or something. :-) > > Cheers, > Eric > > > ___ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Luis Villa Ximian Bugmaster "Quality is an amazing bridge because it is universal in its language." Thomas Corcoran ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] bug ? evolution wont send messages
[sorry if this bug report is not complete] [standard disclaimer applies] i reproduced this bug on following environments: Toshiba Laptop, Intel PIII, 128 RAM, runing RH7.1, kernel 2.4.12 AMD Duron 700 Mhz, 128 RAM, running RH7.1, kernel 2.4.10-ac1 Intel PII, dual, 128M RAM, running RH7.1, kernel 2.4.9-ac10 all are workstations in the company i work for, belonging to me and other 2 coleags. also don't think is anything about the architecture or the kernel installed. Evolution 0.16.99 +cvs2001.10.13.08.08 after writing a message (new message/reply to message), and pressing send, on status bar it says "sending message (100%)", and keep saying that. the message is NOT sent. if you close evolution, open it again and click on "new message" it says "Evolution has found would you like to recovre them ?". if you press yes, it will recover the message you tried to send earlyer. of course, it will not send it now either. usually this are 1 day bugs, so that's why i waited 2 days for a new snapshot. unfortunatelly i had to downgrade to be able to send mails from evolution -- Tiberiu Ungureanu Network Administrator iNES Internet [EMAIL PROTECTED] | Linux Registered User #130450 "Linux is Friendly. It's just selective about who his friends are" ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: Another oaf race condition
> Can you reproduce this with any other components besides wombat? Hm. Interesting. bonobo-application-x-mines behavior: 1. First copy is launched by oafd, calls oaf_active_server_register, which outputs the IOR and returns OAF_REG_SUCCESS 2. Second through fourth copies are launched by oafd, each calls oaf_active_server_register, which outputs the IOR of the already-registered first bonobo-application-x-mines and returns OAF_REG_ALREADY_ACTIVE. bonobo-application-x-mines fails to notice the error return and continues running. Result: four successful oaf-client calls all returning the same answer. One working and three dead bonobo-application-x-mines processes. wombat behavior: 1. First copy is launched by oafd, calls oaf_active_server_register several times. Each call returns OAF_REG_SUCCESS and one of them prints out an IOR because it's registering the --oaf-activate-iid server. 2. Second through fourth copies are launched by oafd. Each makes the first of its several oaf_active_server_register calls, but the first one isn't the interface it was launched to provide, so it doesn't output an IOR. wombat notices the OAF_REG_ALREADY_ACTIVE return value, so it prints a message that wombat is already running and then exits without ever trying to register the other interfaces. Result: one successful oaf-client call and three failures. One working wombat. > > The problem is that each call to impl_OAF_ObjectDirectory_activate after > > the first is called from inside the g_main_run in the > > oaf_internal_server_by_forking_extended that gets called by the previous > > impl_OAF_ObjectDirectory_activate. > > Can you give me some more detail on this? > > What is it about this re-entrancy that makes it break? impl_OAF_ObjectDirectory_activate is called, looks in its hash table, sees that the wombat is not running, and starts to activate it. While it's waiting for wombat to activate, impl_OAF_ObjectDirectory_activate is called again, looks in its hash table, sees that wombat is not running, and starts to activate it. While it's waiting for that second wombat to activate, ... > > I looked at trying to fix this, but it's going to require some not-tiny > > code reorganization, I think. (If it turns out to be too annoying to fix > > quickly for oaf 0.x, a simple hacky solution would be to return a > > "TryAgain" exception and have liboaf loop until it doesn't get that...) > > That sounds like a passable workaround. Well, I'll leave you to do that if you want, since it looks now like we can "fix" evolution without even needing an oaf release by just making wombat always try to register every interface before exiting. -- Dan ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Bug? Filter during Send / Receive eats Inbox
[Sorry if this bug report is a bit vague; it gives me the heebie-jeebies to sit around reproducing corruption bugs.] Evolution 0.15, installed using Red Carpet. To reproduce: Create a large, unfiltered Inbox (several thousand messages seems to be best). Create many filters. Create a large spool file (again, several thousand messages seems to be best). Configure Evolution to know about this spool file, and click on Send / Receive. Now, while Evolution is importing mail, choose "Apply Filters" from the menu. (I don't /think/ you need to run an expunge after filtering, but you may want to try it if you can't reproduce the bug as above.) What happens: The Inbox gets weird. * Sometimes, Evolution complains about not being able to find message number N (during a variety of operations). This can be cured by quiting and restarting Evolution. * Other times, I've lot thousands of messages into never-never land. What should happen: Evolution should either (1) prevent me from editing mailboxes during Send / Receive or (2) deal with the changes gracefully. Possibly related problems: If I open a mailbox before I start importing mail into it (using File/Import...), I seem to retain the ability to edit that mailbox. Proceed with the filtering as before. ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Bug? To-do list freezes X
Evolution 0.15, installed using Red Carpet. To reproduce: Go to the summary view. Click on "Tasks". This brings up the full-screen display. Double-click on the text of a specific task. What happens: X refuses all further input until Evolution is killed from another console. This is consitently reproducible on my machine. What should happen: I presume evolution should pop up a dialog or something. :-) Cheers, Eric ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Python slapd goodies
I decided, in a moment of madness, to make Evolution talk to the Dartmouth Name Directory, an old directory service at my alma mater. This was a slightly crazy thing to do, because I didn't know the first thing about LDAP. :-/ Fortunately, the OpenLDAP project's slapd daemon supports external shell scripts, and there are lots of LDAP-related RFCs out there. (And I'd worked with the DND before.) So after a /very/ long day of hacking, I can now access the DND through LDAP. If anybody else has an older, funky directory service, and wants to be able to access it from Evolution, please let me know. I can package up my Python code in a module and release it. Cheers, Eric ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: [Evolution] Watch out for the new editor changes!
Hello! On Fri, 2001-10-12 at 09:24, Miles Lane wrote: > I have built the code from the latest CVS. > There are many weird bugs showing up when doing things > like pasting links into a message. I have noticed things > like the ends of a URL being repeated multiple time beneath > the text. Like this: > > http://fdg.fdsgf.org/dsfgfdsg/fdsg/dfsg/ffdjkgfd/fdsgs > jkgfd/fdsgs > jkgfd/fdsgs > jkgfd/fdsgs > > Scrolling up and down makes these lines disappear. > I think some of this weirdness only happens when the body > of text that is being pasted into is all formatted as > "Preformat". I've fixed similar issue in CVS, could you please try if it solves your case too? I couldn't reproduce it here, so it's either fixed or I am not trying hard enough ;-) > There are other things, like URLs not turning blue when I paste > them. The turn blue when I place the cursor at the end of the > URL and hit Enter. This didn't work even before my changes, but it seems reasonable to me and is easy to do. > Also, sometimes when I attempt to paste a URL, the first time > I try, what is pasted is whatever I had previously copied > into the X buffer by highlighting some text. The second > attempt of highlighting the new text and then pasting > (middle button) pastes the correct text. This is probably too not related to speed-up changes. It's some selection related bug. Please could you fill bug report about this? Radek -- Radek Doulík Hacker monkey [EMAIL PROTECTED] Ximian, Inc. ___ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
