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

[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 08 Aug '12

08 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

[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] abcl-1.1.0 engineering scrum @ 2100 CET (1900 GMT) on #abcl
by Mark Evenson 06 Aug '12

06 Aug '12

We will be holding the weekly abcl-1.1.0 engineering scrum @ 2100 CET on #abcl. Anyone with questions, priorities, patches, welcome to join. The meeting will probably be sparsely attended, so I will just work on recording the [current status as I see it on the Armed Bear Trac Wiki][1]. We can move to audio/video if there is a need. [1]: http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Unqualified FIND-PACKAGE call in ABCL compiled files
by Vladimir Sedach 06 Aug '12

06 Aug '12

Hi, Currently, ABCL doesn't qualify the package of FIND-PACKAGE when it serializes a package in a compiled file. This causes a bug when loading a compiled file that has code (for example, the EOS:TEST macro from the EOS unit-testing library) that serializes a package, and occurs after an IN-PACKAGE into a package that either shadows or does not import FIND-PACKAGE from COMMON-LISP. I didn't work out a minimum test case, but the problem can be observed when trying to load the Parenscript test suite: (ql:quickload :parenscript.test) Here's the fix: Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 14055) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -1191,7 +1191,7 @@ (defun serialize-package (pkg) "Generate code to restore a serialized package." - (emit 'ldc (pool-string (concatenate 'string "#.(FIND-PACKAGE \"" + (emit 'ldc (pool-string (concatenate 'string "#.(CL:FIND-PACKAGE \"" (package-name pkg) "\")"))) (emit-invokestatic +lisp+ "readObjectFromString" (list +java-string+) +lisp-object+)) Index: src/org/armedbear/lisp/Package.java =================================================================== --- src/org/armedbear/lisp/Package.java (revision 14055) +++ src/org/armedbear/lisp/Package.java (working copy) @@ -865,7 +865,7 @@ public String printObject() { if (_PRINT_FASL_.symbolValue() != NIL && name != null) { - StringBuilder sb = new StringBuilder("#.(FIND-PACKAGE \""); + StringBuilder sb = new StringBuilder("#.(CL:FIND-PACKAGE \""); sb.append(name); sb.append("\")"); return sb.toString(); Happy hacking, Vladimir

2 1

[armedbear-devel] Monday progress meeting
by Erik Huelsmann 05 Aug '12

05 Aug '12

Hi Mark, Dunno if I'll be making it to our monday progress meeting tomorrow (travelling to be done). But this is my status: * My work on DEFINE-METHOD-COMBINATION can be considered Done; I left some todo's behind which should be relatively small in comparison to the original problem. It's now just a matter of changing the symbols in the backquote patterns. * My work on the autoloader has been mostly done as far as our current infrastructure allows; next steps: - Clean autoload.lisp for any symbols which automatically end up in autoload-gen.lisp - Create infrastructure for autoloading of SETF functions (ie function names not designated by a symbol) * Crashes evaluating a form referencing an undefined function in a clean image --> solved by requiring PRINT-OBJECT in the right place With respect to this point: it's possibly a good idea to do a search of the code base and find out if we're doing this everywhere PRINT-OBJECT methods are being defined * COMPILER-UNSUPPORTED-FEATURE-ERROR derived from CONDITION --> solved * Autoloader fails when *READ-xxx* variables bound to unexpected values --> solved * Implement USE-FAST-CALLS properly --> resolved by deleting the USE-FAST-CALLS infrastructure from the interpreter; the compiler already does the right thing * Compiling #n# causes stack overflow --> solved; however, Stas Boukarev reports that the case I've fixed only fixes in-memory compilation and the issue still exists in file compilation. Ticket #191 should be re-opened to and should say so. All in all a pretty good result for one week. However, from here on $WORK will start again which means I'll only be able to address the bigger issues in small steps. Or just the smaller issues, of course. Which is why I'm glad to have worked out the D-M-C stuff. That was a week more than full time work to completely comprehend the spec and macrology going on in our implementation. That's it for now. If I'm available tomorrow at 21:00 CET, I'll be on #abcl. Bye, Erik.

1 0

[armedbear-devel] Trouble compiling functions with cyclic structures.
by Stas Boukarev 05 Aug '12

05 Aug '12

compile-file has trouble with (defun bar () '#1=(cycle . #1#)) -- With best regards, Stas.

1 0