| 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
| 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 | |
| Linux/Mac Scribe Ports | |
|---|---|
|
Date: 24/12/2007 | After pushing out a reasonable Win32 build of Scribe I'm working on the Linux and Mac ports. The linux port is building and running on Ubuntu but I'm getting a bunch of window resizing issues that used to happen every so often but now it happens all the time. So I'm not going to get a build out this year but I'll look at it again in Jan. As I'm not doing PC dev work over the Christmas / New Year holidays.
I am however going to look at the core issues on the Mac build. I'm talking about the lost messages between the worker and GUI threads. This is obviously a fairly core issue that the software relies on. Hence the lack of motivation to work on the Mac port... anyway I've got some time now so I'll have another crack at it. |
| (0) Comments | Add Comment | |
| Lgi/Scribe/Linux News | |
|---|---|
|
Date: 21/12/2007 | After months of tinkering with Lgi on linux, trying to get it to play nicely with Gnome I've worked out what was going on and made a work around for the issue.
If you initialize Gnome in UI mode, i.e. gnome_program_init("Lgi", "2.0.0", LIBGNOMEUI_MODULE, Args, Arg, NULL, NULL);
Then it registers atexit handlers so the library image must remain in memory till the application exits, otherwise it'll try and call the atexit hooks back into Gnome (which has been unloaded) and it crashes. So I added a return parameter to the WmExit method that the parent Lgi app calls before unloading the window manager helper shared object and the WM helper can select to stay in memory.
There is still some question on how to read the right settings out using the Gnome API, but that is a minor issue compared to the ones I've already solved. I know I could've shipped a build of Scribe without any WM support, but I've been a) too busy or b) too sick to do a lot of Linux work lately. I had a virus a few weeks ago where I spent the entire week in bed. Which is unusual for me, as I normally recover quickly from such minor things. Maybe I'm just slowing down a bit in my 30's :) Speaking of intractable coding issues, I recently fixed (some) of the weird focus issues in Scribe. The recently releases were waiting on that fix. Basically I'm a dill and called SetFocus in the WM_CREATE handler if Focus(true) had been called before the view was attached. The problem with that is, if the view had the focus, you detach it, and then re-attach it later it takes the focus again. Which in my case was NOT what I wanted. But after some months of trying different things to work out the problem I hit on the issue and fixed it. And of course... what of the Mac port? Ah... the Mac port. Yes yes. Well that has it's own thorny issue that has me mostly beat. I'm losing messages between the worker thread and the GUI thread and I don't know why. Unbelievably painful. *sigh* |
| (0) Comments | Add Comment | |
| Wikipedia Notability | |
|---|---|
|
Date: 2/11/2007 | So now any trace of i.Scribe and InScribe has disappeared from wikipedia entirely, apparently because it's not "notable" enough.
The comparison page has had all the not notable clients purged from it. Wikipedia used to be awesome for looking stuff up. But I'm beginning to wonder it's imploding in on itself these days under the notability Nazis. I'm certainly no longer keen on putting any more of my time into editing wikipedia articles. |
| (5) Comments | Add Comment | |