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

[armedbear-devel] Patch: sequence implementations can be structures
by Alessio Stalla 07 Nov '11

07 Nov '11

Hello, again musing with FSet on ABCL, thinking about integrating it with the CL sequence API (where it makes sense). FSet collections are structures, so I wrote the attached hack^H^H^H^Hpatch to create a special structure class that extends cl:sequence. This can be used to make user-defined structures obey the sequence protocol without wrappers, though I haven't used it with FSet yet. What do you think about it? Bye, Alessio

1 1

[armedbear-devel] Patch to dynamically load jna.jar for CFFI
by Mark Evenson 06 Nov '11

06 Nov '11

If you have the the [contrib mechanism working correctly, post abcl-1.0.0][1], one can get ABCL to dynamically load the required shared objects to enable [via the following code in your ~/.abclrc][2]: #+abcl (eval-when (:load-toplevel) (require 'abcl-contrib) (require 'abcl-asdf) (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.sun.jna" "jna" "3.0.9"))) ASDF shouldn't really be patched in [this way][1], but it involves debugging the Pathname internals (yet again) which is a task I am postponing until I can string together a bunch of consecutive hours. [1]: http://trac.common-lisp.net/armedbear/changeset/13692 [2]: http://bit.ly/v6OQFf

1 0

[armedbear-devel] adjust-array bug
by Helmut Eller 06 Nov '11

06 Nov '11

Evaluating this form (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) prints a longish stacktrace that doesn't seem right: Armed Bear Common Lisp 1.1.0-dev-svn-13692M Java 1.6.0_18 Sun Microsystems Inc. OpenJDK Client VM Low-level initialization completed in 0.771 seconds. Startup completed in 2.209 seconds. Type ":help" for a list of available commands. CL-USER(1): (adjust-array (make-array 2 :element-type '(unsigned-byte 8)) 4) java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:291) at org.armedbear.lisp.BasicVector_UnsignedByte8.adjustArray(BasicVector_UnsignedByte8.java:40) at org.armedbear.lisp.adjust_array.execute(adjust_array.java:95) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.Autoload.execute(Autoload.java:258) at org.armedbear.lisp.Symbol.execute(Symbol.java:896) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.arrays_2.execute(arrays.lisp:46) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112) at org.armedbear.lisp.LispThread.execute(LispThread.java:666) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:541) at org.armedbear.lisp.Lisp.eval(Lisp.java:506) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733) at org.armedbear.lisp.Lisp.eval(Lisp.java:496) at org.armedbear.lisp.Lisp.progn(Lisp.java:675) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451) at org.armedbear.lisp.Closure.execute(Closure.java:484) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:277) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:415) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:423) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.Interpreter.run(Interpreter.java:360) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:636) #<THREAD "interpreter" {3DC13D}>: Debugger invoked on condition of type ERROR Caught java.lang.ArrayStoreException. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): Helmut

2 1

[armedbear-devel] Symbol-macro patch
by Alessio Stalla 02 Nov '11

02 Nov '11

Greetings, following up from my earlier mail about FSet and ABCL, I propose a patch (attached) to fix ABCL's symbol-macro implementation not to use the symbol's global value slot. Local symbol macros still use the same storage location as variables, since it's not possible to use symbol-value on local variables and it is forbidden to both declare a variable special and associate a symbol macro to its name. I also simplified some code that did not make use of this assumption, and specially handled cases where a symbol was both naming a special variable and a symbol macro. An inconsistency remains: (defvar foo) (define-symbol-macro foo nil) signals an error, while (define-symbol-macro foo nil) (defvar foo) does not. This behaviour is present in stock ABCL as well, and apparently it's allowed by the ANSI standard, although at least SBCL consistently signals an error in both cases. I believe we should do so, too. But I think it pertains to another patch. Please test the patch with your own code; I ran the ANSI test suite and got no regressions, but I'm not very confident about it - apparently it doesn't cover symbol macros very well or at all, since at one time I ran it with define-symbol-macro effectively unimplemented and it happily reported the same 19-20 failures it did before. Cheers, Alessio

2 2

[armedbear-devel] Manual format
by Blake McBride 29 Oct '11

29 Oct '11

Greetings, I was looking at the ABCL manual for ABCL 1.0 under the 'manual' directory. I noticed that it is in LaTeX format. I have been using TeX, LaTeX and Texinfo for many years. Among many other things, I have written two longish user manuals in Texinfo. They are located (including source) at: http://blake.mcbride.name/software/dynace/downloads.html under the 'manual' directory. With the experience I've had with TeX, LaTeX, and Texinfo, I feel very strongly that these are unbelievably great tools, and, in fact, the right tools for the job. However, I also feel strongly that Texinfo is the better format for the particular task of a manual on ABCL. I use LaTeX pretty often, but I have found Texinfo better suited for user manuals of computer topics for several reasons. First, the macros defined are more natural for the topic. Second, Texinfo supplies much better index creation tools for functions, variables, classes, etc.. Lastly, if you use Texinfo, you get online documentation for free! Texinfo is specifically designed for exactly this kind of technical document. LaTeX is equally good, but at writing non-technical books. Latex is not a natural fit for technical documents in my opinion. So, in conclusion: 1. I recommend switching to Texinfo. It would be especially easy at this early juncture. 2. The manuals I wrote come out, IMO, nicely. These documents could be used as templates. 3. My time is a real problem but I think I can convert the existing document so that you'd have it all setup to continue with if that is desired. I welcome your thoughts. Blake McBride

