armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

Re: [armedbear-devel] [armedbear] #83: problem with error reporting on undefined class during make instance
by Mahmud Mohamed 05 Oct '10

05 Oct '10

On 10/4/2010 8:53 AM, armedbear wrote: > mmohamed, thanks for the patch, unfortunately, it completely disables the > possibility (supported by CLHS) to forward-reference classes like this: > Understood. I will rework it later tonight. Cheers!

2 1

[armedbear-devel] Ticket 100: #P deserialization still valid?
by Erik Huelsmann 04 Oct '10

04 Oct '10

Alessio, Could you check ticket #100 (http://trac.common-lisp.net/armedbear/ticket/100)? You reported we don't deserialize well. Since Mark did quite a bit of work on pathnames, has it been fixed? Bye, Erik.

3 3

[armedbear-devel] ABCL Ticket #29: Loading user files off a JAR
by Erik Huelsmann 04 Oct '10

04 Oct '10

Hi Alan, Could you please check ticket #29 (http://trac.common-lisp.net/armedbear/ticket/29)? It's about being able to load files off JARs. However, with Mark Evenson's latest work on loading FASLs off jars, the request may be fulfilled already. Is that the case? With kind regards, Erik.

1 0

[armedbear-devel] CLOS thread safety
by Erik Huelsmann 03 Oct '10

03 Oct '10

Hi David, > Are there any known thread safety issues with CLOS? I've been > getting some weird MOP errors that I made go away by redefining > slot-value such that it has to acquire a global lock before it can do > anything. I assume that the problem is in my code: but the threads > that are executing when I get the failures share no code (or > variables), and every time the errors pop up slot-value is on the > callstack someplace. Well, there have not been any specific threading issues mentioned. Over two years ago, back when I started doing ABCL, there were threading issues which looked like threading issues in CLOS. They turned out to be threading issues in the compiler though. Having said that, I see there have not been taken synchronization measures on a high level: there are no locks and threads:synchronized-on blocks in clos.lisp. There are some synchronized calls on the Java side; I'm not sure the low-level protection is good enough to maintain consistency though. Can you share some examples which show the issues here? Adding thread-safety to clos.lisp - in specific, targeted places - should be well doable. Bye, Erik.

5 15

[armedbear-devel] Bug: (setf (values (struct-slot struct)) (values 42)) fails
by Zach Beane 03 Oct '10

03 Oct '10

(The "Reporting bugs" link on the abcl site doesn't actually link anywhere, so I'm mailing the list.) Here's a file that triggers an ABCL bug: ;;;; abcl-bug.lisp (defpackage #:abcl-bug (:use #:cl) (:export #:trigger)) (in-package #:abcl-bug) (defstruct mystruct slot) (defun trigger () (let ((struct (make-mystruct))) (setf (values (mystruct-slot struct)) (values 42)) struct)) Here's what happens when I run it: Armed Bear Common Lisp 0.22.0 Java 1.6.0_18 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.445 seconds. Startup completed in 1.688 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "abcl-bug")) ; Compiling /tmp/abcl-bug.lisp ... ; (DEFPACKAGE #:ABCL-BUG ...) ; (IN-PACKAGE #:ABCL-BUG) ; (DEFSTRUCT MYSTRUCT ...) ; (DEFUN TRIGGER ...) ; Wrote /tmp/abcl-bug.abcl (0.447 seconds) T CL-USER(2): (abcl-bug:trigger) #<THREAD "interpreter" {1653033E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function (SETF SYSTEM:STRUCTURE-REF) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {8FE2509}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:353) 3: org.armedbear.lisp.Symbol.getSymbolSetfFunctionOrDie(Symbol.java:399) 4: org.armedbear.lisp.abcl_bug_9.execute(abcl-bug.lisp:11) 5: org.armedbear.lisp.LispThread.execute(LispThread.java:552) 6: org.armedbear.lisp.Lisp.evalCall(Lisp.java:514) 7: org.armedbear.lisp.Lisp.eval(Lisp.java:485) [1] CL-USER(4): I would expect to get a structure back with SLOT set to 42, instead of this error. This is a strange case (you normally wouldn't use VALUES there) but it comes from some larger real code that sets multiple struct slots from a multiple-value-returning function. Zach

3 2

[armedbear-devel] What is the consensus on JFLI and JSS?
by mahmud 27 Sep '10

27 Sep '10

Hi there, First, a big thank you and congratulation on a job well done, everyone! Secondly. What is the community take on jfli[1] and jss[1]? I like them both, and I plan to use them heavily to Lispify a few Java libraries. However, the two are incompatible, they both have features I would like to see merged. Have there been any attempts at wrapping the native FFI with something higher level? I am interested in something that does the following: 1) Automatic importing of java packages and making them into Lisp packages. 2) Succinct, case-indifferent syntax. I would like to extend either of them to do: 3) Subclassing of java classes in Lisp. 4) Ability to implement java interfaces in Lisp classes. I have a few more ideas, most of which are feasible, but would like to get the community's input on FFI wrappers before I head off in a solitary direction. Regards. - mahmud

