armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

[armedbear-devel] Problem loading Lisp file on Mac, but works on Windows
by Paul Reiners 25 Jul '09

25 Jul '09

I've written a Java program that calls a Lisp program. On Windows, this works just fine. However when I run it on Mac OS X, I get this error: Error loading /Users/paul/Documents/workspaces/MyOpenSourceProjects/ JVMLanguages/src/life.lisp at line 53 (offset 1628) Debugger invoked on condition of type END-OF-FILE: #<END-OF-FILE {51190A}> [1] CL-USER(1): Any idea what is going wrong here? I wrote both the Lisp and Java files on Windows originally. Is it some sort of character encoding problem? Here are the relevant files: http://automatous-monk.cvs.sourceforge.net/viewvc/automatous-monk/JVMLangua… http://automatous-monk.cvs.sourceforge.net/viewvc/automatous-monk/JVMLangua… Paul

1 0

[armedbear-devel] Holidays or the release of 0.16?
by Erik Huelsmann 25 Jul '09

25 Jul '09

With the normal release schedule, it would be time to release 0.16 in 1 or 2 weeks. However, I'll be travelling with unknown amounts of net time around that time. Until then, I'll be busy with work and travel preparations. So, we have 2 options here: 1. One of the other committers steps up and makes the release Most of our release process is documented in the wiki. What's not there can be added until then 2. We delay 0.16 until some time I have time to create the release. With kind regards, Erik.

2 1

[armedbear-devel] second version of the StackFrame cleanup
by Ville Voutilainen 23 Jul '09

23 Jul '09

Same as before, but use a vararg function instead of doing manual arrays. Java does correctly choose a multi-param version when it's available, it only uses a vararg version when it has to.

1 0

[armedbear-devel] (lisp) Stack management efficiency
by Erik Huelsmann 21 Jul '09

21 Jul '09

Peter Graves pointed me at the language/implementation efficiency shootout at http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html which implements a ray tracer in a multitude of languagues, one of them being Common Lisp. There are a number of rows, which I conviniently name version 1 (row 1) to version 5 (last row). Peter points out that version 1 isn't optized at all: all functions lead to function calls (no inlining). When running this code, it takes around 1440 seconds on my PC. Then I modified the stack management routine to re-use available stack frames (and conses), instead of creating new ones on every call. This took execution time down to around 1240 seconds. A good improvement, I'd say. However, with the change described above, stack frames won't ever become garbage anymore. My question is: does the loss of GC-ability outweigh the performance gain? Please note that it's possible to run without a lisp stack (but that also means without traces) by compiling code with a (SPEED 3) declaration. Comments? Bye, Erik.

7 16

[armedbear-devel] Parameterized Lisp Calls vs Array Calls
by logicmoo＠gmail.com 21 Jul '09

21 Jul '09

Parameterized Lisp Calls vs Array Calls In the code I added a Interface "barrier" just in-case there was some inlining /***********************START JAVA*************************************************/ package benchtest; interface ISomeFunParams { int SomeFun(int i, int j); } interface ISomeFunArray { int SomeFun(int[] ij); } interface ISomeFunVarArgs { int SomeFun(int... ij); } class BenchArrays1 { public static void main(String[] args) { ISomeFunParams sumFun = new SomeFunImpl1(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays2 { public static void main(String[] args) { ISomeFunVarArgs sumFun = new SomeFunImpl2(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays3 { public static void main(String[] args) { ISomeFunArray sumFun = new SomeFunImpl3(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(new int[]{i, j}); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class SomeFunImpl1 implements ISomeFunParams { public int SomeFun(int i, int j) { return i + j; } } class SomeFunImpl2 implements ISomeFunVarArgs { public int SomeFun(int... ij) { return ij[0] + ij[1]; } } class SomeFunImpl3 implements ISomeFunArray { public int SomeFun(int[] ij) { return ij[0] + ij[1]; } } /***********************END JAVA*************************************************/ [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays1 real 0m0.113s user 0m0.040s sys 0m0.013s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays2 real 1m42.898s user 1m21.279s sys 0m0.742s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays3 real 1m40.823s user 1m21.411s sys 0m0.651s

1 0

[armedbear-devel] Proposed patch to move remaining symbols to THREADS
by Mark Evenson 21 Jul '09

21 Jul '09

Attached is a proposed patch to complete moving the various THREADS related stuff into the new package. This patch removes the Gates implementation, as the new SYNCHRONIZED-ON and OBJECT-NOTIFY primitives provide more appropriate (i.e. more JVM specific) abstractions. If Tobias and Erik could check that this patch is what they want to have happen, I'll commit it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] missing right parenthesis for Clisp in build script
by Robert Dodier 20 Jul '09

20 Jul '09

Hi, I tried to use the build-from-lisp.sh with Clisp but there was a missing right parenthesis in the forms to be evaluated on the command line. Just putting in another paren fixed it. HTH Robert Dodier

2 1

[armedbear-devel] Wikipedia page on ABCL deleted
by Kevin Krouse 18 Jul '09

18 Jul '09

Yesterday, the wikipedia minions decided ABCL is not "notable enough" and so have deleted the ABCL page: http://en.wikipedia.org/wiki/Armed_Bear_Common_Lisp http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Armed_Bear_Com… http://en.wikipedia.org/w/index.php?title=Special:Log/delete&page=Armed_Bea… I'm not sure what their requirements for notability are exactly. At any rate, it would be good to get the page restored and expand upon the sparse text that was originally there -- perhaps with code samples and links to projects using ABCL. Kevin

2 1

[armedbear-devel] patch for bug: function JVM::%FLOAT-BITS is undefined
by Anton Vodonosov 18 Jul '09

18 Jul '09

Hello, Consider the following java snippet: public static void main(String[] args) throws Throwable { Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(compile nil '(lambda () 0.1))"); } It fails with error: Debugger invoked on condition of type UNDEFINED-FUNCTION: The function JVM::%FLOAT-BITS is undefined. In the REPL (compile nil '(lambda () 0.1)) works normally. I do not understand what is the difference in environment between ABCL REPL and embedded ABCL, but the following trivial patch fixes the problem in for the embedded case. Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 12050) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -132,7 +132,7 @@ (defknown pool-float (single-float) (integer 1 65535)) (defun pool-float (n) (declare (optimize speed)) - (pool-get (list 4 (%float-bits n)))) + (pool-get (list 4 (sys::%float-bits n)))) (defun pool-long/double (entry) (let* ((ht *pool-entries*) @@ -163,7 +163,7 @@ (defknown pool-double (double-float) (integer 1 65535)) (defun pool-double (n) (declare (optimize speed)) - (let* ((n (%float-bits n)) + (let* ((n (sys::%float-bits n)) (entry (list 6 (logand (ash n -32) #xffffffff) (logand n #xffffffff)))) Best regards, - Anton

1 1

[armedbear-devel] Thread safety of the compiler (was: Thread safety of clos.lisp)
by Erik Huelsmann 17 Jul '09

17 Jul '09

Well, I've been investigating the issue with our clos.lisp not being thread safe and me seeing NullPointerExceptions. It turns out that GENSYM was not thread safe in case there were no thread-local special bindings: the SYMBOL-VALUE wasn't protected against being manipulated from 2 threads at the same time. I changed that. Now, even though clos.lisp is not thread safe, I'm not seeing any NullPointerExceptions anymore. The NullPointerExceptions were caused by the fact that COMPILE was running in 2 threads at the same time, generating the same symbol at the same time. Then, it called REMEMBER from both threads, one overwriting the value stored by the other. That doesn't cause NullPointerExceptions by itself, but when each thread loads its COMPILEd function, the constructor calls Lisp.recall(), which removes the key from the hash used for temp-storage. The second function then finds 'null' instead of the value it stored. So, that's another mystery solved. Fixed in trunk now. However, what remains is the fact that the remember/recall combo uses global keys while COMPILE may be generating thread-local key values. I'm wondering what to do about that. Possibly I should just create a ThreadLocal which has a temp-storage hash table per thread and document remember/recall are a thread-local storage mechanism. Of course, your opinions are welcome as always, especially with respect to the last paragraph. Bye, Erik.

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel