Mandlebrot Generator

I was watching James Sharman’s video about benchmarking his hombrew CPU recently. In that video he generates a mandlebrot set as a benchmark. I realized I’d never written an implementation of mandlebrot, so thought it might be fun. I probably should have started from scratch, but instead I just copied the apple basic version from the multi-mandlebrot repo, which was the base of the benchmark (the apple basic one seemed the easiest to understand).

This was my first semi-working attempt. The code actually takes long enough to run that I was getting script timeouts, so this version does each render loop on a timeout. It made rendering a lot slower, but does prevent the browser from locking up.

You’ll note that this doesn’t look quite right. I thought it might have been the low resolution, or the way I did the mapping to canvas. I messed around with various params, but it took an embarrassingly long time to realized I’d simply added two values instead of subtracting them.

This version is still quite slow, however. It’s because we are doing a timeout after every loop, which introduces a lot of delay. To speed things up we can instead try do do as much work as possible in one loop, then stop and call ourselves again with a timeout (this allows the browser to run the event loop, giving time to respond to events and avoid the slow script issues).

This is reasonably fast, even at higher resolutions & iterations. However I was curious if we used a web worker if I could make things even faster. Since web workers run on their own thread, we don’t have to worry about locking up the browser and can just run in a single loop. One downside to the worker is we have to communicate all of our results via postMessage which means a copy of each message has to be made. If we do this for each point it actually ends up being slower than our original implementation (presumably due to the overhead of copying). We could just send all the points when the loop is done, but then we can’t see any progress. After a little experimentation sending 50 points at at time seemed a reasonable compromise. (note I had to move off jsfiddle to allow use of the worker)

Perceptually the worker seems slower, however if the “ramp” setting is enabled (which re-draws the image with increasingly more iterations) it’s fairly clear the worker is faster. It’s possible we could get even faster using transferable objects or OffscreenCanvas (not to mention potentially optimizing the algorithm itself) but this “final” version is good enough for me.

HD44780 Character Generator

There’s a few generators for LCD characters out there for the classic HD44780 controller. However none of them give you a realistic preview, so it’s hard to get a sense of how good/bad they look. I created a simple one that will give you a little preview.

Lissajous curve

I saw a reddit post earlier about lissajous curves so I threw together a simple thing to draw one using canvas. You can play with the parameters to get different curves.

Differences between Firefox and Chrome Extensions

This entry was written during my time at IBM for a Firefox extension I had developed related to bookmarks

I’ve been using Google Chrome more often lately. I still prefer Firefox in a lot of ways, but you can’t beat the speed of Chrome.

One thing I miss in chrome is a lot of my extensions, including my project. I decided to take a look at how hard (if even possible) it would be to port my project to Chrome. It turns out, not as bad as I thought (though certainly not trivial).

Chrome’s approach to extensions is fundamentally different than Firefox. In Firefox an extension has pretty much full access to the entire browser – you can monitor and change every request the browser makes, you can modify the way tabs work, heck you can build the best javascript debugger on the planet. Chrome extensions are far more limited in what they can do. They run in their own sandbox, apart from the rest of the browser. You’re limited to a button with a dropdown (popup) display, an i con on the URL bar (also with a potential popup), adding items to context menus, and that’s about it. While you can get access to the websites the user accesses, and even modify them, you can’t fundamentally alter the browsers UI or behavior the way you can do with Firefox. This is not necessarily a bad thing – simplicity has it’s virtues – but it makes a big difference in the approach you take to the extensions.

Despite the differences in approach, the differences in writing an extension for one app or the other is not quite as big as I expected. Firefox extensions (for the most part) have their UI written in XUL(XML User Language), are scripted with JavaScript, and is themed with CSS. Chrome extensions have their UI written in HTML, are scripted with JavaScript, and themed with CSS. Well, hey, we have 2 out of 3, right? And while XUL and HTML are pretty different, they’re not that different, especially when talking into account the HTML5 features chrome supports.

