Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 45 46 47 48 50 51 52 53 ... 55 ... 60
|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|
Date: 25/5/2006||I wrote a little utility today that cleans up (X)HTML that has been written by a rich text editor and has masses of styles and strange little XML tags everywhere. i.e. the sort of HTML that Microsoft Office outputs. It's called Squeaky Clean and it uses a XML parser to read the XHTML into a DOM tree, cleans out all the styles and junk tags and then lets you do some clean up by hand. Then save it out to disk or copy some/all of it to the clipboard using the built in editor.
It is somewhat configurable via the 'Clean.xml' options file which specifies which attributes and elements should be deleted.
By default it removes all the styles, so you have to go back and reimplement the styles if you need them. But now that the markup is fixed it's relitively painless. Future versions may expand upon the level of style removal, but for my needs all the source styling is just junk, hence the alpha just removing them.
|(0) Comments | Add Comment|