| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 28 29 30 31 32 33 34 35 36 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75
| Leopard Support | |
|---|---|
|
Date: 19/3/2008 | X-Mailer: InScribe v1.90 (Test3, MacOSX v10.5.2, Debug, en)Yes I'm working on Leopard support. So far the major issue seems to be a slow down somewhere in the startup code. So I've built the codebase on Leopard and fixed the project files. And I'm not seeing any slowness on a Leopard based build. So maybe it's because the current release is built on Tiger that it's having issues. Leopard isn't really stable enough for everyday usage IMHO so I'd like to be able to work out what is borking up Tiger based builds of Scribe on Leopard. Most of the other issues appear to be similar to Tiger. Still there seems to be so much work to do and so little time. One issue I'm looking at is that I can't load libPng in Leopard (works in Tiger). When I dlopen(libPng.dylib) I get "image not found" but a spotlight search turns it up in the frameworks tree. What gives? I have fixed some other non-Leopard issues while I'm here. Unfortunately not "the" issue, which is the hang in the receive mail code due to memory corruption. It's hard to reproduce and harder to debug. |
| (1) Comment | Add Comment | |
| Scribe v2 Progress | |
|---|---|
|
Date: 17/3/2008 | I've ported the existing v2 to both Linux and Mac, although I have no immediate plans to make releases on those platforms I like having a working svn. The linux build is particularly useful for checking under valgrind and the mac port is useful for when I'm working on a laptop away from my PC.
As for v2 itself I've been implementing the foundations for a basic Maildir backend which I can reuse for IMAP. I know its not the "proper" way you should do IMAP but I can move towards that once I've got something working. I'm putting in place methods of converting mail between different backends and making that fairly seemless. Today I've implemented an attachment class for the IMAP code and I'm using the GMime class that I wrote a zillion years ago. Because the new internal API's are now well designed I can change implementation details like exactly how the IMAP cache works without effecting the main app in any significant way. This gives me a lot of freedom that I didn't have before. Some of the work I've been doing this week is going towards adding multiple simultaneous folder support. Which is a stepping stone to good import and export functionality too. I could do something crazy like write a MAPI backend... thing about that. Scribe could be corrupted by the dark side! If I wrote a backend for all the mail import/export formats I can read/write, and then rewrite the import/export code to replicate between any 2 backend mail stores... hmmmmm. The possibilities are endless. So far the whole architecture is holding up well in day to day use. I can't wait to write a faster "native" backend to replace mail2 files. |
| (1) Comment | Add Comment | |
| v2 Where For Art Thou? | |
|---|---|
|
Date: 5/3/2008 | So I guess people are wondering where v2 has gone? Well works continues, abet at a slower pace due to life's interruptions. Currently I'm ripping out the old cruddy IMAP full implementation and making a new one based on the new API's that I've made. This is currently looking a lot like a MAILDIR implementation where all folders and email are read from disk. Basically my idea is to cache email and folders on the IMAP server on disk in a sub-folder under the Scribe location such that you always have an offline database you can access. The IMAP network thread then attempts to keep the folders in sync with whats on the server. I haven't got to that yet, because I'm still building the MAILDIR functionality up. However I get a free MAILDIR implementation at the end as well.
Anyway I might make the implementation of the caching/offline part different later as I build more optimal backends but MAILDIR is way easy and fast to implement (at the expense of runtime performance) so it'll get me a working IMAP implementation faster. And I think everyone would prefer working IMAP sooner even if it's a little slower than it could be. I'm not planning to complicate the MAILDIR stuff with indexing but that would probably fix the speed issues at the cost of extra complexity and implementation time. This will hopefully make the Scribe v2 upgrade worth it. |
| (2) Comments | Add Comment | |
| The evils of cidaemon.exe | |
|---|---|
|
Date: 22/2/2008 | I have been regularly having issues writing to files. The symptoms would basically be, try and open a file, OpenFileW would hang for about 2 minutes and then return a valid handle to the file. This causes havoc in my applications as you can imagine. So I fired up the wonderful SysInternals process explorer and looked for what had that file open and some dinky little process called 'cidaemon.exe' has it open.
Dear Google, what is 'cidaemon.exe'? Dear Matt, 'cidaemon.exe' is the Microsoft indexing service. Riiiiight. Ok well it's indexing my drive for "searching" which btw sucks on windows. So I'm going to turn it off. You can do that on XP by clicking Start->Search->Files/Folders and then in the Search Options clicking the "Indexing Service" field and it'll give you an option to disable it. I consider a process regularly holding a non-sharable lock on MY file for 2 minutes severely broken. So I'm going to see what life is like with the indexing service. I suspect that life will be sweeter, my machine faster and my files will open easily. But this IS windows were talking about... *sigh* |
| (1) Comment | Add Comment | |
| Scribe v2 Beta? | |
|---|---|
|
Date: 17/2/2008 | Well due to some timely feedback on the v2.00 alphas we might be approaching beta (as in all the functionality working again) sometime in the next week. I've crossed off all the bugs reported against alpha3 and made a release for alpha4.
Do what do you think? Any good? |
| (8) Comments | Add Comment | |
| MiserySoft's Finest | |
|---|---|
|
Date: 15/2/2008 | Re: Visual C++ .NET Can't Find Squat.
Well guess what, the bug is still there in Visual C++ 2005. 2 Major releases and 1 service pack later. And the fix still works as well. Unbelievable. So it appears I have to use Visual C++ 2008 now. F. I guess that means I'm looking for a new job. F. 
|
| (0) Comments | Add Comment | |