Blog
Page: 0 ... 5 ... 10 ... 15 ... 20
The new breed
Date: 11/4/2004
As if bombarding my Inbox with hundreds of small viruses, spams and scams each day wasn't enough the malware authors in their infinite wisdom are now trying to DDOS me with 1.12MB viruses.

Which must take their toll on the senders bandwidth. You can't bang them out like the 29KB rodents that I usually get. Gee, just when you thought you'd seen it all.

Currently I've written a filter to delete anything with a zip attachment as spam. So if you are trying to send me something for the first time I suggest not zipping it so that I don't filter it out.
(0) Comments | Add Comment

Scribe Dropped Mail Bug
Date: 7/4/2004
I think I may have found the cause of Scribe dropping mail, ie. downloading it but not inserting it into the mail folders.

In test9 I tried to prevent Scribe from deleting the mail from the server if the download failed. Which should mean that at least the mail is doesn't disappear. However that doesn't solve the bug it just stops the data from being lost.

Now I've discovered what I believe to be the root cause in the POP receive code where if the initial recv on the connection contains the entire message (ie. small message + fast connection) then the code goes down a slightly different path and doesn't set the status code for that message correctly. Which I've just fixed in the developement build.

It remains to be seen whether this is the only cause of the problem or there are other things causing the same problem.

In a semi-related note I'm moving the socket implementation in Lgi to non-blocking (at least on Linux) to work around other API problems. When you close a socket in Linux that is blocking in another thread the blocking function doesn't return. Whereas under Windows it does, with an error code. Which is really handy, you can fire off a thread to handle the connection and if for any reason you want to cancel out of that thread from your main GUI thread you just close the socket and everything will just error out. However all that doesn't work on Linux as I've found out. That in itself required moving to a non-blocking architecture. However I've noticed on Windows that occasionally the socket stalls in an infinite loop inside a 'connect' or 'recv' and never times out. Which is bad behaviour anyway. So a proper non-blocking implementation can easily do timeouts as well. There might be a way to set a timeout for a Windows socket using some Win32 API call which I could investigate when I care enough to do something about it.

So in the next few days I'll do some more testing and release this bug fix for the world to play with. Then I've really only got the "100% CPU" bug to track down so that I can get back to general development.
(0) Comments | Add Comment

Is it the 21st century yet?
Date: 5/4/2004
After all my bitching about XP's scheduler one would have thought that I would have been happy over in Linux land. But no I am not. It can't schedule to save itself.

But you knew that... right?

Oh oh oh! But 2.6?

Hmmm I'm stuck with Redhat9 (at work) for the next 'n' months/years/decades upon when my (dear) sysadmin's see a viable upgrade path.

So meanwhile I do one thing at a time on my Linux box. Smuggly aware that I don't use a Microsoft OS on my machine. Yay computers!
(0) Comments | Add Comment

MemeCode Accounts
Date: 1/4/2004
You can now create an account on MemeCode.com to request notification emails when applications are updated. Once your logged in you can select the applications which you would like to track.
(0) Comments | Add Comment

Scribe
Date: 30/3/2004
For all of you that are waiting on fixes, features or replies to email, I am sorry but 2 large bugs (cockroaches?) are nibbling on the juicy stability of Scribe. And must be delt with post haste.

Firstly, there is the dreaded 100% CPU usage bug, which I think happens when a connect to send (or receive?) is attempted and something gets stuck in a loop. Still no closer to solving this one.

Secondly, there is the abominable lost mails bug, where Scribe just "loses" incomming mail somewhere between downloading it to a temporary file and inserting it into the mail folders for permanent storage. I think I can fix this given enough time and solitude. I've seen it on my machine and can probably reproduce it with enough patience. So I'm hopeful that this is going to be resolved soon.

But of course those things are still not something I can work on "right now" so I've booted Scribe up inside valgrind and I've been running it all day. So far I've found and fixed about 10 mostly minor bugs to do with memory handling. Some in the HTML control, some in the core Lgi view class and other places throughout the code. I'm going to continue to do this in an attempt to really get a handle on the obsurce bugs that only cause problems way down the track, long after the broken code actually executed, meaning that once the program crashes you really have no idea where it went wrong. So I'm hoping that this will mean Scribe is more bulletproof and crashes less. Always a good thing eh?

Thank you for all your messages of support and bug reports.
(0) Comments | Add Comment

Html Support in Scribe
Date: 23/3/2004
I've been reminded recently that the HTML control in Scribe is not perfect by a number of users. And I thought I'd just put my perspective on the record. For starters, the control is designed to handle the sorts of human generated HTML that contains a little bit of styling (bold, colours etc) and maybe a little formatting (bullets, lists). Even an image or 2 is fine. What it's not designed to do is render slick advertising that has built in forms, nested tables, online images and the like.

Email is primarily a text medium and I'd personally like it to stay that way IMHO.

Now I would like to add to those who still want it to render everything and anything that the other main reason for the control in Scribe being written in house is that I garentee that it has no execute capability. And whats the peace of mind worth to you? If I were to use the Mozilla control or the IE control (on Win32) so that rendering would be acurate, could I garentee that no virus will ever infect your computer? No I couldn't. So hence the in house control. And while it's not perfect it is 100% safe from viruses.

The other important point to add is that the in house HTML control doesn't load anything off the network, preventing anybody from havesting information about what mail you read. This is an important part of a secure email environment.

I am interested in fixed trivial bugs in the control, but it's a low priority task at the moment. Feel free to send my HTML that breaks the control and I'll file it away for sometime later.
(0) Comments | Add Comment