gmane.lisp.armedbear.devel

Is anybody interested in jfli-abcl?

Alex Mizrahi — 2012-05-23T13:06:40

jfli-abcl, basically, allows one to quickly create Lisp function 
wrappers for Java classes.

E.g.

(def-java-class "java.sql.DriverManager")
(use-package :|java.sql|)
(DriverManager.getConnection ...)

The benefit over java:jcall  and JSS is that it looks more-or-less like 
normal Lisp function calls, pretty similar to a wrapper you could write 
yourself.
Also, potentially, it might carry less runtime overhead because 
everything can be resolved at compile-time.

And if you use SLIME, auto-completion works. It doesn't like mixed case, 
though, so you need to write it like
(|java.sql|:drivermanager.getcollection ...)
Still, better than nothing.

As far as I can tell, jfli-abcl isn't currently maintained.
But as I'm used to jfli-abcl I maintain my own version with some fixes.

If there is any interest in jfli-abcl I could, perhaps,. publish my 
version and polish it a bit.

(I'm personally not interested in new-class functionality which allows 
one to create Java class from Lisp.)

(I've found this updated version: 
https://gist.github.com/avodonosov/abcl-idea/blob/master/src/abclidea/lisp/jfli-abcl/jfli-abcl.lisp
But haven't yet checked if it works with latest ABCL and what are 
improvements against old one.)

One (probably) stupid question

Francisco Vides Fernández — 2012-05-18T11:14:07

I'm aware that this must be a stupid question, but after googling for a
while can't find the right answer:

How can I invoke a method with a boolean as an argument. I try to do the
following:

---8<---
(let* ((jlclass (jclass "java.lang.Class"))
       (for-name (jmethod  jlclass "forName"
               (jclass "java.lang.String")
               (jclass "boolean")
               (jclass "java.lang.ClassLoader"))))
  (jstatic for-name jlclass "org.postgresql.Driver" t
(get-current-classloader)))
---8<---
But it raises the error:

The value T is not of class boolean
   [Condition of type ERROR]

I tried replacing '(jclass "boolean") for '(jclass "java.lang.Boolean"),
but in that case it doesn't find the for-name method.

How am I supposed to invoke the method!

Thanks in advance!

sockets in CLISP

Santiago Carbonell — 2012-05-18T09:38:57

Hi,

I'm trying to send some strings using the format function in LISP to a
sockets but always I obtain NIL

I'm using this function:

(defun sockets_fun()
(WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 49729 "localhost"))
(let ((*standard-output* socket))
(format socket "The color is ~A" "red")
(force-output socket)
(finish-output nil)
)))

But always I obtain NIL in the socket

Instead of that function I've tried to use this another function:

(defun geetings()
(print "hi"))

and works fine, appears hi in the socket

Why there are problems with sockets with the format function?

Thanks
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Connection to database via JDBC and classpath

Francisco Vides Fernández — 2012-05-17T21:04:01

Hello everyone

I intend to use ABCL in one of my projects. I've started to connectiing
to a postgresq database via jdbc. I've tried something like:

-------8<-------
(add-to-classpath
 (merge-pathnames
#p".m2/repository/postgresql/postgresql/8.4-702.jdbc4/postgresql-8.4-702.jdbc4.jar"

          (user-homedir-pathname)))

(jstatic "forName" "java.lang.Class"  "org.postgresql.Driver")
-------8<-------

But it always returns
-------8<-------
Java exception 'java.lang.ClassNotFoundException: org.postgresql.Driver'.
   [Condition of type JAVA-EXCEPTION]
-------8<-------
The jar file exists, and has the proper class inside. I've read the
manual, and googled a bit, but still get the same error. I'm using
Ubuntu Linux,  with OpenJDK 1.6.0_24, and the latest and greatest ABCL
downloaded as a binary from ABCL website. Can someone point me what I'm
doing wrong?

Many thanks for this great project!!

ABCL has an incorrect belief about hostname andcpu in its fasl storage

Paul Nathan — 2012-05-12T04:06:07

Dear all,

I installed Armed Bear Common Lisp 1.0.1-svn-13750-13751 in order to run it on my OSX 10.6 (Snow Leopard) 64-bit system (Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64), for the purpose of executing cl-test-grid.

