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

[armedbear-devel] Question about calling Java
by Mark Evenson 04 Feb '10

04 Feb '10

Usually, I can find a way to translate given Java code into the ABCL equivalent. Sometimes it takes quite a while to figure the correct syntax which I attribute to the organically evolved nature of our Java integration, but I have never found something ultimately unexpressable. Until now, although I think this has to do with me trying to debug ABCL internals with the ABCL REPL, but I want to document it. Have I missed some way of making this call? The code: SimpleString h = new SimpleString("FOO"); Pathname.LOGICAL_PATHNAME_TRANSLATIONS.get(h)); LOGICAL_PATHNAME_TRANSLATIONS is a EqualHashTable object whose signature of get() is LispObject get(LispObject key) This fails (jcall "get" (jfield "org.armedbear.lisp.Pathname" "LOGICAL_PATHNAME_TRANSLATIONS) (jnew "org.armedbear.lisp.SimpleString" "FOO")) with the error The value "org.armedbear.lisp.SimpleString" is not of type JAVA-OBJECT Diving into the code shows that the Java.translateMethodArguments() call is always going to translate the SimpleString argument into a instance of java.lang.String as this is what SimpleString.javaInstance() returns. Is there any way to tell JCALL not to perform such translation on its arguments? JCALL-RAW doesn't convert its return value, but maybe we need a JCALL-NAKED that doesn't translate its arguments? I suspect that we don't need JCALL-NAKED for anyone not using Java objects that are descendents of org.armedbear.lisp.LispObject but I'm not exactly sure how to prove this claim. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

8 20

Re: [armedbear-devel] translate-logical-pathname and :wild-inferiors regression
by Alan Ruttenberg 04 Feb '10

04 Feb '10

Thanks Mark! A confusing area of common lisp for sure... -Alan On Thursday, February 4, 2010, Mark Evenson <evenson(a)panix.com> wrote: > On 2/3/10 8:22 PM, Alan Ruttenberg wrote: > […] > > pre-r12283 ABCL was buggy in a different way. My best understanding is > that the behavior observed in sbcl and my patched abcl is correct. > > > Ok, now I think I understand the problem Sorry for the confusion on my part. > > Your fix [has been committed in r12147][1]. > > [1]: http://trac.common-lisp.net/armedbear/changeset/12417 > > > -- > "A screaming comes across the sky. It has happened before, but there > is nothing to compare to it now." >

1 0

[armedbear-devel] translate-logical-pathname and :wild-inferiors regression
by Alan Ruttenberg 04 Feb '10

04 Feb '10

A recent commit (dec 2009) seems to have changed the behavior of wild-inferiors. Prior to the change :wild-inferiors would match 0 or more pathname components. After the change 1 or more. e.g. (TRANSLATE-PATHNAME #P"IDO:IMMUNOLOGY;" #P"IDO:IMMUNOLOGY;**;*.*" #P"/Users/alanr/repos/infectious-disease-ontology/trunk/src/ontology/**/*.*") Used to work, but now fails. Unsupported case in TRANSLATE-DIRECTORY-COMPONENTS. -Alan

3 12

[armedbear-devel] Lisp / Java interface utilities and examples
by Blake McBride 03 Feb '10

03 Feb '10

Greetings, Enclosed are the completed Lisp and Java utilities designed to make Lisp / Java interaction easier. It also includes an example / tutorial program. If it is appropriate, I'd like to have these added as one of the ABCL examples in the distribution. Also, if it is advantageous, perhaps we can move the Lisp and Java utilities to be part of ABCL. Thanks. Blake McBride

4 10

[armedbear-devel] Maxima status: performance measurement
by Erik Huelsmann 01 Feb '10

01 Feb '10

Hi Robert, hi all, Today, I ran Maxima through ABCL's profiler to see what's our current status. With our combined changes, we seem to have reduced the throughput time of the Maxima tests on my system from 2200 secs to roughly 1800 secs between October and now. These are the hotest spots now: 3.0 4352336 SIGN01 3.0 4354363 $SIGN 3.1 4531219 MEVALARGS 3.2 4633287 MREAD-RAW 3.2 4633902 MREAD 3.3 4740203 SIGN1 3.7 5402701 SIMPEXPT 4.4 6365392 $FLOAT 4.5 6469447 RECUR-APPLY 4.5 6521950 TEST-BATCH 5.8 8452081 SIMPLIFYA 8.4 12224550 NUD-CALL 11.3 16314266 DLSF 11.3 16362213 DLS 12.2 17658492 PRSMATCH 12.4 17982535 DGRF 12.5 18054353 DGR 20.6 29854294 PARSE-INFIX 22.3 32246473 MEVAL* 22.4 32372076 MEVALN 54.5 78912363 LED-CALL 55.5 80291167 PARSE 59.5 86114793 MEVAL1 60.7 87813616 MEVAL 64.2 92947288 MHEADER 65.2 94346436 STREAM-NAME 65.2 94346559 INSTREAM-NAME 65.2 94346854 PATHNAME 65.2 94347835 ADD-LINEINFO As you can see, the DGR(F) functions which relate to the integrator tests have now been removed from being the main bottle necks. It looks like some evaluator is now our 'hottest' spot. Robert, could you help us to see what we should do to optimize the functions which are now our main performance issue? Thanks in advance! Bye, Erik.

2 1

[armedbear-devel] Development status recap
by Erik Huelsmann 30 Jan '10

30 Jan '10

A lot of different efforts are going on at the moment. So I thought I'd try to write down the efforts and their status as far as I know. Both to be informational, or to comment upon to correct my understanding. 1. The Gray streams effort We're slowly progressing on this issue: a design was agreed upon and Ville has added that to the wiki. Next steps include setting up the right java and lisp code for the structure ANSI-STREAM to hold closures used for I/O processing. Basically this design was taken from SBCL. 2. Better inlining of lambda functions and inlined named functions By inlining lambda functions as much as we can, we can reduce the number of reflection calls required to instantiate all our function classes. Alessio is working on creating a function argument matcher which binds the newest PARSE-LAMBDA-LIST on trunk with the function call arguments in order to generate a LET* form instead of a function call. 3. Pathnames as a way to address JAR file content ABCL extends the pathname scheme in CL to address resources in JAR files. However, this support was limited to a small number of pathnames related functions. Mark Evenson is working to improve the situation. 4. DEFINE-METHOD-COMBINATION Mark Evenson started on this issue; however post-poned it to work on item (3). Feel free to pick it up! 5. Local functions in same class file as the function they're defined in Some time ago, I started working on a general class file writer to make it possible to store local functions inside the same class as the function in which they're defined. This effort is progressing very slowly; it's more of a side project to other improvements in the project. It has the same goal as (2): reduction of the number of required reflection calls to get our classes loaded. Bye, Erik.

1 0

[armedbear-devel] long form of define-method-combination
by Tobias C. Rittweiler 30 Jan '10

30 Jan '10

SACLA seems to contain an implementation of the long form of D-M-C: http://homepage1.nifty.com/bmonkey/lisp/sacla/html/lisp/clos.lisp.html It's released under a BSD license, so just copying it into ABCL is viable, but the code may also just be used for inspiration. -T.

3 3

[armedbear-devel] Common central location for system-wide configuration.
by Olsen, Peter C. 30 Jan '10

30 Jan '10

Ladies and Gentlemen, I've come to the point where it would be convenient for me to establish a system-wide run-time configuration so that every invocation of ABCL for every user starts with a few common packages. The only way I can find to do that is to have everyone put the appropriate code in their .abclrc files. I've tried to put a load command in the shell script that starts the interpreter, but it doesn't work. /usr/bin/java -classpath abcl.jar:jscheme.jar org.armedbear.lisp.Main "(load \"invoke.lisp\")" $@ I suggest that we consider changing the processInitializationFile method in Interpreter.java to look for some sort of initialization file in the directory in which abcl.jar is located when the Interpreter starts. That seems to be a simple change. A more elegant solution would be add some code to determine the OS and then look for configuration files in an appropriate place for each one. I'm a newbie to this project, so I don't want to overstep my bounds. Having said that, I'd be happy to make and test the changes I've proposed. Comments (particularly on the OS variation)? Thanks! Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Heterogeneity is inevitable and must be supported by design. (RFC 1958)

4 4

[armedbear-devel] [BUG] EXT:ARGLIST produces bogus case-sensitive arglists
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

`arglist' in `arglist.java' calls `readObjectFromString' which uses the FASL Readtable which is case sensitive. This ain't good because this way the lambda-list keywords (&OPTIONAL etc.) are not properly read back (EXTENSIONS:|&optional|) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] No restarts available on error in thread
by Tobias C. Rittweiler 29 Jan '10

29 Jan '10

Evaluating the following (threads:make-thread #'(lambda () (error "foof")) :name "foof") will get you into the debugger. But there's not restart available. As it does not make sense to provide a RETURN-TO-TOPLEVEL restart for an error occuring in a thread, I think there should be a TERMINATE-THREAD restart instead. And the debugger should probably print the thread's name the error occured in. -T.

2 1