SICStus Prolog Compile Error Regexp

compilation-error-regexp-alist is used to parse the *compilation* buffer, and allow you to jump from compile error messages directly to the problem in the source line

(require ‘compile)

(add-to-list ‘compilation-error-regexp-alist

‘(sicstus “^!\\(.\\|\n\\)*Approximate lines: \\([0-9]+\\)-[0-9]+, file: ‘\\(.*?\\)’$” 3 2))


Vagrant for impatient

Vagrant manages VMs.

Vagrant executes Ruby scripts for that.

You should buy VMware provider if you do any serious work because for one VirtualBox is slow.

Don’t worry, you can get your $79 for VMware provider back in 30 days.

Box is a directory with either VMware or VirtualBox files. Most(?) boxes are for VirtualBox only. This is output of “vagrant up” for such a box

The box you’re attempting to add doesn’t support the provider

you requested.


Requested provider: [“vmware_desktop”, “vmware_fusion”, “vmware_workstation”]

Oh, vmware provider is default after the installation. Use “vagrant up –provider=” to override.

How to convert VirtualBox to VMware

Get box files from Atlas. Atlas is where all boxes are stored

vagrant box add deb/jessie-amd64

Navigate to “~/.vagrant.d/boxes”

You’ll find directory corresponding to that box there.

Import *.ovf file into VMware i.e. lunch VMware and Import… VMware would complain that *.ovf does not comply. Let it relax the requirements.

Run the VM.

Install VMware tools. Otherwise you’ll stuck at this:

…Waiting for HGFS kernel module to load

Again, “Show package content” for VMware Fusion application. Locate “linux.iso” there.

Attach it to the VM. Mount and install vmware tools

$ sudo mount /media/cdrom

$ cd /media/cdrom

$ sudo apt-get install linux-headers-X.Y.Z

$ sudo ./vmTAB

Be sure to check that HGFS was built successfuly

Also, say “yes” to VMware kernel module auto loading (won’t hurt but gets vagrant’s other shit solved)

You are almost there.

Now. Under “~/.vagrant.d/boxes/that-box” locate directory “virtualbox”

Keep “metadata.json” & “Vagrantfile” from that directory

Rm that directory

Create a new one instead “vmware_fusion” and copy over content of the box VM which is up in VMware Fusion where you have just installed the vmware tools…

Copy metadata & Vagrant there too

You are Gucci now!

Try firing “vagrant up” in some project directory which uses that box i.e. Vagrantfile contains = “deb/jessie-amd64”

Try “vagrant ssh” to get in. Find your stuff under “/vagrant” there

Choosing a practical functional language (WIP)

I initially picked OCaml for my commercial project because

  • it’s imperative
  • fast
  • number of promising libraries were already written in OCaml (it’s a security project)

OCaml turned out to be a poor choice. It’s a “better C” language.

OCaml Haskell
Has fast FFI Yes Yes
Preemptive MT No Yes
Build system? No Yes
QuickCheck No Yes
(Referential transparency) No Yes

Both OCaml & Haskell can interface C at the overhead similar to inline call.

OCaml lacks preemptive multi threading. It’s foreign calls would block runtime system. To make it work with rest of application polling should be used (say OCaml goes to a plugin) Both are ugly

OCaml build system is behind Cabal. It’s impossible to mix C sources and OCaml in one shared library for instance without writing a plugin for ocamlbuild (which in turn is poorly documented)

Imperative programming promised to be a good way to make shortcuts for fast implementation of my project. In long run its bad too. Because of that there is no QuickCheck for OCaml.

Lack of referential transparency renders refactoring not safe. Again, slows down development

Bonus. Oh, did I mention CircleCI provides continuous integration for Haskell (Cabal) out of the box? smile

How to get minor GHC version from custom Setup.hs

Haskell Cabal is an advanced build system which can produce self contained shared library with few lines.
It’s necessary to list GHC’s runtime system to be able to dlopen the library:

  ghc-options: -threaded
  extra-libraries: HSrts-ghc7.10.2

-threaded is there to use the FFI in a multi-threaded setting which is usually the case.

Name of the library produced by GHC changes from build to build (due to “hash” being attached?)

Shared libraries are commonly used as a plugins. Other naming convention can be implemented at a postBuild hook in custom Setup.hs e.g. by renaming the library.

The tricky part comes when we need to figure out that “hash”.

We could use mkSharedLibName of Distribution.Simple.BuildPaths but that uses System.Info.compilerVersion internally which does not report minor version of GHC (that’s by design)

To address that this quick workaround will suffice for me for now. Get GHC version from Cabal:

 Just loc <- findProgramOnSearchPath normal defaultProgramSearchPath (programName ghcProgram)
 Just (Version { versionBranch = [g,h,c] }) <- programFindVersion ghcProgram normal loc

And re-write mkSharedLibName using g,h,c instead of CompilerId which is left as an exercise blink

I wonder what that “hash”‘s all about…