Planet Lisp
March 18, 2010
18:00
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.
March 17, 2010
22:19
[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
14:47
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.
07:10
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.
March 16, 2010
12:10
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.
March 15, 2010
14:56
[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.
March 11, 2010
11:19
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.
March 10, 2010
March 9, 2010
March 7, 2010
March 6, 2010
04:54
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!
March 5, 2010
20:59
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
06:20
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.
March 1, 2010
11:07
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.
February 28, 2010
18:00
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.
February 22, 2010
05:12
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!
February 19, 2010
04:02
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.
February 18, 2010
10:53
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
|
Recent comments
13 hours 45 min ago
19 hours 59 min ago
3 days 8 hours ago
3 days 23 hours ago
4 days 17 hours ago
6 days 8 hours ago
1 week 2 days ago
1 week 2 days ago
1 week 3 days ago
1 week 4 days ago