4 4

[armedbear-devel] FSet on ABCL
by Alessio Stalla 26 Oct '11

26 Oct '11

Greetings, as part of my nth plan to conquer the world (which of course I won't unveil right now), I tried FSet on ABCL. I managed to make it run, but I had to patch it; you can find the patch attached (it's taken against the version in Quicklisp, but I believe it's the latest version). Besides some minor #+abcl porting stuff, the one thing that stuck out was the DEFLEX macro for defining global lexical variables, which conflicts with ABCL's implementation of symbol macros. (deflex var) expands basically into (define-symbol-macro var (symbol-value 'var)). The problem: ABCL stores symbol macros in the value cell of symbols, so you can't have a symbol which is both a variable and a symbol macro. Now, I believe deflex as written is non portable CL. This is because accessing the symbol-value of an unbound variable is, to my interpretation, unspecified [*]; and if you use defvar/defparameter with var, then you cannot use it as a symbol macro. Thus, I patched it (taking inspiration from Rob Warnock's version of deflex/defglobal). However, I do think ABCL's implementation is very brittle (and probably conflicting with ANSI as well), because if you setf the symbol-value of a symbol with a global symbol macro attached, you remove the symbol macro! So, I think we should fix it for 1.0.1. Perhaps I can do the fix myself, but we better discuss it before because I fear this might be a deep change. [*] symbol-value ... Accesses the symbol's value cell. [1] value cell n. Trad. (of a symbol) The place which holds the value, if any, of the dynamic variable named by that symbol, and which is accessed by symbol-value. [2] dynamic variable n. a variable the binding for which is in the dynamic environment. [3] I don't think a symbol for which there is no special declaration in scope can be considered to name a dynamic variable, and thus to have a value cell at all. [1] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-v… [2] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#value_ce… [3] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#dynamic_… Cheers, Alessio

1 0

[armedbear-devel] Support for specialized arrays?
by Blake McBride 26 Oct '11

26 Oct '11

Greetings, I presume ABCL supports specialized arrays (element-type:) syntactically but I am wondering if ABCL actually creates more efficient, type specific, arrays rather than generic, arrays of objects? Thanks. Blake McBride

3 3

Re: [armedbear-devel] bug of resolve-symlinks
by Gábor Balázs 25 Oct '11

25 Oct '11

hY, I think there is a bug in the list-directory function. The resolve-symlinks flag seems to always resolve the directory symlinks even when the flag is set to nil. Let's have a directory as : total 4 drwxr-xr-x 2 bege users 4096 Oct 23 23:52 dir lrwxrwxrwx 1 bege users 3 Oct 23 23:53 dir-link -> dir -rw-r--r-- 1 bege users 0 Oct 23 23:53 file lrwxrwxrwx 1 bege users 4 Oct 23 23:53 file-link -> file Then Armed Bear Common Lisp 0.26.2 Java 1.6.0_26 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 1.436 seconds. Startup completed in 5.385 seconds. Type ":help" for a list of available commands. CL-USER(1): *(directory "./*" :resolve-symlinks nil)* (#P"/home/bege/TEST/./file" *#P"/home/bege/TEST/dir/"*#P"/home/bege/TEST/./file-link" *#P"/home/bege/TEST/dir/"*) Sorry, if this has been already fixed... Best, `bg`

2 1

Re: [armedbear-devel] destroy-thread and unwind-protect
by Mark Evenson 24 Oct '11

24 Oct '11

On Oct 24, 2011, at 17:59 , James Lawrence wrote: […] > Thanks for the response. > > That seems like a different issue. The purpose is not to guarantee > that the thread is destroyed. > > The behavior sought is: when the protected form stops executing, run > the cleanup forms. […] > In my case I am only interested in detecting the termination of a > thread without polling. Maybe there is an ABCL-specific way to do > that. THREADS:THREAD-ALIVE-P Function: Boolean predicate whether THREAD is alive.

2 4

[armedbear-devel] asdf and windows vs unix on abcl
by Faré 24 Oct '11

24 Oct '11

ABCL is special in that it can run on either Windows or Unix. The problem is that ASDF 2.017 determines which of Windows or Unix at compile-time, which causes confusion when ABCL's builtin ASDF is compiled on Windows and used on Unix or vice-versa. And I can tell your binary was definitely produced on Windows. (I found this issue while testing cl-launch. I also noticed that you fixed your ext:*command-line-argument-list* albeit in a necessarily incompatible way.) I suppose the solution is that the test of unixness vs windowsness should happen at runtime. Crazy. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

5 13