However, I observed that the fasls were being stored in ~/.cache/common-lisp/abcl-1.0.1-svn-13750-13751-fasl38-solaris-x86

You will quickly note that my system is neither solaris nor x86. 

However, I checked some of the environment settings:

 java -jar abcl.jar 
Armed Bear Common Lisp 1.0.1-svn-13750-13751
Java 1.6.0_31 Apple Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.619 seconds.
Startup completed in 1.511 seconds.
Type ":help" for a list of available commands.
CL-USER(1): *features*
(:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :DARWIN :CDR6)
CL-USER(2): (machine-instance)
"elendil.local"
CL-USER(3): (machine-type)
"X86_64"
CL-USER(4): (software-type)
"Mac OS X"
CL-USER(5): (software-version)
"10.6.8"
CL-USER(6): (machine-version)
NIL

And they turn out correct.

I am not a regular ABCL user, so pardon me if this is already known.  If an OSX Snow Leopard system is not available for testing, I volunteer my time and machine to test a patch.

Regards,
Paul Nathan

how to redirect format function to a socket stream

Santiago Carbonell — 2012-05-13T19:00:16

Hi,

I've a socket stream named "socket" in this port and host: 50362 and
localhost

I've written this function to redirect format function to the socket but
only appears NIL. How can I redirect format t lisp function to a socket?

(defun colors()
(WITH-OPEN-STREAM (socket (SOCKET:SOCKET-CONNECT 50362 "localhost"))
(let ((*standard-output* socket))
(format t "The color is ~A" "red")
)))

Thanks
_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Error building abcl-servet

aditya siram — 2012-05-08T18:06:11

Hi all,
I am trying to build abcl-servlet and running into the following error:
...
/home/deech/Lisp/abcl-servlet/build.xml:36:
org.armedbear.lisp.Interpreter$UnhandledCondition: Unhandled lisp
condition: #<MISSING-COMPONENT {98F805}>
at org.armedbear.lisp.Interpreter$1.execute(Interpreter.java:568)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.debug_6.execute(debug.lisp:105)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124)
at org.armedbear.lisp.Symbol.execute(Symbol.java:808)
at org.armedbear.lisp.LispThread.execute(LispThread.java:683)
at org.armedbear.lisp.debug_7.execute(debug.lisp:114)
at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.signal_2.execute(signal.lisp:63)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:124)
at org.armedbear.lisp.Symbol.execute(Symbol.java:808)
at org.armedbear.lisp.LispThread.execute(LispThread.java:683)
at org.armedbear.lisp.asdf_250.execute(asdf.lisp:1692)
at org.armedbear.lisp.LispThread.execute(LispThread.java:633)
at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633)
at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.asdf_249.execute(asdf.lisp:1692)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.asdf_248.execute(asdf.lisp:1692)
at org.armedbear.lisp.clos_297.execute(clos.lisp:2120)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.clos_282.execute(clos.lisp:1934)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.clos_275.execute(clos.lisp:1768)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.asdf_239.execute(asdf.lisp:1623)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.asdf_238.execute(asdf.lisp:1623)
at org.armedbear.lisp.clos_297.execute(clos.lisp:2120)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.clos_282.execute(clos.lisp:1934)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.clos_275.execute(clos.lisp:1768)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101)
at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2791)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.clos_244.execute(clos.lisp:1381)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.clos_247.execute(clos.lisp:1400)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101)
at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:131)
at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.asdf_493.execute(asdf.lisp:2565)
at org.armedbear.lisp.LispThread.execute(LispThread.java:633)
at org.armedbear.lisp.asdf_241.execute(asdf.lisp:1633)
at org.armedbear.lisp.Symbol.execute(Symbol.java:785)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.asdf_492.execute(asdf.lisp:2565)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.asdf_491.execute(asdf.lisp:2565)
at org.armedbear.lisp.clos_295.execute(clos.lisp:2016)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.clos_282.execute(clos.lisp:1934)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.clos_275.execute(clos.lisp:1768)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2794)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.clos_244.execute(clos.lisp:1381)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.clos_247.execute(clos.lisp:1400)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:112)
at org.armedbear.lisp.StandardGenericFunction.execute(StandardGenericFunction.java:138)
at org.armedbear.lisp.Symbol.execute(Symbol.java:796)
at org.armedbear.lisp.LispThread.execute(LispThread.java:666)
at org.armedbear.lisp.Lisp.funcall(Lisp.java:174)
at org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2842)
at org.armedbear.lisp.Primitive.execute(Primitive.java:148)
at org.armedbear.lisp.Symbol.execute(Symbol.java:820)
at org.armedbear.lisp.LispThread.execute(LispThread.java:701)
at org.armedbear.lisp.asdf_497.execute(asdf.lisp:2625)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548)
at org.armedbear.lisp.Lisp.eval(Lisp.java:513)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.Primitives$sf_eval_when.execute(Primitives.java:3874)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Load.loadStream(Load.java:567)
at org.armedbear.lisp.Load.loadFileFromStream(Load.java:535)
at org.armedbear.lisp.Load.load(Load.java:670)
at org.armedbear.lisp.Load$_load_returning_last_result.execute(Load.java:648)
at org.armedbear.lisp.Symbol.execute(Symbol.java:820)
at org.armedbear.lisp.LispThread.execute(LispThread.java:701)
at org.armedbear.lisp.load_2.execute(load.lisp:46)
at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101)
at org.armedbear.lisp.LispThread.execute(LispThread.java:649)
at org.armedbear.lisp.Lisp.evalCall(Lisp.java:548)
at org.armedbear.lisp.Lisp.eval(Lisp.java:513)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Primitives$sf_multiple_value_prog1.execute(Primitives.java:3969)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Primitives$sf_unwind_protect.execute(Primitives.java:3840)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169)
at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.eval(Lisp.java:506)
at org.armedbear.lisp.Lisp.eval(Lisp.java:511)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:275)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:146)
at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.eval(Lisp.java:506)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169)
at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169)
at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
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:548)
at org.armedbear.lisp.Lisp.eval(Lisp.java:513)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
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.evalCall(Lisp.java:548)
at org.armedbear.lisp.Lisp.eval(Lisp.java:513)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.SpecialOperators._let(SpecialOperators.java:169)
at org.armedbear.lisp.SpecialOperators$sf_let.execute(SpecialOperators.java:101)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3733)
at org.armedbear.lisp.Lisp.eval(Lisp.java:503)
at org.armedbear.lisp.Lisp.progn(Lisp.java:682)
at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:451)
at org.armedbear.lisp.Closure.execute(Closure.java:561)
at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:234)
at org.armedbear.lisp.scripting.AbclScriptEngine.eval(AbclScriptEngine.java:243)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

My ABCL version is 1.0.1.
-deech

load-pathname with incorrect value

wl chiu — 2012-04-26T12:47:39

Hi again,
I have a file:
---- load-pathname.lisp -----
(print *load-pathname*)
-----------------------------
When loaded, I get this:

java.exe -cp "abcl.jar" org.armedbear.lisp.Main --load load-path.lisp==> #P"load-path.lisp" 


According to CLHS, I believe this is wrong?
  During a call to load, *load-pathname* is bound to the pathname denoted by  the the first argument to load, merged against the defaults; that is, it  is bound to (pathname (merge-pathnames filespec)).  During the same time


Cheers,
Wei-Lun Chiu

Funny behavior about flet after compilation.

wl chiu — 2012-04-25T10:47:11


Hi dear devs,
I encountered some funny behaviour between compiled and interpretedcode with flet. I'm not sure if this is a duplicate bug?
-------- flet-bug.lisp --------------
(defun foo (x)  (print x))
(defun test1 ()  (flet ((foo1 ()           (foo 3)))    (foo1)))
(defun test2 ()  (flet ((foo ()           (foo 3)))    (foo)))
------------------------------------
We compile the following file,
  (compile-file "c:/me/temp/flet-bug.lisp")  ; Compiling C:/me/temp/flet-bug.lisp ...
  ; (DEFUN FOO ...)
  ; (DEFUN TEST1 ...)
  ; (DEFUN TEST2 ...)
  ; Wrote c:/me/temp/flet-bug.abcl (2.62 seconds)

Then either load it interpreted or compiled. Interpreted, everything'sfine:
  > (load "c:/me/temp/flet-bug.lisp")  T  > (test1)  
  3 
  3  > (test2)  
  3 
  3
