Posts tagged ‘emacs’

The Hitchhiker’s Guide to an Ioke Dev Env From Source (part 5: Ioke and the REPL)

This is the fifth part in a series of posts for non-experts about setting up an Ioke development environment on Linux. Please see the previous posts to start at the beginning:

This time we will finally get the Ioke source code, build it, and test the Ioke REPL!

Ioke

Ioke uses Git as the source code versioning tool, with a public repository set up on GitHub (soon I’ll be linking like Jeff Atwood).

So – let’s get Ioke using Git by cloning Ola’s repository:

~/bin$ cd ~/work
~/work$ git clone git://github.com/olabini/ioke
Initialized empty Git repository in /home/melwin/work/ioke/.git/
remote: Counting objects: 9221, done.
remote: Compressing objects: 100% (2941/2941), done.
remote: Total 9221 (delta 5782), reused 8656 (delta 5351)
Receiving objects: 100% (9221/9221), 45.95 MiB | 399 KiB/s, done.
Resolving deltas: 100% (5782/5782), done.

Great – let’s quickly move on to the build step:

~/work$ cd ioke
~/work/ioke$ ant
...
     [java] 2606 examples, 0 failures
jar:
      [jar] Building jar: /home/melwin/work/ioke/lib/ioke.jar
 
BUILD SUCCESSFUL
Total time: 22 seconds

Running just ant will execute the default target in the build.xml file. This target will make sure Ioke is compiled and the test suite is run.

At the end is a summary of the test results – if these are not all successful you might have a problem with the environment or you might have checked out a broken build from the repository.

The Ioke REPL

Now all is installed and Ioke is compiled, so let’s fire up the REPL. This is done by just running the main Ioke binary:

~/work/ioke/$ bin/ioke
iik>

When doing this we get the iik> REPL prompt. From here we can execute most Ioke code. Let’s try to print a string:

iik> "Hello World!" println
Hello World!
+> nil
 
iik>

Here we create a Text (Ioke’s string type) literal and send it the message println, which will cause the text to be printed to the console. The return type of println is nil (similar to null), which is printed by the REPL itself. After that we get the prompt back and can execute another line.

Let’s try a little more complex example – the factorial:

iik> fact = method(n, if(n > 1, n * fact(n pred), 1))
+> fact:method(n, if(n >(1), n *(fact(n pred)), 1))

Note how the REPL prints the method definition in a canonical form – it makes it obvious how Ioke parses the code, what are messages and what are arguments.

Let’s run our new factorial function:

iik> fact(3)
+> 6
 
iik> fact(10)
+> 3628800
 
iik> fact(50)
+> 30414093201713378043612608166064768844377641568960512000000000000

Ioke handles arbitrarily big numbers, so we don’t need to think about what fits in a certain number of bits.

The Iik REPL also comes with a simple debugger, which helps with handling conditions. For instance, let’s try to run the fact method, passing a message which doesn’t mean anything (yet):

iik> fact(f)
*** - couldn't find cell 'f' on 'Ground_0xC360E7' (Condition Error NoSuchCell)
 f                                                [<init>:1:5]
The following restarts are available:
 0: storeValue           (Store value for: f)
 1: useValue             (Use value for: f)
 2: abort                (restart: abort)
 3: quit                 (restart: quit)
 
 dbg:1> 1
  dbg:1:newValue> 5
  +> 5
 
+> 120

The above output shows that when we try to reference something that doesn’t exist we get a chance to provide that value. Here I decided to provide a value using the useValue restart and entered the value 5. This let the method continue executing and the result was printed.

To exit the REPL, just type: exit

Next up are the Emacs modes for Ioke – stay tuned!

/M

The Hitchhiker’s Guide to an Ioke Dev Env From Source (part 3: emacs-starter-kit)

This is the third part in a series of posts for non-experts about setting up an Ioke development environment on Linux. Please see the previous posts to start at the beginning:

The emacs-starter-kit is a set of base configuration for Emacs. It contains a number of useful elisp libraries, with a slight focus on dynamic languages.

To install it, perform the following steps (note that we move any existing Emacs configuration out of the way first to avoid stomping what you currently have):

~/work/emacs$ cd
~$ mv .emacs.d .emacs.d.old
~$ mv .emacsrc .emacsrc.old
~$ git clone git://github.com/technomancy/emacs-starter-kit.git .emacs.d

If you now start Emacs again you’ll see that the menu bar and the toolbar is gone. This is the default in emacs-starter-kit as most Emacs users don’t find them useful. For new users the menu bar can sometimes come in handy, to get it back temporarily, just press F1.

Configuring Emacs

If you want to add your own customizations to Emacs when using emacs-starter-kit, just add an Emacs LISP file called username.el, or hostname.el, in the ~/.emacs.d directory. For instance, to make the menu bar always visible:

  1. Open Emacs, if it’s not open already.
  2. Press C-x C-f and type in: ~/.emacs.d/username.el
    Where username is the name you log in with (for instance, in my case the complete filename is melwin.el).
  3. Type in the following in the file:
    (menu-bar-mode 1)
  4. And save the file with C-x s.
  5. Now quit (C-x c) and restart and you’ll see that the menu bar is shown.

Working with Magit

emacs-starter-kit includes, among many other things, the very nice Magit Git mode for Emacs, which gives you a nice interface for working with a Git repository.

Let’s use this mode to commit our recent changes to the configuration file to our local clone of the emacs-starter-kit repository. This helps us track changes we make and also makes a backup of the file in case we screw (sorry, mess) something up.

Note 1: To move easily between Emacs windows using the keyboard, just press Shift and the arrow key pointing in the direction you want to move.
Note 2: To only show the current Emacs window – press: C-x 1

  1. Inside Emacs, press C-x g to run magit-status and enter the directory (note that Tab auto-completes): ~/.emacs.d
    Emacs magit-status
  2. Put the cursor over the username.el in the list of Untracked files.
  3. Press s to Stage the new file – this adds the file to the Git staging area, from which all files are committed.
    Emacs magit-status staged
  4. Press d and then accept to diff against HEAD – this will show you a diff view of the changes we have staged – just the add of a single file.
    Emacs magit-status diff
  5. Press c to perform the commit. This opens a new buffer into which a commit message can be added.
  6. Write something like: Add personal configuration file.
  7. Now press C-c C-c to commit the file.

That’s it – now the change has been committed to the local clone of the emacs-starter-kit Git repository.

To see the log of all commits, press l (lowercase L) in the magit-status buffer:
Emacs magit-status log

To look at a certain commit – just press Enter on it and a view of the diff will be shown. This makes it quite easy to browse through commits in a repository. At the top of the log is the most recent commit, which in this case is the file we just added.

To update emacs-starter-kit with the latest changes in the GitHub repository, just press F in the magit-status buffer or run git pull in the ~/.emacs.d directory.

Summary

Now that we have Git and Emacs set up we can finally move to Ioke. In the next post we’ll go through installing the latest Java JDK and getting and compiling the Ioke source code.

Join me then!

/M

Update: Part 4: Java and Ant

The Hitchhiker’s Guide to an Ioke Dev Env From Source (part 2: Emacs)

This is the second part in a series of posts for non-experts about setting up an Ioke development environment on Linux. Please see the previous post to start at the beginning:

In this post we will install GNU Emacs from source and also get a basic configuration set up using the emacs-starter-kit.

If you already have Emacs installed and have an old configuration laying around you probably want to make a backup of this before following the below instructions. This post assumes that there is no Emacs installed and that the user doesn’t have any Emacs configuration in the home directory.

Installing Emacs

Git is an efficient Distributed Version Control System. Although the primary VCS for Emacs is still CVS – and it looks like they are moving towards Bazaar – we’ll get the Emacs sources from the Emacs Git mirror. We want to be cool, right?

~$ cd work
~/work$ git clone --depth 1 git://git.sv.gnu.org/emacs.git
Initialized empty Git repository in /home/melwin/work/emacs/.git/
remote: Counting objects: 46400, done.
remote: Compressing objects: 100% (24410/24410), done.
remote: Total 46400 (delta 41204), reused 25501 (delta 21836)
Receiving objects: 100% (46400/46400), 74.38 MiB | 213 KiB/s, done.
Resolving deltas: 100% (41204/41204), done.
Checking out files: 100% (2837/2837), done.

With the --depth 1 parameter we limit the history so that we only get the latest version of the files – in this case we’re not interested in the full history.

Note: As we’re getting the bleeding edge source code of Emacs, it could happen that the build is broken. I’ve never had this happen on me, but in case you get strange errors when building Emacs, this might be the reason. Usually such problems are fixed quickly, so try to do a git pull a bit later to update the downloaded source.

Previously, to get fun things like multi-tty support and smooth fonts, we had to get specific feature branches of Emacs. Nowadays, however, all the things we want are merged into the Emacs master branch. Before building, the only thing we need to do is to make sure the necessary development libraries are installed. In case you wonder how I came up with this list: the good ol’ method of trial and error. I simply ran the configure command and checked the error messages. This helped me identify the needed libraries. Now you can reap the benefits by just doing the following:

~/work$ sudo apt-get install libgtk2.0-dev libxpm-dev libjpeg-dev libgif-dev libtiff-dev
...

… and then run the classical configure, make and make install:

~/work$ cd emacs
~/work/emacs$ ./configure --prefix=$HOME/opt/emacs-23.0.60
...
~/work/emacs$ make
...
~/work/emacs$ make install
...

Phew. That burned som CPU cycles…! Once done – let’s add it to our bin directory, just as we did with Git.

~/work/emacs$ cd ~/bin
~/bin$ ln -s ../opt/emacs-23.0.60/bin/emacs
~/bin$ ln -s ../opt/emacs-23.0.60/bin/emacsclient
~/bin$ ls
emacs  emacsclient  git

Time to test. Just run emacs:

~/bin% emacs

This should show you an Emacs window with a pretty(?) GNU.

Emacs Window

If you’re completely new to Emacs, this might be a good opportunity to run the Emacs tutorial. Emacs is a self-documenting editor, which means that most things that you might want to learn about Emacs can be found inside the editor itself – including information about internal functions and libraries.

To run the tutorial, just press Ctrl+h t (that is, control and h, release control, then press t), or, in Emacs lingo, C-h t (which is the convention I’ll use from now on).

Once you’ve learned enough (you did complete the whole thing, right?), just quit using C-x c.

Note: To update the source code and rebuild, do a git pull in the emacs directory, then make distclean (in case some build files changed) and then perform the compile and installation as per the above again.

Next up is emacs-starter-kit to get more functionality in Emacs and a decent default configuration to help us get going – stay tuned!

/M

Update: Part 3: emacs-starter-kit