MemeCode - Blog

Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45 46 47 48 49 50 51 52 53 54 ... 55 ... 60

The Franken-Bear-Light
Date: 17/7/2006	As you might be aware I have 2 kids, 3 1/2 and 2 years old. And we have 2 "bear lights", which are night lights in the shape of a teddy bear. They have a timer mode to switch them off after a while and a 2 monophonic tunes they can play. And of course our little ones love them, "bear light daddy!" is the cry if I forget to turn them on. Some months ago first one and then the other started playing up, in that they'd turn themselves off for a while in the middle of the night, at which point if the child noticed they would cry out and wake us up. (We don't use the auto off mode). This will not do at all. So after last night's wake up call I decided it's time. Time to hack. So I opened one of them up and it's got all this circuitry inside. I tried to step my way through it with a multi-meter and well I'm not an electrical engineer so all those IC's and transistors were over my head. I gave up on understanding the original circuit and ripped all the active components out, and using a basic light circuit someone thoughtlessly left lying around on the intarweb I cobbled together a working light using the main variable resistor / switch as a dimmer and a resister of roughly the right value I found on the PCB. I drilled some holes in the plastic casing, mounted the pot back on the body of the unit with tiny bolts and screwed it all back together. I'm quite proud of my first ever circuit design... be it simple as it is. Beware the franken-bear-light!
(2) Comments \| Add Comment

Scribe On Linux Issue
Date: 6/7/2006	I've been working on the Linux build, getting it to build and run on Suse 10, which is my latest distro. Suse 10 comes with GCC 4 so I had to fix all the build errors that had appeared since I last compiled on GCC 3.x, which took a while. Then I had to fix the keyboard input. The #1 complaint about the Linux version is that is doesn't support international keyboard input properly, so I finally found a way of adding support for that without going insane. The documentation is beyond hopeless with regards to XIM (X Input Manager) and this has prevented me from adding support for XIM for about 3 years now. So this time round I just had a look at an existing implementation and copied it. The implementation that was easiest to understand was SDL, I had tried to extract a usage example from KDE back in the day but that was fairly futile. SDL is much simpler and I got what I needed fairly easily. Now Lgi supports XIM, or more to the point uses it all the time. I expect this will mean that older distros aren't supported but I care little for backwards compatibility in the Linux world. Linux is so backward that the "current" setup is just barely good enough. Thus you have to have FontConfig, XRENDER, XIM to run any current Lgi apps. I'm not going to support X fonts or the old X keyboard input that belong in the '80s. We are in 2006 now upgrade or die! ;) Anyway, it came to my attention that Scribe can hit the 1024 open files limit quite easily in Linux. So you had 1300 mail in your POP account and you try and download it all, Scribe opens a file handle for each one, all at the same time. Now I could fix this now, but it would delay the test4 release, and for most users you rarely have to download that many mail at once. Is this a showstopper? Or should I just release now and fix it later? I guess users could just change the limit if it effects them. The ulimit command can change that limit if you have super user rights (I think).
(1) Comment \| Add Comment

i.Mage Scripting
Date: 7/6/2006	I wrote a simple scripting language for i.Mage last night. Lets you create graphics based on little bits of script that can specify things in exact co-ordinates. This is generally useful to me for generating bits of graphics for web pages and applications that conform to some very specific size and shape requirements. Things like little circular filets for rounding off corners in webpages and the like. But I'm sure others will come up with a whole plethora of uses for it.
(9) Comments \| Add Comment

Filter UI
Date: 5/6/2006	Last night I ripped out the UI for conditions in Filters and replaced it with the slick new UI that I wrote last year. I've updated it and intergrated it into the application and it looks and works great. The UI is serialized into XML which is stored as a new property field in the existing filter object. Old filters are upgraded transparently to the new format when you save them. So there is some lack of backward compatibility, i.e. if you save a filter in the new version of Scribe and then try and view it in an old version all the conditions will disappear. Oh well, at least it won't crash or misbehave beyond that. All I need to do now is hook up the new condition data to the code that evaluates the conditions against an email. I'm thinking about actually letting the user export/import filters to XML files. Some benifits of being able to do that would be allowing groups of users distribute their custom filters, backup/restore and maybe evan scripting/automation of filters down the track. The filter UI will also effect the find/search window, which I haven't even started on yet. But chances are I'll get to it this week.
(1) Comment \| Add Comment

Scribe Test4 Directions
Date: 2/6/2006	Apart from fixing the new Scribe crashes that are appearing in Test2 and Test3 I just wanted to say a few words on where I'm heading in Test4 in terms of upgraded functions and features. Fix Bug #42 by implementing a new search function using the Filter UI that I wrote last year. Improve the mail2 export with all the feedback I'm getting. So far the dialog wording is ambiguous and some defaults need fixing. Also some things in the backend need to be reworked a little and support for other types of objects needs to be added. For many many versions Scribe has supported the one folder format, and older versions read/write the mail2 file without issues. But I want to make some non-backward compatible changes to the file format. I want to move the body of messages into child nodes of messages instead of being a property of the message node itself. And then maybe force all the messages to be in a single data block so that I can read them in without seeking around inside the mail2 file. This would be the ultimate fix for folder loading speed. But it would not be backward compatible, so I'd have to call it "mail3". At the same time I'm also thinking of supporting maildir + indexes as a mail store. Which would likely involve API changes, which combined with the mail3 changes would make sense to do at the same time. I would also like to rip out the crusty MIME parser that Scribe's been using for like ever now and replace it with the shiny new one that doesn't suck. The issue with that is a lot of the "smarts" with charsets and decoding of content is embedded in the current MIME parser and needs to be extracted out so that it can be added to the new parser. Which is a) painful and b) likely to be buggy to start with. Here is where the rubber hits the road. If the software is going to get "better" then it needs to get worse in the short term as I rip out badly written code and insert better foundations. Change always brings unstability in the short term. It's a constant in the software industry. Especially with a dev team of one. The options are lots of fast turn around test builds that are not stable, or no releases for a while (months?) and then a relitively stable release. What would you, as a user prefer?
(3) Comments \| Add Comment

Scribe Release
Date: 29/5/2006	It's time for a new release of Scribe as the change list has become long and a) it needs testing and b) people need the fixes contained therein. If you have some outstanding issue that isn't addressed in the change list that you want to remind me of, you have about 24 hours to tell me about it. I think I've covered everything but feel free to correct me if I've overlooked something. Also if your a translator, now would be a good time to send me any edits to your translation. I'm going to test things for a day, let the last few changes get some exercise and make a release tomorrow night if no show stoppers appear.
(1) Comment \| Add Comment