End the War on Freedom

Also, Laser Spigot! And XIOTANK!

As promised my UCT implementation is released, albeit somewhat belatedly. It's in Micmac v0.0.1, see test/test-uct.lisp for an example. Now I only owe you Alpha-beta.

[from a email note from Marc Battyani] There are some positions for Common Lisp internships at HPC Platform in Boston and Paris. Some full time positions will be available in Boston in the next months. HPC Platform makes the fastest hardware (FPGA) based processing systems on the planet and for that we develop domain specific compilers and other tools written in Common Lisp (Lispworks on Linux). We are looking for people knowing Common Lisp and preferably topics like compilation, code generation, VHDL, FPGA, networking, optimization, statistics and more. http://www.hpcplatform.com is rather outdated but gives an idea of what we do. Contact marc.battyani@hpcplatform.com for more details. Thanks, Marc

Things are beginning to take shape for the European Lisp Symposium (May 6-7, Lisbon): I'm glad to say that the review process is over and the preliminary programme is now available. The symposium website has also undergone a facelift: out with the spartan, old-school look, and in with the tasteful and functional; Edgar Gonçalves put the new look and content together in very short order, so thanks to him; thanks also to the event's supporters. The final organizational details are being sorted out, and registration should be open very soon.

cl2md is a quick hack inspired by pbook.el (which you should check out if you've never heard of it and are an Emacs user since it marks up the source code much nicer).The page "cl2md" in the previous paragraph links to is the actual source code file which has been run through itself and a Markdown converter.

A few years back (for a very generous few), we needed to parse a wide variety of XML strings. It was quite tedious to go from the XML to the native-language representations of the data (even from a DOM version). Furthermore, we needed to parse this XML both in Java and in C++. I wrote (in Java) an XML parser generator that took an XML description of how you’d like the native-language data structures to look and where in the XML it could find the values for those data structures. The Java code-base for this was ugly, ugly, ugly. I tried several times to clean it up into something publishable. I tried to clean it up several times so that it could actually generate the parser it used to read the XML description file. Alas, the meta-ness, combined with the clunky Java code, kept me from completing the circle. Fast forward to last week. Suddenly, I have a reason to parse a wide variety of XML strings in Objective C. I certainly didn’t want to pull out the Java parser generator and try to beat it into generating Objective C, too. That’s fortunate, too, because I cannot find any of the copies (in various states of repair) that once lurked in ~/src. What’s a man to do? Write it in Lisp, of course. Example Here’s an example to show how it works. Let’s take some simple XML that lists food items on a menu:         name="Belgian Waffles" price="$5.95" calories="650"                 two of our famous Belgian Waffles with plenty of real maple syrup                 We craft an XML description of how to go from the XML into a native representation: root="menu" from="/menu"   name="food item"     type="string" name="name" from="@name" />     type="string" name="price" from="@price" />     type="string" name="description" from="/description/." />     type="integer" name="calories" from="@calories" />     name="menu"     name="menu items"               type="food item" from="/food" />             Now, you run the parser generator on the above input file: % sh parser-generator.sh --language=lisp \                            --types-package menu \                            --reader-package menu-reader \                            --file menu.xml This generates two files for you: types.lisp and reader.lisp. This is what types.lisp looks like: (defpackage :menu   (:use :common-lisp)   (:export #:food-item              #:name              #:price              #:description              #:calories            #:menu              #:menu-items)) (in-package :menu) (defclass food-item ()   ((name :initarg :name :type string)    (price :initarg :price :type string)    (description :initarg :description :type string)    (calories :initarg :calories :type integer))) (defclass menu ()   ((menu-items :initarg :menu-items :type list :initform nil))) I will not bore you with all of reader.lisp as it’s 134 lines of code you never had to write. The only part you need to worry about is the parse function which takes a stream for or pathname to the XML and returns an instance of the menu class. Here is a small snippet though: ;;; ================================================================= ;;; food-item struct ;;; ================================================================= (defmethod data progn ((handler sax-handler) (item food-item) path value)   (with-slots (name price description calories) item     (case path       (:|@name| (setf name value))       (:|@price| (setf price value))       (:|/description/.| (setf description value))       (:|@calories| (setf calories (parse-integer value)))))) Where it’s at I currently have the parser generator generating its own parser (five times fast). I still have a little bit more that I’d like to add to include assertions for things like the minimum number of elements in an array or the minimum value of an integer. I also have a few kinks to work out so that you can return some type other than an instance of a class for cases like this where the menu class just wraps one item. My next step though is to get it generating Objective C parsers. Somewhere in there, I’ll post this to a public git repository.

[Not a Lisp job, but supporting a major Lisp provider] Franz Inc. is the provider of Allegro Common Lisp and associated products.  We are looking for a qualified applicant to help with the following responsibilities: * IT administration and maintenance of internal computer systems. Possible tasks could include: - hardware and software upgrades of Linux or Windows servers - hardware and (system) software troubleshooting - virtualization of existing servers - network management - attending to backups Experience in the following areas would therefore be valuable: * Linux installation and administration – shell scripting, perl, NFS, autofs, DNS, DHCP, SMTP, Samba, iptables, RAID and LVM. * Windows (2000 and later). * Mac OS X experience is a plus. This is a part-time position.  Ideally, it would be 20 hours per week spread over 3 days (M-F).  This position is office-based and not eligible for telecommuting. If you feel you are a good match for the above, please send a letter of interest and your resume to hrbox at franz dot com.  EOE.

http://careers.northropgrumman.com/tasc/getJobPostDetail.do?sequenceNumber=197279 Title: Engineer Software 3 Category: Technical Services/Operations Location: Falls Church, VA / USA |   Sector: TASC Posting ID:  TA/106202 Description: TASC Inc is seeking to fill a Software Developer to support design and development application software for the Army Intelligence Master Plan program. Desired skills include working knowledge of structure and semantics of Army Corporate databases; experience in designing and developing applications for both browser delivery and selected other client options. Familiarity with Lisp system development and source tracking tools, as well as, CL-HTTP or Allegro-Serve are a plus. Requires Bachelors Degree and 5+ years experience designing and developing Object Oriented Systems using ANSI Common Lisp language. 9 years experience in lieu of degree. Applicant selected will be subject to a security investigation and must meet eligibility requirements for access to classified information. U.S. citizenship and DoD/Secret security clearance required. TS/SSBI preferred. Security Clearance Required.

Sorry for the CamelCase but I didn't come up with the names :-)For those bitten by the game AI bug since the Google AI Challenge (all eleven of us) I've started working on a Common Lisp (CL) client for the StarCraft ProxyBot with the StarCraft AI competition in mind: http://github.com/aerique/cl-starcraft-proxybot.The project is still in its early stages but the important groundwork is done: commands can be send to in-game units.Before this project I started working on a CL client for GameBots 2004 with which one can control an Unreal Tournament 2004 avatar.  The project's stalled for now and hasn't come much farther than setting up the initial connection but for those interested it is here: http://www.aerique.net/software/.Lastly for those interested in game AI: TAEB is on my radar.  See also this excellent blog post: Planar - a TAEB AI.

Lisp/Act-R experience “strongly preferred.” Air-traffic control research.

I posted about Common Lisp messaging libraries before, so I'm happy to see that James Anderson has recently released de.setf.amqp, a native Common Lisp AMQP client. (thanks to Vitaly Mayatskikh for the heads-up).

Together with Juan Jose Garcia-Ripoll, I worked on improving the integration of ECL into Slime.He did a tremendous job on the ECL side adding all the stuff that's needed for a well-working swank backend, so if you're going to try out ECL with Slime, and are pleasantly surprised, please direct most of the gratitude towards him.I threw out backwards compatibility, and you really have to get the 10.3.1 release otherwise the CVS of Slime will refuse to compile. There's no point in artificially maintaining backwards compatibility for something which barely worked.Most noteworthy is the fact that you can now M-. all the way down, that is not just into the Lisp source base of ECL, but also into the C source base. And because it's based on TAGS file, M-. (and M-*) will continue to work once in a .c file. For illustration, I created an animated screenshot. (Blogspot seems to convert uploaded images into the PNG format which is the reason that I have to externally link to animated gifs rather than include them into by blog posting proper.)There's of course still stuff to do:

• storing arglist information for user-written functions
• storing source-location information for each method of a gf
• introspection into C objects

Especially the last thing would be rather cool. And while I think the first two items are on Juanjo's agenda, the last item needs some brave hero looking for fame and glory. In case you want to volunteer, drop a mail to the ECL mailing list!

This release has three important focuses: performance improvements in various fronts (garbage collection and hash tables), extending the run-process function and important fixes to let ECL work better with Slime. Note however that now at least Slime from last week's CVS is needed and that future versions of Slime will require at least this version of ECL to work.See file src/CHANGELOG or browse it online http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/CHANGELOG?view=markupDownloading ECL: http://ecls.sf.net/download.html

In December 2009, Stas Boukarev and myself added some really cool stuff to the slime-asdf contrib, and while I've always wanted to blog about it, I just haven't come around doing so.

• M-x slime-load-system (,load-system): Compile and load an ASDF system; that command currently hooks into the Slime compilation-notes machinery, so compilation notes, warnings, etc. will be collected and will end up in the *SLIME Compilation* buffer. This command has always been there, I just mention it for sake of completeness.

• M-x slime-open-system (,open-system): Open all the files specified in the system.

• M-x slime-isearch-system and M-x slime-rgrep-system: Run the command isearch and rgrep respectively on all the files specified in a system. That is particularly useful if slime-edit-definitions (M-.) and slime-edit-uses (M-?) won't do.In case of slime-rgrep-system, the commands next-error and previous-error will jump through the matches in the *grep* buffer. I bound those commands to F11 and F12, though by default they're also bound to M-g p and M-g n (also C-x `).

• M-x slime-query-replace-system: Poor man's refactoring tool; run query-replace on all the specified files in a system. See this animated screenshot for an exemplary run. (Animated gif was generated on behalf of Zach Beane's Skippy library!)

• M-x slime-query-replace-system-and-dependents: Like the former function, but also run query-replace on all the files of all systems depending on the user-queried system.

The latter two functions are really useful if you're past the initial state of something -- your system already grew to multiple files -- but still away from finishing and so you often want to rename identifier and slightly change APIs.

Yesterday, I was compiling a function in SLIME, and I consistently got error: illegal function call messages from SBCL. The function was a pretty complicated one, and I couldn't figure out the error. I even resorted to commenting out sections, until I had an empty shell, with only the docstring. Then realization dawned — here is a simplified example of how the function looked like: (defun foo (bar) "Docstring, followed by accidental dot". (let ((baz (1+ bar))) baz)) Did you notice the dot? I didn't, for a while (guess I should take breaks every hour or so and rest my eyes, especially in the evening). But the reader did.

I released Parenscript 2.1 (Parenscript now has real version numbers!) this week. Check out the updated reference manual.Eager Future also got a new release making it optionally eager (by popular demand).Paddy Mullen decided to take over css-lite development. His fork includes new features and actual code examples. You can find it on github (ASDF-installable package coming soon): http://github.com/paddymul/css-liteThomas de Grivel forked uri-template: cl-uri-templates adds the substitution operators introduced in the third draft of the URI Template proposal. I think they are quite horrible and so have abstained from implementing them.

For what has been a fun ride the official results are now available. In the end, 11th out of 700 is not too bad and it's the highest ranking non-C++ entry by some margin. I entered the contest a bit late with a rather specific approach in mind: UCT, an algorithm from the Monte Carlo tree search family. It has been rather successful in Go (and in Hex too, taking the crown from Six). So with UCT in mind, to serve as a baseline I implemented a quick minimax with a simple territory based evaluation function ... that everyone else in the competition seems to have invented independently. Trouble was looming because it was doing too well: with looking ahead only one move (not even considering moves of the opponent) it played a very nice positional game. That was the first sign that constructing a good evaluation function may not be as hard for Tron as it is for Go. But with everyone else doing minimax, the plan was to keep silent and Monte Carlo to victory. As with most plans, it didn't quite work out. First, to my dismay, some contestants were attempting to do the same and kept advertising it on #googleai, second it turned out that UCT is not suited to the game of Tron. A totally random default policy kept cornering itself in a big area faster than another player could hit the wall at the end of a long dead end. That was worrisome, but fixable. After days of experimentation I finally gave up on it deciding that Tron is simply too tactical - or not fuzzy enough, if you prefer - for MC to work really well. Of course, it can be that the kind of default policies I tried were biased (a sure thing), misguided and suboptimal. But then again, I was not alone and watched the UCT based players struggle badly. In the final standings the highest ranking one is jmcarthur in position 105. One of them even implemented a number of different default policies and switched between them randomly with little apparent success. Which makes me think that including a virtual strategy selection move at some points in the UCT search tree should be interesting, but I digress. So I went back to minimax, implemented Alpha-beta pruning with principal variation, and iterative deepening. It seemed to do really well on the then current maps whose size was severely reduced to 15x15 to control the load on the servers. Then I had an idea to explore how the parities of squares in an area affect the longest path possible which was quickly pointed out to me over lunch by a friend. And those pesky competitors have also found and advertised it in the contest forum. Bah. There were only two days left at this point and I had to pull an all nighter to finally implement a graph partitioning idea of mine that unsurprisingly someone has described pretty closely in the forum. At that point, I finally had the tool to improve the evaluation function but neither much time or energy remained and I settled for using it only in the end game where the players are separated. The code itself is as ugly as exploratory code can be, but in the coming days I'll factor the UCT and the Alpha-beta code out.

Stefan Richter, our speaker at the February Berlin Lispers Meetup, has made the slides of his presentation available on line. Enjoy, and see you next week!

Date: Saturday, 2010-02-27 Time: 12:30 Venue: In and around the Metalab, Rathausstrasse 6, Vienna (map) I’m pleased to announce the first international totally informal lisp meeting in Vienna. A bunch of Lisp hackers are coming to here on the 27th, and we will meet, talk and hack in and around the Metalab. The approximate schedule is as follows: 12:30 - Lunch at Fromme Helene. There is a table reserved for 15 persons (we’re 5 confirmed hackers at the moment). If you want in, drop me a line. ~14:30 - Reconvene at the Metalab for hacking/coffee/cold drinks/(optional) lightning talks Hackers who have confirmed they’ll be there, so far:

• Tobias C. Rittweiler
• Luke Gorrie
• Stelian Ionescu
• Attila Lendvai
• Gábor Melis
• Mark Evenson

Thanks to the SBCL team for infusing this event with positive energy. SBCL: Harming the software industry since 1999.

Clojure / Lisp Developers wanted in Sunny South Florida Our customer located in the Ft. Lauderdale area is looking for fulltime employees to join their team as Clojure Developers. Position involves web application development for mobile devices. Will develop algorithms and artificial intelligence. Required skills: Strong mathematical and analytical skills Clojure experience or Lisp and Java experience would be ideal. Perl experience is an added plus. Seeking professional developers, but if your Lisp or Clojure, or Perl experience is a hobby that will be considered. If you are interested please send your resume to pkincer@comsys.com or call me at 954-382-5624 Paul Kincer