Writing an extension for Chrome is very similar to writing a website. In fact, it’s pretty much identical. The only difference is that you have access to the chrome.* API, giving you some control over browser tabs, windows, history, etc. The downside is that you don’t have a rich featureset of widgets like you do with firefox ( trees, autocomplete, date controls, etc). On the other hand however, you can use javascript libraries like jquery or dojo, and not pollute or mess up the browser namespace. If you’re experienced with developing web applications, then it’s pretty easy to dive into creating an extension for chrome. Writing an extension for Firefox takes a bit more getting used to, learning a new UI language (similar to, but still different from HTML), new set of widgets, new set of quirks (although projects like jetpack are making it easier to write Firefox extensions).

Here’s a list of things I’ve found different going through and porting my project.

No for each loop

One of the nice things about writing a Firefox or Chrome extension is that both browsers are fairly standards compliant, and both support modern versions of javascript ( Version 1.8.1 as of Firefox 3.5. Chrome supports ECMA Script Edition 3, + roughly Javascript 1.7 ). This means stuff like properties, fun array methods and other little goodies. One of the things that Firefox supports is the for each loop, which is actually part of the E4X standard. This is a handy little item, it lets you loop through all of the items in an object, rather than the properties in an object. The catch? It’s not supported in chrome. I had to remove all of these loops in the my project’s code in order for chrome to even load my JavasScript.

No Preferences System

Firefox has a fairly nice preference system. Accessing it is a bit clunky, but the nice thing is that you can place an observer on any preference branch and get updates as soon as it changes.

In chrome there’s no such thing. There is localStorage, which you can use to store preferences, but if you want the observer functionality, you have to build it yourself.

I wrote a wrapper around localStorage to present a similar interface to Firefox for preferences, and added methods for registering observers. Because all of the pref changes that need observing are made by only by my project, I didn’t have to worry about observers getting updates if they changed through some other means.

No Password Storage

Firefox has nsILoginManager for storing passwords. By default these are stored unencrypted, but you can set a master password to encrypt them. In chrome, the only option for storing password is localStorage, which is unencrypted.

Different way to get the current window information

my project needs to know the URL of the current window so it can bookmark it. The way to access this information is different in each browser.

Firefox:

var info={url:getWebNavigation().currentURI.spec,
  title: getWebNavigation().document.title}
In chrome the method is asynchronous, and requires additional permissions in the chrome.manifest:
        chrome.tabs.getSelected(null, function _getWinInfo(tab){
                var info = {
                        url:tab.url,
                        title:tab.title
                };
            });

Different logging

My project has a bunch of built in logging. Much is for diagnostic purposes, but some is for important errors. For the most important errors Components.utils.reportError is used. This reports the error to the built in Firefox Error Console. It’s possible to report other errors to this console, but it’s more complicated.

The rest of logging in my project is provided by a home-grown logging service. Extensions in Firefox can write to disk, so that’s what the project’s logging service does. Chrome doesn’t allow extensions to write to disk. It does have a console object however, that can be used for logging at various levels (a la firebug).

To prevent having to change a bunch of code, I created a bridge to reportError:

//Fake out the report error method so we can still use it in code

    Components = {
            utils:console
    }
    Components.utils.reportError=console.error;

Different system for localization

Chrome’s localization system sucks.  The FF version isn’t great either, but I really hate the chrome one.  In FF you have two different ways to localize strings – in XUL, you can use DTDs.  This is a very strange use of DTD, but in practice it’s pretty straightforward.  In your XUL, you reference some string with an entity reference like &confirmButtonLabel;.  In your DTD you will have an entry like so:

<!ENTITY confirmButtonLabel “Do It!”>

The other method is through javascript, using stringbundles.  You create a .properties file with strings (similar to java), get reference to the bundle, and then call

somebundle.getString("somekey")
You can also call getFormattedString to fill in placeholders in a string.

In chrome, there is only one localization system.  You create a weird JSON formatted messages.json for each language, and pull strings from that file.  You get a string by calling

chrome.i18n.getMessage("somekey")
The reason I say this sucks is that there’s no way to automatically substitute strings in an HTML file.  You have to do it all with script.  If your popup is just some fixed HTML, you have to figure out your own substitution system.  This is annoying, and a feature sorely lacking from chrome.  The messages.json format is also weird, and there’s no existing tools that I could find to work with it.

No Prompt Service

Firefox has the nsIPromptService which makes simple dialogs easy.  You can crate things from a simple alert (with control of the title) to a more complex dialog with multiple custom labeled buttons.  I haven’t ported the functionality needed to do this just yet, but when I do, I will probably use jQuery UI.

No Built In Widgets

Firefox has all kinds of built in widgets.  The main one I was missing was a typeahead and search textbox. I used jQuery UI for the typeahead, and wrote a custom search textbox to emulate the behavior of the FF version.

getElementsByTagName is not scoped to the default namespace

In Firefox, when dealing with a namespaced document (like an atom feed), doing feed.getElementsByTagName is limited to the default namespace of the document. In chrome, it looks in all the namepsaces. This is a problem, because in dogear feeds there are two link elements. They’re not really the same element, because they’re in different namepsaces, but apparently that doesn’t matter to chrome.
<link href="http://signature.innovate.ibm.com/index" />
<snx:link linkid="9a18b409-3188-41be-a87c-815d4de784ec"/>
To be fair, the dom spec doesn’t say which way browsers should implement this method. I can’t really think of an instance where the chrome behavior would be useful. While both those things above are in a tag named link, they have completely different meanings. That’s the whole reason for having namespaces in the first place.

Fortunately the solution isn’t that difficult, you just have to call getElementsByTagNameNS, passing in the default atom namespace. It’s an annoying thing to have to change, however.

Less tolerance for twice defined variables

Another problem I quickly encountered was issues with variables defined twice. Javascript only has two levels of scope, function or local scope, and global scope (JS 1.7 now has block level scope, but never you mind that). No mater how nested it might be, once a variable is defined in a function, it exists throughout the entire function. This means that it’s actually wrong to declare it again (though you’ll get no error if you do so). Firefox and Chrome behave differently if you do so. Here’s an example of an issue I had
if(someCondition){
    var something="xyz";
}else{
    var something="123";
}
alert(something);

In Firefox, if someCondition is true, the result is the alert will display “xyz”. This is valid because once something is defined, it’ll exist throughout the function.

In chrome, the value of something ended up being undefined (actually, if you run this example, chrome will say xyz. Mine must have been more specific, but was similar in concept). The reason wasn’t clear until I looked in fireb Developer Tools. What was happening is two something variables were being defined, and chrome decided to use the second, uninitialized one. One way to fix this is to remove the second var:

if(someCondition){
    var something="xyz";
}else{
    something="123";
}
alert(something);

alert(something);but this makes the Java/C++ developer in me cringe. Instead, I did a more proper looking:

var something;
if(someCondition){
    something="xyz";
}else{
    something="123";
}

alert(something);
(Note I couldn’t actually come up with a sample that replicates this problem — maybe it was really another issue and I just thought this was the issue.)

Much ado about AMC and Jeep intake manifolds

So, I never intended for this blog to contain any useful information about anything in particular, but as time goes on my repository of knowledge about various things has started to include some of what others may actually consider useful, so I suppose I will go back on my intentions for the good of the masses. At any rate, I spent a good deal of time figuring this out and would like to put it somewhere before I forget.

The Venerable AMC Straight Six

The AMC straight six has been produced (in some form) from 1964 to 2006, an amazing 42 years of service (AMC had an earlier flat-head I6 they produced from 58-65). Well known by AMC aficionados and Jeepers alike, the AMC I6 was produced in essentially three incarcerations — the 199/232, the 232/258 and the 4.0. The 199 and 232 were produced from 1964-1970, and were the exact same engine with a different stroke to provide the different displacements. In the 1970s AMC stopped producing the 199, and raised the deck height of the 232 by 1/8″ to accommodate the 258, simply the 232 with a longer stroke. This engine was produced with little change until 1986 (the 232 stopped being produced in 1979). In 1987 the AMC I6 got its first major overhaul in years. Although in some ways a different engine than the earlier 258, the 4.0 retained much in common with its ancestor. The connecting rods from a 258 can be used in a 4.0L to give a 4.5L engine. With slight modification, the head from a 4.0L can be used on the earlier I6 series. In 1991, another change was made to the 4.0 to give better flow through the head, increasing horsepower. Other minor changes were made in the life of the engine as time went on before its final discontinuation in 2006.

Intake Manifolds

So, seeing the amount of compatibility between the AMC I6 engine, I wondered if I could fit a fuel injection system from a later model I6 on my 75 AMC 232. I found someone on ebay selling a fuel injection manifold he claimed had been installed on his 258. Taking a chance, I bought it hoping it would fit on my AMC. Although I didn’t actually take my manifold off to check, by comparing various photos and the manifold gaskets I had purchased, I could see fairly clearly that it would not. Since the manifold was useless to me, I decided to try and find out what it would fit, so I could proceed to sell it on ebay. After some extensive search, I came up with the following. Note that this is based on heresay and photographic evidence, and NOT experience. While I think this information is accurate, don’t come complaining to me that the intake from that 1986 Spirit didn’t fit on your 1965 Rambler American.

There are what I would call three eras of intake (and exhaust) manifolds. 1965-1986, 1987-1990, and 1991 and up (I should note that I didn’t check much after 1993, but I don’t think there’s much if any difference to the bolt patterns and such, although another change was made in the head around 96-98 to lower the flow through the heads, so there may actually be a difference.).

1965-1986

The 65-86 era is a huge span, and as you’d expect, there are some changes in those years. However, the bolt patterns and shapes of the ports did not change, so an 86 intake should bolt up to a 65 head without any trouble. The differences are that in 1965-1972 there were no federal emissions requirements, and as such the intakes and exhausts had no EGR valves. In 73 the EGR valve was added, so the manifolds were changed to allow exhaust gas to be recirculated into the intake manifold. During 1973-1980 this consisted of some kind of port between the exhaust and intake, with a gasket between the two. In 81 it seems this was changed somehow, and from 1981-1986 the intake and exhausts were separate, IE there was no gasket between them. There was an EGR valve however, so I presume there was some sort of tube between the two to allow the recirculation of the exhaust gas.

1987-1990

1986 saw the introduction of the 4.0, and as you might expect, the manifolds changed. Although the bolts are actually fairly close between the 4.0 and the 199/232/258, the shapes of the ports are completely different. The exhaust ports are round or nearly so, and the intake ports have an additional jut-out on top to allow some room for the injector stream from each intake port.

1991 and up

1991 is the year where the 4.0 was reworked to produce the 4.0 HO model (high output). This was done mostly by changing the shape and flow of the heads, as well as a new camshaft, and computer improvements. As you might expect, the intake ports changed once again. However, the change wasn’t major. I would describe it as moving the bottom half of the intake up while keeping the top in the same position. Not quite a squash since the top didn’t really change much, but almost. The exhaust looks exactly the same. From what I’ve heard, the earlier 87-90 intakes and exhausts work fine on the later model heads, with one exception. One bolt (I’m not sure which) was moved slightly, so in order to allow the bolting up of the older head, you must use a smaller size stud in this hole or somesuch. I’m not quite sure how this works exactly, since to be honest I didn’t look into it much, but I’ve heard no claims to the contrary that it cannot be done.

So there you have it. A stock fuel injection manifold will not fit on your Rambler American, or any other 65-86 era AMC or Jeep, unless you perform a head swap from a 4.0L engine (or perform extensive modifications to the manifold). However, an intake from 65-86 should be interchangeable on any AMC/Jeep I6 from that same span, with the provision that the exhaust and intake may not mate up perfectly if you put an intake with an EGR valve on an exhaust that did not have one, etc. Manifolds from the 87 and up era should be similarly interchangeable, with the one caveat of the different bolt position.

So go forth, change manifolds, be happy, and don’t come to me if I was completely wrong because the bolts were in a different place in 1968 and 1984.

Random Word Picker

I recently noticed that one of my favorite websites, the random english word picker is down. I think it’s been down for a while, in fact. In an attempt to fill in the void opened by this missing website, I have endeavored to create my own random word picker. I don’t quite remember the layout of the other one, but at any rate mine’s got multiple dictionaries, so that’s nice. Some of them are rather stupid, but, hey, what do you want. If you just want a standard dictionary, use the system dictionary. That is all.

Station Wagon Bandwidth

Up to 50x faster than covered wagon bandwidth! <br /><a href="http://old.alexrock.com/serendipity/archives/19-Station-Wagon-Bandwidth.html#extended">Continue reading "Station Wagon Bandwidth"</a>

Frozen Pudding

Oh, oh: you see, the kids, they listen to the rap music whichgives them the brain damage. With their hippin’, and the hoppin’, and the bippin’, and the boppin’, so they don’t know what the jazz…is all about! You see, jazz is like the Jello Pudding Pop — no, actually, it’s more like Kodak film — no, actually, jazz is like the New Coke: it’ll be around forever, heh heh heh.

So, in keeping with my promise (for suitably small values of promise) from last post, I decided to freeze some pudding and see what I got. Now, I was reminded that pudding pops are a commercial product. I hadn’t thought of this at all when I was writing the last entry, but remembered the slew of jokes about Bill Crosby and pudding pops once I was reminded. I hadn’t heard about them in a while, so I did a quick search to see what the deal was. Apparently pudding pops were discontinued sometime in the late 80’s and weren’t put back on the market until sometime in 2004. I seem to recall some sort of knockoff pudding pop that was wide and more like a creamsicle rather than the pudding pops, which are the same shape as regular popsicles (or at least, are now). It occurs to me that the knockoff things might have been fudge pops, which may or may not be different. It also occurs to me that I never liked them.

Anyhow, I bought some instant pudding mix and some milk last week, intending to eat half and then freeze half. Well, I ended up eating it all, so there was nothing but an empty container to freeze, and that’s no fun. Here’s a fun fact though: Rubbermaid plastic containers (fake Tupperware) have very good tops on them, and are great for making pudding (and I suspect other things made by combining powder + liquid). Just put the ingredients in, shut the top tight, and shake. Pudding mixed faster than with a blender (or whatever). I put it inside a plastic bag just to be safe (I wasn’t sure how good the top was) but I was pleasantly surprised, so you probably don’t need it (thought I take no responsibility for what happens if you don’t use one). So anyhow, I bought some jello pudding cups recently and decided to just freeze one (much like I did with the jello). If you’d like to try this experiment at home, I used the Oreo style pudding cups, which have chocolate pudding on the top and bottom, and a whitish pudding in the middle who’s flavor I could not identify, but can say with certainty that it didn’t taste like the middle of an Oreo (neither did the chocolate for that matter).

When I took it out, the frozen pudding looked about the same as it did when it was at whatever temperature mini-fridges are. I was afraid for a moment that it might have frozen solid, but when I went at it with the spoon, it scooped fairly easily. The chocolate part tasted like a mix between chocolate syrup and chocolate fudge. The whitish part I couldn’t place (I couldn’t figure out what it tasted like unfrozen) but if I had to guess I’d say it tastes like what I’d suspect mousse to taste like. Now, as to texture, here’s where things get weird. If you take little scoops and let them kind of melt in your mouth, they begin to have a very chocolate syrup like texture (I suspect it’d become more pudding like as you wait). If you take a bigger scoop however, the middle melts slower, and gives a very frozen jello like texture (a weird thick jelloey texture that’s hard to describe if you’ve never had frozen jello). This put me off a bit, and made me suspect that the pudding cup may have contained gelatin. Unfortunately I don’t have the box the pudding came in, and couldn’t find the ingredients on line so that’s a mystery that’ll have to wait for me to remember to look at a package in the future (unlikely) or someone to do it for me (more likely, but not much more).

