Archive for the ‘computer programming’ Category.

Google Gears – Grinding To A Halt

Those of you web developers who have been using Google’s Gears API are in for some bad news, you’re going to have to shift your paradigm to something else.  Google is dropping Gears in favor of HTML5 API.

We will continue to support Gears until such a migration is more feasible, but this support will be necessarily constrained in scope. We will not be investing resources in active development of new features,says Ian Fette on Google’s Gears blog.

I guess that even the mighty Google can’t really afford to reinvent the wheel in multiple simultaneous ways.  Not really a surprise, that.  Still, I do rather feel bad for anyone who has heavily based their code on Gears.  Looks like it’s time to research your best feasible transition.

Y2K? Y Not Y2.01K? OK!

It was the sh_tstorm that never really was: The dreaded Y2K bug.  Just because a computer may not be capable of telling the year 2000 from 1900 because some bright spark decided to only use two digits to record the date instead of the proper four, people assumed the world would suddenly end.  Power plants would shut down.  Chaos would rule the streets.  And if you didn’t stock up on portable generators and 15 years of toilet paper you were going to die a horrible death.

Of course that didn’t happen.

Mostly because people realized, der, it was actually a fairly easy thing to fix.  So each and every software company (that were still in operation anyway) fixed their products, and that was that.  No one wanted egg on their faces, so everyone got their butts in gear to solve the problems.

But also there was this great backup called the flexibility of humanity.  If something doesn’t work, you simple do something else until it does again.  Or you just keep doing something else.  And either way, life goes on.

Which was great.  Y2K turned out to be the Fake-ocalypse.  Apart from a lot of embarrassed stockpilers with thousands of tins of beans, life went on smoothly.

Of course, what society didn’t see coming was 2010.

What happened on our fabulous New Year?  Well for starters, about 30 million German bank cards stopped working because the “high-tech” computer chip inside of the cards couldn’t fathom 2010 being a valid year.  A fix to transaction machines and ATMs is, of course, being quickly worked on and deployed.  In the mean time however there are some folks who simply can’t live off of their card anymore.  Oops.

Also in the wonderful world of banking, some Australians are having similar woes because of a bug causing all 2010 dates to actually be seen as 2016, often rendering a purchase past the expiration date of a credit card, for example.

Likewise, this same 2010-to-2016 bug is hitting a lot of Windows smartphones, causing these Windows Mobile users to have some rather weird dates on their texts and such.

And then there’s the rather humiliating bug in Symantec’s Endpoint Protection Manager, which, horribly, was programmed to reject any definition updates dated later than December 31, 2009 11:59pm as “out of date”.  Yikes!  Of course, again, a fix is being worked on.

Apache SpamAssassin was also in the list of 2010 Woes and Dohs!  In this spam filter is a rule which states that any year past 2009 was grossly in the future (whooooo, we’re in the future) and nailed it as spam.  It being the year 2010 of course caused all sorts of problems.  Strangely enough, the bug was actually identified and reported in 2008 and fixed in the repositories.  However for reasons that remain untold, those fixes weren’t backported to 3.2 users.  Until now.

No doubt all sorts of other interesting bad programming bugs relating to the year 2010 will crop up.  And will be fixed when needed.  Because frankly, that’s life.  Sometimes things break.  Sometimes for darn stupid reasons.  But then they get fixed or replaced.  It happens in computer software.  It happens in everything else ever manufactured too.

It’s not often though that you can blame the problem on New Year.

Happy New Year 2010!

“Fail to create pixmap with Tk_GetPixmap in ImgPhotoInstanceSetSize” – A Matplotlib WinXP Nightmare

Those of you Python programmers out there on Windows boxes who use the wonderful library matplotlib / pylab to render your charts and graphs have probably run into this before:

Fail to create pixmap with Tk_GetPixmap in ImgPhotoInstanceSetSize

It’s not immediately clear just why matplotlib generates this error.  I’m guessing by the namespace that it uses Tk under the hood.  Okay.  And apparently Tk has issues on Windows XP and earlier (not sure about later versions of Windows) where it eventually runs afoul of either a memory leak or a bitmap handle reference limitation … or something. Information is kind of sketchy.

