armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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

[armedbear-devel] asdf encodings and abcl
by Faré 18 Apr '12

18 Apr '12

Dear ABCL developers, I'm currently adding source file encoding support to ASDF. It will hopefully be part of ASDF 2.21, though the plan is that anything but :utf-8 and :default requires an extension :asdf-encodings. I didn't find any way with ABCL to detect the list of external formats, or to determine is a given keyword is an acceptable name for an external format. How do I do that? —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If there's a book you really want to read but it hasn't been written yet, then you must write it. — Toni Morrison [same with software, —♯f]

2 7

[armedbear-devel] Bug in abcl/contrib/jss/invoke.lisp - trying to call JScheme's jsint.Invoke.poke, jsint.Invoke.pokeStatic
by Jonathan P. Bona 11 Apr '12

11 Apr '12

An issue in invoke.lisp (below): set-java-field calls the poke and pokeStatic methods from jscheme's jsint.Invoke class. This should be replaced, right? ;;; http://svn.common-lisp.net/armedbear/tags/1.0.1/abcl/contrib/jss/invoke.lisp (defun set-java-field (object field value &optional (try-harder *running-in-osgi*)) (if try-harder (let* ((class (if (symbolp object) (setq object (find-java-class object)) (if (equal "java.lang.Class" (jclass-name (jobject-class object)) ) object (jobject-class object)))) (jfield (if (java-object-p field) field (find field (#"getDeclaredFields" class) :key 'jfield-name :test 'equal)))) (#"setAccessible" jfield t) (values (#"set" jfield object value) jfield)) (if (symbolp object) (let ((class (find-java-class object))) (#"pokeStatic" 'invoke class field value)) (#"poke" 'invoke object field value)))) - Jonathan Bona

3 2

[armedbear-devel] Cannot get abcl 1.0.1 working with slime
by Arnaud Bailly 06 Apr '12

06 Apr '12

Hello, I am trying to use ABCL 1.0.1 with slime under emacs and get the following errors: (progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp" :verbose t) (funcall (read-from-string "swank-loader:init")) (funcall (read-from-string "swank:start-server") "/tmp/slime.3985" :coding-system "iso-latin-1-unix")) Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.297 seconds. Startup completed in 0.935 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ... Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at line 143 (offset 5611) #<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of type READER-ERROR The package "ASDF" can't be found. Restarts: 0: TOP-LEVEL Return to top level. [1] SWANK-LOADER(2): Here is my .emacs: (add-to-list 'load-path "/usr/share/emacs/site-lisp/slime") ;;(setq inferior-lisp-program "/usr/local/bin/sbcl") (setq inferior-lisp-program "java -cp /home/arnaud/soft/abcl-bin-1.0.1/abcl-contrib.jar -jar /home/arnaud/soft/abcl-bin-1.0.1/abcl.jar") ;; from http://functionalrants.wordpress.com/2008/09/06/how-to-set-up-emacs-slime-s… (require 'slime) (slime-setup '(slime-fancy)) Help greatly appreciated. Thanks Arnaud

3 3

[armedbear-devel] Calling java from lisp
by Arnaud Bailly 06 Apr '12

06 Apr '12

Hello (again), I am trying to invoke java code from lisp code following http://common-lisp.net/project/armedbear/doc/abcl-user.html. Here is the code I am trying to run: CL-USER> (defun java-format (fmtstring &rest args) (let* ((string-class (jclass "java.lang.String")) (array-of-objs (jclass "[Ljava.lang.Object;")) (method (jmethod string-class "format" string-class array-of-objs))) (jcall method fmtstring args))) JAVA-FORMAT And here is what I got when I try to run it: > (java-format "" "%d %08.d %s" 1 2 3) Wrong number of arguments for public static java.lang.String java.lang.String.format(java.lang.String,java.lang.Object[]): expected 2, got 1 [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 {53C470B}> #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>) 1: (APPLY #<FUNCTION {53C470B}> (#<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>) 3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {76F2D004}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:381) 5: org.armedbear.lisp.Java.jcall(Java.java:880) 6: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:755) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 8: (JCALL #<java.lang.reflect.Method public static java.lang.String j.... {451CF2D}> "" ("%d %08.d %s" 1 2 3)) 9: (JAVA-FORMAT "" "%d %08.d %s" 1 2 3) 10: (SYSTEM::%EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3)) 11: (EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3)) --more-- What am I doing wrong ? Arnaud

2 2

Re: [armedbear-devel] run-program :environment nil
by Ville Voutilainen 31 Mar '12

31 Mar '12

On 29 March 2012 17:15, Rudolf Schlatte <rudi(a)ifi.uio.no> wrote: > asdf doesn't use run-program for abcl, just run-shell-command. But I see your point about API changes, especially for a non-major release. I guess right now we're bike-shedding. Let's hear what Pascal prefers, but I'm leaning towards your version as well at the moment. I'm not hell-bent on it, just wanted to point that out since I did consider that even though my patch doesn't mention such considerations. Ville-code is sometimes like that, it's well thought-out and minimal, modify anything and things break (for certain values of "break"), but I'm not the best user of explanatory comments on the planet. :)

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel