[armedbear-devel] SBCL->ABCL migration questions
I'm involved with a project that uses Steel Bank Common Lisp (SBCL). I'm interested in the possibility of moving it to ABCL, in order to take advantage of interoperability with some other JVM languages (eg, Clojure, JRuby, Jython). FYI, the project software currently uses several requires: (require :bordeaux-threads) (require :mcclim) ; CLIM public implementation (require :MT19937) ; Mersenne Twister random number generator Does anyone have any caveats or suggestions to offer? I'd also be interested in learning about ABCL (or, more generally, Common Lisp) consultants who are willing to take on small assignments. -r
Hi Rich, On Aug 25, 2013 11:51 PM, "Rich Morin" <rdm@cfcl.com> wrote:
I'm involved with a project that uses Steel Bank Common Lisp (SBCL). I'm interested in the possibility of moving it to ABCL, in order to take advantage of interoperability with some other JVM languages (eg, Clojure, JRuby, Jython).
FYI, the project software currently uses several requires:
(require :bordeaux-threads)
Bordeaux-threads - if taken to be recent enough - should not be a problem ...
(require :mcclim) ; CLIM public implementation
... but this require might be a challenge. I know that Rudi Schlatte started to port McCLIM to ABCL. I have no idea what his current progress is.
(require :MT19937) ; Mersenne Twister random number generator
No idea about this one. Never heard about problems with it, but I expect that to be because noone tried it yet.
Does anyone have any caveats or suggestions to offer? I'd also be interested in learning about ABCL (or, more generally, Common Lisp) consultants who are willing to take on small assignments.
See private mail on the subject of contracting. Bye, Erik.
On 8/26/13 12:18 AM, Erik Huelsmann wrote:
Hi Rich,
On Aug 25, 2013 11:51 PM, "Rich Morin" <rdm@cfcl.com <mailto:rdm@cfcl.com>> wrote:
I'm involved with a project that uses Steel Bank Common Lisp (SBCL). I'm interested in the possibility of moving it to ABCL, in order to take advantage of interoperability with some other JVM languages (eg, Clojure, JRuby, Jython).
FYI, the project software currently uses several requires:
[…] (require :MT19937) ; Mersenne Twister random number generator
No idea about this one. Never heard about problems with it, but I expect that to be because noone tried it yet.
[…] MT19937 works fine, but could use better statistics-based tests to show that the resulting distribution of random numbers is indeed statistically random for your purposes. […] -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Aug 26, 2013, at 00:18, Erik Huelsmann <ehuels@gmail.com> wrote:
Hi Rich,
On Aug 25, 2013 11:51 PM, "Rich Morin" <rdm@cfcl.com> wrote:
I'm involved with a project that uses Steel Bank Common Lisp (SBCL). I'm interested in the possibility of moving it to ABCL, in order to take advantage of interoperability with some other JVM languages (eg, Clojure, JRuby, Jython).
FYI, the project software currently uses several requires:
(require :bordeaux-threads)
Bordeaux-threads - if taken to be recent enough - should not be a problem ...
(require :mcclim) ; CLIM public implementation
... but this require might be a challenge. I know that Rudi Schlatte started to port McCLIM to ABCL. I have no idea what his current progress is.
Now that abcl has a mop implementation, a port is theoretically possible. In fact, porting the existing X-Windows backend should not be too much work. I started noodling around with a Swing-based backend, but did not progress beyond an application frame with vertically stacked labels so far. Current progress is at https://github.com/rudi/mcclim/tree/abcl-backend; I'm not working actively on it currently but it can serve as the basis for a port of the X-Windows backend since the abcl-specific files are there. Rudi
On Aug 26, 2013, at 05:26, Rudi Schlatte wrote:
Now that abcl has a mop implementation, a port is theoretically possible. In fact, porting the existing X-Windows backend should not be too much work. ...
"theoretically possible" isn't too encouraging. Maybe I should take a closer look at my goals and (still speculative) approach. The program uses McCLIM to provide a single, tabbed window. I'd like to retain the back-end logic, but replace the front end with a JavaScript single page application, using D3.js, jQuery UI, etc. Given that McCLIM isn't currently supported on ABCL, it probably makes sense to do the GUI conversion first. Certainly, porting McCLIM to ABCL only to discard it seems like a waste of effort. So, recasting the question, are there any web server libraries I should consider? I'd like something pretty minimal (ala Rack or Sinatra); all I need to do is handle requests from a client and respond with appropriate data structures (eg, JSON, EDN). On a related front, I'd love to hear about any work in using EDN with Common Lisp: https://github.com/edn-format/edn https://github.com/edn-format/edn/wiki/Implementations -r -- http://www.cfcl.com/rdm Rich Morin http://www.cfcl.com/rdm/resume rdm@cfcl.com http://www.cfcl.com/rdm/weblog +1 650-873-7841 Software system design, development, and documentation
On 8/26/13 6:24 PM, Rich Morin wrote:
On Aug 26, 2013, at 05:26, Rudi Schlatte wrote:
Now that abcl has a mop implementation, a port is theoretically possible. In fact, porting the existing X-Windows backend should not be too much work. ...
"theoretically possible" isn't too encouraging. Maybe I should take a closer look at my goals and (still speculative) approach.
The program uses McCLIM to provide a single, tabbed window. I'd like to retain the back-end logic, but replace the front end with a JavaScript single page application, using D3.js, jQuery UI, etc.
[…]
So, recasting the question, are there any web server libraries I should consider? I'd like something pretty minimal (ala Rack or Sinatra); all I need to do is handle requests from a client and respond with appropriate data structures (eg, JSON, EDN).
I like building CL web apps with [RESTAS][] to map the URI space on top of Hunchentoot, using [Parenscript][] to glue together the necessary Javascript libraries. RESTAS uses a similiar abstraction as Ruby on Rails' "routes" to quickly hook representations into the URIs your application serves. I use Parenscript so that I don't make so many mistakes writing client closures, as the Parenscript compiler can only emit syntactically correct Javascript. Usually, I end up creating semi-general macros to write the actual content with [CL-WHO][], as I find that I need to abstract the "content domain" in a per-application manner, which I end up refactoring over the course of the project, tweaking for expressive power vs. maintainability. The trick about such apps always seems to lie in the separation of the content (per-MIME "Content-Type"), the presentation (CSS), and the logic (Parenscript wrapped Javascript). While I like dealing with everything in s-exprs, there are many good reasons for using appropiate DSLs in other templating systems (like Sinatra), such as when one has a person helping out who is especially profficient at browser Javascript and/or CSS/HTML. [RESTAS]: http://code.google.com/p/restas/ [Parenscript]: http://common-lisp.net/project/parenscript/ [CL-WHO]: http://weitz.de/cl-who/
On a related front, I'd love to hear about any work in using EDN with Common Lisp:
https://github.com/edn-format/edn https://github.com/edn-format/edn/wiki/Implementations
Given the list of implementations that you have cited--and knowing nothing about EDN--I would go for using CFFI to the C implementation, knowing that one could possibly use Jython or JRuby to orchestrate their implementations of EDN as a backup. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
participants (4)
-
Erik Huelsmann -
Mark Evenson -
Rich Morin -
Rudi Schlatte