armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

[armedbear-devel] java interop question
by Kevin Raison 14 Oct '10

14 Oct '10

I am an old hand at cl, but java is still a bit of a mystery to me. I am particularly puzzled as to why, when trying to use the apache http components library to do a simple http get in abcl, I cannot make it work. My code: (defun http-get (url) (let* ((url (jnew (jclass "java.lang.String") url)) (client-class (jclass "org.apache.http.impl.client.DefaultHttpClient")) (client-obj (jnew client-class)) (get-class (jclass "org.apache.http.client.methods.HttpGet")) (get-obj (jnew get-class url))) (jcall (jmethod client-class "execute") client-obj get-obj))) And the java code from the apache tutorial http://hc.apache.org/httpcomponents-client-4.0.3/tutorial/html/fundamentals…: HttpClient httpclient = new DefaultHttpClient(); HttpGet httpget = new HttpGet("http://localhost/"); HttpResponse response = httpclient.execute(httpget); ... For some reason, my code fails with No such method: org.apache.http.impl.client.DefaultHttpClient.execute(). I do have the appropriate jars in my class path. The java code specifically calls the execute method on its instantiated httpclient, but I cannot do the same from abcl. This method is inherited from org.apache.http.impl.client.AbstractHttpClient, in case that makes a difference. (http://hc.apache.org/httpcomponents-client-4.0.3/httpclient/apidocs/index.h…). Thanks for any insight! -Kevin

3 4

[armedbear-devel] AbclScriptEngine exits on load
by Ole Myren Rohne 08 Oct '10

08 Oct '10

Hi ABCL-developers, Thank you for releasing abcl-0.22! I'm playing with AbclScriptEngine (with Electric VLSI) and found a tiny problem with config.lisp: EXT:MAKE-THREAD should be THREADS:MAKE-THREAD. Unfortunately the problem was unnecessary hard to debug because in the absence of TPL::REPL the debugger ends up quitting the entire application. I'm wondering if in that case it would be more useful to throw a Java error, eg like SYS::%DEBUGGER-HOOK-FUNCTION? Best regards, Ole

3 3

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

04 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel