- armedbear-devel - mailman3.common-lisp.net

maven binary location under mac homebrew
by Cyrus Harmon 24 Apr '15

24 Apr '15

For the maven ASDF contrib stuff to find the mvn executable when using the homebrew packaged maven, I need the following patch: diff --git i/contrib/abcl-asdf/maven-embedder.lisp w/contrib/abcl-asdf/maven-embedder.lisp index c0b67ad..a64f8fa 100644 --- i/contrib/abcl-asdf/maven-embedder.lisp +++ w/contrib/abcl-asdf/maven-embedder.lisp @@ -115,6 +115,9 @@ (defun find-mvn-libs () (truename d))) (list (make-pathname :defaults (merge-pathnames "../lib/" (find-mvn)) :name nil :type nil) + ;; library location for homebrew maven package on MacOS + (make-pathname :defaults (merge-pathnames "../libexec/lib/" (find-mvn)) + :name nil :type nil) #p"/usr/local/share/java/maven3/lib/" ;; FreeBSD ports #p"/usr/local/maven/lib/"))) ;; OpenBSD location suggested by Timo Myyrä is there a better way to do this? thanks, Cyrus

2 1

cl-test-grid results for svn revision 14755
by Anton Vodonosov 11 Apr '15

11 Apr '15

Hello, Diff between ABCL 1.3.1 and the current dev version (svn revision 14755): https://common-lisp.net/project/cl-test-grid/abcl/abcl-diff25.html Unfortunately there are only regressions. (The green results for cffi-libffi are due to installed libffi-dev on the testing machine, not because of ABCL improvement) Best regards, - Anton

4 15

Upcoming abcl-1.3.2
by Mark Evenson 11 Apr '15

11 Apr '15

I hearby officially announce my attention to release abcl-1.3.2 before ELS 2015. If people have time to fix outstanding bugs over the weekend, please submit your patches or concerns as soon as you can either to the mailing list on on IRC at [#abcl][]. [#abcl]: http://webchat.freenode.net/?randomnick=1&channels=abcl&prompt=1&uio=d4 One can view the more-or-less complete list of [CHANGES][1] in trunk. [1]: http://abcl.org/trac/browser/trunk/abcl/CHANGES There are six (6) [ANSI regressions][2] that occur on JRE 7/8 that don't appear on previous versions of the JRE, namely READ-BYTE.ERROR.5 WRITE-BYTE.ERROR.4 CLEAR-INPUT.ERROR.5 FINISH-OUTPUT.ERROR.3 FORCE-OUTPUT.ERROR.3 CLEAR-OUTPUT.ERROR.3, which have something to do with generic function dispatch that I haven't quite figured out, but will probably not address in this release. [2]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/ansi-test-failures#L… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] Losing on multiprocessing
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Howdy, I wonder if those of you have worked with threads might have a quick look to see if I am doing something stupid. https://lsw2.googlecode.com/svn/branches/bona/util/jargrep.lisp The situation is that I want to do stuff (like look for matches to a regular expression) in 240k files which comprise 52G of data. I am running on a VM allocated 5 CPUs each with three cores. Because at the moment the disk subsystem isn't very fast, I decided to approach this by breaking up the 240k files into 15 parts and put each part in a jar file. The code mentioned above looks for a regular expression (two methods for two different regex handlers: java and dk.brics.automaton It is invoked something like: (jar-map-threads-automaton-find regex (generate-filename-sequence "/data/jars/15/file#.jar" 2 0 14)) This spawns off 15 threads that go at it for something around a minute. As they find hits they save them in a lisp hash table keyed by the entry name in the jar file, which is unique across all the jar files. The result of running this is about (and their's the rub) 20 key value pairs in the hash table (I had read that ABCL hash tables are thread safe). The problem is that different runs of this code on the same data get different numbers of key value pairs, between 13 and 24! I'm not sure whether I'm just not doing this the right way, in which case it would be very helpful to get an explanation of why not, or there's a problem somewhere in the implementation. Any ideas would be greatly appreciated. Best, Alan (LISP-IMPLEMENTATION-VERSION) "1.2.0-dev-svn-14436M" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_21-b11" "amd64-Linux-3.8.0-30-generic"

2 7

[armedbear-devel] abcl.org down
by Mark Evenson 08 Apr '15

08 Apr '15

abcl.org is currently unreachable: we expect to have it up around 2300 GMT. A [relatively up-to-date mercurial repostiory][1] exists if you absolutely have to diff trunk *right now*. [1]: https://code.google.com/p/abcl-dynamic-install/ Sorry about this, Bear fans, -- The Mgmt. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] SBCL->ABCL migration questions
by Rich Morin 08 Apr '15

08 Apr '15

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

4 5

[armedbear-devel] Futile attempt at using Akka
by ubikation _ 08 Apr '15

08 Apr '15

Hello, I have been playing around with Common Lisp for a while and I really want to get this idea working. I have been reading a lot about Akka, but I'm not really a Java/Scala/distributed guy. To my understanding, Akka is an agnostic way to create Actors that can send messages at varying speeds, speeding up with the available memory and cores and easily extending itself for distributed communication via remote Actors. I'm not an expert by any means, so feel free to correct me on the description. I would like to create bindings to this example http://doc.akka.io/docs/akka/2.1.2/java/untyped-actors.html and it was suggested to me that I might use "java:jnew-runtime-class" by the very nice ehu on #abcl. My repository is at https://github.com/ubikation/chemicalambda if anyone is interested in my progress or wants a better idea of where I am (not really beyond starting the project at the moment). At the minimum I would like to create bindings, but I would like to do something more interesting after I get some stuff working. I do not know what I am doing at all, but I am hoping that creating these bindings will help solidify my understanding of Common Lisp and of ABCL in particular. Thanks again!

3 3

[armedbear-devel] undesirable behavior in #'directory ?
by Alan Ruttenberg 08 Apr '15

08 Apr '15

Emacs creates files like this: lrwxr-xr-x 1 alanr staff 30 Jan 6 01:40 .#foo.sql@ -> alanr(a)conjunctive-2.local.6427 as lock files, IIRC. In such cases, the target of link names a file that doesn't exist. #'directory calls #'truename on the filenames that are listed, and truename does a probe file. Incidentally It looks like that is done in the java as well as the lisp function making the latter redundant. It seems wrong that there is a situation in which one can't call directory at all without getting an error. The crux of the matter is how to interpret the documentation of truename in the presence of symbolic links. The doc for truename says: If filespec is a pathname it represents the name used to open the file. This may be, but is not required to be, the actual name of the file." "actual name of the file" suggests that there is a file, but also suggests that it is the name that is important. Also whereas directory allows implementation-dependent keywords, truename is not so defined. I'll take the position that truename should *not* depend on the file existing, but rather focus on what names are present in directory structures. So resolve-truenames nil should should return the names in the directory and for resolve-truenames t it should follow symbolic links as long as they can be followed without hitting a name that doesn't designate an existing file. -Alan

5 13

[armedbear-devel] installing java dependencies with :mvn ASDF component
by Anton Vodonosov 08 Apr '15

08 Apr '15

Hello. I need to import data from Excel, and following Hans Hübner's article for how to do this with ABCL: http://netzhansa.blogspot.com/2013/03/dealing-with-excel-files-from-common.… The Hans' code depends on Apache POI library. I saw that ABCL comes from abcl-asdf contrib, which extends ASDF by adding a :mnv component, so that we can specify :mvn artifact as a dependency of our ASDF system. I would like to use this facility to automatically install the POI .jar files. I created an .asdf file with this content: (defsystem :excel-s :defsystem-depends-on (:abcl-asdf) :version "0.1.0" :encoding :utf-8 :components ((:mvn "org.apache.poi/poi-ooxml/3.9"))) Then I invoke ABCL: C:\Users\anton\projects\abcl\abcl.bat --batch --eval "(require :abcl-contrib") --eval "(pushnew \"./\" asdf:*central-registry* :test #'equal)" --eval "(ql:quickload :excel-s)" It fails with exception: java.lang.ClassNotFoundException: aether.util.artifact.DefaultArtifact This exception is throw by abcl-asdf::resolve-dependencies function, defined in the contrib/abcl-asdf/maven-embedder.lisp. Maven is installed on my machine, including the /lib/ directory containing the Aether API jars. I performed some investigation and tried to ensure the Aether .jars are added to classpath: (abcl-asdf::init) (let ((*default-pathname-defaults* abcl-asdf::*mvn-libs-directory*)) (dolist (jar-pathname (or (directory "**/*.jar") (error "no jars found in ~S - expected Apache Maven /libs/ directory ~ installation there" (merge-pathnames abcl-asdf::*mvn-libs-directory*)))) (java:add-to-classpath (namestring jar-pathname)))) Still I have the same error - class aether.util.artifact.DefaultArtifact not found. Is the way I am trying to install java libs expected to work, and how to find the problem? Best regards, - Anton

2 8

Re: [armedbear-devel] Pdfdoclet - Javadoc for ABCL in PDF format
by Mark Evenson 08 Apr '15

08 Apr '15

On 7/23/13 11:34 PM, Sean Champ wrote: […] > Personally and primarily, I've been interested in the possibility of > developing an ABCL interface onto Apache Jena, and possibly an interface > onto some JARs distributed by the GeoTools project - would like to > develop a process of transforming an ESRI Shapefile into an OWL > ontology, and it seemed that ABCL would be a good Common Lisp > implementation to use for such a purpose. See [jeannie][] for an initial wrapping of Jena with ABCL. It doesn't do much more than read RDF from a PATHNAME, but adding the rest is a matter of rolling up the proverbial sleeves. [jeannie]: http://bitbucket.org/easye/jeannie […] > In looking at that idea, I'd been interested about how the CLOS support > is implemented in ABCL, and whether and how MOP might be implemented, > there. As much of CLOS/MOP as possible has been implemented in Lisp: see clos.lisp. CLOS is mostly historical, evolving in fits and starts over the lifetime of ABCL. The MOP has been added mostly of the last year by Rudi Schlatte. Following his commits chronologically would give somewhat of an impression of how it is implemented. […] > (On a personal note: > Between moving and returning to college, it's been a busy summer, > frankly, but there are some bluesky ideas that one can focus on, I suppose) No sweat: we should still be here when you get some time. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 2