So anyhow that’s it for that. I’m not sure what I’ll freeze next. Someone suggested oatmeal, I doubt that’ll work very well, but It’s better than not freezing anything, so I’ll probably try that.

Apparently freezing jello is one of the top questions on the jellowebsite, so I guess I’m even less original than I thought:

Can I freeze the JELL-O Ready-To-Eat Pudding & Gelatin?

Both Ready-to-Eat and traditional boxed JELL-O pudding and gelatin may be eaten frozen. However, we recommend against freezing pudding or gelatin and then thawing it to be eaten.

From another question:

Prepared pudding should not be frozen; it would become watery upon thawing.

Frozen Jello

How to ruin food in one easy step!

First off, let me apologize for whatever this little thing I do here becomes today. I’m using this as a distraction from an english paper I should be writing that was due like two weeks ago now.

So, the other night I was eating some jello. At some point while I was eating suddenly the words “jello popsicle” popped into my head. Now, I am not one to let such a fantastic idea just drop on the floor. I unfortunately don’t have the facilities to make real popsicles, so I figured the next best thing would be to just stick one of the jello snack cup things in the freezer and see what comes back out. Looking back now I wonder what the hell I was thinking.

I wasn’t sure if jello could even freeze. I realize it’s mostly water and sugar, but don’t forget the magical properties the gelatin imparts on those components. I wasn’t sure if it lowered the freezing point of the water or not. I’m still have no idea if it did or not, but I do know that my freezer is cold enough to freeze it, so that’s a good start. I’m not sure what I was expecting when I put it in there. A big strawberry flavored brick of ice I suppose. Well, when I pulled it out, it was certainly frozen, but it wasn’t hard like ice/a popsicle. It had changed colors though from the deep red #40 to a pinkish color.

When I opened up the jello cup it occurred to me that I had no idea how to eat this thing. It wasn’t on a stick, so I couldn’t eat it like a popsicle (which was the original intent) so I decided on the next best thing – a spoon. I’m happy to say (well, maybe not happy – perhaps I am not disheartened to say) that the spoon was quite capable of extracting the jello from its semi-cylindrical freeze-chamber. Unfortunately what it extracted wasn’t exactly delicious. It tasted pretty much the same, but the texture was just awful. Imagine syrupy gummi bears and you’ve pretty much got what it was like to eat it. Needless to say, I was quite disappointed with the results.

I should’ve realized that it wouldn’t’ve worked because jello doesn’t work like popsicles. When you lick a popsicle you melt it and extract it’s sugar water goodness. When you lick jello you accomplish nothing – jello doesn’t melt, it just kind of…. sits there. You get flavor from it for sure, but you don’t get much else. It also doesn’t work as a sherbet/ice cream/other-frozen-concoction because of it’s awful texture. I will say this, as it melted it seemed to turn back into the jello we all know and love, so at the very least, freezing jello doesn’t seem to harm it in any way. Now, why you would want to freeze jello is beyond me (I realize how ironic that sounds). I have no idea if jello can go bad, and if freezing it can delay that process (sounds like another experiment).

Now, if you think that this one bad experiment will stop me from freezing various random things that weren’t ment to be frozen, think again. Pudding seems the next logical choice. Well, maybe not so much logical as not-so-random. I have no idea what the results will be – I’m not even sure what pudding is, exactly, other than delicious – but I am sure they’ll be mighty interesting :p.

Update! — 01/14/05

So apparently it is possible to make successful jello popsicles. These are sometimes advertised as ‘dripless’ popsicles (something I’ve heard of, but never realized there was jello in them).