armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

Re: [armedbear-devel] Qi Lisp II
by Raoul Duke 23 Dec '09

23 Dec '09

how goes Qi on ABCL? cf. http://n2.nabble.com/Qi-on-ABCL-td3001784.html apologies if there's an answer out there that i just haven't hit via googling yet. thanks :)

2 1

[armedbear-devel] [PATCH] jcall(there are multiple matching methods)
by Yoshinori Tahara 23 Dec '09

23 Dec '09

Hello. Attached is a patch which fixes jcall in case there are multiple matching methods. Regards, -- Yoshinori Tahara

6 17

[armedbear-devel] Exception Handling
by Peter Olsen 18 Dec '09

18 Dec '09

Ladies and Gentlemen, I'm writing to ask how to handle exceptions generated in Java code called from ABCL. I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp. One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these? I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls. Thanks! Peter Olsen -- Peter Olsen, P.E., Ae.E. olsen(a)sigmaxi.net Engineering is the art of using a professional knowledge of mathematics and the physical sciences to get things done.

5 5

[armedbear-devel] abcl 0.17 & slime 1:20080223-2
by Durward McDonell 11 Dec '09

11 Dec '09

Hello. I have been trying to get abcl to run under slime, and I have hit the limits of my understanding of all the relevant components. This is on Ubuntu Jaunty (9.04), with abcl 0.17.0 and slime 1:20080223-2. The symptom is that slime starts to load, then quits with the error "Package "CLC" not found." I tracked this down to swank-loader: binary-pathname calls clc:calculate-fasl-root. I've tried everything I could think of, like loading clc from my .abclrc, but I could not trick it into loading. This must be a solved problem, but I have not been able to find anything on the web. On a tangentially related note, in doing all this I discovered that asdf integrates with sbcl specially, in a way that makes it a little bit easier to load packages. Is there a way to get abcl to look in more than one directory for (load "foo.lisp")? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu

2 2

[armedbear-devel] Faster startup on GAE
by Erik Huelsmann 08 Dec '09

08 Dec '09

One of the conclusions of many of the profiles that we've been doing on our code base was that our boot up loads compiled functions through reflection. However, reflection is a very costly business, so it's best avoided. This is specially notable with Google App Engine which allows limited time per request, but uses that time limit on all requests including the first - which needs to initialize the entire JVM (!). To reduce the time spent on booting ABCL, I changed our class loading routine (on a branch) to *only* resolve byte code into classes which are actually required for execution of the lisp code which is currently executed. All other functions stay in memory without being resolved into classes, preventing invocations of reflection. With this method - which is in branches/fast-boot-preloading - we've reduced GAE startup times from 19000 cpu_ms to roughly 11000 cpu_ms. I intend to clean up the code - adding documentation and code comments - and moving this to the trunk. To anybody who wants a stable release: this is at the heart of the implementation; please help us test it with your application(s)! With kind regards, Erik.

1 0

[armedbear-devel] AASTORE Removal - Bounds checking
by logicmoo＠gmail.com 03 Dec '09

03 Dec '09

With the execute(...) functions in Primitive.java @Override public LispObject execute(LispObject first, LispObject second, LispObject third) { LispObject[] args = new LispObject[3]; args[0] = first; args[1] = second; args[2] = third; return execute(args); } Should probably be transformed to @Override public LispObject execute(LispObject first, LispObject second, LispObject third) { return execute(new LispObject[]{first,second,third}); } To remove the redundant bounds checking of AASTORE

2 2

[armedbear-devel] Virtual call removal patch
by Ville Voutilainen 29 Nov '09

29 Nov '09

Here's a patch that removes some virtuals from LispObject. My measurements show a small positive performance impact. I see no reason not to apply this patch, so please holler if you have any complaints. Erik, does this require a fasl version update? I imagine yes, but I'm not 100% sure, and haven't have time to check.

1 0

[armedbear-devel] Bug in translate-logical-pathname.
by Thomas Russ 26 Nov '09

26 Nov '09

