Previous 10 | Next 10

Oct. 24th, 2013

Clozure CL and Mavericks/Xcode 5

Here's some helpful info from rme:
From: "R. Matthew Emerson"
Subject: [Openmcl-devel] ccl and recent Apple updates
To: openmcl-devel Development
Date: Thu, 24 Oct 2013 13:49:11 -0400

Some people have reported problems building ccl after updating to Xcode 5, or after updating to OS X Mavericks.

The version of Subversion that is included with Xcode 5 uses a new working copy format. Past versions of Subversion would upgrade working copies automatically and silently, but this time, the Subversion developers decided to require manual intervention.

Go to your ccl directory and run "svn update" by hand, and note that it prints out a message prompting you to run "svn upgrade". Run "svn upgrade" as it prompts.

On OS X Mavericks, it appears that installing Xcode does not install include files in /usr/include. It used to be the case that you could solve this problem by downloading the Command Line Tools from Xcode's preference panel. On Mavericks, this no longer appears to be an option. Instead, you must run "xcode-select --install" from a terminal. This will show a dialog, make you agree to some license or other, and then offer to download the files that ccl needs in order to build. It may even be the case that you don't need to download Xcode just to install the command-line tools, which would save you a 2 GB download if you only want to rebuild ccl. </blockqoute>

Tags:

Oct. 7th, 2013

ECL needs a maintainer

Juanjo sent en email yesterday about about the status of ECL:

* First of all, ECL no longer relates to my own work. On the contrary, other open source projects that I carry on (https://github.com/juanjosegarciaripoll?tab=repositories) are more directly related to my research and are demanded by my group. This is detracting development time from the project, but there is little I can do, as that numerical software is what feeds our bellies right now.

* Not only does my work consume most of my open-software development time, but the job overall does significantly constraint the time I can spare for the project. As group leader in a research environment with scarce resources, I spend more time writing grant applications and bureaucracy than I do in front of Emacs. Quite frustrating as it is, I only see it worsening in the near future.

* The consequence is that the time I can devote to ECL has serious ups and downs. In an environment of rapidly developing tools and libraries, this is quite unfortunate, as the project may lag behind and become obsolete. This is indeed what has happened with several of the ports out there.

* On top of this, there are a lot of frustrating things that I did not want to care about but which are bugging me right now and also stealing time. The first one is the license issue. I put out a suggestion to migrate to MPIR because I knew that MPIR had an effort to stay with LGPL2. Regrettably, I did not know that this effort was abandoned so that if ECL wishes to upgrade to any more recent version of GMP/MPIR it has to migrate to LGPL3.

* Another nagging issue is testing. You have suffered this in the past and it still is a problem: my testing environment is broken and I do not have time to fix it. Despite Anton's wonderful library, the fact is that it is a heck of a problem to maintain several virtual machines and computers in an uncooperative computing environment with frequent blackouts.

* Finally, on the one hand, there are many new upcoming implementations out there, some with promising results and features that I do not have the time to incorporate -- but which would be simple with resources -- and certain forks are consolidating. On the other hand, despite ten years of development, I have failed to aggregate any number of contributing developers around this project. This may be blamed on the community or on myself, and it does not match the supportive and helpful user base that ECL has always had, but the fact is that it is a problem and a time has come to accept it [but please, I do not need your pity on the IRC channels, ok?]

Though I did not have time to develop, I had time to think, even if on the bus trips and planes, and I came to the following conclusions:

* I am resigning and opening the position of ECL maintainer for anyone to take. I will grant him or her with full administrative rights and full responsibility over the project's future. No need to fork the project: if you really feel you can make it better, step ahead and take it. I will remain as a support developer and help you as much as I can.

* If no one takes over maintenance, I will continue working as I can, when I can. This may be unsatisfactory for many of you -- if this is the case, I am sorry, but that's all there is.

Read the whole thing.

Tags:

Sep. 1st, 2013

ledsign

A survey of Common Lisp JSON libraries

Sabra Crolleton has put together a thorough, detailed survey of Common Lisp JSON libraries. If you are trying to evaluate which one to use, this survey may help you understand the features, strengths, and weaknesses of cl-json, st-json, yason, jsown, and com.gigamonkeys.json.

Tags:

Jul. 9th, 2013

A bit of Common Lisp history

The SAILDART archives are pretty fascinating. I stumbled across a page there that describes an approach to Common Lisp standardization of which I was previously unaware: the white, yellow, red, and blue pages concept.

The white pages is a language specification rather than an implementation specification. It defines a set of standard language concepts and constructs that may be used for communication of data structures and algorithms in the Common Lisp dialect. [...]

The yellow pages is a program library document, containing documentation for assorted and relatively independent packages of code. While the white pages are to be relatively stable, the yellow pages are extensible; new programs of sufficient usefulness and quality will routinely be added from time to time. The primary advantage of the division into white and yellow pages is this relative stability; a package written solely in the white-pages language should not break if changes are made to the yellow-pages library.

The red pages is implementation-dependent documentation; there will be one set for each implementation. Here are specified such implementation-dependent parameters as word size, maximum array size, sizes of floating-point exponents and fractions, and so on, as well as implementation-dependent functions such as input/output primitives.

The blue pages constitutes an implementation guide in the spirit of the Interlisp virtual machine specification. It specifies a subset of the white pages that an implementor must construct, and indicates a quantity of Lisp code written in that subset that implements the remainder of the white pages. In principle there could be more than one set of blue pages, each with a companion file of Lisp code. (For example, one might assume IF to be primitive and define COND as a macro in terms of IF, while another might do it the other way around.)

[...]

[W]e will produce the first version of the blue pages. This requires producing a detailed specification of the subset of the white pages that must be written, expanding on the white pages description where necessary. We will also write, test, and document an implementation of Common Lisp in that subset and make that code available to anyone wanting to implement a Common Lisp. Thus, for any group to implement a Common Lisp, all that will need to be done is to write the specified subset language in whatever other language their hardware supports and to then take a copy of the Lisp code we will have produced which will complete the implementation of the white pages language.

(Emphasis and hyperlinking added.)

See the full ARPA.PRO document for the entire message. It's from 1982. What would the CL landscape be like today if this plan was followed to fruition?

Tags:

Jul. 8th, 2013

Corman Lisp may go open source

Last month I emailed Roger Corman about his future plans for Corman Common Lisp. Here's his response:

Hi Zach,
Thanks for your interest in Corman Lisp. I have been unable to commit any resources to developing Corman Lisp for the last couple of years. I would be willing to convert it to open source, and let others take it over, as I don't expect to be able to get back to it any time soon. My medical software business consumes most of my time these days. The source code is all already included (at least for Corman Lisp itself). The source code for the IDE is not included, and I could package it up and add it to the distribution. Then I guess the thing would be modifying the licensing terms to reflect one of the open source models.

I see two primary issues at this point. First, the Corman Lisp kernel needs to be built with Visual Studio 2005, which is an old version of VS. At one point I built it with VS2008 and it built and ran, but some problem with the FFI caused applications saved, and the IDE, to have problems. This type of thing is fairly common as Microsoft makes subtle changes to the code generation of their C compiler, which in turn affects the Lisp kernel which has very tight rules about how it expects its code to look. I did a lot to reduce the kernel (move things from the kernel to Lisp code, which is then compiled safely), but did not fully resolve the VS 2008 issues. Now there is VS 2010 and 2012, and I never tried building with either of those. In general I find each newer version of VS is worse for native C/C++ debugging, as .NET has become Microsoft's primary platform for new software.

The other issue is running on 64-bit OS. Again, the FFI misbehaves when you have saved an application, or just doing a bunch of FFI stuff in an application. It is something to do with GC and the 64-bit support for running 32-bit applications (which is what CL is). It could be related to the same issue as I encountered with building under VS2008.

Tracking down this problem is difficult.

Regarding converting to a full 64-bit Lisp, this would be a much bigger effort. Corman Lisp gets such good performance by a large amount of hand-optimized x86 assembly code. This would all have to be rewritten/replaced in a 64-bit Lisp.

When Corman Lisp was first developed in the late 90s, there was really no competition on Windows platforms. Franz only had a 16-bit Lisp they were selling, and not really taking the Windows market seriously. Mac Common Lisp was on 680x0 and later PowerPC but didn't get to Windows for a very long time, and LispWorks didn't support Windows until much later. Now I think most all of those have good implementations on Windows (though only MCL is free). I have used Allegro extensively for a large contract with SRI and I see the value of a mature cross-platform system like they have. It is however extremely expensive, and developing applications for distribution requires lots of negotiation and per-license payments to Franz. Corman Lisp still has some advantages, I think--it is really a good hackers Lisp, when you want to easily get down into the assembly level, or in the guts of the compiler, to do almost anything. You have the power of Lisp to do those things with macros and a nice high-level dynamic environment.

I definitely want to see it live on, so am open to whatever enables that. I don't currently derive any significant income from it so that's not a concern for me.

Roger

I can't wait to see how this goes!

Tags:

Jul. 1st, 2013

Mark Watson is updating his Common Lisp book

Mark Watson wrote to me about an announcement he made today on his blog:

I ... got back to my Common Lisp “roots” last week when I was enjoying playing with the mocl Common Lisp system for Android and iOS development. I wrote an AI book using Common Lisp for Springer-Verlag in the 1980s, which was lots of fun, and in 2007 I put together a very short PDF free “book” called “Loving Lisp, or the Savvy Programmer’s Secret Weapon” with the help of many people in the Common Lisp community who offered corrections and suggestions. A few years ago I spent a weekend correcting and adding material to “Loving Lisp, or the Savvy Programmer’s Secret Weapon” but I never published the new material. I just decided last night to spend some of my free time updating this book adding more material on: accessing PostgreSQL, MongoDB and CouchDB; writing web apps; a native Common Lisp SPARQL client and some ideas for using SPARQL endpoints in Common Lisp applications, and some general material on information gathering. Basically, supporting an old language like Common Lisp with some fun modern application examples.

(Emphasis added.)

Read more on Mark's blog.

Tags:

Direct syscalls on CMUCL and maybe SBCL

About 10 years ago I read an article on comp.lang.lisp about system calls and the condition system:

... I would have liked a native Unix system call interface that could skip the dumbing-down that the C interface library represents. e.g., most system calls in most Unix implementations return an error as a CPU flag, not as some stupid special value and setting a global variable like the C library exports to C programmers. that is, it should be fairly simple to create a condition system for Unix system calls that could be more efficient and less insane than the C stuff we have to deal with via today's foreign function interfaces.

That sounded interesting, and I started hacking around on it, and someone sent me code from Douglas T. Crosher for direct syscalls in CMUCL on Linux/x86. Then I lost interest in the project and forgot about the code, until yesterday. So I posted the code on github in case it seems interesting to someone else. I'm not sure how much work it would take to get it running on modern CMUCL or SBCL.

Tags:

Jun. 6th, 2013

Boston Lisp Meeting on June 12th

Here are the details from Alex Plotnick:

From: Alex Plotnick
Subject: Boston Lisp Meeting 2013-06-12T18:00
To: boston-lisp@common-lisp.net

I'm pleased to announce that Jonathan Smith will present his work on '$-Calculisp' at the next Boston Lisp meeting. The meeting will take place on Wednesday, 12 June at 6:00 PM, in the Star Conference room at MIT's Stata Center (MIT 32-D463; <http://whereis.mit.edu/?go=32>).

$-Calculus (pronounced cost calculus), is a descriptive fourth generation language designed for modeling parallel algorithms, artificial intelligence applications, and bounded super-Turing computation. $-Calculisp is a domain specific language modeled on $-Calculus and implemented in Common Lisp. $-Calculisp is implemented using a variety of techniques based on Common Lisp's unique macro and object system facilities. Rather than being an interpreter, it is a macro compiler, expanding $-Calculisp code into efficiently compiled Common Lisp code. It is intended to be a robust extension to the Common Lisp language, as such, it allows for integration of regular common lisp functions alongside $-Calculisp code.

Jonathan Smith is a software engineer at NovaSparks, where he currently works on their HPCC lisp to VHDL compiler infrastructure. Previously, he worked at Westinghouse Electric Company, where he supported their ShuffleWorks product line. Shuffleworks is an expert system, (written in Lisp) for coordinating nuclear fuel movement within power plants.

Tags:

Jun. 2nd, 2013

An important notice about Quicklisp

From today's perusal of comp.lang.lisp, Madhu blows the lid off the Quicklisp conspiracy:

From: Madhu
Subject: Re: proper use of require
Newsgroups: comp.lang.lisp
Date: Sun, 02 Jun 2013 14:10:21 +0530

* Tamas K Papp :
Wrote on Sun, 02 Jun 2013 07:41:59 +0200:
| REQUIRE & related functionality is deprecated, so I don't understand
| why you prefer it. On many CL implementations (SBCL included) it just
| hooks into ASDF anyway, so you might as well use ASDF:LOAD-SYSTEM, but
| using Quicklisp should be fine too.

A lot of functions are "Deprecated", in the spec, but in retrospect it is the "deprecation" that is shortsighted. REQUIRE is in the CommonLisp spec, but ASDF and QUICKLISP instruments are from Satan to take control of your code through the middleware layers. The dependency conspiracy is carefully thought out, but by the time you figure it out, you will be buried and forgotten; while Papp & Co. will be around using advertising and marketing machinery, [mis]leading a new generation of users that are ready and willing to suffer for the first time. ---Madhu

Now you know.

Tags:

May. 22nd, 2013

Boston Lisp Meeting on May 23

Boston Lisp meetings are a lot of fun. Here's Alex Plotnick's announcement for the next meeting:

I'm pleased to announce that François-René Rideau will speak at the next Boston Lisp meeting on his recent work on ASDF 3. The meeting will take place on Thursday, 23 May at 6:30 PM, in the Star Conference room at MIT's Stata Center (MIT 32-D463; <http://whereis.mit.edu/?go=32>).

I'm sorry about the short notice on this one; communications problems of all kinds have been gumming up the works. Please feel free to spread the word about the meeting via whatever mechanisms are available to you.

Talk details (courtesy of Faré) follow. I hope to see you all there!

Title: "ASDF 3, or lessons in building portable Common Lisp programs"

Summary:
"ASDF (Another System Definition Facility) has been the de facto standard Common Lisp build system for over ten years. I recently rewrote it completely, several times, all the time (mostly) preserving backwards compatibility. The latest incarnation, ASDF 3, in addition to fixing deep design bugs older than ASDF itself, also includes extensive portability library, UIOP, not to be confused with an existing parallelizing extension, POIU. I will show how to use ASDF, explain the recent improvements, and discuss the challenges of writing portable Common Lisp programs and what that means for the past and future of Lisp."

About the speaker:
"François-René Rideau is a Lisp plumber. On good days, he designs great piping for persistent data, to be used in airline reservation system of ITA (now part of Google). On bad days, he dons his rubber gloves and scrubs the pipes. He also has a blog, Cybernethics, where he writes on liberty, music, programming, and dynamic systems in general."

I can't make it, but if you're in the Boston area, you should go!

Tags:

Previous 10 | Next 10

April 2014

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930   

Syndicate

RSS Atom
Powered by LiveJournal.com