Author: Andy Balaam

Building jEdit from source

I have recently agreed to take over development of the JSLint plugin for my favourite editor, jEdit.

To start developing I decided to build jEdit and its plugins from source, which wasn’t as easy as I would have expected (thanks to deffbeff for some pointers). A few small changes to the setups for the plugins would make it much easier – at some point I may try to help out there, but for now, here is how I built jEdit and the set of plugins I use regularly:

sudo apt-get install openjdk-6-jdk ant git-core subversion

cd ~/code/public
mkdir jedit
cd jedit

svn co https://jedit.svn.sourceforge.net/svnroot/jedit/jEdit/trunk jEdit

cd jEdit; ant; cd ..

mkdir plugins

Now I made a file inside plugins called build.properties which looked like this:

install.dir       = ../../jEdit/build/settings/jars
jedit.plugins.dir = ../../jEdit/build/settings/jars
jedit.install.dir = ../../jEdit/build
build.support     = ../build-support

And then continued like this:

cd plugins
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/build-support/trunk build-support

svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/ErrorList/trunk ErrorList
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/CommonControls/trunk CommonControls
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/InfoViewer/trunk InfoViewer
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Console/trunk Console
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/BufferList/trunk BufferList
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/FindFile/trunk FindFile
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/GnuRegexp/trunk GnuRegexp
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/OpenIt/trunk OpenIt
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/RecentBufferSwitcher/trunk RecentBufferSwitcher
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/Sessions/trunk Sessions
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/WhiteSpace/trunk WhiteSpace
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/ScriptEnginePlugin/trunk ScriptEnginePlugin
svn co https://jedit.svn.sourceforge.net/svnroot/jedit/plugins/JavascriptScriptEnginePlugin/trunk JavascriptScriptEnginePlugin

git clone git://jedit.git.sourceforge.net/gitroot/jedit/ProjectViewer
git clone git://github.com/andybalaam/jslint-plugin-for-jedit.git jslint

cd ErrorList; ant; cd ..
cd CommonControls; ant; cd ..
cd InfoViewer; ant; cd ..
cd ProjectViewer; ant; cd ..
cd Console; ant; cd ..
cd BufferList; ant; cd ..
cd FindFile; ant; cd ..
cd GnuRegexp; ant; cd ..
cd OpenIt; ant; cd ..
cd RecentBufferSwitcher; ant; cd ..
cd Sessions; ant; cd ..
cd WhiteSpace; ant build; cd ..
cd ScriptEnginePlugin; ant; cd ..
cd JavascriptScriptEnginePlugin; ant; cd ..
cd jslint; ant; cd ..

To find out the dependencies of all plugins and therefore what order to build them, I did this:

find ./ -name "*.props" | xargs grep "depend.*plugin"

Surely something should do this for me automatically?

The problem I haven’t solved yet is that the FTP plugin requires JUnit. I could have copied the junit.jar into the jars dir and I think it would have worked, but I want to do it “properly”…

Finally, I made a .desktop shortcut file in ~/.local/share/applications/jedit.desktop like this:

[Desktop Entry]
Name=jEdit
GenericName=Programmer's Text Editor
Comment=Edit text files
Exec=java -jar /home/andy/code/public/jedit/jEdit/build/jedit.jar -settings=/home/andy/code/public/jedit/jEdit/build/settings %U
Icon=/home/andy/code/public/jedit/jEdit/doc/jedit.png
Terminal=false
Type=Application
Categories=Development;TextEditor;
StartupNotify=true
MimeType=text/plain;
StartupWMClass=org-gjt-sp-jedit-jEdit

Which enabled me to run the jEdit I had built from my system menu.

Note that I am running jEdit under OpenJDK because Sun/Oracle Java is annoying to get hold of at the moment, and generally somewhat evil. Thanks Oracle for killing Java. jEdit does not work brilliantly with OpenJDK, which is frustrating. Maybe I’ll try to fix it?

Goodness in programming languages, part 1 – syntax and layout

In this series I will comment on what I like in some of the languages I use. I will cover things that I find convenient, things that might lead me to write correct code, things that tend to make my code more readable, and possibly other things that I just like for no clearly-articulated reason. The purpose of this series is to help me think about what features I would put in a language if I created my own.

Posts in this series: Syntax, Deployment, Metaprogramming, Ownership

What aspects of syntax and layout – how the code appears in your text editor – do I like? This is entirely irrelevant to the computer that is running the code, and an implementation detail of the language compiler or interpreter, but is extremely important to me.

  • Python and Scheme’s low-symbol approach. Python and Scheme tend towards the use of English words, rather than symbols to express concepts. This makes code easier to read for someone unfamiliar with the language, and also for me.
  • Python’s unambiguous block structure. Python uses indentation to express block structure (e.g. for variable scope, namespaces and logic structures). Programmers in most languages (notably C-like and Lisp-like ones) tend to use indentation to help humans understand the block structure of their code, but the computer uses different symbols to understand the same thing. This can lead to ambiguity where a human may mis-read the real block structure of some code because the indentation is inconsistent with the symbols. Python avoids the problem by making indentation the syntax understood by the compiler. [Go avoids the same problem by stating that code with inconsistent indenting (as defined by the gofmt program) is invalid.]
  • Scheme’s simplicity. Scheme (like other Lisp dialects) has very simple rules to describe its syntax. This means you need to learn very little before you can understand the structure of Scheme programs, and it is unlikely you will be confused by rare structures.

Of course, there are trade-offs in all these points. Using fewer symbols can make programs verbose (although I find Python feels very concise). The lack of an end-of-block symbol makes short Python snippets look clean, but can make longer sections hard to understand (perhaps better editor support would help with this?). Scheme’s use of brackets for everything means there are a lot of brackets, so working out which does what job can be difficult.

Nevertheless, the goals of reducing the number of symbols with special meaning, allowing humans and computers to use the same ways of understanding code, and being as simple as possible are good goals to have.

Ethernet not working on Ubuntu with Realtek RTL8111/8168B

Thanks to rvdavid, the network on my new PC is now working, despite Ubuntu misrecognising it:

How to Get Gigabit Speeds from RTL8111/8168B PCI Express Gigabit Ethernet controller on Ubuntu Linux.

This is the kind of thing I had to do 10 years ago. I thought we’d moved on…

Entertain your baby using your Android phone

Last night my friend and I uploaded the first version of Baby Distraction, an Android app featuring charming cartoon animals, vibration and sounds.

I helped almost exclusively in an advisory capacity, but still am inexplicably proud of the result: it’s incredibly simple, but polished, and, most importantly, their baby loves it.

This morning I searched for “baby games” on the Android Marketplace, and it was the top hit. Fame and fortune await.