| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 29 30 31 32 33 34 35 36 37 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75
| The Big Scribe Re-write | |
|---|---|
|
Date: 8/2/2008 | Yes. I'm in rewrite number 4 of Scribe. I've taken an extremely pessimistic view of what I can achieve and aimed low. Let me explain, in all the previous efforts I was trying to replace the backend at the same time as changing the API between the objects in memory and the disk storage interface. This was always problematic because there is too much going on at any one time and it unravels and I lose momentum and the rewrite dies...
So this time, a new idea. Don't re-write the backend, just use the existing mail2 code BUT fix the object's so that they have a clean interface to the storage code. The system I've built on for the last n years has been one with a less than ideal architecture. And now I'm finally ripping that up and replacing it with the new. The in memory objects for Mail, Folders, Calendars, Contacts etc all derive from the "Thing" class (yes I know... original) and they include all sorts of data members that get written to disk. This meant that the "Thing" objects were the only code that knew how to read and write themselves to the mail2 file. The mail2 code didn't know what it was storing. So for me that meant I couldn't read/write the objects to a different back end easily. Now I've separated out the serialization code from the "Thing" objects into a pure virtual API that glues the Things to their mail2 backend. But of course can be replaced with any other backend that implements the glue API. So that could be a Sqlite database, an MBOX store... or a MAILDIR folder. Or a caching IMAP implementation. Anyway, currently the app boots, loads a folder and shows email. It's not sending or receiving yet, but I think I'm close to getting that working. Receiving should be easy, sending... uh less so. Because in the object hierarchy shuffle the Mail object lost it's "MailMessage" parent which the sending code uses to encode the outgoing mail. That means more mucking around for me when preparing a message for SMTP. But no doubt I'll have that licked in short order. One of the releases in the next few weeks will be off this new architecture. And it'll suck. Seriously it'll be a big backward step compared to the latest v1.90 test2 release. Because lots and lots of code has changed... challenging, application wide refactoring. And I won't get that right first go... it'll need lots of field testing, and it won't even do any new tricks to start with either. It'll be the same old UI and feature set... just with more bugs, missing features and crashes. You like? Well it had to be done, and I'm giving the beta testers fair warning that all hell will break loose in the following releases. So there. More updates to follow. |
| (10) Comments | Add Comment | |
| Update | |
|---|---|
|
Date: 2/2/2008 | Lots of things going on. Firstly I made a triple platform release of Scribe this week. I think thats the 2nd one I've ever done. *pats self on back* Hopefully it's a reasonable release quality wise too. Let me know if you have issue (of course).
Secondly I came off my scooter 2 days ago and twisted my ankle and knocked a chip off a bone in my foot. They put on a cast of sorts to stop me moving it around and I'll see the specialist next week to get the full rundown. Not so much fun that. Worst case is 6 weeks in a cast, but I'm prayin that doesn't happen and it's more like 2 weeks for the soft tissues to heal. I've only been riding a year and I grabbed too much front brake in an emergency braking situation, locked the front and it buckled under the bike, over she went. The bike is ok, scratched up a bit but ridable. Thirdly I've been "production" testing my revamped SMTP client/server which will probably make it's way into the Scribe email client down the track as an end to end SMTP solution (i.e. not reliant on the ISP's SMTP server). It has most of the kinks worked out of it. |
| (2) Comments | Add Comment | |
| Compiling With Windows Media Format SDK | |
|---|---|
|
Date: 29/1/2008 | This article is purely to document a fix for Google to index.
If you are trying to compile code that uses the Windows Media Format SDK and you are getting these sorts of errors: 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C2146: syntax error : missing ';' before identifier 'SHCOLUMNID' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C2143: syntax error : missing ';' before '*' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C2378: 'SHCOLUMNID' : redefinition; symbol cannot be overloaded with a typedef 2> d:\program files\wmsdk\wmfsdk11\include\shtypes.h(448) : see declaration of 'SHCOLUMNID' 2>d:\program files\wmsdk\wmfsdk11\include\shtypes.h(450) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>d:\program files\wmsdk\wmfsdk11\include\propsys.h(438) : error C2061: syntax error : identifier 'REFPROPVARIANT' 2>d:\program files\wmsdk\wmfsdk11\include\propsys.h(564) : error C2061: syntax error : identifier 'REFPROPVARIANT' Then you'll find that re-ordering the include paths in your Visual C++ settings will help. Your path to the WMF SDK (???\WMSDK\WMFSDK11\include) needs to be before the ???\PlatformSDK\include line. However you still get warnings about macros redefinitions. |
| (0) Comments | Add Comment | |
| Mac's PostEventToQueue | |
|---|---|
|
Date: 8/1/2008 | I officially hate PostEventToQueue. It's still flaking out on me and dropping some messages between the worker thread and the GUI thread on the Mac build of Scribe. So I'm going to have to rewrite the message passing mechanism to use something else before I make a release. I thought the locking issue was involved but now that is fixed and this is still happening.
Bugger..... BUGGGER. |
| (0) Comments | Add Comment | |
| Death By Paper Cuts | |
|---|---|
|
Date: 8/1/2008 | Just a small slice of the Scribe todo list:
In no particular order. Thats why there is never any work on "v2" or the big changes like fixing IMAP. Because there is always a flood of little things to fix. Or I get tired and go to bed early ;) |
| (2) Comments | Add Comment | |
| Scribe ala Mac | |
|---|---|
|
Date: 7/1/2008 | If you have been poking around in the release notes you'd have noticed that I've done a heap of work on the Mac port of Scribe. So far the one outstanding thing I must fix before I ship it is a thread lock that gets stuck in the locked state and kills the app after some hours of running.
Other than that it's fairly useful as a daily email client as it stands right now. Most of the really annoying quirks (for me) are now fixed. So it's running now and I'm waiting for the locking bug to show up. I've added file/line parameters to the semaphores lock method which tells me where the lock/unlock pair failed. And so far its failed once in a peice of code that can't possibly not unlock the semaphore... there is no return statement between the lock and unlock (which is the usual cause for lock/unlock pairing pain). Which leads me to think that the semaphore code itself can fail. Looking at the unlock code is uses pthread_mutex_trylock to lock the semaphore object first before touching it's internal parameters. And in the lock method it retries pthread_mutex_trylock if it fails... but in the unlock it doesn't... just a one off attempt. So my current theory is that occasionally pthread_mutex_trylock fails temporarily and you can re-attempt it. Thus if unlock fails because pthread_mutex_trylock fails... you'd see this crazy sort of deadlocking stuff where something random locks the object and just hangs on to it's lock forever. Interestingly the original problem with the messages being dropped between the worker and GUI thread seems to not be happening any more. Possibly because the real issue is in the semaphore code. Fingers crossed I'll have it sorted in the next few days and I'll be cleaning up for release this week. Update: So far it's been running for 12 hours or so without lock up. Things are looking very positive right now. :) |
| (1) Comment | Add Comment | |