armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

[armedbear-devel] Site is down
by Victor 08 Apr '15

08 Apr '15

Hi, I noticed that http://armedbear.org/abcl.html points to the Common-Lisp.net project page that redirects to www.abcl.org that is currently down. Is it possible either to restore the site or turn the redirect off? Thanks, Victor

1 0

[armedbear-devel] Catching exceptions from toString() methods
by Olof-Joachim Frahm 08 Apr '15

08 Apr '15

Hi, I've mentioned this on IRC, just so it isn't forgotten: I was getting some objects from Hibernate in the REPL, which worked fine until the toString() method of an object was called and threw an exception, terminating ABCL completely. Attached is a patch which catches all exceptions during the printObject() method of JavaObject. Best regards, Olof

2 1

[armedbear-devel] threads:interrupt-thread
by Carlos Ungil 08 Apr '15

08 Apr '15

Hello, is there a reason why interrupt-thread doesn't seem to run the requested function in some cases? The following code tries to run a function in each existing thread (the variable *output* logs the calls that we try to run and the ones that are actually run). (defvar *output*) (defun test-run () (setf *output* nil) (threads:mapcar-threads (lambda (thread) (push (format nil "~A : calling" thread) *output*) (threads:interrupt-thread thread (lambda () (push (format nil "~A : running" thread) *output*)))))) (defun test-report () (format t "~{~A~%~}" (reverse *output*))) Running in the command line: CL-USER(5): (threads:make-thread #'test-run :name "TEST-RUN") #<THREAD "TEST-RUN" {49BBE826}> CL-USER(6): (test-report) #<THREAD "TEST-RUN" {49BBE826}> : calling #<THREAD "interpreter" {409CB8AF}> : calling I can understand that the thread "TEST-RUN" that I create to run the function might disappear before it gets to run the function as requested, or maybe the reason is that a thread can't interrupt itself by design... But why doesn't the thread "interpreter" run the function? Running in slime there are many threads present, and most of them will respond as expected. But "TEST-RUN", "interpreter" and "reader-thread" won't. #<THREAD "control-thread" {3C036436}> : calling #<THREAD "reader-thread" {10A08BAA}> : calling #<THREAD "swank-indentation-cache-thread" {2A83402}> : calling #<THREAD "Swank Sentinel" {66E71110}> : calling #<THREAD "repl-thread" {699D8335}> : calling #<THREAD "Swank Sentinel" {66E71110}> : running #<THREAD "TEST-RUN" {4E0267BA}> : calling #<THREAD "repl-thread" {699D8335}> : running #<THREAD "auto-flush-thread" {6913E490}> : calling #<THREAD "interpreter" {1902DFD5}> : calling #<THREAD "auto-flush-thread" {6913E490}> : running #<THREAD "swank-indentation-cache-thread" {2A83402}> : running #<THREAD "control-thread" {3C036436}> : running Cheers, Carlos

1 0

[armedbear-devel] Disable debugger completely
by Jonathan Fischer Friberg 08 Apr '15

08 Apr '15

Hi, This is related to my previous question on catching cl errors in java. This time, I would like to know if it's possible to completely disable the debugger. The error catching that I'm currently using (from the previous thread) works fine, but some things can still escape. Whenever the debugger is started, my whole program locks up for some reason and I'm unable to resume. Jonathan

1 0

[armedbear-devel] Bugs
by Faré 08 Apr '15

08 Apr '15

Testing ASDF found several bugs in ABCL. cd ~/cl/asdf/ abcl --noinform --eval '(or`#.(load(string`|test/script-support.lisp|)`:verbose():print())#.(asdf-test::exit-lisp`0))' Failed to require LOOP because 'Illegal function object: (bqv).' Maximum error depth exceeded (11 nested errors) with 'Illegal function object: (bqv).'. abcl --noinform --eval "(or'#.(load(string'|test/script-support.lisp|):verbose():print())#.(asdf-test::exit-lisp'0))" So your backquote parser is broken somehow. Also, upgrading from ASDF 2.25 or 2.26 used to work, but not anymore. Now 2.27 is needed (as configured in header.lisp, and tested with make u l=abcl ASDF_UPGRADE_TEST_TAGS=2.25). Finally, there are many instances of abcl in #+ or #- in the test/ directory, including two new ones in test-bundle on Mac (which is a regression from abcl 1.1.0) and in test-stamp-propagation (which is a new test, and a bug shared with XCL). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Not all Law is created equal before Man. Some Law causes least conflict and least perverse incentives. By definition we call it Natural Law.

2 8

[armedbear-devel] Bug report: non-standard metaclass causes aberrant behaviour
by William Hounslow 08 Apr '15

08 Apr '15

Dear maintainers #1 a user-defined allocate-instance method is not called at all #2 slot-missing is called with a slot-name of nil #3 update-dependent is not being applied to its keyword arguments Best regards William "1.2.1" "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_17-b02" "x86-Windows_7-6.1" ;;;#1 CL-USER(2): (defclass quux-class (standard-class) ()) #<STANDARD-CLASS QUUX-CLASS {D2A36B}> CL-USER(3): (defmethod allocate-instance :after ((class quux-class) &rest initargs) (format t "allocated ~S~%" class)) #<STANDARD-METHOD ALLOCATE-INSTANCE :AFTER (QUUX-CLASS) {14A0B92}> CL-USER(4): (defclass quux nil (bar) (:metaclass quux-class)) #<QUUX-CLASS QUUX {50039B}> CL-USER(5): (make-instance *) #<QUUX {B2D899}> CL-USER(6): (inspect (fdefinition 'allocate-instance)) 0 LAYOUT -----------> #<LAYOUT {BEF803}> 1 NAME -------------> ALLOCATE-INSTANCE 2 LAMBDA-LIST ------> (CLASS &REST ...) 3 REQUIRED-ARGS ----> (CLASS) 4 OPTIONAL-ARGS ----> NIL 5 INITIAL-METHODS --> NIL 6 METHODS ----------> (#<STANDARD-METHOD ALLOCATE-INSTANCE :AFTER (QUUX-CLASS) {14A0B92}> #<STANDARD-METHOD ALLOCATE-INSTANCE :BEFORE (CLASS) {18C9692}> ...) 7 METHOD-CLASS -----> #<STANDARD-CLASS STANDARD-METHOD {A801B0}> 8 %METHOD-COMBINATION -> #<METHOD-COMBINATION STANDARD {F167BB}> 9 ARGUMENT-PRECEDENCE-ORDER -> (CLASS) 10 DECLARATIONS -----> NIL 11 CLASSES-TO-EMF-TABLE -> #<EQUAL HASH-TABLE 0 entries, 11 buckets {D15EE4}> 12 %DOCUMENTATION ---> NIL ;;;#2 CL-USER(11): (make-instance 'quux) #<QUUX {F2AE7E}> CL-USER(12): (slot-value * 'baz) #<THREAD "interpreter" {1A2FE4D}>: Debugger invoked on condition of type SIMPLE-ERROR The slot NIL is missing from the class #<QUUX-CLASS QUUX {50039B}>. Restarts: 0: TOP-LEVEL Return to top level. ;;;#3 CL-USER(2): (defclass foo-class (standard-class) ()) #<STANDARD-CLASS FOO-CLASS {14A123F}> CL-USER(3): (defclass foo-dep () ()) #<STANDARD-CLASS FOO-DEP {145B486}> CL-USER(4): (defmethod mop:update-dependent ((class foo-class) (dep foo-dep) &key direct-slots &allow-other-keys)) #<STANDARD-METHOD MOP:UPDATE-DEPENDENT (FOO-CLASS FOO-DEP) {155388B}> CL-USER(5): (defclass foo () (bar) (:metaclass foo-class)) #<FOO-CLASS FOO {25D10A}> CL-USER(6): (mop:add-dependent * (make-instance 'foo-dep)) (#<FOO-DEP {F167BB}>) CL-USER(7): (trace mop:update-dependent) (MOP:UPDATE-DEPENDENT) CL-USER(8): (defclass foo () (bar baz) (:metaclass foo-class)) 0: (MOP:UPDATE-DEPENDENT #<FOO-CLASS {25D10A}> #<FOO-DEP {F167BB}> (:DIRECT-SUPERCLASSES NIL :DIRECT-SUPERCLASSES NIL DIRECT-SLOTS ((:NAME BAR) (:NAME BAZ)))) #<THREAD "interpreter" {886140}>: Debugger invoked on condition of type PROGRAM-ERROR Odd number of keyword arguments. Restarts: 0: TOP-LEVEL Return to top level.

2 1

[armedbear-devel] CLOS for ABCL based on interpreted Closette?
by ubikation _ 08 Apr '15

08 Apr '15

I've been trying to read AMOP and looking at the Closette code. It seems to me that ABCL uses Closette for CLOS... but the original Xerox code seems to explicitly warn against using it for compiled CLOS. I was just wondering if this is perhaps the reason for the performance issues of CLOS in ABCL. Do other CL implementations use Closette? The text is "Load this source file directly, rather than trying to compile it." from here: http://homepage.stat.uiowa.edu/~luke/xls/xlispstat/other/closette/closette.… Thanks!

1 0

[armedbear-devel] Compiler loses lexical macro in (eval-when (:compile-toplevel ...))
by Douglas Katzman 08 Apr '15

08 Apr '15

Hi. This code fragment works with (LOAD "/tmp/foo.lisp") but not (COMPILE-FILE "/tmp/foo.lisp") (eval-when (:compile-toplevel :load-toplevel :execute) (defvar *count* 0) (macrolet ((something (sym) `(setf (get ,sym 'uniqueid) (incf *count*)))) (defun register-it (x) (something x)))) (eval-when (:compile-toplevel :execute) (format t "~&OK so far~%") (register-it :foo)) (eval-when (:compile-toplevel :execute) (format t "~&Got ~D~%" (symbol-plist :foo))) Armed Bear Common Lisp 1.3.0 Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.258 seconds. Startup completed in 1.231 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/tmp/foo.lisp") ; Compiling /private/tmp/foo.lisp ... ; (DEFVAR *COUNT* ...) ; (DEFUN REGISTER-IT ...) OK so far #<THREAD "interpreter" {3A284BEE}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SOMETHING is undefined. Restarts: ...

2 1

[armedbear-devel] Problem in CLOS MOP in abcl 1.2.0
by Pascal Costanza 08 Apr '15

08 Apr '15

Hi, There is a problem in the MOP implementation in abcl 1.2.0: It seems that the parameter list for std-find-method-combination has changed, but the corresponding :initform for :method-combination for standard-generic-function has not been updated to reflect this. I now get an error that std-find-method-combination gets the wrong number of arguments in my test suites. I don't have a good idea how to work around this problem in Closer to MOP, so I believe I cannot officially declare support for abcl 1.2.0. Another recommendation: The *features* list currently doesn't provide a way to detect the version of abcl. Most Common Lisp implementation have one convention or the other to encode this information. If I had a workaround for the above problem, detecting the version via *features* would allow me to provide a version of Closer to MOP that works with several versions of abcl. (This may, however, not be as crucial as for the commercial implementations.) Best, Pascal -- Pascal Costanza

2 1

Re: [armedbear-devel] Site is down
by Victor 08 Apr '15

08 Apr '15

On Wed, 09 Oct 2013 16:19:45 +0300, Victor <bobbie(a)ua.fm> wrote: > On Wed, 09 Oct 2013 16:11:34 +0300, Erik Huelsmann <ehuels(a)gmail.com> wrote: > >> Thanks for the heads-up. The site should be up again. > > Hi Erik, > > the server/host is now up on the internet again but instead of a nice Welcome page it shows a directory listing that reminds me of common-lisp.net before its upgrade. The site is back again. Thanks! > > Thanks, > Victor > > >> >> >> >> On Wed, Oct 9, 2013 at 2:17 PM, Victor <bobbie(a)ua.fm> wrote: >> >>> Hi, >>> >>> I noticed that http://armedbear.org/abcl.html points to the >>> Common-Lisp.net project page that redirects to www.abcl.org that is >>> currently down. >>> >>> Is it possible either to restore the site or turn the redirect off? >>> >>> Thanks, >>> Victor >>> >>>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel