Blog
Page: 0 ... 5 ... 10 ... 15 ... 20
i.Task on Debian
Date: 27/4/2004
I've heard that on Debian GNU/Linux 3.0r2 i.Task displays an error when trying to load saying it can't find the symbol 'dlopen'. So I've fixed the libraries that it links against and put a new build here.

Would someone with that OS be able to test it for me?

I'd like to know if my fix worked or not.
Update: Looks like it's fixed... thanks.
(0) Comments | Add Comment

For Sale: Fender Strat
Date: 22/4/2004
I'm selling my strat, if you interested take a look.
(0) Comments | Add Comment

i.Task Released
Date: 20/4/2004
I've released a new application for watching processes under Linux called i.Task.

Source and binaries are available.
(0) Comments | Add Comment

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