For those of you who don't want to run a Java applet, here's a video
demonstration. Gravity is reversed every few seconds, causing the
liquid to slosh up and down over and over. The two triangles on the
sides help mix things up a bit. The video flips through the different
components of the animation.
It's not a perfect liquid simulation. The surface never settles down,
so the liquid is lumpy, like curdled milk. There's also a lack of
cohesion, since JBox2D doesn't provide cohesion directly. However, I
think I could implement cohesion on my own by writing a custom
contact.
JBox2D is a really nice, easy-to-use 2D physics library. I only had to
read the first two chapters of
the Box2D manual. Everything else can
be figured out through the JBox2D Javadocs. It's also available from
the Maven repository, which is the reason I initially selected it. My
only complaint so far is that the API doesn't really follow best
practice, but that's probably because it follows the Box2D C++ API so
closely.
I'm excited about JBox2D and I plan on using it again for some future
project ideas. Maybe even a game.
The most computationally intensive part of the process isn't
the physics. That's really quite cheap. It's actually blurring, by
far. Blurring involves convolving a
kernel over the image -- O(n^2) time. The graphics card would be
ideal for that step, probably eliminating it as a bottleneck, but it's
unavailable to pure Java. I could
have pulled in lwjgl, but I wanted to
keep it simple, so that it could be turned into a safe applet.
As a result, it may not run smoothly on computers that are more than a
couple of years old. I've been trying to come up with a cheaper
alternative, such as rendering a transparent halo around each ball,
but haven't found anything yet. Even with that fix, thresholding would
probably be the next bottleneck -- something else the graphics card
would be really good at.
At work I’ve recently been generating viewsheds over DTED sets. Earlier this week I was asked to give an informal presentation on what I was doing. I wanted some terrain that demonstrated some key features, such as vision being occluded by hills of varying heights. Rather than search through the available DTED files for something good, I opted for generating my own terrain, using an old trick of mine: my Perlin noise “cloud” generator. That’s a lesson in the usefulness of maintaining a blog. The useful things you learn and create are easy to revisit years later!
I generated some noise, looked at it with surf(), and repeated until I found something useful.
It still wasn’t smooth enough. So I repeated the process a bit,
fori= 1:10
ms=conv2(ms,k,'same');end
Perfect! I used that for my presentation. However, I was having fun and decided to experiment more with this. I filtered it again another 1000 times and generated a surf() plot with a high-resolution colormap – the default colormap size caused banding.
I think it looks like a photograph from a high-powered microscope, or maybe the turbulent surface of some kind of creamy beverage being stirred.
At work when I need something Matlab-ish, I use Octave about half the time and Matlab the other half. In this case, I was using Matlab. Octave doesn’t support the EdgeAlpha property, nor the viewshed() function that I needed for my work. Matlab currently makes much prettier plots than Octave.
CSS variables have been proposed a numberof times already, but, as far as I know, it has never been taken seriously. Variables – constants, really, depending on the proposal – would be useful in eliminating redundancy, because the same value often appears multiple times across a consistent theme. The cascading part of cascading stylesheets can deal with some of this, but not all. For example,
Because the color has been defined in one place, adjusting the color theme requires only one change. That’s a big help to maintenance.
I recently investigated CSS variables, not so much to reduce maintenance issues, but mainly because I wanted to have user-selectable color themes. I wanted to use JavaScript to change the variable values dynamically so I could modify the page style on the fly. Since CSS variables are merely an idea at the moment, I went for the next tool already available to me: Liquid, the templating system used by Jekyll. Jekyll essentially is Liquid, which is what makes it so powerful. It continues to be my ideal blogging platform.
If you look in my site’s source repository (not the build code hosted here), you’ll see my core stylesheet is an _include and looks like this,
That’s just some YAML front-matter defining the theme’s variables. For my themes, I define three background colors, two foreground colors, and the link color. For each theme, a full stylesheet is generated from the stylesheet template above. To allow the user to select a theme, I just use some JavaScript to select the proper stylesheet. You can try this out with the theme-selector on the sidebar.
I’ve done all my video editing in a very old-school, unix-style way. I actually have no experience with real video editing software, which may explain why I tolerate the manual process. Instead, I use several open source tools, none of which are designed specifically for video editing.
The first three are usually available from your Linux distribution repositories, making them trivial to obtain. The last one is easy to obtain and compile.
If you’re using a modern browser, you should have noticed my portrait on the left-hand side changed recently. That’s an HTML5 WebM video – currently with Ogg Theora fallback due to a GitHub issue. To cut the video down to that portrait size, I used the above four tools on the original video.
WebM seems to be becoming the standard HTML5 video format. Google is pushing it and it’s supported by all the major browsers, except Safari. So, unless something big happens, I plan on going with WebM for web video in the future.
The -benchmark option hints for mplayer to go as fast as possible, rather than normal playback speed.
Next look through the output frames and delete any unwanted frames to keep, such as the first and last few seconds of video. With the desired frames remaining, use ImageMagick, or any batch image editing software, to crop out the relevant section of the images. This can be done in parallel with xargs’ -P option – to take advantage of multiple cores if disk I/O isn’t being the bottleneck.
ls *.jpg | xargs -I{} -P5 convert {} 312x459+177+22 {}.ppm
That crops out a 312 by 459 section of the image, with the top-left corner at (177, 22). Any other convert filters can be stuck in there too. Notice the output format is the portable pixmap (ppm), which is significant because it won’t introduce any additional loss and, most importantly, it is required by the next tool.
If I’m happy with the result, I use ppmtoy4m to pipe the new frames to the encoder,
As the name implies, ppmtoy4m converts a series of portable pixmap files into a YUV4MPEG2 (y4m) video stream. YUV4MPEG2 is the bitmap of the video world: gigantic, lossless, uncompressed video. It’s exactly the kind of thing you want to hand to a video encoder. If you need to specify any video-specific parameters, ppmtoy4m is the tool that needs to know it. For example, to set the framerate to 10 FPS,
... | ppmtoy4m -F 10:1 | ...
ppmtoy4m is a classically-trained unix tool: stdin to stdout. No need to dump that raw video to disk, just pipe it right into the WebM encoder. If you choose a different encoder, it might not support reading from stdin, especially if you do multiple passes. A possible workaround would be a named pipe,
I have attempted to do two passes with the WebM encoder (--passes=2), but there’s always been a floating-point bug that prevents it. For now I just use the --best option, telling the encoder to takes its time to do a good job.
To produce Ogg Theora instead of WebM, ffmpeg2theora is a great tool. It’s well-behaved on the command line and can be dropped in place of vpxenc.
If you want to do audio and video … that’s a lot more work. I’ve never done it myself, but how I suspect I’d handle it is with Audacity and lots of synchronization trial-and-error.
Extra notes update: There’s a bug in imlib2 where it can’t read PPM files that have no initial comment, so some tools, including GIMP and QIV, can’t read PPM files produced by ImageMagick. Fortunately ppmtoy4m is unaffected. However, there is a bug in ppmtoy4m where it can’t read PPM files with a depth other than 8 bits. Fix this by giving the option -depth 8 to ImageMagick’s convert.
With Emacs being a breeze to synchronize between my computers, I noticed a new bottleneck emerged: my .ant directory. Apache Ant puts everything in $ANT_HOME/lib and $HOME/.ant/lib into its classpath. So, for example, if you wanted to use JUnit with Ant, you’d toss junit.jar in either of those directories. $ANT_HOME tends to be a system directory, and I prefer to only modify system directories indirectly through apt, so I put everything in $HOME/.ant/lib. Unfortunately, that’s another directory to keep track of on my own. Fortunately, I already know how to deal with that. It’s now another Git repository,
With that in place, settling into a new computer for development is almost as simple as cloning those two repositories. Yesterday I took the step to eliminate the only significant step that remained: setting up java-docs. Before you could really take advantage of my Java extension, you really needed to have a Javadoc directory scanned by Emacs. The results of that scan not only provided an easy way to jump into documentation, but also provided the lists for class name completion. Now, java-docs now automatically loads up the core Java Javadoc, linking to the official website, if the user never sets it up.
So if you want to see exactly how my Emacs workflow with Java operates, it’s just a few small steps away. This should work for any operating system suitable for Java development.
Let’s start by getting Java set up. First, install a JDK and Apache Ant. This is trivial to do on Debian-based systems,
sudo apt-get install openjdk-6-jdk ant
On Windows, the JDK is easy, but Ant needs some help. You probably need to set ANT_HOME to point to the install location, and you definitely need to add it to your PATH.
Next install Git. This should be straightforward; just make sure its in your PATH (so Emacs can find it).
Clone my .ant repository in your home directory.
cd
git clone https://github.com/skeeto/.ant.git
Except for Emacs, that’s really all I need to develop with Java. This setup should allow you to compile and hack on just about any of my Java projects. To test it out, anywhere you like clone one of my projects, such as my example project.
If that works, you’re ready to set up Emacs. First, install Emacs. If you’re not familiar with Emacs, now would be the time to go through the tutorial to pick up the basics. Fire it up and type CTRL + h and then t (in Emacs’ terms: C-h t), or select the tutorial from the menu.
Move any existing configuration out of the way,
mv .emacs .old.emacs
mv .emacs.d .old.emacs.d
Clone my configuration,
git clone https://github.com/skeeto/.emacs.d.git
Then run Emacs. You should be greeted with a plain, gray window: the wombat theme. No menu bar, no toolbar, just a minibuffer, mode line, and wide open window. Anything else is a waste of screen real estate. This initial empty buffer has a great aesthetic, don’t you think?
Now to go for a test drive: open up that Java project you cloned, with M-x open-java-project. That will prompt you for the root directory of the project. The only thing this does is pre-opens all of the source files for you, exposing their contents to dabbrev-expand and makes jumping to other source files as easy as changing buffers – so it’s not strictly necessary.
Switch to a buffer with a source file, such as SampleJavaProject.java if you used my example project. Change whatever you like, such as the printed string. You can add import statements at any time with C-x I (note: capital I), where java-docs will present you with a huge list of classes from which to pick. The import will be added at the top of the buffer in the correct position in the import listing.
Without needing to save, hit C-x r to run the program from Emacs. A *compilation-1* buffer will pop up with all of the output from Ant and the program. If you just want to compile without running it, type C-x c instead. If there were any errors, Ant will report them in the compilation buffer. You can jump directly to these with C-x
` (that’s a backtick).
Now open a new source file in the same package (same directory) as the source file you just edited. Type cls and hit tab. The boilerplate, including package statement, will be filled out for you by YASnippet. There are a bunch of completion snippets available. Try jal for example, which completes with information from java-docs.
When I’m developing a library, I don’t have a main function, so there’s nothing to “run”. Instead, I drive things from unit tests, which can be run with C-x t, which runs the “test” target if there is one.
To see your changes, type C-x g to bring up Magit and type M-s in the Magit buffer (to show a full diff). From here you can make commits, push, pull, merge, switch branches, reset, and so on. To learn how to do all this, see the Magit manual. You can type q to exit the Magit window, or use S-<arrow key> to move to an adjacent buffer in any direction.
And that’s basically my workflow. Developing in C is a very similar process, but without the java-docs part.
See it in action: CubeDemo.jar (4.7 MB) (Linux, Windows, and Mac OS X) (source)
NativeGuide is a Java utility library I wrote that makes native libraries easier to manage. Really, it’s a very small and simple library, but it provides some critical functionality I desire and I feel many libraries are sorely lacking. Since I would absolutely love for other Java libraries to start using it, I went through the extra effort to have it placed conveniently in the central Maven repository: com.nullprogram:native-guide.
As a side note, I actually worked out my own staging solution rather than rely on Maven – I always go out of my way to avoid Maven. For reuse-ability, I added it to my sample-java-project as the “bundle” target. It generates all of the required artifacts, digitally signs them, and bundles them up.
The demo at the top of this post contains native libraries for running OpenGL programs on seven platforms. NativeGuide takes care of getting the proper library in place for the JVM to load. All of this is hopefully transparent to you, the user, so that this appears to be a regular run-anywhere Java application.
The issue that NativeGuide solves is a special case of the distribution problem. Distribution is one of the major problems every language/platform must solve. That is, how do you get your application to the end user so that they can run it? In the case of a C or C++ application, you compile it for the user’s native system, either statically link or pack up the dependencies, and wrap it all up in an installer. Python and Perl have working solutions for different platforms. Ruby must have something figured out, though I don’t know what it is.
I believe this is one of Lisp’s biggest problems, because there’s no real solution yet. Assuming the user already has a Lisp system installed – a very big assumption – what do you deliver? FASL files aren’t compatible between Lisps and sometimes even between versions of the same Lisp. You’re left either targeting their specific Lisp system or distributing source – which either you can’t do or you really can’t expect the user to compile. That’s a long ways away from a simple double-click shortcut. If you somehow got that work, then how to you make it convenient to launch?
If the user doesn’t have a Lisp system installed you then have to package your own. Maxima does this, but their solution takes a lot of work and maintenance. It’s unreasonable for every application to do this. SBCL is pretty close to making that part work well, through a feature to save executable images. However, until very recently this came with lots of overhead. A “Hello, World” program would be around 60 MB, since it includes an entire Common Lisp system. Another problem is the program is entirely integrated to the particular SBCL with which it was compiled. The user can’t install a newer, potentially more secure, SBCL and run it with the new one.
I think Java’s method of application distribution is really nice. The JRE is easy to install so it’s available almost everywhere. Unfortunately, when it’s not installed and you try to package a JRE with your application, the situation starts to look like SBCL. Fortunately, that’s not a very common problem. Applications can be packed up into a single .jar file, including all the art assets, configuration XML, and so on, and distributed as a single file, which is usually easy to launch. Java provides special support for accessing those packed up resources right from the packaging: Class.getResource() and Class.getResourceAsStream().
However, the same courtesy is not provided for packed up native libraries. There’s no support for loading them from within a .jar file. What sometimes happens is these libraries end up being delivered alongside the application. They have to be installed somewhere and there has to be some kind of OS/architecture detection in the launcher, the hardest place to do it, to determine the right libraries to use. In a few cases they’re packed up with the application, which copies them out to a temporary directory for loading. That’s even more effort duplication, having to detect the OS and architecture again, figuring out where exactly to copy them, what to do if they’ve already been copied, maybe updating the java.library.path which isn’t as sample as just setting the system property.
Libraries often don’t worry about that part, leaving it to the users of the libraries to figure something out. Everyone using the library makes their own solutions in parallel when it would have been better if the work was done just once by the library. (A few librarieshave done the right thing.)
The goal of NativeGuide is to make all of that mess go away. You pack up your native libraries as resources and register them with NativeGuide at run-time. NativeGuide detects which library the JRE can use, copies the correct ones to a temporary directory, and appends that directory to the java.library.path if needed. For example, this is what registration looks like,
Outside of this registration, the whole thing is transparent. I’ve already used it with two projects allowing me to package them up into a single .jar file as if no native library was being used. One is a project at work which uses RXTX and the other is a branch of my sample-java-project: lwjgl. This allows me to produce a single .jar OpenGL application that users on Linux, Windows, and Mac OS X can just double-click to run.
So my hope is to get libraries using NativeGuide to save everyone time. The users of the library would probably be unaware that NativeGuide is there. Just like all of my code, I made it public domain, so there can be no license objections. However, if the library maintainers don’t choose use it, I made it flexible enough that you can work around them with little trouble.
Over the last couple of years I’ve worked out some cool shell tricks, which I use as aliases. Like any good software developer, if I notice a pattern I take steps to generalize and reduce it. For shells, it might be as simple as replacing a regularly typed long command with a short alias, but the coolest tricks are the ones that reduce an entire habit.
The first one is the singleton pattern. Say you have a terminal program that should only have a single process instance but should only start on demand. Some programs may enforce that rule, if it makes sense to, but some do not.
In my case, that program was rtorrent. I only want a single instance of this program running at a time, but I also don’t want to have to think about whether or not I’ve started it already. I always run it in screen so that I can detach it and let it run in the background. My shell habits looked like this.
# Assume it's there already
$ screen -r rtorrent
# If not, fire it up
$ screen -S rtorrent rtorrent
If I needed to start rtorrent for the first time I was often typing in that first command just to see it fail. Fortunately, it really does fail: the exit code is non-zero. This allows me to make this cool alias,
alias rt='screen -r rtorrent || screen -S rtorrent rtorrent'
Either it attaches to the existing instance or fires a new one up for me and attaches me to that one. Now, there is a race condition here. That “or” operator isn’t atomic, so something else might spawn an rtorrent instance in between check and creation. Since I’m only ever running this by hand, and there is only one of me, that’s not a problem.
The next trick has to do with my habit of throwing up a temporary web server when I need to share files. I noticed that I would launch it, run it for a minute, kill it, run one or two commands, and launch it again. For example, if I’m working on a program and I want to share the build with someone else. I might drop out of it just to do something with git and rebuild. Once again, my alias fix involves screen,
alias httpd='screen -S http python -m SimpleHTTPServer 8080'
Rather than kill the server only to restart it again, I always run it in screen. So instead I detach, but I don’t even need to bother reattaching.
This next one is my Emacs alias. Emacs has the really, really cool ability to become a daemon. You can launch a daemon instance, then connect to it as needed with clients to do your editing (emacsclient
--create-frame or just -c). This allows your Emacs session to live for a long time, preserving all your buffers. Long-living sessions are an old Lisp tradition. Also, being a daemon eliminates any lengthy startup penalty, because it only happens once after reboot.
$ emacs --daemon
$ emacsclient -c
# Close it and sometime later start another client
$ emacsclient -c
This is another case of the single-instance problem. However, Emacs is really smart about managing this by itself. It has an argument, --alternate-editor (-a), which allows you to specify another editor to use in case the daemon isn’t started.
emacsclient -ca nano
The most important part of this option is its hidden feature. When the argument is empty it defaults to launching a daemon. No need to launch it manually, it’s just one command.
alias e='emacsclient -cna ""'
Naturally, Emacs gets to be in one of the coveted, single-letter slots. I also set one up for terminal mode Emacs (-t instead of -c),
alias et='emacsclient -ta ""'
And just to teach the editor heathens a lesson or two, this command has a second alias,
alias vi='emacsclient -ta ""'
The final trick is one I just figured out this week, and it involves passphrase agents. Just in case you are not familiar, both ssh and gpg have daemons which will securely store your passphrases for you.
OpenSSH is loaded with extremely useful functionality. One of them is key authentication. Rather than use a password to log into a system, you can prove your identity cryptographically – you solve a math problem that only you have the information to solve. This is invaluable to Git, because it allows for passwordless access to remote repositories. You can host a repository for a bunch of users without the awkward password step (“Pst … your password is passwordABC. Change it after you first log in.”). Instead, they all send you their public keys.
To use this feature, you first you generate a public/private keypair for yourself, which gets stored in ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub.
$ ssh-keygen
At one point in this process you will be asked for a passphrase, which is used to encrypt your private key. At first you might wonder why you bother with the key at all if you’re going to encrypt it. Rather than enter a password to log into a system, you have to enter a passphrase, which is even worse because it’s longer. So you don’t bother with a passphrase. This is dangerous because it’s practically the same as storing your login password in a file! If someone got a hold of your private key file, they have full access to your systems.
This is where ssh-agent comes in. It runs as a service in the background. You register your private key with it with ssh-add and it queries for your passphrase, storing it in memory. It’s very careful about this. It’s stored on a memory page that has been registered with the operating system such that it’s never written to permanent storage (swap). When the process dies, or zeros out that memory, the passphrase is completely lost.
GnuPG’s daemon, gpg-agent, works very similarly. It holds onto your PGP passphrase so you can perform a number of actions with it without needing to enter it a bunch of times.
gpg and ssh know how communicate with their agents through information stored in environmental variables. However, this creates a problem when launching the agents. They can’t change the environment of their parent process, your shell. The easiest way to do it is to reverse the relationship, with the agent becoming the parent of your shell.
$ exec ssh-agent bash
This tells ssh-agent to launch a new shell with the proper environment. In case you’re not familiar, the exec causes the new shell replace the current one. It’s the same exec() as the POSIX function. You could leave it off, but you’ll be left with nested shells, which can be very confusing.
GnuPG’s agent is launched like this,
$ exec gpg-agent --daemon bash
My problem was that I often want both of these at the same time. I could run them back to back, but making them into a single, alias-able command is tricky. This naive expression will not work,
$ exec ssh-agent bash && exec gpg-agent bash
The first exec causes the current shell to end, so the second part is never evaluated. I can’t simply remove the execs and live with nested shells because the next agent isn’t launched until the first agent’s shell dies. The very cool solution is to chain them together!
alias agent='exec ssh-agent gpg-agent --daemon bash'
The current shell turns into the ssh-agent, which spawns gpg-agent with the proper environment for ssh, which forwards its environment along to spawn a new shell with the proper environment for both.
If I ever need another agent I just add it to the chain. That command should probably be at the end of my .bashrc or something, but it’s just an alias for now. Sometimes I log into X first, sometimes ssh first, so I’m not sure what the correct place would be.
I finally got my entire Emacs configuration into source control. My previous solution was to copy around my .emacs.d/ to each computer I use. This works well enough with two computers, but beyond that it’s difficult to propagate any changes I make. Counting all my VMs, I have around a dozen systems where I use Emacs. This is the exact problem that source control exists to fix.
If you move your .emacs and .emacs.d/ out of the way, clone my repository right into your home directory, clone the submodules, and then run Emacs 23 or greater, you’ll see my exact Emacs setup, theme and all.
Notice there’s an init.el in there. Emacs tries to load ~/.emacs first, but if that doesn’t exist it loads ~/.emacs.d/init.el. That’s why you need to move your own .emacs out of the way to see my stuff. I do still make use of a .emacs file. That’s my system-specific configuration, where, for example, I tell Emacs where to find Javadoc files. At the top of this file I make sure to load my other init file.
;; Load standard configuration(load-file"~/.emacs.d/init.el")
One reason I didn’t use source control right away was the submodule problem – my configuration is largely made up of other repositories. Git has good support for putting foreign Git repositories within your own repository, but a couple of repositories I was using were Subversion and CVS. I managed to cut down to just Git repositories and one Subversion repository, for which I now
maintain a Git mirror, making these *all* Git repositories. (Update November 2011: YASnippet has moved to Git.)
I also trimmed down a bit, cutting out some things I noticed I wasn’t using (breadcrumbs, pabbrev) or things that didn’t need to be in there, such as Slime. I now use Quicklisp to manage my Slime installation, which I connect with my configuration in my system-specific .emacs. Using source control will help better track what I’m using and not using, keeping the whole thing more tidy. Removing an experimental addition should be a simple revert commit.
I recently toyed around with some halftone, a technique for simulating continuous tone images using solid dots. I can’t remember what specifically gave me the idea to try it out. Perhaps it was because it provided a good use-case for my newly discovered hot code replacement.
Halftone dates back to the 19th century and was the first low-cost method for printing images because it didn’t require highly skilled artists. What made it so inexpensive was that producing the relief surface was an entirely mechanical process. Light is projected through a negative, through a mesh screen, and onto a plate containing light sensitive chemicals. Brighter parts of the image would form larger spots and dimmer parts smaller dots. The chemical on the plate would react to the light and rise up very slightly. The plate is then inked and used for printing.
Halftone printing is still used today, but, of course, the process for generating the halftone version of an image is all done with computers. Digital halftoning. Digital halftoning provides several different ways to arrange the dots: by size (amplitude modulation), by spacing (frequency modulation), by shape, or any combination of these. In my little demo above I took the simplest route, by size.
I scale the image down using bicubic interpolation (thanks to the handy AffineTransform). With it scaled down, each pixel becomes a single dot in my final image. Since I want the dots to fully fill their space at the most extreme, their maximum radius is the square root of two times the spacing. That is, the dots will just touch on the diagonal when full. To determine magnitude of the dot I used the luma coefficients. That makes the RGB values weighted more accurately to the way human sight perceives brightness.
Rotating the image would be an improvement over the flat grid it is now. A 45-degree rotation helps break up potential patterns. I tried to do this, but I couldn’t get the math right along with the correct parameters to the AffineTransform. Something was always getting clipped or padded incorrectly. Adding CMYK color would also be interesting, and would also require rotation of the dot grid – each color gets its own angle.
I also thought about having it dump out the image in vector form as a SVG or PostScript, which would make it start to behave like The Rasterbator. With that output, it would only need to split up that output into normal-sized pages and I could use it to produce large images from a cheap printer.
I finally started taking advantage of a JVM feature that’s been around for almost a decade: hot code replacement. HCR was introduced in 1.4 as part of the Java Platform Debugger Architecture (JPDA). It provides the ability for code to be updated seamlessly in a running Java program. This can really cut down on the development cycle because the program doesn’t need to be started over from the beginning for every little change.
This is not actually a new concept or development style for me. Updating live, running code is fundamentally how Lisp programs are developed. This is how I wrote my Emacs web server. I opened a socket to listen on 8080, which originally did nothing but accept connections, and built up a web server behind the socket without ever taking it down. It’s be unusual to develop Lisp any other way.
Eclipse has directly supported HCR for some years now. I had heard about it, but never investigated the issue until I saw Markus “Notch” Persson using it while coding his Ludum Dareentry (source) on a live-stream. It was really neat to see it in use on a graphical program.
If you know anything about my professional habits, you know I’m not a fan of giant IDEs like Eclipse. I hack Java with a combination of Ant and Emacs, with my own custom extensions. So any hotswap solution has to be built on that. Luckily, I found this great Ant extension: hotswap. It provides a hotswap task for performing HCR.
It relies on Ant to prepare replacements and determine which files are to be swapped. They provide an example target on their website demonstrating how to set it up. Personally, I think it’s a sloppy way to do it. It writes a timestamp to a string (the only Ant data structure available for this), redundantly performs compilation, then parses the time string to compare it to all of the files, picking out new ones.
There’s actually an modified selector exactly for this type of job. Here’s my solution (as seen in my sample-java-project),
The modified filter is not timestamp based. It creates a cache.properties file containing the hash of all of your class files. Trivial changes, such as to comments or whitespace, will not trigger for replacement. Because that’s taken care of without the timestamp business, no need to write out the compile task again. We can just call the original as a dependency of this target.
An easy way to try this out for yourself now is with the hotswap-demo branch of my chess engine. (This branch is special because it forces the GUI to redraw every second, causing changes to take effect immediately.) Check out that branch, run the program with the run target, then in BoardPanel.java change the colors of the board in paintComponent() – change LIGHT to Color.WHITE and DARK to Color.GRAY, for example. Then, without stopping the program, run the hotswap target. Ant will inject the new code into the running program and the board will change before your eyes.
I look forward to making good use of this in the future. Expect it to be a typical Ant target in all of my Java projects from now on.