There seems to be a bug in TRANSLATE-LOGICAL-PATHNAME when the logical pathname source includes constant elements in addition to wildcards. Here is an example that demonstrates the problem: CL-USER(1): (setf (logical-pathname-translations "L") '(("L:NATIVE;**;*.*" "/usr/lisp/abcl/native/**/*.*"))) ((#P"L:NATIVE;**;*.*" #P"/usr/lisp/abcl/native/**/*.*")) CL-USER(2): (translate-logical-pathname "L:NATIVE;TEST;FOO.FASL") #P"/usr/lisp/abcl/native/native/test/foo.fasl" ;; ERROR. Should be #P"/usr/lisp/abcl/native/test/foo.fasl" ;; ;; With :wild-inferiors, the full directory path is copied instead of ;; just the part after the matching constant part. That results in ;; the "native" element appearing twice. ;; The problem seems to be in the file "abcl/src/org/armedbear/lisp/ pathnames.lisp", in the function SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS: (defun translate-directory-components (source from to case) (cond ((null to) nil ) ((memq (car to) '(:absolute :relative)) (cons (car to) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car to) :wild) (if (eq (car from) :wild) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) (error "Unsupported case 1: ~S ~S ~S" source from to)) ) ((eq (car to) :wild-inferiors) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) (t ;; "If the piece in TO-WILDCARD is present and not wild, it is copied ;; into the result." (append (casify (car to) case) (translate-directory-components source from (cdr to) case)) ) )) The final COND clause ("T") needs to be more sophisticated in what it does. If there are non-wildcard elements in the FROM, then it will need to eliminate the the common prefix between "source" and "from". In order to be a valid match, it I think it SHOULD be guaranteed that a non-wildcard "from" component is a leading subsequence or equal to "source" -- but I'm not fully familiar with the code, but a quick test seems to indicate that the following modified function covers at least the simpler cases of this issue. It adds a new clause checking for :WILD-INFERIORS in the FROM slot which performs the current function, and changes the T clause to properly manage the subsequence matching. (defun translate-directory-components (source from to case) (cond ((null to) nil ) ((memq (car to) '(:absolute :relative)) (cons (car to) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car to) :wild) (if (eq (car from) :wild) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) (error "Unsupported case 1: ~S ~S ~S" source from to)) ) ((eq (car to) :wild-inferiors) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car from) :wild-inferiors) ;; "If the piece in TO-WILDCARD is present and not wild, and the FROM item ;; doesn't contain any constants, then just copy TO to the result." (append (casify (car to) case) (translate-directory-components source from (cdr to) case))) (t ;; "If the piece in TO-WILDCARD is present and not wild, then FROM should ;; be a subsequence of SOURCE. The common subsequence needs to be removed ;; in the recursive call. Special case handling for a full match is ;; also needed." (let ((pos (mismatch (car source) (car from) :test #'string- equal))) (append (casify (car to) case) (if (null pos) ;; A full match, pop both source and from (translate-directory-components (cdr source) (cdr from) (cdr to) case) (translate-directory-components (cons (subseq (car source) pos) (cdr source)) (cdr from) (cdr to) case)))) ) ))

5 5

Re: [armedbear-devel] DEFUN (SETF ...)s
by dmiles＠users.sourceforge.net 23 Nov '09

23 Nov '09

Ah, look at this: (offline Erik suggested something) Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.766 seconds. Startup completed in 1.642 seconds. Type ":help" for a list of available commands. CL-USER(1): (require "JAVA") ("CLOS" "JAVA-EXTENSIONS") CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") "stuff" CL-USER(3): If my app calls (require "JAVA") first that's not a bad thing When I use Allegro Lisp I gotta call a few forms before #'jfield works :) (require :jlinker) (use-package "javatools.jlinker") (jlinker-init) It is kinda a hard call to know when we have to require the user to (require ..something..) ? so much in ABCL happens by magic.. I get spoiled > > ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 12:38 PM > Subject: Re: [armedbear-devel] DEFUN (SETF ...)s > > > It might be related to autoloading: java.lisp is not autoloaded by > (setf jfield), but it is by the debugger, so after the error it works. > If that is the problem, I don't have the solution... other than > calling some function defined in java.lisp before (setf jfield), but > that's not pretty. > > hth, > Alessio > > On Mon, Nov 23, 2009 at 9:30 PM, <logicmoo(a)gmail.com> wrote: >> It looks to be a loadtime thing (offline Erik thought maybe it was so) >> See this output: >> >> Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) >> Java 1.6.0_10 Sun Microsystems Inc. >> Java HotSpot(TM) 64-Bit Server VM >> Low-level initialization completed in 0.658 seconds. >> Startup completed in 1.516 seconds. >> Type ":help" for a list of available commands. >> CL-USER(1): (jfield "dmiles.TestClass" "StaticField") >> "fresh" >> CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> Debugger invoked on condition of type UNDEFINED-FUNCTION: >> The function (SETF JFIELD) is undefined. >> Restarts: >> 0: TOP-LEVEL Return to top level. >> [1] CL-USER(3): 0 >> CL-USER(4): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> Debugger invoked on condition of type UNDEFINED-FUNCTION: >> The function (SETF JFIELD) is undefined. >> Restarts: >> 0: TOP-LEVEL Return to top level. >> [1] CL-USER(5): :bt >> 0: (SYSTEM:BACKTRACE) >> 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {27F40B69}>) >> 2: org.armedbear.lisp.Lisp.error(Lisp.java:365) >> 3: org.armedbear.lisp.SpecialOperators$14.execute(SpecialOperators.java:493) >> 4: org.armedbear.lisp.Lisp.eval(Lisp.java:461) >> 5: org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) >> 6: org.armedbear.lisp.Lisp.eval(Lisp.java:471) >> 7: org.armedbear.lisp.Lisp.progn(Lisp.java:640) >> [1] CL-USER(6): 0 >> CL-USER(7): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> "stuff" >> CL-USER(8): >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >>

1 0

Re: [armedbear-devel] DEFUN (SETF ...)s
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

It looks to be a loadtime thing (offline Erik thought maybe it was so) See this output: Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.658 seconds. Startup completed in 1.516 seconds. Type ":help" for a list of available commands. CL-USER(1): (jfield "dmiles.TestClass" "StaticField") "fresh" CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") Debugger invoked on condition of type UNDEFINED-FUNCTION: The function (SETF JFIELD) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): 0 CL-USER(4): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") Debugger invoked on condition of type UNDEFINED-FUNCTION: The function (SETF JFIELD) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {27F40B69}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:365) 3: org.armedbear.lisp.SpecialOperators$14.execute(SpecialOperators.java:493) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:461) 5: org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) 6: org.armedbear.lisp.Lisp.eval(Lisp.java:471) 7: org.armedbear.lisp.Lisp.progn(Lisp.java:640) [1] CL-USER(6): 0 CL-USER(7): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") "stuff" CL-USER(8):

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel