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

[armedbear-devel] LISTEN doesn't work on non-character streams
by Stas Boukarev 13 Aug '12

13 Aug '12

(with-open-file (stream "/dev/zero" :element-type '(unsigned-byte 8)) (listen stream)) #<FILE-STREAM {5CF9DE08}> is not a character input stream. -- With best regards, Stas.

1 0

[armedbear-devel] Stack overflow when compiler macro with fallback is triggered
by James M. Lawrence 12 Aug '12

12 Aug '12

(eval-when (:compile-toplevel :load-toplevel :execute) (defun foo () 99) (define-compiler-macro foo () `(locally (declare (notinline foo)) (foo)))) (defun call-foo () (foo)) Of course, the use case is a compiler macro that says, "OK, let's optimize! ... Never mind, I don't want to optimize that." Armed Bear Common Lisp 1.0.1-svn-13750-13751 Java 1.7.0_04 Oracle Corporation [...] ; (DEFUN FOO ...) ; (DEFINE-COMPILER-MACRO FOO ...) ; (DEFUN CALL-FOO ...) java.lang.StackOverflowError at org.armedbear.lisp.StructureObject$pf_make_structure.execute(StructureObject.java:671) at org.armedbear.lisp.Symbol.execute(Symbol.java:865) at org.armedbear.lisp.LispThread.execute(LispThread.java:760) at org.armedbear.lisp.jvm_714.execute(jvm.lisp:567) 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.jvm_746.execute(jvm.lisp:572) at org.armedbear.lisp.Symbol.execute(Symbol.java:775) at org.armedbear.lisp.LispThread.execute(LispThread.java:633) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_61.execute(compiler-pass1.lisp:1204) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.compiler_pass1_20.execute(compiler-pass1.lisp:383) at org.armedbear.lisp.Symbol.execute(Symbol.java:785) at org.armedbear.lisp.LispThread.execute(LispThread.java:649) at org.armedbear.lisp.compiler_pass1_26.execute(compiler-pass1.lisp:487) [...]

5 5

[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] compile doesn't return correct values for warnings-p and failure-p
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile nil '(lambda () (char=))) ; Caught WARNING: ; Wrong number of arguments for CHAR=. ; Compilation unit finished ; Caught 1 WARNING condition #<FUNCTION (LAMBDA ()) {456E3EB3}> NIL NIL while it should be T, T. jvm-compile, which handles this doesn't succeed because the underlying with-compilation-unit eats all the warnings and errors so that jvm-compile's handler-bind doesn't get a piece of them. Binding *resignal-compiler-warnings* to T inside jvm-compile resolves this. -- With best regards, Stas.

1 0

[armedbear-devel] char= compilation warning
by Stas Boukarev 11 Aug '12

11 Aug '12

(compile (defun test (a b c) (if (char= a b c) t))) ; Caught WARNING: ; Wrong number of arguments for CHAR= (expected 2, but received 3). The error is caused by p2-test-char= in compiler-pass2.lisp:2667 calling (check-arg-count form 2). -- With best regards, Stas.

1 1

[armedbear-devel] [Patch]: Which allows drakma to run.
by Stas Boukarev 11 Aug '12

11 Aug '12

Drakma uses its own type OCTET as element-type for streams it's defined as (deftype octet () '(unsigned-byte 8)) But read-byte and friends don't recognize type because it's not expanded before-hand. So, what I did is to apply EXPAND-DEFTYPE beforehand. Perhaps UPGRADED-ELEMENT-TYPE would've been better, or something entirely different in an another place or more places. But it allows me to use drakma successfully. So, one can do (push :drakma-no-ssl *features*) ;; I can't load CFFI needed for cl+ssl (asdf:load-system :drakma) (drakma:http-request "http://bing.com") => fancy results On another note, I couldn't get usocket to work on Debian until I discovered that I need to either do echo 0 > /proc/sys/net/ipv6/bindv6only or launch java with -Djava.net.preferIPv4Stack=true Otherwise usocket returns a very cryptic error SOCKET-TYPE-NOT-SUPPORTED-ERROR which is in reality "java.net.SocketException: Network is unreachable". -- With best regards, Stas.

2 2

[armedbear-devel] MACROLET environment issue in DO?
by Theam Yong Chew 11 Aug '12

11 Aug '12

Hi devs, I've just stumbled upon something that looks buggy. In the following form, I am particularly focusing on the end-test-form in the do macro. (macrolet ((foo () '(print "macrolet foo"))) (foo) (do ((p 0 (1+ p))) ((foo)) (print "LOOP"))) Prints "macrolet foo" "macrolet foo" then returns ==> NIL Looks fine, but if I wrap that in a function, (defun use-foo () (macrolet ((foo () '(print "macrolet foo"))) (foo) (do ((p 0 (1+ p))) ((foo)) (print "LOOP")))) (use-foo) Prints "macrolet test" then raises an error: The function FOO is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [CONTINUE] Try again. 1: [USE-VALUE] Specify a function to call instead. 2: [RETURN-VALUE] Return one or more values from the call to FOO. 3: [RETRY] Retry SLIME interactive evaluation request. 4: [*ABORT] Return to SLIME's top level. 5: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {1879842}> #<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>) 1: (APPLY #<FUNCTION {1879842}> (#<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<UNDEFINED-FUNCTION {1426780}> #<FUNCTION {1879842}>) 3: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {1426780}>) 4: (ERROR #<UNDEFINED-FUNCTION {1426780}>) 5: (SYSTEM:UNDEFINED-FUNCTION-CALLED FOO NIL) 6: (FOO) Locals: "??" = "??" 7: (USE-FOO) Locals: "??" = "??" 8: (SYSTEM::%EVAL (USE-FOO)) Locals: "??" = "??" 9: (EVAL (USE-FOO)) Locals: "??" = "??" .... If I define a function with same name as the local macro, (defun test () (print "function test")) (defun use-test () (macrolet ((test () '(print "macrolet test"))) (test) (do ((p 0 (1+ p))) ((test)) (print "LOOP")))) (use-test) Prints "macrolet test" "function test" then returns ==> NIL If I manually macroexpand the do form & substitute the expansion back into the function (with some gensym tidy up), (defun macro-expanded-do () (macrolet ((test () '(print "macrolet test"))) (test) (BLOCK NIL (LET ((P 0)) (TAGBODY (GO G4759) G4758 (PRINT "LOOP") (PSETQ P (1+ P)) G4759 (UNLESS (TEST) (GO G4758)) (RETURN-FROM NIL (PROGN))))))) (macro-expanded-do) Prints "macrolet test" "macrolet test" ; No value and returns ==> NIL Is this a bug? I'm running on Windows, using (lisp-implementation-version) ==> "1.0.1-svn-13750-13751" Thanks, Yong.

2 1

[armedbear-devel] breakage in r14066
by James M. Lawrence 09 Aug '12

09 Aug '12

(defstruct foo (data nil)) (defun test () (let ((foo (make-foo))) (symbol-macrolet ((x (foo-data foo))) (setf x 99)) (foo-data foo))) (test) ;=> NIL

2 1

[armedbear-devel] IGNORE declaration in inline function not heeded
by James M. Lawrence 09 Aug '12

09 Aug '12

(declaim (inline foo)) (defun foo (x) (declare (ignore x)) 99) (defun bar (a) (foo a)) compile-file emits ; Caught STYLE-WARNING: ; The variable X is defined but never used. 1.1.0-dev-svn-14066

2 1

[armedbear-devel] Bogus error signaled when compiling bogus RETURN call
by James M. Lawrence 09 Aug '12

09 Aug '12

CL-USER> (lisp-implementation-version) "1.1.0-dev-svn-14066" CL-USER> (defun foo () (return)) FOO CL-USER> (compile 'foo) ; Caught ERROR: ; RETURN-FROM NIL: no block named NIL is currently visible. The value #<EQUAL HASH-TABLE 0 entries, 11 buckets {AE9DCF}> is not of type STRUCTURE-OBJECT. [Condition of type TYPE-ERROR] 0: (#<FUNCTION {1FA8BA4}> #<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>) 1: (APPLY #<FUNCTION {1FA8BA4}> (#<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {1E5E70E}> #<FUNCTION {1FA8BA4}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {1E5E70E}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:423) 6: org.armedbear.lisp.LispObject.getSlotValue(LispObject.java:1241) 7: org.armedbear.lisp.compiler_pass2_389.execute(compiler-pass2.lisp:7453) 8: org.armedbear.lisp.compiler_pass2_375.execute(compiler-pass2.lisp:7408) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:628)

1 0