3 2

[armedbear-devel] [ANNOUNCE] ABCL 0.22.0
by Erik Huelsmann 26 Sep '10

26 Sep '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.20.0 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements Java Specification Request (JSR) 223: Java scripting API. The release is a small maintenance release: most efforts were focussed on work happening on branches some of which has already been merged to trunk for 0.23. The release notes can be viewed at http://common-lisp.net/project/armedbear/release-notes-0.22.shtml. and the list of changes at http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES. Latest and older binary and source distributions can be downloaded from http://common-lisp.net/project/armedbear/releases/

1 1

Re: [armedbear-devel] [armedbear-cvs] r12918 - in trunk/abcl: . src/org/armedbear/lisp test/lisp/abcl test/lisp/ansi
by Erik Huelsmann 25 Sep '10

25 Sep '10

Hi Alessio, Thanks! Great to see the branch on trunk now! Bye, Erik. On Sat, Sep 25, 2010 at 12:35 AM, Alessio Stalla <astalla(a)common-lisp.net>wrote: > Author: astalla > Date: Fri Sep 24 18:35:02 2010 > New Revision: 12918 > > Log: > generic-class-file branch merged. > > > Added: > trunk/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-class-file.lisp > trunk/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/src/org/armedbear/lisp/jvm-instructions.lisp > trunk/abcl/test/lisp/abcl/class-file.lisp > - copied unchanged from r12917, > /branches/generic-class-file/abcl/test/lisp/abcl/class-file.lisp > Removed: > trunk/abcl/src/org/armedbear/lisp/opcodes.lisp > Modified: > trunk/abcl/abcl.asd > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compile-system.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/jvm.lisp > trunk/abcl/src/org/armedbear/lisp/known-symbols.lisp > trunk/abcl/test/lisp/ansi/parse-ansi-errors.lisp > >

1 0

[armedbear-devel] generic-class-file branch landed on trunk: who re-enables runtime-class.lisp/RuntimeClass.java?
by Erik Huelsmann 25 Sep '10

25 Sep '10

Finally, the branch which is about implementing a generic class file generator (en rewriting the compiler output generator in terms of it) has landed on trunk. These are the next steps: 1. Devise an api for external users - there are currently *no* exported symbols 2. Rewrite runtime-class.lisp in terms of this API, instead of the old ASM bytecode modifier library. Any takers? Next to the re-enabling of runtime-class.lisp, the other benefit of the branch is that it's now possible to create Java class files from the compiler which contain much more complicated (but hopefully better performing) method patterns. Regards, Erik.

1 0

[armedbear-devel] How to use JARRAY-SET to fill a byte array?
by Chun Tian (binghe) 14 Sep '10

14 Sep '10

Hi again ... ABCL I want to fill a Java byte[] array. But I don't know how to correctly use JARRAY-SET (I should use it, right?): CL-USER(1): (defvar $*byte (jclass "byte")) $*BYTE CL-USER(2): (setf array (jnew-array $*byte 10)) #<jarray [B@7a2ee7e5 {1D7AAA0E}> CL-USER(3): (jarray-set array 1 0) #<THREAD "interpreter" {6E61A414}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.IllegalArgumentException: argument type mismatch'. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): 0 CL-USER(5): (jarray-ref array 0) 0 So, a plain number "1" cannot work, but what else I can do? a object of java.lang.Byte? And, is there any quick way I can fill a byte array using contents from a Lisp array? Regards, Chun Tian (binghe)

3 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel