armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

Re: [armedbear-devel] [fset-devel] FSet on ABCL
by Alessio Stalla 09 Nov '11

09 Nov '11

Hi, to follow up on the topic of running FSet on ABCL, I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine. However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization? Bye, Alessio On Thu, Oct 27, 2011 at 1:19 AM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott(a)sympoiesis.com> wrote: >> On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla >> <alessiostalla(a)gmail.com> wrote: >>> 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). >> >> Thanks for the patch! >> >> Did you run the test suite? Were any non-default JVM settings >> required, e.g. stack size? >> >> Do you have any performance comparisons (of FSet operations in >> particular) vis-a-vis, say, SBCL? > > I haven't run the test suite yet, nor made any performance > comparisons. Regarding JVM settings, in order to compile and load FSet > (under SLIME) I had to increase the maximum heap size from the (iirc) > 64M default. I set it at 256M but it may well be that a lower value is > sufficient. In the next few days I'll do a few tests and benchmarks > and I'll keep you informed on the results. > >> >>> 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). >> >> Heh -- I had seen Rob's implementation and wondered why he created a >> second symbol. Now I know :-) > > I don't particularly like the second interned symbol solution... I > tried initially with a gensym, but it's hard to get right the > interplay between compile-time, load time, and the file compiler > possibly losing gensym identity, so I guess Rob's approach is the most > practical. > >> >>> 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. >> >> On a strict reading, you're probably correct. But I had never seen an >> implementation for which this was not the case. > > Yes, me neither, and I'd like to get ABCL fixed in that regard. You > might keep your implementation of deflex as-is; in the meantime I will > use my patched version, until ABCL is fixed. > > Thanks, > Alessio >

1 0

[armedbear-devel] stack overflow for worst-case vector sort
by James M. Lawrence 08 Nov '11

08 Nov '11

ABCL-1.0.0 (let ((a (map-into (make-array 10000) (let ((x 0)) (lambda () (incf x)))))) (sort a #'<) nil) => Stack overflow. [Condition of type STORAGE-CONDITION] 0: (#<FUNCTION {7F535BDF}> #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 1: (APPLY #<FUNCTION {7F535BDF}> (#<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {74A2B3B8}> #<FUNCTION {7F535BDF}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {74A2B3B8}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:374) 5: org.armedbear.lisp.Java$pf_jrun_exception_protected.execute(Java.java:1315) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:785) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:649) 8: org.armedbear.lisp.swank_469.execute(swank.lisp:2116) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:683) 10: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2797) 11: (JAVA:JRUN-EXCEPTION-PROTECTED #<FUNCTION {39B4CEC7}>) It looks like the quick-sort function (attributed to ECL) pivots off the first element. I would suggest using a midpoint instead. ABCL's sort also seems a little slow. The psort benchmarks show too much speedup for only 2 cores (http://lparallel.com/download). size 1000 | op < | SORT 11 size 1000 | op < | SORT 11 size 1000 | op < | SORT 12 size 1000 | op < | SORT 12 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 1000 | op < | PSORT 5 size 1000 | op < | PSORT 4 size 50000 | op < | SORT 1014 size 50000 | op < | SORT 1011 size 50000 | op < | SORT 1012 size 50000 | op < | SORT 1013 size 50000 | op < | PSORT 413 size 50000 | op < | PSORT 417 size 50000 | op < | PSORT 415 size 50000 | op < | PSORT 416 size 200000 | op < | SORT 4703 size 200000 | op < | SORT 4701 size 200000 | op < | SORT 4715 size 200000 | op < | SORT 4712 size 200000 | op < | PSORT 1977 size 200000 | op < | PSORT 1975 size 200000 | op < | PSORT 1979 size 200000 | op < | PSORT 1994 psort is based upon the following (posted to usenet by Roger Corman; free license). (defun quicksort (vec lo hi comp-func) (if (> hi lo) (let* ((mid (round (+ lo hi) 2)) (i lo) (j (+ hi 1)) (p (elt vec mid))) (rotatef (elt vec mid) (elt vec lo)) ;; swap mid element to first (loop (loop do (incf i) until (or (> i hi) (funcall comp-func p (elt vec i)))) (loop do (decf j) until (or (<= j lo) (funcall comp-func (elt vec j) p))) (if (< j i) (return)) (rotatef (elt vec i)(elt vec j))) (rotatef (elt vec lo) (elt vec j)) ;;put partition element in place (quicksort vec lo (- j 1) comp-func) (quicksort vec i hi comp-func))) vec) (defun qsort (sequence comp-func) (quicksort sequence 0 (- (length sequence) 1) comp-func))

2 1

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

08 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel