armedbear-devel

armedbear-devel@common-lisp.net

2 participants
1202 discussions

[armedbear-devel] Fwd: Wild pathnames
by Faré 08 Apr '15

08 Apr '15

Bug report: abcl doesn't correctly process filenames with a "*" in them. Here is the command I ran, where cl is the latest cl-launch 4: mkdir -p /tmp/x ; touch "/tmp/x/*" ; for i in sbcl ccl clisp cmucl ecl abcl \ scl allegro lispworks gcl xcl ; do echo $i ; cl -l $i -iw \ '(let ((x (directory "/tmp/x/*"))) (list "'$i'" x (pathname-name (first x))))' ; done And the summarized results are: Escape properly: ("sbcl" (#P"/tmp/x/\\*") "*") ("ccl" (#P"/tmp/x/\\*") "\\*") ("cmucl" (#P"/tmp/x/\\*") "*") ("lispworks" (#P"/tmp/x/\\*") "\\*") ("scl" (#P"file://localhost/tmp/x/*") "*") Read badly: ("clisp" (#P"/tmp/x/*") :WILD) ("ecl" (#P"/tmp/x/*") :WILD) ("allegro" (#P"/tmp/x/*") :WILD) ("xcl" (#P"/tmp/x/*") :WILD) Error out: abcl Fatal condition: Bad place for a wild pathname. gcl: Fatal condition: Condition in LET [or a callee]: INTERNAL-SIMPLE-FILE-ERROR: File error on "/tmp/x/*": File "/tmp/x/*" is wild —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No man would listen to you talk if he didn't know it was his turn next. — Edgar Watson Howe

2 1

[armedbear-devel] multidimensional java arrays?
by Cyrus Harmon 08 Apr '15

08 Apr '15

I am trying to connect ABCL up with some java code that uses multidimensional arrays of the form: int[][] theArray = new int[4][4]; The problem is that when I call this code I get something like this in return: #(#<jarray [I@2d983837 {6492BA43}> #<jarray [I@5d02b84a {5D9131FA}> #<jarray [I@67684413 {6E4D706E}> #<jarray [I@1e107e55 {4CD60DDE}>) that is a lisp array that contains 4 java arrays. I can’t pass this off to a method like this: static public int[][] arrayTest2(int[][] oldArray) { … } I can work around this by creating a new java array myself (and populating it appropriately), but this is no fun. Is this the intended behavior? thanks, Cyrus

3 5

[armedbear-devel] Trouble calling a static function
by ubikation _ 08 Apr '15

08 Apr '15

I have been trying to create a static function that allows me to create an Akka Actor so I can try to play with it from within slime, but I am running into a very odd issue. ----- Issue: The static function for Java works perfectly, but the equivalent static function for slime does not. ----- The files for reproducing this issue are attached, and the repository that I am using is: https://github.com/ubikation/chemicalambda Testing requires having the correct jars, which are installable via the pom.xml: mvn install mvn dependency:copy-dependencies The second command should create a target/dependency folder that you have to add to the classpath, along with the dir containing all of the files I've attached to this email. ----- Here is my calling session: CL-USER> (load "/home/ubikation/src/lisp/chemicalambda/AkkaTest.lisp") T CL-USER> (my-test) This is the error when trying to call the static function: Java exception 'java.lang.NoClassDefFoundError: akka/actor/ActorSystem'. [Condition of type JAVA-EXCEPTION] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {1E9ABE91}> #<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>) 1: (APPLY #<FUNCTION {1E9ABE91}> (#<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<JAVA-EXCEPTION {15883401}> #<FUNCTION {1E9ABE91}>) 3: (INVOKE-DEBUGGER #<JAVA-EXCEPTION {15883401}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.jstatic(Java.java:487) 6: org.armedbear.lisp.Java$pf_jstatic.execute(Java.java:513) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 8: (JSTATIC "test" "AkkaApiSimple") 9: (VOID-FUNCTION) 10: (MY-TEST) 11: (SYSTEM::%EVAL (MY-TEST)) 12: (EVAL (MY-TEST)) 13: (SWANK::EVAL-REGION "(my-test) ") 14: (#<FUNCTION {210E38B2}>) 15: (SWANK::TRACK-PACKAGE #<FUNCTION {210E38B2}>) 16: (#<FUNCTION {2CAC3F12}>) 17: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation request." #<FUNCTION {2CAC3F12}>) 18: (#<FUNCTION {6060CDA7}>) 19: (FUNCALL #<FUNCTION {6060CDA7}>) 20: (#<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {735DC05F}> #<FUNCTION {6060CDA7}>) 21: (APPLY #<FUNCTION (LAMBDA (SWANK-BACKEND::FN)) {735DC05F}> #<FUNCTION {6060CDA7}> NIL) 22: (SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS #<FUNCTION {6060CDA7}>) 23: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<FUNCTION {6060CDA7}>) 24: (SWANK::REPL-EVAL "(my-test) ") 25: (SWANK:LISTENER-EVAL "(my-test) ") 26: (SYSTEM::%EVAL (SWANK:LISTENER-EVAL "(my-test) ")) 27: (EVAL (SWANK:LISTENER-EVAL "(my-test) ")) 28: (#<FUNCTION {1000D825}>) 29: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1000D825}>) 30: (SWANK:EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(my-test) ") "COMMON-LISP-USER" 12) 31: (APPLY #<EVAL-FOR-EMACS {4FAC1D53}> ((SWANK:LISTENER-EVAL "(my-test) ") "COMMON-LISP-USER" 12)) 32: (SWANK::PROCESS-REQUESTS NIL) 33: (#<FUNCTION {276E6D58}>) 34: (EVAL (SWANK:LISTENER-EVAL "(test) ")) 35: (#<FUNCTION {42CCC0A1}>) 36: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {42CCC0A1}>) 37: (SWANK:EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(test) ") "COMMON-LISP-USER" 9) 38: (APPLY #<EVAL-FOR-EMACS {4FAC1D53}> ((SWANK:LISTENER-EVAL "(test) ") "COMMON-LISP-USER" 9)) 39: (SWANK::PROCESS-REQUESTS NIL) 40: (#<FUNCTION {107AAC4A}>) 41: (#<FUNCTION {65C536B9}>) 42: (FUNCALL #<FUNCTION {65C536B9}>) 43: ((FLET SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK) #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}>) 44: (APPLY #<(FLET CALL-WITH-DEBUGGER-HOOK) {768BDFE1}> #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}> NIL) 45: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<SWANK-DEBUGGER-HOOK {773F0D3A}> #<FUNCTION {65C536B9}>) 46: (#<FUNCTION {59176994}>) 47: (SWANK::CALL-WITH-BINDINGS ((*STANDARD-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*STANDARD-INPUT* . #S(SLIME-INPUT-STREAM)) (*TRACE-OUTPUT* . #S(SLIME-OUTPUT-STREAM)) (*ERROR-OUTPUT* . #S(SLIME-OUTPUT-STREA.. 48: (#<FUNCTION {3A65F5B1}>) 49: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {3A65F5B1}>) 50: (#<FUNCTION {7BE5556A}>) 51: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {7BE5556A}>) 52: (SWANK::HANDLE-REQUESTS #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {6BC6FEA9}> :SOCKET-IO #<TWO-WAY-STREAM {55794086}> :DEDICATED-OUTPUT NI.. 53: (SWANK::REPL-LOOP #S(SWANK::MULTITHREADED-CONNECTION :SOCKET #<java.net.ServerSocket ServerSocket[addr=0.0.0.0/0.0.0..... {6BC6FEA9}> :SOCKET-IO #<TWO-WAY-STREAM {55794086}> :DEDICATED-OUTPUT NIL :USE.. 54: (#<FUNCTION {B7B4941}>) 55: (SWANK::CALL-WITH-BINDINGS NIL #<FUNCTION {B7B4941}>) 56: (#<FUNCTION {4B06504A}>) 57: (FUNCALL #<FUNCTION {4B06504A}>) 58: (#<FUNCTION (LAMBDA ()) {B8150C1}>) 59: (THREADS::THREAD-FUNCTION-WRAPPER #<FUNCTION (LAMBDA ()) {B8150C1}>) I've tried to be very clear but I'm sure I've missed something. I don't know what's causing this error, and I can't tell if I'm going about this in some stupid manner or if this is a symptom of a more complex issue. If you need any help reproducing this issue please email me, I'm desperate for any input. Thank you very much for your time!

