Zero Brane

Dynamic execution of embedded gists

2012-03-31T21:47:57Z

Gists are short code snippets that are useful for quick and simple code sharing. However, with all the functions provided by GitHub, gists are useful for much more than that: they are git repositories that have limited functions, but are versioned, can be forked, can be public/private, and can have their code embedded in web pages. It is this last feature I will use to show how the code that is stored and managed in a gist can be executed on a page.

]]> First of all, embedding of a gist is very easy: you add ). If you access that URL you get back several document.write calls that have the content of your gist and the code to do styling and syntax highlighting.

For this example I created a gist that has two files with some Lua code that I want to execute in a browser. To execute this Lua code I use the mechanism I described earlier.

Now, with the code of our gist available on the client, all we need to do is to write some JavaScript code to parse and execute the gist. This may look something like this:

function luagist() {
  var gists = document.getElementsByClassName("gist-data");
  for (var i = 0; i < gists.length; i++) {
    var text = [];
    var lines = gists[i].getElementsByClassName("line");
    for (var l = 0; l < lines.length; l++)
      text.push("textContent" in lines[l] ? lines[l].textContent : lines[l].innerText);
    (lua_load(text.join('\n')))();
  }
}

The logic here is simple: GitHub returns elements with gist-data class (one per each file in your gist). One complication is that every file is split into multiple lines and then split into tokens to provide syntax highlighting. It can be quite cumbersome to assemble the original content from all these fragments, but fortunately HTML provides textContent and innerText methods that do all the heavy lifting. The script processes every line and then joins all the lines in one script that then gets interpreted and executed. This execution is done one per file, in the same order as your files are presented in a gist (hence you may want to use 01-, 02-, or similar prefixes to make sure the files are loaded in the order you need).

The last step, which you may not need, is to hide the content on the page; this is done with .gist { display: none }. You can see the complete demo here. The disadvantage is that the access may be occasionally slow; the advantage is that any changes done to the "gisted" script become immediately available to the users.

Another way to embed the Lua code you may want to execute is to use a

The JavaScript code to process this content is only few lines long:

function luascript() {
  var tags = document.getElementsByTagName("script");
  for (var i = 0; i < tags.length; i++) {
    if (tags[i].type == "text/x-luascript") (lua_load(tags[i].text))();
  }
}

The code loops through all

DHCP Server with Arduino v0.06

2011-11-13T00:13:36Z

This version of the library added options for renewal and rebinding timers and a new example with AJAX processing that streams real-time data from Arduino.

The library now works correctly with Mac OS clients, but still doesn't work with iPhone (iOS versions 2 and 4) and iPad (iOS version 5). If someone knows what needs to be fixed, please send me an email.

DHCP and DNS servers with Arduino

2011-10-30T22:45:05Z

I have been working on my Arduino-based robot and wanted to have a way to run several devices on the same ad-hoc network and use their host names rather than their IP addresses.

It turned out that there was nothing available that worked out of the box. I tried several libraries, but some didn't have DNS server functionality, some were for the Ethernet library, which wasn't compatible with my shield (RedFly), and some simply didn't work.

First step was to get DHCP working. The sequence of DHCP messages is simple, but the format is not so much; it took me several attempts to get the format to be correct enough for the client to take the response. Wireshark was invaluable in showing the messages and giving me the ability to compare correct messages from the DHCP server in my router with the (initially) incorrect messages from my DHCP server.

Here is how the sequence of messages looks in Wireshark (this is between Windows Vista as a client and my DHCP server implementation running on Arduino + RedFly):

]]> Note that you can use "bootp" filter to select DHCP and BOOTP related messages. The Windows client sends DHCP Request message, which gets DHCP NAK in response as the server doesn't have any record of the client's mac address in its table (assuming this is a fresh restart of the server). The client then sends DHCP Discover message, which gets DHCP Offer response (the server offered to extend a lease). The client then sends DHCP Request, which now gets DHCP ACK as the server already registered the client in its lease table and confirms the lease.

This is the final confirmation message in this session:

At this point the client gets its DHCP address and can ping the server (in this case Arduino, which has 192.168.2.1 address).

Now the DNS server comes into play. If you enter "arduino" into the browser the client (or rather its DNS resolver) will try to resolve this name by sending queries to the registered DNS servers (or by using other means like mDNS and LLMNR). This interaction can be seen if you filter captured packets in Wireshark by "dns" or port number "udp.port == 53":

As can be seen in the screenshot, the client sent a query about "arduino.mshome.net" (in this case "mshome.net" is configured as the domain name, which was returned in the DHCP response as option 15); the server responds with the IP address for this hostname (192.168.2.1). Note that the server responded with "No such name" response to queries about other domains as it had no information and no access to other DNS servers to forward the request to.

The client then sends an HTTP request to that address and gets a simple HTTP response back:

Here is how you'd use this library:

#include 
...
      // for a request that comes to port DHCP_SERVER_PORT (UDP/67)
      buf_len = DHCPreply((RIP_MSG*)buf, buf_len, serverIP, domainName); 
...
      // for a request that comes to port DNS_SERVER_PORT (UDP/53 or TCP/53)
      buf_len = DNSreply((DNS_MSG*)buf, buf_len, serverIP, serverName);

Both DHCPreply and DNSreply methods use the buffer that has the received message to compile a return message; they both return a new message length or 0 to indicate a problem with the received message.

The code for this library is available here. Give it a try and leave a comment or send me an email if you see a problem.