Planet Lang

Rob Warnock shares some Lisp-helpful vi settings and Mikael Jansson gives you Lisp argument lists in vim.

Following up to the previous post, with the usual caveat about needing to put spaces around angle-brackets for the syntax highlighter, with this script Timestamp.fsx

#light open System
open System.IO let format = "#light
open System.Reflection;
open System.Runtime.CompilerServices;
open System.Runtime.InteropServices; // General Information about an assembly is controlled through the following set of attributes.
[< assembly: AssemblyTitle(\"your assembly name\") >]
[< assembly: AssemblyDescription(\"\") >]
[< assembly: AssemblyConfiguration(\"\") >]
[< assembly: AssemblyCompany(\"Your co.\") >]
[< assembly: AssemblyProduct(\"Your product\") >]
[< assembly: AssemblyCopyright(\"Copyright © you, 2009\") >]
[< assembly: AssemblyTrademark(\"\") >]
[< assembly: AssemblyCulture(\"\") >] [< assembly: ComVisible(false) >] [< assembly: AssemblyVersion(\"1.0.{0}\") >]
[< assembly: AssemblyFileVersion(\"1.0.{1}\") >]
()" let now = DateTimeOffset.UtcNow
let epoch = new DateTimeOffset(2000, 1, 1, 0, 0, 0, new TimeSpan(int64 0))
let diff = now.Subtract(epoch)
let fraction = diff.Subtract(TimeSpan.FromDays(float diff.Days))
let revision= ((int fraction.TotalSeconds) / 2)
let version = String.Format("{0}.{1}", diff.Days, revision) File.WriteAllText ("AssemblyInfo.fs", String.Format (format, version, version))

suitably adjusted to taste in your main project folder, and a pre-build step of

cd ..\..
"C:\Program Files\FSharp-1.9.6.2\bin\fsi.exe" --exec Timestamp.fsx

you can get an automatically timestamped assembly, as per a C# 1.0.* version.

Note that using [< assembly: AssemblyVersion(\"1.0.*\") >] gives an assembly version of 0.0.0.0 in the DLL manifest, and no file version whatsoever.

You will have to bootstrap the process by creating a dummy AssemblyInfo.fs, and adding it to the project -- but of course not checking it in to source control or anything like that, since it is recreated every build.

Erlang Exposed! Chris Williams from NOVAlanguages (http://tinyurl.com/9o859p) will be giving an intro to Erlang and will describe what makes it so cool. You'll learn how the Erlang Concurrency Model allows for robust multiprocessor and distributed computing. As an opening presentation, Conrad Barski will present some new software written in Arc Lisp for automated cartoon cell colorization. Afterwards, we'll head over to a Mongolian Grill for some beer and conversation.

The meeting is generously hosted by Clark & Parsia (http://tinyurl.com/6wmmbj) located at 926 N St NW REAR Studio #1 Washington DC and is near the Convention Center Metro Stop. (Map http://tinyurl.com/7mbc4o) Anyone is welcome to join our meetings!

FringeDC is a programming group in Washington DC interested in Functional and Fringe programming languages (Lisp, Haskell, Erlang, etc) http://lisperati.com/fringedc.html

1. we have a List with some String values abstracted in different forms


2. need to iterate over the list


3. do some stuff with elements in the list and compute an Int value

nqueens n = exist n $ \queens -> model queens n /\
 enumerate queens

model queens n = queens ‘allin‘ (1,n) /\ 
 alldifferent queens /\ 
 diagonals queens
 
allin queens range = conj [q ‘in_domain‘ range | q - queens ] 
alldifferent queens = conj [ qi @\= qj | qi:qjs - tails queens,
 qj - qjs ]

diagonals queens = conj [ qi @\== (qj @+ d) /\ qj @\== (qi @+ d)
 | qi:qjs - tails queens, (qj,d) - zip qjs [1..]]

conj = foldl (/\) true 

enumerate = Lazy . (label firstfail middleout)

> solve dfs it $ nqueens 4
[[2,4,1,3],[3,1,4,2]]

The search strategy used above is depth-first search (dfs) without
any additional search transformers (i.e. identity transformer it).
Here are three variations, using alternative search strategies:

> solve dfs (nb 100 :- db 25 :- bb newBound) $ nqueens 4
> solve bfs (db 25 :- nb 100 :- bb newBound) $ nqueens 4
> solve bfs (ld 10 :- nb 100 :- bb newBound) $ nqueens 4

• bfs is the breadth-first queueing strategy,


• nb n stops search after visiting n nodes in the search tree,


• dbn does not visit nodes below depth n in the search tree,


• ld n does not visit nodes that are more than n right branches from the root of the search tree (limited discrepancy), and


• bb newBound is branch-and-bound optimization (in this example the value of the last queen is minimized; makes more sense for other problems).

• Draft paper
• Prototype code (requires GHC >= 6.10)
  

Our .NET PDF Toolkit, in 100% F#, cross-compiled with OCaml is now available, starting at £495. It does everything the command line tools do, and more, but is usable natively from VB.NET, C# and ASP.NET.

At the same time, we’ve updated the Command Line Tools (written in pure OCaml) with bug fixes and new features, and now provided for Solaris 10 Sparc and Intel out of the box.

The codebase of about 40,000 lines ended up requiring only 30 points at which conditional compilation was needed to cover the differences between F# and OCaml, though plenty of code had to be modified to compile in both environments in a way that didn’t require conditional compiltion.

There will be a new release of CamlPDF soon, which will have many new features, and which will cross-compile with F# out of the box.

Since its relaunch, Planet Erlang is now indexing content from tens of Erlang related blogs. Thank to its search engine, you can now find many blog posts and articles on lots of different Erlang topic. ejabberd is one of the most covered topic there.

You should have a look and try searching for ejabberd in the search engine (search field on the right).

The list of resources is growing every day as we are adding even more older resources.

Your comments and feature requests are welcome !

November and december have been busy months and time was short to find enough time to write about VSLab. However, things are going on and we are planning a new release of VSLab soon. The major contribution is from Giacomo Righetti, who has spent time for building a framework of lightweight controls using a former definition from me. Lightweight controls are missing from Windows Forms, and now you can have them in F# (and .NET languages). Giacomo implemented a set of predefined controls such as buttons, scrollbars, and many others so that viewlet development becomes easier. The VSLab shell project is also going on, and actually I have configured my Acer aspire one to start VSLab as a system shell :) I don't really miss Windows explorer... (ok, ok, I know I'm a little bit biased!).

cc004.hs:16:0:
 calling convention not supported on this architecture: stdcall
 When checking declaration:
 foreign import stdcall safe "static &p" m_stdcall
 :: StablePtr a -> IO (StablePtr b)

-- Floating point assignment to a register/temporary
-- ToDo: Verify correctness 
assignReg_FltCode :: Size -> CmmReg -> CmmExpr -> NatM InstrBlock
assignReg_FltCode pk reg src = do ...

Configuring stage 1 in sparc-sun-solaris2.10/libgcc
...
checking for suffix of object files... configure: error: cannot compute
suffix of object files: cannot compile.

/home/benl/files/gcc/build/gcc-4.3.2-obj/./gcc/xgcc ...
conftest.c:1: internal compiler error: Segmentation Fault
Please submit a full bug report,

config.status: executing gstdint.h commands
make[3]: Entering directory `/home/benl/files/gcc/build/gcc-4.2.4-obj/libdecnumber'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/benl/files/gcc/build/gcc-4.2.4-obj/libdecnumber'
make[3]: Entering directory `/home/benl/files/gcc/build/gcc-4.2.4-obj/gcc'
make[3]: *** No rule to make target `all'. Stop.
make[3]: Leaving directory `/home/benl/files/gcc/build/gcc-4.2.4-obj/gcc'

One of the features that the Groovy people like to flaunt is the joint compilation of .groovy and .java files.  This is a fantastically powerful concept which (among other things) allows for circular dependencies between Java, Groovy and back again.  Thus, you can have a Groovy class which extends a Java class which in turn extends another Groovy class.

All this is old news, but what you may not know is the fact that Scala is capable of the same thing.  The Scala/Java joint compilation mode is new in Scala 2.7.2, but despite the fact that this release has been out for more than two months, there is still a remarkable lack of tutorials and documentation regarding its usage.  Hence, this post…

For starters, you need to know a little bit about how joint compilation works, both in Groovy and in Scala.  Our motivating example will be the following stimulating snippet:

// foo.scala
class Foo
 
class Baz extends Bar

…and the Java class:

// Bar.java
public class Bar extends Foo {}

If we try to compile foo.scala before Bar.java, the Scala compiler will issue a type error complaining that class Bar does not exist.  Similarly, if we attempt the to compile Bar.java first, the Java compiler will whine about the lack of a Foo class.  Now, there is actually a way to resolve this particular case (by splitting foo.scala into two separate files), but it’s easy to imagine other examples where the circular dependency is impossible to linearize.  For the sake of example, let’s just assume that this circular dependency is a problem and cannot be handled piece-meal.

In order for this to work, either the Scala compiler will need to know about class Bar before its compilation, or vice versa.  This implies that one of the compilers will need to be able to analyze sources which target the other.  Since Scala is the language in question, it only makes sense that it be the accommodating one (rather than javac).

What scalac has to do is literally parse and analyze all of the Scala sources it is given in addition to any Java sources which may also be supplied.  It doesn’t need to be a full fledged Java compiler, but it does have to know enough about the Java language to be able to produce an annotated structural AST for any Java source file.  Once this AST is available, circular dependencies may be handled in exactly the same way as circular dependencies internal to Scala sources (because all Scala and all Java classes are available simultaneously to the compiler).

Once the analysis phase of scalac has blessed the Scala AST, all of the Java nodes may be discarded.  At this point, circular dependencies have been resolved and all type errors have been handled.  Thus, there is no need to carry around useless class information.  Once scalac is done, both the Foo and the Baz classes will have produced resultant Foo.class and Baz.class output files.

However, we’re still not quite done yet.  Compilation has successfully completed, but if we try to run the application, we will receive a NoClassDefFoundError due to the fact that the Bar class has not actually been compiled.  Remember, scalac only analyzed it for the sake of the type checker, no actual bytecode was produced.  Bar may even suffer from a compile error of some sort, as long as this error is within the method definitions, scalac isn’t going to catch it.

The final step is to invoke javac against the .java source files (the same ones we passed to scalac) adding scalac’s output directory to javac’s classpath.  Thus, javac will be able to find the Foo class that we just compiled so as to successfully (hopefully) compile the Bar class.  If all goes well, the final result will be three separate files: Foo.class, Bar.class and Baz.class.

Although the concepts are identical, Scala’s joint compilation works slightly differently from Groovy’s from a usage standpoint.  More specifically: scalac does not automatically invoke javac on the specified .java sources.  This means that you can perform “joint compilation” using scalac, but without invoking javac you will only receive the compiled Scala classes, the Java classes will be ignored (except by the type checker).  This design has some nice benefits, but it does mean that we usually need at least one extra command in our compilation process.

All of the following usage examples assume that you have defined the earlier example in the following hierarchy:

• src
• main
• java
• Bar.java
• scala
• foo.scala
• target
• classes

# include both .scala AND .java files
scalac -d target/classes src/main/scala/*.scala src/main/java/*.java javac -d target/classes -classpath $SCALA_HOME/lib/scala-library.jar:target/classes src/main/java/*.java

<target name="build"> <scalac srcdir="src/main" destdir="target/classes"> <include name="scala/**/*.scala"/> <include name="scala/**/*.java"/> </scalac>
  <javac srcdir="src/main/java" destdir="${scala.library}:target/classes" classpath="target/classes"/>
</target>

One thing you gotta love about Maven: it’s fairly low on configuration for certain common tasks.  Given the above directory structure and the most recent version of the maven-scala-plugin, the following command should be sufficient for joint compilation:

mvn compile

Unfortunately, there have been some problems reported with the default configuration and complex inter-dependencies between Scala and Java (and back again).  I’m not a Maven…maven, so I can’t help too much, but as I understand things, this POM fragment seems to work well:

<plugin> <groupId>org.scala-tools</groupId> <artifactId>maven-scala-plugin</artifactId>
  <executions> <execution> <id>compile</id> <goals> <goal>compile</goal> </goals> <phase>compile</phase> </execution>
  <execution> <id>test-compile</id> <goals> <goal>testCompile</goal> </goals> <phase>test-compile</phase> </execution>
  <execution> <phase>process-resources</phase> <goals> <goal>compile</goal> </goals> </execution> </executions>
</plugin>
 
<plugin> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.5</source> <target>1.5</target> </configuration>
</plugin>

You can find more information on the mailing-list thread.

Joint compilation for mixed Scala / Java projects has been a long-standing request of mine in Buildr’s JIRA.  However, because it’s not a high priority issue, the developers were never able to address it themselves.  Of course, that doesn’t stop the rest of us from pitching in!

I had a little free time yesterday afternoon, so I decided to blow it by hacking out a quick implementation of joint Scala compilation in Buildr, based on its pre-existing support for joint compilation in Groovy projects.  All of my work is available in my Buildr fork on GitHub.  This also includes some other unfinished goodies, so if you want only the joint compilation, clone just the scala-joint-compilation branch.

Once you have Buildr’s full sources, cd into the directory and enter the following command:

rake setup install

You may need to gem install a few packages.  Further, the exact steps required may be slightly different on different platforms.  You can find more details on Buildr’s project page.

With this highly-unstable version of Buildr installed on your unsuspecting system, you should now be able to make the following addition to your buildfile (assuming the directory structure given earlier):

require 'buildr/scala'
 
# rest of the file...

Just like Buildr’s joint compilation for Groovy, you must explicitly require the language, otherwise important things will break.  With this slight modification, you should be able to build your project as per normal:

buildr

This support is so bleeding-edge, I don’t even think that it’s safe to call it “pre-alpha”.  If you run into any problems, feel free to shoot me an email or comment on the issue.

Joint compilation of Java and Scala sources is a profound addition to the Scala feature list, making it significantly easier to use Scala alongside Java in pre-existing or future projects.  With this support, it is finally possible to use Scala as a truly drop-in replacement for Java without modifying the existing infrastructure beyond the CLASSPATH.  Hopefully this article has served to bring slightly more exposure to this feature, as well as provide some much-needed documentation on its use.

Just a small selection from the last week or so, and not even trying to keep up with PoSh v2CTP3 goodness -- I will be so pleased when that gets to go-live state!

AssemblyInfo.fs usage for F# DLLS and console executables. Note that the ability to default build and revision numbers as in [<assembly: AssemblyVersion("1.0.*")>] is not provided for you -- time-stamping has to be done externally e.g. by a pre-build step.

Generics in XAML.

Avoiding deadlocks when redirecting stdin/out/err for spawned processes in .Net code.

Speech recognition with .Net 3 and speech synthesis too!