2 4

[armedbear-devel] hang with threads:object-wait
by James M. Lawrence 08 Apr '15

08 Apr '15

(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001)))) For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001. The context is the new timeout option for bordeaux-threads:condition-wait, https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp… 1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae Best, lmj

4 22

Re: [armedbear-devel] Pure threads and hashtables test
by Mark Evenson 08 Apr '15

08 Apr '15

Eh. Upon reflection, not entirely sure that the increments are happening CV correctly. I will try to move the test to counting the total entries in the hash table, rather than only accessing one key. This should be closer to Alan's original problem.

3 6

[armedbear-devel] Building with gcj
by David Creelman 08 Apr '15

08 Apr '15

Hi All, First of, a big congrats on ABCL. It seems to be getting better and better all the time. I'm able to run ABCL under Java on Debian (testing) with no troubles (using ant or build-abcl.lisp with a few changes). However, I'm stumped about how to use gcj to make an exe. I'm wanting to use the exe on a site that doesn't have java, but will allow server exes. For a normal Java build, on Debian I needed to change the script a little so that the java and javac exe were found at /usr/bin/java, rather than /bin/java. Perhaps this could be made into a defconstant/defparameter? If someone has built ABCL with gcj and could point me to some docs I may have missed or some information that may be missing, but is in someones head or a custom build script, please let me know. Once I find out how to do it, I'll be more than happy to write up how it works for the ABCL docs and build scripts. Cheers David

2 1

[armedbear-devel] Backquote bug
by Faré 08 Apr '15

08 Apr '15

Subtle bug in ABCL. What should this form read as? `#5(1 ,@`(2 3)) ECL, LispWorks and fare-quasiquote agree on #(1 2 3 2 3) allegro, ccl, clisp, sbcl return the arguably conformant #(1 2 3 2 3 2 3 2 3) abcl, cmucl, gcl, xcl all return the arguably completely buggy #(1 2 3) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty.

4 6

[armedbear-devel] abcl-1.3.0 released
by Mark Evenson 08 Apr '15

08 Apr '15

