armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[armedbear-devel] Dynamic classpath settings (ticket #18)
by Erik Huelsmann 24 Jan '11

24 Jan '11

Hi Alessio, There's a ticket (#18, http://trac.common-lisp.net/armedbear/ticket/18) to add dynamic classpath capabilities to ABCL, just as used by invoke.lisp. Browsing through our sources, I think you may have added this capability already. Can the issue be closed? Bye, Erik.

3 3

[armedbear-devel] [ANNOUNCE] ABCL 0.24.0 released
by Erik Huelsmann 22 Jan '11

22 Jan '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.24.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 JSR 223: Java scripting API. This release features - among lots of other things - improved embedding support through elimination of System.exit() calls and fixes a regression causing FASLs to be limited in the number of functions they can contain. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.24.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-src-0.24.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.ta… http://common-lisp.net/project/armedbear/0.24.0/releases/abcl-src-0.24.0.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.ta… http://common-lisp.net/project/armedbear/releases/0.24.0/abcl-bin-0.24.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.24.0.zip.asc

1 0

[armedbear-devel] Design issue regarding condition printing (was: Error reporting problems)
by Erik Huelsmann 22 Jan '11

22 Jan '11

In order to start addressing our issue with error reporting, I thought I'd start poking around at the source of all Java based exception classes (of which both PROGRAM-ERROR and SIMLE-ERROR are part). This source is the Condition java class. In the class 3 methods have been defined, all related to printing of (java based) errors: * getMessage() [overridden 13 times, 8 call sites] * getConditionReport() [not overridden, 1 call site] * writeToString() While the role of "writeToString()" is clear (it's called by PRINT to print all Java-based objects) and hence should function differently under different circumstances, the role separation between getMessage() and getConditionReport() isn't quite so well defined. This conclusion comes both from the extreme lack of documentation as well as the following: getConditionReport() calls getMessage() to find an "alternative message" to be reported. getMessage() finds out if there's a formatControl string; if there is, it calls writeToString() to generate a message, returning that to getConditionReport(). If getConditionReport() doesn't get an alternative from getMessage() to return back to the caller, it calls Lisp.format() to generate a formatted string to be presented to the user. However, this second path will never get called, except when there's no format string.... Lisp.format() explicitly checks for a null format control string and returns an empty string - which explains why we haven't seen crashes from the above code paths. So, how does that tie into the grand scheme of error reporting? We have two places where errors are being reported: 1. the lisp debugger, which prints errors using the real (lisp based) FORMAT function if it's autoloaded (but falls back to Lisp.format() if FORMAT isn't autoloaded yet) which is invoked by INVOKE-DEBUGGER-REPORT-CONDITION 2. the ERROR place holder Primitives.ERROR() which calls Condition.getConditionReport() The Lisp based FORMAT uses PRINT-OBJECT to print conditions. PRINT-OBJECT.lisp defines specialized instances for several classes in the condition class hieranchy. I know I added some in order to try to address the exact issue we're talking about here. The Java based Lisp.format() function uses <condition>.writeToString() to produce its output. With all these facts on the table, I think we need to do a few things to clean up the mess: - Any condition overriding getMessage() in order to call FORMAT should be removed - getMessage() should be documented *not* to use writeToString() on its own instance - getConditionReport() should be documented not to be overridden, but to override getMessage() instead (maybe declare 'final'?) - Remove all the special methods for classes derived from CONDITION in the print-object.lisp file: they should all fall back to the general method for printing conditions. - Both INVOKE-DEBUGGER-REPORT-CONDITION and Lisp.ERROR should bind the following variables to these listed values, in order to make sure conditions are printed for humans: *print-readably* nil --> all other *print-** variables bound like the values specified for WITH-STANDARD-IO-SYNTAX (except maybe *PRINT-ESCAPE*) The above looks like it should solve our issues. I'd greatly welcome any comments: it's a rather big change, judging by the description above. Ville, you were going to look at it, maybe you can verify if I'm half way right? Bye, Erik.

4 7

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

Hello, could you please make the method getStatus from the class ProcessingTerminated public? One need this to mimic what the Main class/function does from /outside/ the ABCL package. Thank you! -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com

1 0

[armedbear-devel] Please make getStatus public (thanks :-)
by Didier Verna 18 Jan '11

18 Jan '11

1 0

[armedbear-devel] Another error message enhancement request
by Blake McBride 15 Jan '11

15 Jan '11

I just got the following error: #<THREAD "http-8084-1" {41ABA945}>: Unhandled condition of type SIMPLE-ERROR: The method has the wrong number of required arguments for the generic function. Which method? I have a macro that creates many, many methods. If it gave me the method name I'd be able to track the problem easily. I am embedding ABCL in a very large web application. Starting and stopping the server takes a significant amount of time, and I have no command line access to the code. Giving me the name of the method in question could save me 30 minutes easily. Thanks. Blake McBride

1 0

[armedbear-devel] Error condition is too strong
by Blake McBride 14 Jan '11

14 Jan '11

Greetings, I am in the process of embedding ABCL into a web server application I have. While it is okay for an error to either be caught and handled, or not handled and having the thread terminate, it definitely is not okay for an error condition to kill the entire server. I am executing a (load "file") command (where "file" doesn't exist) from Java and it kills the entire server. I tried enclosing it in a try/catch block (I tried Exception & Throwable) and it still killed the server. I then replaced the load with (without a try/catch): File file = null; file.canRead(); And the error didn't kill the server. I just got a backtrace and the thread ended. (I think the error was caught higher up.) Is ABCL calling System.exit() or doing something similar? Thanks. Blake McBride

3 5

[armedbear-devel] Alex Muscar wants to stay in touch on LinkedIn
by Alex Muscar 14 Jan '11

14 Jan '11

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Alex Muscar Alex Muscar Student at Universitatea din Craiova Romania Confirm that you know Alex Muscar https://www.linkedin.com/e/-if48af-giwrckr2-4k/isd/2142627460/1VpMmRDn/ -- (c) 2010, LinkedIn Corporation

1 0

[armedbear-devel] Proposed solution to the "too many functions in FASL" problem
by Alessio Stalla 13 Jan '11

13 Jan '11

Hello all, since my merge of the less-reflection branch with trunk[1], several of you have been bitten by the new limitation in the number of functions that can be contained in a FASL. The reflection-less scheme requires creating a loader class because it needs to spell out in the bytecode all the class names corresponding to compiled Lisp functions in the FASL. Functions are numbered from 1 onwards and a method is created that is a huge switch (actually a chain of if's) that returns the right function given its index: if(index >= 1 && index < 1024) { if(index == 1) return new function_1(); if(index == 2) return new function_2(); ... } else if(index >= 1024 ... In the presence of many functions, this method grows very large, eventually surpassing the JVM's 64k method size limit. A couple of days ago Erik and I discussed a bit about the issue and how to solve it. One option is to implement method splitting for the big FASL loader method. Method splitting in general is hard (you'd need some form of CPS conversion) but in this case it's quite easy. The current scheme, though, has drawbacks: it's more complicated than it used to be, and it's not that beneficial performance-wise - from a profiling I did a while ago, its performance gains amounted to ~1% of our loading time, which is completely dominated by I/O and UTF-8 decoding. So, there's another option: go back to reflection-based loading. Using reflection has the benefit of being simpler. On certain platforms (e.g. mobile JVMs or similar, like Dalvik), reflection has a higher cost, but we currently don't run satisfactorily on those platforms anyway and we'd require multiple changes to do so. After my discussion with Erik, a further refinement of this second option came to my mind. As part of the no-reflection effort, the compiler was changed to stop emitting calls to loadCompiledFunction(className) in favor of generating `new className()` bytecode for local functions, in accordance with the goal of avoiding reflection as much as possible. A special classloader is used to both resolve those local function references, and to load the FASL loader class (and thus transitively all top-level functions). I propose keeping the compilation of local function references as it is, and thus the special classloader; and use it directly (via reflection) to load top-level functions, instead of generating one big loader method. This would result in slightly less reflection, but more importantly in a clearer function loading scheme, and less development effort compared to returning completely to the reflection-based scheme also for local functions. What do you think? If it's not clear, both Erik and I sponsor the solution of returning to a reflection-based approach, but we'd like to hear everyone's opinions. Bye, Alessio

2 4

[armedbear-devel] Recovering "special slots" after package deletion
by Erik Huelsmann 11 Jan '11

11 Jan '11

The other day, Ville and I were discussing the issue with recovery of "special slots" after package deletion on IRC. Let me start by describing the problem for you first. After that I'll describe the solution I see, however, your feedback on the solution is very much appreciated. Special symbol slots? ABCL - like SBCL and CCL - uses a thread-local array containing the 'current' values of its special variables. All symbols which have been declared or declaimed special at one point or another have been assigned an index in this array. This method allows very quick access to the special value (and hence the symbol value) with only a single level of added indirection: the symbols hold the number of their index in the array, meaning that having a reference to the symbol and the current thread is enough to find its value. When I implemented it, it was a huge difference with respect to the method we were using before. Do those need release? Since packages can be deleted, symbols be garbage collected. In the current implementation, GC-ing a special symbol will leave the slot it was assigned unused. There's no way the slot gets reassigned, because nothing keeps track of these 'dead' slots. To make matters worse: there may be huge lisp structures referenced in the dead slot, because it's also not cleared out. In the very long run, this will cause issues in scenarios as Blake describes where one creates, deletes and re-creates packages. The symbols in the packages are new symbols on every re-creation. Yet there are only 4096 spots in the special-symbols table. The solution? Well, the solution I see is to use the Object.finalize() method to release the index back to a freelist. There's a downside here though: the 4096 slots may run out before a multi-gb system sees its first GC run. There are two ways out here: grow the table once we run out of free slots (even though many potentially free slots may be pending GC). Or force a gc/runFinalization() run when running out of indices. Surely a combination of both would also be an option. Ville partially objects to the above because he's used to the pattern "you can't depend on finalize() to be invoked". Reading its documentation and googling the topic a bit, I see that finalize() can't be depended upon especially on JVM termination. However, that particular case isn't interesting here: we're looking at releasing "memory" related resources, which seems to be the exact purpose of finalize() as described in all the web docs I found. Can you comment? Is my approach as sane as I think it is? Bye, Erik.

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel