MemeCode - Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 22 23 24 25 26 27 28 29 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85

Rocket Science
Date: 28/10/2008	There has been two recent events in rocket science that have really advanced the state of the art for private enterprise getting into space. This is exciting on a number of levels, both from the little kid point of view, "wow rockets!" and the more mature, "finally someone other than the government doing it right" point. Generally governments are not good at long term development, and when politics get involved things go sideways (e.g. the shuttle debacle) for a long time. Anyway, here they are: Armadillo won the level 1 prize of the Lunar Lander Challenge this week. I've been watching Armadillo for a very long time and they finally won something, which is well deserved for all the blood, sweat and tears they put into their rockets. Well done Armadillo! Secondly, SpaceX put their Falcon1 into orbit, which is a great step forward towards cheap privately funded space access. SpaceX got it right on try number 4 after going so close on the previous 2 attempts. And it's really good to see them get to orbit. Obviously Scaled Composites won the X Prize a while back, but great things are still happening in the space industry.
(0) Comments \| Add Comment

Looking for Scribe v1.88 Users
Date: 24/10/2008	I've had some bug reports from people upgrading between v1.88 to v1.89 or v1.90 where the folder names disappear or other problems with accessing their mail and contacts. I want to look into this issue and sort it out, so I've been running v1.88 in parallel with v2 just to collect some mail and try the upgrade myself. So far so good, the upgrade is perfect, all email, folders and so on usable in later version (although I can't open the upgraded folders in v1.88 anymore). If you have some mail folders from v1.88 that you haven't opened in a more recent version that doesn't have anything too confidential that you wouldn't mind donating a copy of to improve the Scribe software I'd be interested. Especially if it doesn't upgrade well. To test if it upgrades well or not, MAKE A COPY of your Scribe folder, install a later version (i.e. the latest v1.90 build) into that copied folder and run the new version. If there are problems then you can help! Drop me an email and we'll sort out something in terms of file transfer. If you zip the OLD v1.88 folder you'll probably be able to upload it to a free file sharing site (google it) and post me a URL to download. That way I can sort out the bugs and stop others from experiencing them.
(1) Comment \| Add Comment

Gcc Pain
Date: 22/10/2008	It seems that gcc even in it's more recent versions (v4.2 in my case) has an obnoxious little bug in that 2 classes defined locally in separate C++ files can "intermingle" in the global namespace and cause chaos. e.g. // File1.cpp class ClassA { int a; public: ClassA() { a = 1; } ~ClassA() { } }; void MethodA() { ClassA instance1; } And... // File2.cpp class ClassA { char *b; public: ClassA() { b = strdup("Hello"); } ~ClassA() { free(b); } }; void MethodB() { ClassA instance2; } In Visual C++ this is fine, the 2 classes have scope limited to their local C++ file and using them causes no issues. However in gcc C++ destroying ClassA in one C++ file can result in the destructor from the "other" ClassA to be called, i.e. File1.cpp's trying to destroy the stack variable instance1 and ends up in File2.cpp's ClassA::~ClassA() implementation, which tries to free the string and crashes. Awesome. And this goes on with no compile or link time errors or warnings. You just find out the hard way at runtime. And if the classes are similar enough you might not even notice the problem until later. Very insidious indeed. Just beware. This week I found 2 pairs of classes with the same name, one of which causes a crash, and the other I only noticed because of valgrind complained I was writing off the end of a block of memory. In both cases there was one original copy of the code and I made of a copy of it to implement a different version or mode of operation, each with a local helper class, with the same name. One was the old scripting engine vs the new one, and the other case was the Mail2 backend (Scribe v2) vs the Imap backend. (Of course I could've missed something really basic with my makefile's or compile options, and I'm happy to take blame if it's me doing something dumb. But I think I'm doing fairly mundane and reasonable things in those areas so I doubt it's my fault in this case)
(0) Comments \| Add Comment

Gcc Pain

Date: 22/10/2008

It seems that gcc even in it's more recent versions (v4.2 in my case) has an obnoxious little bug in that 2 classes defined locally in separate C++ files can "intermingle" in the global namespace and cause chaos. e.g.

// File1.cpp
class ClassA
{
    int a;

public:
    ClassA()
    {
         a = 1;
    }

    ~ClassA()
    {
    }
};

void MethodA()
{
    ClassA instance1;
}

And...

// File2.cpp
class ClassA
{
    char *b;

public:
    ClassA()
    {
         b = strdup("Hello");
    }

    ~ClassA()
    {
         free(b);
    }
};

void MethodB()
{
    ClassA instance2;
}

In Visual C++ this is fine, the 2 classes have scope limited to their local C++ file and using them causes no issues.

However in gcc C++ destroying ClassA in one C++ file can result in the destructor from the "other" ClassA to be called, i.e. File1.cpp's trying to destroy the stack variable instance1 and ends up in File2.cpp's ClassA::~ClassA() implementation, which tries to free the string and crashes.

Awesome. And this goes on with no compile or link time errors or warnings. You just find out the hard way at runtime. And if the classes are similar enough you might not even notice the problem until later.

Very insidious indeed. Just beware.

This week I found 2 pairs of classes with the same name, one of which causes a crash, and the other I only noticed because of valgrind complained I was writing off the end of a block of memory. In both cases there was one original copy of the code and I made of a copy of it to implement a different version or mode of operation, each with a local helper class, with the same name. One was the old scripting engine vs the new one, and the other case was the Mail2 backend (Scribe v2) vs the Imap backend.

(Of course I could've missed something really basic with my makefile's or compile options, and I'm happy to take blame if it's me doing something dumb. But I think I'm doing fairly mundane and reasonable things in those areas so I doubt it's my fault in this case)

(0) Comments | Add Comment

Using XML in the real world.
Date: 13/10/2008	Some people have some very er... interesting ways to use XML. Myself, on the other hand think of it as a flexible data store for lightweight things like application options and as glue between 2 disparate systems. Said interesting people have tendencies to mirror all the XML elements in C++ with arcane, long winded, fragile and complicated class hierarchies where each element and attribute has it's own class. I however am not insane. I like tools that reduce the lines of code I have to write. And I almost always use generic DOM trees for all my work, keeps the lines of code to a minimum. My latest little innovation is a little UI glue library that makes my lightweight XML library (DOM tree style) talk to standard Lgi controls. I've actually been using this for quite a while in the simple case of converting an XML element's attributes to values in controls on a dialog and back again for serializing UI to disk. i.e. take a string value from the XML, stuff it in an editbox, let the user change it, then write it back into the XML element's attribute and then eventually to disk. Fairly mundane. However this week I'm starting to experiment, successfully, with serializing more complex controls, like list boxes and tree controls to XML elements. I found myself writing the same code over and over, i.e. taking lists of XML elements and using them to instantiate rows into a listbox and back again. So this week I wrote that functionality into the base XML<->UI layer. I plan to apply the same idea to tree controls as well at some point, probably when the need arises. The main change to make that feasible was adding a virtual method to the GList class so that the UI glue code can ask the list item to read or write itself to XML. I'm always a little careful about breaking the ABI, I'd rather not if it's all the same. But I think thats the great thing about Lgi, it's small enough not to worry about frozen versions that I can't change, if a change would improve the apps and make my life easy... do it.
(0) Comments \| Add Comment

Dogfood: Scribe v2
Date: 8/10/2008	I'm going to try using v2 as my day to day client from here on. I don't know why I didn't do that earlier but I'm always busy and well it was a little bit chicken and egg, it's not quite stable enough for everyday usage, because I don't use it everyday. So here I go. The IMAP code has come a long way but I don't get very far when I work on the IMAP codebase. It's all reasonably well designed but I keep bumping into new issues that disappear when I try and reproduce them. So I think I need a whole bunch of unit tests that I can run over and over. But I havn't done graphical unit tests before so I'm thinking I'll have to use the built in Scribe scripting... maybe. It's a lot of work just to make that happen. I keep finding little issues in the scripting language compiler or VM that means it's not ready for the unwashed masses. But for IMAP unit tests I'd need to be controlling the server as well as the client. Which adds to the complexity even more. But if I just bumble around doing testing on my own it's very time consuming anyway. There is no easy way to work on the stability and completeness without getting myself into a lot of work. Anyway I'll get the mail2 back end working smoothly enough for everyday usage in the meantime. Which is mostly smoothing over issues in the UI <-> back end changes, which applies to all the back end layers. So thats still very useful.
(0) Comments \| Add Comment

76 MPG
Date: 4/10/2008	Oh yeah, I hit 76 MPG on that last tank. Lots of nanny riding for sure, but that's a personal best. :D That's about 3.07 liters/100km in metric. But it's no Bajaj, which are known to hit 100km/lt (235 MPG) on the highway with a 125cc engine (same as my scooter). sigh In other news someone I know IRL is converting their car to electric. I bumped into that URL when I was moaning about 300kW V8's being legal here whereas 300w electric bicycles are not on the communal white board and Carmel wrote her URL beneath. I would too, but I can't afford to convert my car (say ~$20k?) at the moment. However I might be able to afford converting the scooter at some point. Muhaha.
(0) Comments \| Add Comment

Sitemap