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

[armedbear-devel] ASDF: Cannot handle the special form EXTENSIONS:TRULY-THE
by Blake McBride 24 Mar '13

24 Mar '13

Greetings, Trying to load a package with ASDF I ran into the following error: ASDF could not load because Cannot (currently) handle the special form EXTENSIONS:TRULY-THE. #<THREAD "interpreter" {4BC78066}>: Debugger invoked on condition of type SIMPLE-ERROR Cannot (currently) handle the special form TRULY-THE Restarts: ... I traced the problem to ASDF and not the package I was attempting to load. Does anyone know anything about this? (I am running the latest SVN head of ABCL) Thanks. Blake McBride

6 14

[armedbear-devel] Double printing of the prompt
by Blake McBride 12 Aug '12

12 Aug '12

Greetings, The latest version of ABCL is double printing the prompt at times as follows: Armed Bear Common Lisp 1.1.0-dev-svn-13783 Java 1.6.0_29 Apple Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.465 seconds. Startup completed in 1.453 seconds. Type ":help" for a list of available commands. CL-USER(1): 3 3 CL-USER(2): 'hello HELLO CL-USER(3): '(a b c) (A B C) CL-USER(4): nil NIL CL-USER(5): CL-USER(5): 77 77 CL-USER(6): (cdr '(hello)) NIL CL-USER(7): nil NIL CL-USER(8): CL-USER(8): 3 3 CL-USER(9):

3 3

[armedbear-devel] destroy-thread and unwind-protect
by James Lawrence 08 Aug '12

08 Aug '12

(defun test-cleanup () (let* ((cleanedp nil) (thread (threads:make-thread (lambda () (unwind-protect (sleep 999) (setf cleanedp t)))))) (sleep 0.5) (threads:destroy-thread thread) (sleep 0.5) cleanedp)) (test-cleanup) ABCL-1.0.0 and ABCL-0.27.0 return NIL. Other implementations I tested all return T -- Allegro, Clozure, LispWorks, SBCL (changing "threads" to "bordeaux-threads"). Of course this isn't a bug since ABCL is free to do what it wishes. Does ABCL wish that?

5 5

[armedbear-devel] JSS issues: bug in jss::with-constant-signature, jss::invoke-find-method?
by Jonathan P. Bona 16 May '12

16 May '12

I'm working with Alan Ruttenberg to port LSW from the old version of JSS to the JSS that is now part of abcl-contrib. We've run into the following bug when using with-constant-signature: ; these first two work fine: (#"substring" "some string" 2 4) ; "me" (#"substring" "some string" 2) ; "me string" ; and so does this (with-constant-signature ((substring "substring")) (substring "some string" 2 4)) ; "me" ; but this breaks: (with-constant-signature ((substring "substring")) (substring "some string" 2)) ; Wrong number of arguments for public java.lang.String java.lang.String.substring(int,int): expected 2, got 1 ; [Condition of type PROGRAM-ERROR] A problem seems to be in jss::invoke-find-method, which is finding the two argument version of java.lang.String.substring no matter how many arguments its given: (jss::invoke-find-method "substring" "this is a string" '(1)) ; should return the java.lang.String.substring method with one int arg ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2) ) ; #<method public java.lang.String java.lang.String.substring(int,int)> (jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6 7 8) ) ; should be an error ; #<method public java.lang.String java.lang.String.substring(int,int)> - Jonathan Bona

3 5

[armedbear-devel] Patch with improvements to stable-sort and sort
by Jorge Tavares 07 May '12

07 May '12

Hi, I send in attach a patch with further improvements to sort and stable-sort for sequences other than lists. In short, the patch includes a merge sort for vectors. To allow different types I've written the algorithm using macros and these generate the appropriate code according to the vector type. This way the algorithm is in a single place avoiding duplication of code. The macros also take care of the situation of when no key is present, avoiding the use of unnecessary funcalls. The quicksort algorithm was also refactored in the same way. I've tested the algorithms and they seem to be working correct. Stable sort is now considerably faster since the fix before converted the sequences to a list and used the sort-list function. I've made some benchmarking to verify how fast is sort and stable-sort. The tables with the results are also in a file sent in attach [1]. For stable-sort I've compare the current trunk version with the patched one while for sort I've compared 1.0.1, the trunk and with the patch. For unsorted vectors sort has a speed up of 7.5 from 1.0.1 and this considers only vectors of size 8 to 8192 (1.0.1 hits the worst-case quite fast). For stable-sort the speed up is around 90.2 from vectors of size 8 to 32768. The sort functions become even faster for the nearly sorted vectors. I think the tables clearly show the speed-ups :-) Naturally these benchmarks cannot be used to draw definite conclusions since they lack rigorous testing but I think they can provide some indications. With this patch, I think ABCL gets good performant sorting functions, especially for large vectors. As for lists, I haven't looked at them so probably they can also be improved (but I really don't know). Cheers, Jorge [1] The tables result from the generation of simple-vectors of sizes 8 to 524288 (powers of 2 from 3 to 19) with distinct integer: unsorted, nearly sorted (distances 0, 4 and 16), sorted and reversed sorted. The nearly sorted vectors were constructed by selecting pairs where they would swap with a neighbor at a certain distance. I did 100 runs and timed only the sorting operation. The tables contain the averages of the 100 runs. They were performed in an iMac (2.5GHz i5, 4GB) with Mac OS X 10.7.3. -- http://jorgetavares.com

2 2

[armedbear-devel] *load-pathname* with incorrect value
by wl chiu 06 May '12

06 May '12

Hi again, I have a file: ---- load-pathname.lisp ----- (print *load-pathname*) ----------------------------- When loaded, I get this: java.exe -cp "abcl.jar" org.armedbear.lisp.Main --load load-path.lisp==> #P"load-path.lisp" According to CLHS, I believe this is wrong? During a call to load, *load-pathname* is bound to the pathname denoted by the the first argument to load, merged against the defaults; that is, it is bound to (pathname (merge-pathnames filespec)). During the same time Cheers, Wei-Lun Chiu

2 1

[armedbear-devel] asdf 2.21 released
by Faré 30 Apr '12

30 Apr '12

I am pleased to announce the release of ASDF 2.21. Since previous release 2.20, the changes are as follow: * New features: * Most importantly, encodings. ASDF now lets you specify an :encoding for a system, module or component, that is used when loading or compiling Lisp files. See the documentation. By default, the only useful value is :utf-8, and we recommend you use UTF-8 everywhere. We intend to make UTF-8 the default in the future (current default is the legacy behavior of using whichever implicit default your underlying implementation is currently configured to use). An extension asdf-encodings is available that supports more encodings, including autodetection of encoding from either emacs-style declaration -*- Mode: Lisp ; coding: utf-8 -*- or content. * require-system works like load-system, but won't try to load or update systems that have already been loaded, as listed by loaded-systems. More generally, you can specify a list of systems as :force-not argument to load-system and the specified systems won't be loaded or updated. * You can specify :force-not and a list of systems when loading a system, * You can now specify :hostname in your asdf-output-translations, so you can easily share a home directory via the network yet split its fasl cache between several subtly different machines. * Bug Fixes: * lp#982285. since 2.014.4, the default source-registry was skipping anything from /usr or XDG_DATA_DIRS, because of a missing test in getenv-absolute-pathnames. Fixed in .15. * In 2.019.9 aka 2.20, ECL support was broken by using a function in the wrong package (defined in cl-user). Fixed in .1. * logical-pathname support was somewhat broken since 2.017.6, due to the way most implementations fail to read physical namestrings when *default-pathname-defaults* is a logical-pathname. Fixed, together with other logical-pathname issues, and a test case was added to the test suite to ensure no further regression. Works great modulo quirks around implementation bugs on CLISP and Allegro. * Make upgrading ASDF more robust on CMUCL, LispWorks, SBCL. * Minor tweaks: * Use :unspecific in pathname components on more implementations. * export and/or document more utilities. * add a few missing compatfmt for Genera. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A single flaw in someone else's beliefs, they are discredited. Repeated obvious flaws in your own, you keep the blind faith. Government saves!

2 1

[armedbear-devel] Package redefinition issue in REPL.
by wl chiu 28 Apr '12

28 Apr '12

Hello dear developers, I' just experienced an odd issue with defpackage. It looked like the package will not be modified if I call defpackage again. For example, I define a package called "a-package". After a while I wanted to export a function that I've just implemented called "a-new-foo". Naturally I would add a new entry under the :export section of defpackage, and then eval the expression again. However, I still cannot access "a-new-foo" as the REPL gives me "such symbol is not external of package [a-package]" error message. Please advice and many thanks, Wei-Lun Chiu

4 4

[armedbear-devel] Funny behavior about flet after compilation.
by wl chiu 25 Apr '12

25 Apr '12

Hi dear devs, I encountered some funny behaviour between compiled and interpretedcode with flet. I'm not sure if this is a duplicate bug? -------- flet-bug.lisp -------------- (defun foo (x) (print x)) (defun test1 () (flet ((foo1 () (foo 3))) (foo1))) (defun test2 () (flet ((foo () (foo 3))) (foo))) ------------------------------------ We compile the following file, (compile-file "c:/me/temp/flet-bug.lisp") ; Compiling C:/me/temp/flet-bug.lisp ... ; (DEFUN FOO ...) ; (DEFUN TEST1 ...) ; (DEFUN TEST2 ...) ; Wrote c:/me/temp/flet-bug.abcl (2.62 seconds) Then either load it interpreted or compiled. Interpreted, everything'sfine: > (load "c:/me/temp/flet-bug.lisp") T > (test1) 3 3 > (test2) 3 3 Compiled, we get an error in test2: > (load "c:/me/temp/flet-bug.abcl") T > (test1) 3 3 > (test2) ; Evaluation aborted on #<PROGRAM-ERROR {797E7B}>. The stack trace for this is: Wrong number of arguments for #<FOO {CCA5B9}>. [Condition of type PROGRAM-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {490A12}> #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>) 1: (APPLY #<FUNCTION {490A12}> (#<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {19430CA}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:381) 5: org.armedbear.lisp.Function.execute(Function.java:312) 6: org.armedbear.lisp.Primitive.execute(Primitive.java:113) 7: (FOO 3) 8: (TEST2) 9: (SYSTEM::%EVAL (TEST2)) 10: (EVAL (TEST2)) 11: (SWANK::EVAL-REGION "(test2) ") ... etc ... Thanks for your attention, Wei-Lun Chiu

1 0

[armedbear-devel] SLIME reconnection on ABCL 1.1.0-dev fails
by aditya siram 24 Apr '12

24 Apr '12

Hi all, If I connect to a repl with M-x slime , disconnect using M-x slime-quit-lisp and reconnect it loads the fasls and then fails with: WARNING: #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR #<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of type SIMPLE-ERROR Maximum error depth exceeded (11 nested errors). CL-USER(2): CL-USER(2): The prompt "CL-USER(2)" works but emacs stays locked with a "Polling "/tmp/slime.2616".. (Abort with `M-x slime-abort-connection'.)" One possible indication of the problem is that there is no file /tmp/slime.2616. If I delete the fasls and start slime, it re-compiles them all and starts fine. This does not happen with abcl-1.0.1. Thanks! -deech

4 11