Notes on programming

I have attempted a number of times to create a pull request from the comfort of Emacs and Magit, with no success yet. The main problem is that I use most of the time my company’s GitHub Enterprise instance, not the public service called github.com. The GitHub service is so ubiquitous that many people forget there are other installations, not seen on the public Internet, where big corporations and hip companies keep their precious, precious code.

This week I finally made progress in setting up the connection.

This is how you can use a function written in D from a Racket script.

In a file called logc.d:

import std.stdio;

extern(C)
void hello()
{
  writeln("hi from D");
}

Compile to a shared library with:

$ ldc2 -shared -m64 logc.d

or with

$ dmd -shared -m64 -fPIC -defaultlib=libphobos2.so logc.d

Use the generated liblogc.so (or liblogc.dylib) from a Racket script:

(require ffi/unsafe)

(define logc-lib (ffi-lib "liblogc"))

(define logc-hello
  (get-ffi-obj "hello" logc-lib
               (_fun -> _void)))

Try the results:

> (logc-hello)
hi from D

This post is based on Call D from Ruby using FFI and tutorial using racket’s ffi

This is a list of practical tasks that I learn in any language. Each point builds more or less on top of the previous ones.

• write a unittest
• read a configuration file
• parse command line arguments
• pass arguments to different functions
• logging
• write to a database
• run concurrent processes
• monitoring of a server process
• reporting/alerting
• create a GUI
• create a web interface
• create a REST interface
• create an installer/deployable app

Is your terminal SBT and your Emacs (or Spacemacs) SBT giving you different results? More confusingly, is SBT doing the correct thing from inside Emacs if Emacs is started from the terminal and not as a GUI application?

This can be caused by Emacs producing its own environment if started as a GUI application! (And you thought all environments were created equal, out of .bashrc or whatever … Nope.)

This new env that Emacs creates for itself is based on … magic, I guess.

In any case, it does not necessarily respect the JAVA_HOME that you carefully set in your normal (terminal) environment.

In order to correct this, add to your init.el (or dotspacemacs/user-init in .spacemacs):

(setenv "JAVA_HOME"
        "/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/")

or whatever it is that JAVA_HOME should point to.

As an alternative, you can set this variable per project by adding a file .sbtopts in the project root with the following:

-java-home /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/

If you have a dodgy source jar file, it will probably blow up the ensime server with java.util.zip.ZipException: error in opening zip file. The solution offered in the project’s Github issue is to delete your local copy of the bad file and add it to the list of excluded classifiers in ivy (i.e. ~/.ivy2/exclude_classifiers), and report the file to the nexus hosts to have it deleted.

Mine is a bit longer …