And what’s worse, the results of this bug are disastrous.  It doesn’t stacktrace.  It simply crashes Python with the message to stderr:

This application has requested the Runtime to terminate it in an unusual way.

Please contact the application’s support team for more information.

Loverly.

But fear not!  There’s actually a simple solution.  Don’t import matplotlib globally.  Import it locally instead.  This causes whatever limitation gets exceeded to be reset because the module gets unloaded once it goes out of reference.  And if your code somehow generates so many charts in one function that even that isn’t enough to fix your matplotlib woes, then take it one step further and reload the library using the reload statement.

Yes, it really is that simple.

Though it’d be awfully nice if matplotlib (or Tk) were to just fix this problem in the first place.  As of the time of writing this bug is still in matplotlib up to version 0.99.1.

Red Green Blue To Red Yellow Blue – Part 2

Okay, so I kind of forgot to finish up my work on converting a Red Green Blue color system to a Red Yellow Blue color system.  For those of you who don’t remember (and who would) here is the basic recap:

Since the dawn of time, children have been taught their primary colors: Red, Yellow, and Blue.  And they have been taught their secondary colors: Red and Yellow make Orange, Yellow and Blue make Green, Blue and Red make Violet (otherwise known as Purple).  It’s a simple system.  We all know it.  Artists have been using it forever.

The Red Yellow Blue Color Wheel

The Red Yellow Blue Color Wheel

And computers have these lovely computer programs that have all sorts of neat artistic tools.  There’s Adobe Photoshop, GIMP, Paint Shop Pro, even MS Paint.  The list goes on virtually forever.  But they all have one basic flaw:  They don’t use the same color system as artists do.

What?

I know!

Computers base their color system on the invention of the monitor, which itself is based on the color TV.  And these devices base their colors on the light spectrum, which has the primary colors of Red, Green, and Blue.  Making for secondary colors where Red and Green makes Yellow, Green and Blue makes Cyan, and Blue and Red makes Magenta.

The Red Green Blue Color Wheel

The Red Green Blue Color Wheel

Somehow this RGB (or sometimes known as CMY ) color system has dominated computers, so much so that software doesn’t even try to give users an option of a Red Yellow Blue color system.

Until now!

Yes, that’s right.  I, Arah J. Leonard, have written a bit of Python code (though the formulas should translate easily into any language) that converts RGB to RYB and back again.  And let me tell you, it makes a huge difference in calculating complementary colors!  Using this bit of code you can make, for example, button text that always stands out correctly against the color of a button.

And I’m making the code free to use, to all, and free to distribute.  It’s licenced under the LGPL.  Use it to your heart’s content folks!  Download your free copy of rgb2ryb.py to convert between Red Green Blue (RGB) and Red Yellow Blue (RYB).

Enjoy!


# Author: Arah J. Leonard
# Copyright 01AUG09
# Distributed under the LGPL - http://www.gnu.org/copyleft/lesser.html
# Enjoy!

# Convert a red-green-blue system to a red-yellow-blue system.
def rgb2ryb(r, g, b):
    t = type(r)

    # Remove the whiteness from the color.
    w = float(min(r, g, b))
    r = float(r) – w
    g = float(g) – w
    b = float(b) – w

    mg = max(r, g, b)

    # Get the yellow out of the red+green.
    y = min(r, g)
    r -= y
    g -= y

    # If this unfortunate conversion combines blue and green, then cut each in half to preserve the value’s maximum range.
    if b and g:
        b /= 2.0
        g /= 2.0

    # Redistribute the remaining green.
    y += g
    b += g

    # Normalize to values.
    my = max(r, y, b)
    if my:
        n = mg / my
        r *= n
        y *= n
        b *= n

    # Add the white back in.
    r += w
    y += w
    b += w

    # And return back the ryb typed accordingly.
    return t(r), t(y), t(b)