http://abcl.org/releases/1.3.0 abcl-1.3.0 is a feature release. 15-MAR-2014 ## Features * Make LispStackFrame.UNAVAILABLE_ARG a singleton object, and lazily create the little used portions of the Lisp stack. Aggressively cache and control the use of memory by the underlying Lisp stack frame representation by introducing the private LispThread.StackFrame and LispThread.StackSegments classes. Contributed by Dmitry Nadezhin. LispStackFrame object are allocated on every LispThread.execute(...) . However, they are seldom [accessed] ([... verify via] inspect[tion of the] stack trace). This patch delays allocation of LispStackFrame? objects until they are requested. Raw information about stack frames is stored in stack. Stack is an Object[] array (more precisely a list of [...]4 [Mib] Object[] arrays). ME: We are going to need a way to try to less agressively grab 4Mib chunks in low memory situations. Memory profiling of ABCL shows that the classes with largest allocation count are org.armedbear.lisp.LispStackFrame and org.armedbear.lisp.LispStackFrame.UnavailableArgument. Contributed by Dmitry Nadezhin. [r14572]: http://abcl.org/trac/changeset/14572 [r14579]: http://abcl.org/trac/changeset/14579 * ASDF 3.0.1.94 shipped with the implementation * per function call stack and memory exception handler in CL:COMPILE Inline calls to jrun-exception-protected (used by handler-bind to catch out of memory conditions). This commit saves generation roughly 50 cls files. [r14552]: http://abcl.org/trac/changeset/14552 * SYS:SHA256 audited The functionality if the SYS:SHA256 algorithim has been audited for use on inputs of single for files with recently shipping ORCL Java 7 implementations (through jdk-1.7.0_51). [r14582]: http://abcl.org/trac/changeset/14582 * Connect to NetBeans controlled JDWP via SLIME The Netbeans IDE configuration now includes a way to connect to the running-under-jdb ABCL via SLIME. One needs a version of SLIME able to be loaded from its 'swank.asd' definition. * Install 'abcl.jar' and 'abcl-contrib.jar' locally as Maven artifacts The Ant `abcl.mvn.install` target now installs build artifacts into the local Maven repository (Olof-Joachim Frahm) [r14579]: http://abcl.org/trac/changeset/14606 ## Compatibility * CL:DIRECTORY The implementation specific :RESOLVE-SYMLINKS argument to the ANSI DIRECTORY function has been changed to nil. This implements behavior closer to SBCL and guarantees that a DIRECTORY operation will not signal a file error. [r14619]: http://abcl.org/trac/changeset/14619 [ticket-340]: http://abcl.org/trac/ticket/340 ## Fixes * Fix CL:SLEEP for intervals less than a millisecond. For intervals less than or equal to a nanosecond, including an interval of zero, the current thread merely yields execution to other threads. [r14632]: http://abcl.org/trac/changeset/14632 ## Tested ### "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.7.0_51-b13" "x86_64-Mac_OS_X-10.9.1" ### "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-1.8.0-b129" "x86_64-Mac_OS_X-10.9.2" ## Contrib #### abcl-asdf * Now working with both Maven 3.0.x and 3.1.x. Thanks to Anton for the help! [ticket-328]: http://abcl.org/trac/ticket/328 * cache Maven dependency resolution to avoid repeated lookups. Instead of calling ABCL-ASDF:RESOLVE in both the ASDF COMPILE-OP and LOAD-OP, we now cache the result of invocation in COMPILE-OP and add this value in the LOAD-OP phase. Contributed by Cyrus Harmon. [r14631]: http://abcl.org/trac/changeset/14631 #### jna Now references jna-4.0.0. Some incompatibility with CFFI ([in progress with fixing upstream][cffi-easye]). [cffi-easye]: http://github.com/easye/cffi/

5 16

[armedbear-devel] Setup changes for cl-test-grid.cloud.efficito.com
by Erik Huelsmann 08 Apr '15

08 Apr '15

Hi Anton, Looking at some of the test grid failures for ABCL, I noticed some of the OpenGL packages failing due to being unable to locate LibGL.so. To resolve that, I ran: $ aptitude install libgl1-mesa-swx11 Then I noticed something wanted to require JSS, but didn't know how to, so I've added "(require :abcl-contrib)" to /home/testgrid/.abclrc. With these in place cl-glfw-opengl-core seems to load just fine. Any other libraries or measures I should take in order to be able to load (currently failing) systems? Bye, Erik.

3 3

[armedbear-devel] abcl-1.2.0 RC 0
by Mark Evenson 08 Apr '15

08 Apr '15

Live from the floor of ECLM 2013, [Binaries for the first release candidate for abcl-1.2.0][abcl-1.2.0-rc-0] have been uploaded and signed by <evenson.not.org(a)gmail.com>. For reasons that aren't entirely clear, the size of the archive has increased to 10 Mib. I'm not sure if this has been just a slow creep, or is related to the recent conversion of CLOS infrastructure from Java to Lisp. Please test if you can, letting us know if you have problems. [branch for 1.2.0]: http://abcl.org/svn/branches/1.2.0 [abcl-1.2.0-rc-0]: http://abcl.org/releases/1.2.0/rc-0

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel