Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 46 47 48 49 51 52 53 54 ... 55 ... 60
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.
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|
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|
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:
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|