MemeCode - Blog

Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 47 48 49 50 51 52 53 54 55 ... 60

Filter UI
Date: 5/6/2006	Last night I ripped out the UI for conditions in Filters and replaced it with the slick new UI that I wrote last year. I've updated it and intergrated it into the application and it looks and works great. The UI is serialized into XML which is stored as a new property field in the existing filter object. Old filters are upgraded transparently to the new format when you save them. So there is some lack of backward compatibility, i.e. if you save a filter in the new version of Scribe and then try and view it in an old version all the conditions will disappear. Oh well, at least it won't crash or misbehave beyond that. All I need to do now is hook up the new condition data to the code that evaluates the conditions against an email. I'm thinking about actually letting the user export/import filters to XML files. Some benifits of being able to do that would be allowing groups of users distribute their custom filters, backup/restore and maybe evan scripting/automation of filters down the track. The filter UI will also effect the find/search window, which I haven't even started on yet. But chances are I'll get to it this week.
(1) Comment \| Add Comment

Scribe Test4 Directions
Date: 2/6/2006	Apart from fixing the new Scribe crashes that are appearing in Test2 and Test3 I just wanted to say a few words on where I'm heading in Test4 in terms of upgraded functions and features. Fix Bug #42 by implementing a new search function using the Filter UI that I wrote last year. Improve the mail2 export with all the feedback I'm getting. So far the dialog wording is ambiguous and some defaults need fixing. Also some things in the backend need to be reworked a little and support for other types of objects needs to be added. For many many versions Scribe has supported the one folder format, and older versions read/write the mail2 file without issues. But I want to make some non-backward compatible changes to the file format. I want to move the body of messages into child nodes of messages instead of being a property of the message node itself. And then maybe force all the messages to be in a single data block so that I can read them in without seeking around inside the mail2 file. This would be the ultimate fix for folder loading speed. But it would not be backward compatible, so I'd have to call it "mail3". At the same time I'm also thinking of supporting maildir + indexes as a mail store. Which would likely involve API changes, which combined with the mail3 changes would make sense to do at the same time. I would also like to rip out the crusty MIME parser that Scribe's been using for like ever now and replace it with the shiny new one that doesn't suck. The issue with that is a lot of the "smarts" with charsets and decoding of content is embedded in the current MIME parser and needs to be extracted out so that it can be added to the new parser. Which is a) painful and b) likely to be buggy to start with. Here is where the rubber hits the road. If the software is going to get "better" then it needs to get worse in the short term as I rip out badly written code and insert better foundations. Change always brings unstability in the short term. It's a constant in the software industry. Especially with a dev team of one. The options are lots of fast turn around test builds that are not stable, or no releases for a while (months?) and then a relitively stable release. What would you, as a user prefer?
(3) Comments \| Add Comment

Scribe Release
Date: 29/5/2006	It's time for a new release of Scribe as the change list has become long and a) it needs testing and b) people need the fixes contained therein. If you have some outstanding issue that isn't addressed in the change list that you want to remind me of, you have about 24 hours to tell me about it. I think I've covered everything but feel free to correct me if I've overlooked something. Also if your a translator, now would be a good time to send me any edits to your translation. I'm going to test things for a day, let the last few changes get some exercise and make a release tomorrow night if no show stoppers appear.
(1) Comment \| Add Comment

Hard Disk Prices
Date: 29/5/2006	Gee let me see... where is the sweet spot in $/MB I wonder? Wow, it really goes flat there for a bit doesn't it. Seems like 300gb is the g.o.
(0) Comments \| Add Comment

Scribe Folder Load Speed
Date: 26/5/2006	It seemed to me that over the years the speed of loading folders in Scribe has got slower and slower. To the point that I grimice inside everytime that stupid progress bar comes up. Well today something very interesting happened. I was testing the mail2 export code (now almost finished!) by exporting the spam folder to a empty mail2 file. Then loading it in a clean install of i.Scribe. And I knew that with about 7000 and something messages, loading that folder should take 10 seconds or so. And you know what. It took about a second. Huh I thought? So thus the little light went on in my head. I tried it again, still uber fast. I loaded up the dev build of InScribe and.... slooooow. i.Scribe... fast... InScribe... slooooow. Ok so what the hell is going on here? Firstly I recompiled the dev version in release mode. Just to rule out the different between release and debug builds. That didn't make a whole lot of difference. Then I rebuilt as i.Scribe and that didn't change anything. So I tried clean installs, removing the accounts, trying every different combination until I hit upon the problem. Everytime I load an email the to and from address are turned into objects that have links back into the contact database. The action of creating these links while loading mail in a folder is somewhat time consuming when done en masse. The solution? Do it on demand. It then only gets done on a few email at a time, spread out over time so it's almost negligable. But that frees up the folder load to run at full speed, not bogged down with all this searching around in the address book. And man does it fly now. A folder of 7000 odd messages loads in about a second. And a lot of folders that would progress bar me every day now load instantly. This little edit might break a few things here and there. But in the long run it'll be good for everyone. I'm sure we'll iron out the bugs in no short time with a little feild testing. Yay for speed. Update: Well over the last few days where I've got to use the code more and see it working on a different system it's not all as good as I'd hoped. I think the issue is that the disk cache is making any sort of meanful measurement of folder load speed meaningless. When I initially load a folder after system boot, nothing is cached and it's only marginally faster than before. Not instant. However later on after loading things a few times, it's fetching from cache and it's a lot faster. Every now and then windows dumps the cache and it slows down. So I'm not sure how much faster it really is. I expect it's really somewhere in the order 30-50% faster than before. Does anyone know how to profile code that accesses the disk? Is there a way of flushing the disk cache before running your tests?
(2) Comments \| Add Comment

Zeta Install
Date: 26/5/2006	Well the old dual 400 machine I built the other night is now running Zeta RC3. Apart from some hiccups getting it to install I'm pleasantly surprised by a few things: Network worked out of the box, just had to set DHCP. There is a reasonably current build of Firefox for it. ssh is installed and works! svn installs and works! So I checked out the Lgi codebase and tried compiling it. Hahah.. what a huge long list of (weird) errors. I really struggled getting Zeta to run on my main machine (nvidia support), I should try it on the new system sometime. But having a old compatible system is good too. Means I might get some work done in Zeta again. Previously I was pretty ticked that svn didn't work. Now that it does, I'm in a more forgiving mood. However I still remember all too well how lame bdb is.
(0) Comments \| Add Comment