After a lot of time of searching what is the best way to synchronously load javascript from javascript I finally found a way to do it that works in almost any browser. The hardest part of it all is not loading and eval’ing the script, but allowing the script to set new variables in the global scope.

This is what I’m finally using on my open source modular javascript project. To test it out I also found this website very useful. What I did was to create a test page that loaded a script, declared some global variables in different ways:

Then loaded the website through browsershots and the results came in a few minutes. The tests passed on a lot of browsers including all versions I could test of Firefox, Opera, MSIE, Safari, with some minor exceptions: Safari 3.2.1 on Windows XP and OS X 10.5, Opera 7.54 on Windows XP, Konqueror 4.2 on Ubuntu 9.04.

The case with Safari 3.2.1 is that it cannot set global variables declared with var inside a eval’ed script. There’s a newer 3.2.3 version that I would like to test on to see if there is any difference. As for Opera, it’s an old version that nobody is probably using anymore. But for Konqueror I really don’t know the source of the error.

Take the test yourself. If you would like to see how the tests were done take a look at the sources here.

Update: The test suite now passes in almost every browser with the exception of some older versions of opera .

A long time ago computers started to be able to store “things” in memory. Even though there’s no doubt that today we mostly store “files” in computers, that doesn’t mean that’s the only thing we can store. There’s a real world analogy from some terms we use to store data in our computers. Quoting from wiktionary.org:

file

A collection of papers collated and archived together.

folder/directory

An organizer that papers are kept in, usually with an index tab, to be stored as a single unit in a filing cabinet.

library

A collection of books or other forms of stored information. An individual may refer to his collection of books and other items as his library.

An equiavlent collection of analogous information in a non-printed form, e.g. record library

index

An alphabetical listing of items and their location; for example, the index of a book lists words or expressions and the pages of the book upon which they are to be found.

Some time in the past century the file system was created. Since then a thousand file systems had come to existence. Most of them can store basically two things: folders and files. Well, most of them also store information about these two items like dates and sizes, and permissions, and extended attributes. But are they indexable? Can anybody do a fast search on those attributes? From the btrfs changelog:

Btrfs indexes directories in two ways. The first index allows fast name lookups, and the second is optimized to return inodes in something close to disk order for readdir. The second index is an important part of good performance for full filesystem backups.

But is there any filesystem that creates indexes on anything else? Well many desktop searching applications create their own indexes. You have Spotlight on the mac, beagle, tracker, etc on Linux, google desktop search on windows. They can really get out of sync. If you take your external hard drive from a mac to a Linux machine copy some files and then back again you need to wait to Spotlight to catch up. Sometimes I just want to search for a file and I only remember it was an image I copied yesterday. Browsing through a whole messy external hard drive to find that can take forever.

That’s why I started working on dejumble. I don’t want to organize my files on folders anymore. I just want to find them!

I had this error for a very long time when trying to use extensions in Inkscape 0.46 for Mac OS X:

“The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore this extension”

After many hours of trying to find a solution I got it to work. This is what I did:

After that, all extensions (those found under the effects menu) started to work.

Update:
The problem seems to be fixed on the latest development version.

Update 2:
Fixed typo. Thanks to Bill Gathen for your comment.

When using ProjectPier in a different language than English you may come to see a bug when browsing through the dashboard. Some translations include html code in their strings (because of a migration from activeCollab?). ProjectPier escapes this strings and the code leaks to the user interface.

For example there is this Spanish translation:

On a first instance, %s is replaced by some string that may contain html, lets say “A&B”. Then ProjectPier scapes the resulting string and ends up like:

And the end user-visible result is:

A&B <strong>agregado</strong>

I’ve attached a patch to this post that fixes this. This patch is a temporary solution for the problem, but a real solution would be filter the real content before it is inserted in the translated string. This is for ProjectPier v.0.8.0.3.

Download: projectpier-lang.patch

On my previous post I looked at how some frameworks handle the multimodule approach to separate javascript code. Since then I’ve been playing with different ways of loading scripts online vs. doing it offline.

After doing some research on the subject I found this website where they show three different approaches to load javascript files. I did some testing and here are some results. The three methods to load the javascript tested were:

Inserting a script tag with a src into the head of the document:

Inserting a script tag with code fetched using ajax into the head of the document:

Using eval to execute the code fetched using ajax:

The test code was the following:

This files were loaded using a local Apache server. The results were the following:

Firefox 3.1 Beta 2 on Mac

loadScriptTag
Before
After

loadScriptTagWithAjax
Before
Test loadScriptTag
Test loadScriptTagWithAjax
After

loadScriptAjax
Before
Test loadScriptAjax
After

It seems that firefox executes the script with src just before the script with text everytime. Any way it is asynchronous.

Safari 3.2 on Mac

loadScriptTag
Before
After

loadScriptTagWithAjax
Before
Test loadScriptTag
Test loadScriptTagWithAjax
After

loadScriptAjax
Before
Test loadScriptAjax
After

Safari works just like firefox.

Opera 10 Alpha on Mac

loadScriptTag
Before
After

loadScriptTagWithAjax
Before
After

loadScriptAjax
Before
Test loadScriptAjax
After
Test loadScriptTag
Test loadScriptTagWithAjax

Opera executes the script tags when all the code is done running.

IE 6.0 on Mac using ies4osx

loadScriptTag
Before
After

loadScriptTagWithAjax
Before
Test loadScriptTagWithAjax
After

loadScriptAjax
Before
Test loadScriptAjax
After
Test loadScriptTag

IE executes the script tag with src at the end but the script tag with content in the right place.

Overall the only common result is using ajax with eval. This is my choice for modularjs.

Grab here the sources for these tests

When I’m developing small or medium or large javascript projects I end up with the same problem all the time: code grows and it starts getting a mess if you don’t do something about it. The only way out is separating your code into different modules which leads to the only conclusion of separating it on different files.

Most javascripts frameworks use different approaches to this. Some use an offline builder to create a single javascript file they distribute. Some other use a online dependency loading through different methods and some others a combination of both. Here’s a small list of frameworks and what they do:

YUI Loader Utility

If you plan to use the YUI Loader Utility, it means that you’ll have to add it to your page, in other words 9.4kb more, not too bad. You can load any javascript file. It also supports rolled up files, this means that you can have all the source files “rolled up” on one file and the loader works exactly the same way as if you were using separate files. This is an online only loader. It looks like this:

For custom modules it looks like this:

Dojo Toolkit

This choice means that you’ll have to build over dojo and use dojo’s require and provide mechanisms to request and provide modules online. It also has a ant and rhino based build system that can pack offline all modules in one file. The base dojo script takes ~100kb compressed which is quite large. I’m not really sure if the build system would work without the base dojo.js file. It looks like this:

And the module file, in this case by default at dijit/form/Button.js, should start with:

Prototoype

The Prototype build system uses Rake. This approach has the benefit of having multiple source javascript files and through a build system combine them on a single file. The downside is that you cannot choose at runtime which modules to load or not making it a all-or-nothing package. Also while developing you’ll need a ruby server to be able to test your code without compiling it. The code you need looks like this:

Note that it is not javascript but ruby code.

Mochikit

The Mochikit build system is based on python and rhino. It’s an offline packer and for development you’ll have to add all the scripts you are developing and dependencies on the right order. It has some sort of validation of import like this:

In the next article I’ll write about the internal methods used to load javascript files online, their advantages and disadvantages as well as my own way of doing it.

I’m starting a new project. The problem I need to address is now glass cutting and how to optimize a set of cuts to satisfy an order of cut glass sheets. The algorithm I used is the following:

1. Get the largest piece of material from the order.
2. Get the smallest piece of material from the available material that can contain the ordered piece.
3. Cut.
4. Repeat the process.

It seems to be working just fine for a large set of examples. I cannot find some example where it would fail to produce the best result. There were some constraints I had to take into account.

• Cuts should always be done from side to side on the available material and the cuts should be done perpendicular to the largest of the sides of the material whenever possible.
• Each cut should be independent of the previous cuts and sequential in case there’s a glass breaking or anything else. In that case the cuts should be able to be “replayed” from the failure point forward after doing the correction.

Here’s an image of the result.

The 10th cut as calculated by sectum.