Compiled, we get an error in test2:
  > (load "c:/me/temp/flet-bug.abcl")  T  > (test1)  
  3 
  3  > (test2)  ; Evaluation aborted on #<PROGRAM-ERROR {797E7B}>.

The stack trace for this is:
    Wrong number of arguments for #<FOO {CCA5B9}>.       [Condition of type PROGRAM-ERROR]        Restarts:     0: [RETRY] Retry SLIME REPL evaluation request.     1: [*ABORT] Return to SLIME's top level.     2: [ABORT] Abort thread.        Backtrace:      0: (#<FUNCTION {490A12}> #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>)      1: (APPLY #<FUNCTION {490A12}> (#<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>))      2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR {19430CA}> #<FUNCTION {490A12}>)      3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {19430CA}>)      4: org.armedbear.lisp.Lisp.error(Lisp.java:381)      5: org.armedbear.lisp.Function.execute(Function.java:312)      6: org.armedbear.lisp.Primitive.execute(Primitive.java:113)      7: (FOO 3)      8: (TEST2)      9: (SYSTEM::%EVAL (TEST2))     10: (EVAL (TEST2))     11: (SWANK::EVAL-REGION "(test2)
         ")     ... etc ...

Thanks for your attention,
Wei-Lun Chiu       _______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Package redefinition issue in REPL.

wl chiu — 2012-04-25T10:56:20

Hello dear developers,
I' just experienced an odd issue with defpackage.  It looked like the package will not be modified if I call defpackage again.
For example, I define a package called "a-package".  After a while I wanted to export a function that I've just implemented called "a-new-foo".  Naturally I would add a new entry under the :export section of defpackage, and then eval the expression again.  However, I still cannot access "a-new-foo" as the REPL gives me "such symbol is not external of package [a-package]" error message.
Please advice and many thanks,
Wei-Lun Chiu

       _______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

SLIME reconnection on ABCL 1.1.0-dev fails

aditya siram — 2012-04-16T22:00:20

Hi all,
If I connect to a repl with M-x slime , disconnect using M-x
slime-quit-lisp and reconnect it loads the fasls and then fails with:
WARNING:
#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

#<THREAD "interpreter" {1F873DD}>: Debugger invoked on condition of
type SIMPLE-ERROR

Maximum error depth exceeded (11 nested errors).
CL-USER(2): CL-USER(2):

The prompt "CL-USER(2)" works but emacs stays locked with a "Polling
"/tmp/slime.2616".. (Abort with `M-x slime-abort-connection'.)"
One possible indication of the problem is that there is no file
/tmp/slime.2616.

If I delete the fasls and start slime, it re-compiles them all and starts fine.

This does not happen with abcl-1.0.1.

Thanks!
-deech

asdf encodings and abcl

Faré — 2012-04-09T01:21:22

Dear ABCL developers,

I'm currently adding source file encoding support to ASDF.
It will hopefully be part of ASDF 2.21, though the plan is that
anything but :utf-8 and :default requires an extension :asdf-encodings.

I didn't find any way with ABCL to detect the list of external formats,
or to determine is a given keyword is an acceptable name for an external format.

How do I do that?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If there's a book you really want to read but it hasn't been written yet,
then you must write it. — Toni Morrison [same with software, —♯f]

_______________________________________________
armedbear-devel mailing list
armedbear-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Bug in abcl/contrib/jss/invoke.lisp - trying to call JScheme's jsint.Invoke.poke, jsint.Invoke.pokeStatic

Jonathan P. Bona — 2012-04-05T20:52:20

An issue in invoke.lisp (below): set-java-field calls the poke and
pokeStatic methods from jscheme's jsint.Invoke class. This should be
replaced, right?

;;; http://svn.common-lisp.net/armedbear/tags/1.0.1/abcl/contrib/jss/invoke.lisp
(defun set-java-field (object field value &optional (try-harder
*running-in-osgi*))
  (if try-harder
      (let* ((class (if (symbolp object)
(setq object (find-java-class object))
      (if (equal "java.lang.Class" (jclass-name (jobject-class object)) )
  object
(jobject-class object))))
     (jfield (if (java-object-p field)
 field
       (find field (#"getDeclaredFields" class) :key 'jfield-name
:test 'equal))))
(#"setAccessible" jfield t)
(values (#"set" jfield object value) jfield))
    (if (symbolp object)
(let ((class (find-java-class object)))
  (#"pokeStatic" 'invoke class field value))
      (#"poke" 'invoke object field value))))


- Jonathan Bona

Calling java from lisp

Arnaud Bailly — 2012-04-05T14:12:37

Hello (again),
I am trying to invoke java code from lisp code following
http://common-lisp.net/project/armedbear/doc/abcl-user.html.
Here is the code I am trying to run:

CL-USER> (defun java-format (fmtstring &rest args)
           (let* ((string-class (jclass "java.lang.String"))
                  (array-of-objs (jclass "[Ljava.lang.Object;"))
                  (method (jmethod string-class "format" string-class
array-of-objs)))
             (jcall method fmtstring args)))

JAVA-FORMAT

And here is what I got when I try to run it:


Wrong number of arguments for public static java.lang.String
java.lang.String.format(java.lang.String,java.lang.Object[]): expected
2, got 1
   [Condition of type PROGRAM-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Abort thread.

Backtrace:
  0: (#<FUNCTION {53C470B}> #<PROGRAM-ERROR {76F2D004}> #<FUNCTION {53C470B}>)
  1: (APPLY #<FUNCTION {53C470B}> (#<PROGRAM-ERROR {76F2D004}>
#<FUNCTION {53C470B}>))
  2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<PROGRAM-ERROR
{76F2D004}> #<FUNCTION {53C470B}>)
  3: (INVOKE-DEBUGGER #<PROGRAM-ERROR {76F2D004}>)
  4: org.armedbear.lisp.Lisp.error(Lisp.java:381)
  5: org.armedbear.lisp.Java.jcall(Java.java:880)
  6: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:755)
  7: org.armedbear.lisp.Primitive.execute(Primitive.java:135)
  8: (JCALL #<java.lang.reflect.Method public static java.lang.String
j.... {451CF2D}> "" ("%d %08.d %s" 1 2 3))
  9: (JAVA-FORMAT "" "%d %08.d %s" 1 2 3)
 10: (SYSTEM::%EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3))
 11: (EVAL (JAVA-FORMAT "" "%d %08.d %s" 1 2 3))
 --more--

What am I doing wrong ?

Arnaud

Cannot get abcl 1.0.1 working with slime

Arnaud Bailly — 2012-04-05T13:04:17

Hello,
I am trying to use ABCL 1.0.1 with slime under emacs and get the
following errors:

(progn (load "/usr/share/common-lisp/source/slime/swank-loader.lisp"
:verbose t) (funcall (read-from-string "swank-loader:init")) (funcall
(read-from-string "swank:start-server") "/tmp/slime.3985"
:coding-system "iso-latin-1-unix"))

Armed Bear Common Lisp 1.0.1-svn-13750-13751
Java 1.6.0_26 Sun Microsystems Inc.
Java HotSpot(TM) 64-Bit Server VM
Low-level initialization completed in 0.297 seconds.
Startup completed in 0.935 seconds.
Type ":help" for a list of available commands.
CL-USER(1): ; Loading /usr/share/common-lisp/source/slime/swank-loader.lisp ...
Error loading /usr/share/common-lisp/source/slime/swank-loader.lisp at
line 143 (offset 5611)
#<THREAD "interpreter" {33E136A8}>: Debugger invoked on condition of
type READER-ERROR
  The package "ASDF" can't be found.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] SWANK-LOADER(2):

Here is my .emacs:

(add-to-list 'load-path "/usr/share/emacs/site-lisp/slime")


;;(setq inferior-lisp-program "/usr/local/bin/sbcl")
(setq inferior-lisp-program "java -cp
/home/arnaud/soft/abcl-bin-1.0.1/abcl-contrib.jar -jar
/home/arnaud/soft/abcl-bin-1.0.1/abcl.jar")

;; from http://functionalrants.wordpress.com/2008/09/06/how-to-set-up-emacs-slime-sbcl-under-gnulinux/
(require 'slime)
(slime-setup '(slime-fancy))

Help greatly appreciated.

Thanks
Arnaud

JSS issues: bug in jss::with-constant-signature,jss::invoke-find-method?

Jonathan P. Bona — 2012-03-30T21:36:03

I'm working with Alan Ruttenberg to port LSW from the old version of
JSS to the JSS that is now part of abcl-contrib.

We've run into the following bug when using with-constant-signature:

; these first two work fine:
(#"substring" "some string" 2 4)  ; "me"
(#"substring" "some string" 2)     ; "me string"

; and so does this
(with-constant-signature ((substring "substring")) (substring "some
string" 2 4))   ; "me"

; but this breaks:
(with-constant-signature ((substring "substring")) (substring "some string" 2))
; Wrong number of arguments for public java.lang.String
java.lang.String.substring(int,int): expected 2, got 1
;   [Condition of type PROGRAM-ERROR]


A problem seems to be in jss::invoke-find-method, which is finding the
two argument version of java.lang.String.substring no matter how many
arguments its given:

(jss::invoke-find-method "substring" "this is a string" '(1))  ;
should return the java.lang.String.substring method with one int arg
; #<method public java.lang.String java.lang.String.substring(int,int)>

(jss::invoke-find-method "substring" "this is a string" '(1 2) )
; #<method public java.lang.String java.lang.String.substring(int,int)>

(jss::invoke-find-method "substring" "this is a string" '(1 2 3 4 5 6
7 8) )  ; should be an error
; #<method public java.lang.String java.lang.String.substring(int,int)>




- Jonathan Bona

run-program :environment nil

Pascal J. Bourguignon — 2012-03-26T16:12:39

(lisp-implementation-version) --> "1.0.1"


The documentation of extensions:run-program is misleading:

    :environment 
        An alist of STRINGs (name . value) describing the new
        environment. The default is to copy the environment of the current
        process.

The alist doesn't describe the NEW environment, it is only MERGED into
the current environment.


Now of course, I consider the current behavior to be a bug:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash"  …)


I would expect:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ()

and:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment
                                                   '(("LC_CTYPE" . "C")))))
    --> ("LC_CTYPE=C"))

Which would match what the documentation says.



Also, in a shell environment, an empty variable is not the same as an
inexistant variable, so I cannot just loop over all the existing
variables to set them to an empty string.  I see no
SYSTEM::%PROCESS-BUILDER-ENV-REM function…

ABCL on jdk-1.7.0_03

Mark Evenson — 2012-03-21T10:50:02

I've just run abcl-1.1.0-dev the ANSI-COMPILED tests on jdk-1.7.0_03
with reasonable looking results of 31 failures, which is roughly
the same number as those run with jdk-1.6.0_31 (some of the tests
use randomly generated data so they sometimes either fail or succeed).

Previously, I think that we weren't even completing the ANSI-COMPILED
test suite due to issues in the character set encoding, so I think
we should now more fully endorse running ABCL on Java7.

compiled errors: debug.assertTrue()

2012-02-28T11:28:15

Hi,

When I try to compile the mcs-core.cl file (attached) with java abcl, I get this error:

Failed to get InputStream for 'jar:file:D:/otro/kernel/modules/fmcs.bin!/mcs_core_4.cls'ABCL Debug.assertTrue() assertion failed!java.lang.Error: ABCL Debug.assertTrue() assertion failed!

 

Why is this happening? How can I resolved it?

 

Thanks

 _______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

compiling lisp files outside Java and calling itafter with abcl

2012-02-28T11:32:50

Hi,I'm trying to compile a lisp application and I get a lot of errors with java abcl. I thought that if I try to compile this lisp files outside of abcl with other systems, perhaps, I could then call this compiled functions lisp files from ABCL (look like a jar file of lisp compiled files). Is this possible?How can I compiled this files outside ABCL? Some examples?Thanks_______________________________________________
armedbear-devel mailing list
armedbear-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

Patch for ABCL to dynamically load CFFI JNArequirement

Mark Evenson — 2012-02-24T17:16:06

Please consider the referenced patch for inclusion in cffi-0.10.7. 
Comments towards improvments solicited.

Improvements to ABCL CFFI implementation:

o  autoload the 'jna.jar' dependency if possible (requires abcl-1.1.0-dev)

o  initial implementation of callbacks

Needs ABCL specific tests, but I can load CL+SSL with this patch.

[1]: http://slack.net/~evenson/abcl/cffi/abcl-cffi-20120224a.diff

Cheers,
easyE