# Convert a red-yellow-blue system to a red-green-blue system.
def ryb2rgb(r, y, b):
    t = type(r)

    # Remove the whiteness from the color.
    w = float(min(r, y, b))
    r = float(r) – w
    y = float(y) – w
    b = float(b) – w

    my = max(r, y, b)

    # Get the green out of the yellow and blue
    g = min(y, b)
    y -= g
    b -= g

    if b and g:
        b *= 2.0
        g *= 2.0

    # Redistribute the remaining yellow.
    r += y
    g += y

    # Normalize to values.
    mg = max(r, g, b)
    if mg:
        n = my / mg
        r *= n
        g *= n
        b *= n

    # Add the white back in.
    r += w
    g += w
    b += w

    # And return back the ryb typed accordingly.
    return t(r), t(g), t(b)

# Return the complementary color values for a given color. You must also give it the upper limit of the color values, typically 255 for GUIs, 1.0 for OpenGL.
def complimentary(r, g, b, limit=255):
    return limit – r, limit – g, limit – b

# Debugging test code. Not intended to be used as an application.
if __name__==”__main__”:
    red = (255, 0, 0)
    green = (0, 255, 0)
    blue = (0, 0, 255)
    cyan = (0, 255, 255)
    magenta = (255, 0, 255)
    yellow = (255, 255, 0)
    black = (0, 0, 0)
    white = (255, 255, 255)
    orange = (255, 128, 0)
    darkgreen = (0, 128, 0)
    tests = [red, green, blue, cyan, magenta, yellow, black, white, orange, darkgreen, (255, 128, 64), (255, 64, 128), (64, 255, 128), (128, 255, 64), (64, 128, 255), (128, 64, 255)]
    for test in tests:
        ryb = rgb2ryb(test[0], test[1], test[2])
        rgb = ryb2rgb(ryb[0], ryb[1], ryb[2])
        cryb = complimentary(ryb[0], ryb[1], ryb[2])
        crgb = ryb2rgb(cryb[0], cryb[1], cryb[2])
        print test, “rgb2ryb”, ryb, “ryb2rgb”, rgb
        print “complimentary rgb”, complimentary(rgb[0], rgb[1], rgb[2])
        print “complimentary ryb”, cryb, “to rgb”, crgb
        print

Google’s Gmail No Longer Beta – It’s About Time!

News breaks that Google is no longer calling Gmail a beta version.  And everyone is left … baffled.

I mean first of all, it hasn’t really been a beta version for years.  It hasn’t even been some super-secret closed private (in theory anyway) trial service in years.  It’s been nicely public and released for a very long time.  The only thing about Gmail that was still beta was the damned logo.

But on top of that, just what made it not beta anymore?  Well, the fact that businesses typically don’t trust beta software is what made it not beta anymore.  It wasn’t a certain amount of testing.  It wasn’t a certain confidence in the software.  In spite of the fact that that is exactly what beta means.  In-house testing is Alpha testing.  When that passes muster it goes to limited customer-based testing, called Beta testing.  And then when that is cleared as good-to-go, it’s released.

Only somewhere along the line, Google, software mavens they are, seemed to have forgotten the little details like that.

Oh, sure, alpha, beta, they may be all Greek to you.

But to the software industry, these things are industry standards for testing and quality assurance.  Standards that, as Google becomes more like Microsoft, seem to go out the window for Google … just as they did for Microsoft.  Not because doing things differently is the “right” way to do things, but simply because they’re just too big and important now to do things the same way everyone else does them.  That wouldn’t be “cool”.

And the really sad testament to the sheep we people are, is that folks are already freaking out over the loss of the beta logo.  They’ve  become so used to seeing that their software is constantly in beta (which is a bad thing by the way, because it means it never has finished testing) that now that their software is officially considered tested and good to go, they’re forlorn.

Bah!

Whatever.

Does any of it really matter?

So Google keeps their software labeled as beta for far too long after, just because.  And then on a whim one day decides to take away the beta and call it released, not because it has been tested, but because they’re afraid of losing money from Big Business.  It was so ridiculous that it was a joke on Google to begin with.  So who cares?

The same as how Microsoft supposedly tests their operating systems and then releases them, but IT departments and computer experts world-wide know those first releases are actually the equivalents of beta-tests, and won’t move over to the newer version of an OS until the first service pack hits, because that’s when the problems found during testing are finally fixed in Microsoft’s world.

It’s all a joke.  They do business stupidly, we adapt.  Simple.

So none of it really affects anyone.

But for some reason, people pretend to care anyway.

Whatever makes them happy.

But we know better.