gmane.lisp.armedbear.devel

Re: Connection to database via JDBC and classpath

Alessio Stalla — 2012-05-24T07:05:43

On Thu, May 24, 2012 at 4:30 AM, Alan Ruttenberg
<alanruttenberg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

The only way I know is mucking with ClassLoader via reflection. Not
pretty and not portable, since the accessed fields are private.

Alessio

Re: Connection to database via JDBC and classpath

Alan Ruttenberg — 2012-05-24T02:30:53

I have had trouble if there is an associated native library that needs to
be loaded - in that case the java initializer will expect to be able to
load the native library, but I don't know any way to dynamically extend the
native library path. That may not be happening in your case, but I figured
I'd add this factoid to the thread for later searching. If anyone knows how
to actually change java.library.path at run time (and have the change
matter), do let me know.
-Alan

On Fri, May 18, 2012 at 9:08 AM, Mark Evenson <evenson-VmQCmMdMyN0AvxtiuMwx3w< at >public.gmane.org> wrote:

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

Re: Is anybody interested in jfli-abcl?

Ole Myren Rohne — 2012-05-23T18:57:49

Hi Alex,

I also have my own hacked up version of jfli, if you want to have a look it is here:

<https://github.com/mrohne/jfli>

Ole

On 2012-05-23, at 15:06 , Alex Mizrahi wrote:


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

Re: Is anybody interested in jfli-abcl?

Mark Evenson — 2012-05-23T18:31:02

[…]

If jfli-abcl is pure Common Lisp, I offer to package it as a 
ABCL-CONTRIB extension.  JSS is only one of the experiments in Java 
syntax we would like to support in our aim to make the Bear 
polymorphously perverse.

All one needs to do is create a toplevel ASDF definition in 'jfli.asd' 
and move it into 'ABCL_ROOT/contrib/jfli/' in the build tree.

After recompiling, the source may be loaded into the running JVM via the 
CL:REQUIRE mechanism:

(require :abcl-contrib)
(require :jfli)

Right now I'm really trying to triage stuff for [abcl-1.1.0][], but if 
you gave me a patch to apply to [ABCL trunk][2], I could easily commit it.

[abcl-1.1.0]: http://trac.common-lisp.net/armedbear/milestone/1.1.0
[2]: http://code.google.com/p/abcl-dynamic-install/source/browse/

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 ve

Re: ABCL has an incorrect belief about hostnameand cpu in its fasl storage

Paul Nathan — 2012-05-18T14:12:40

cl-test-grid reports in by OS name & architecture. This implies that ABCL results from different architectures (which potentially might differ) will be conflated.  

Thanks for taking a look!

On May 18, 2012, at 2:49 AM, Mark Evenson wrote:


Regards,
Paul Nathan




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

Re: Connection to database via JDBC and classpath

Mark Evenson — 2012-05-18T13:08:19

On May 18, 2012, at 14:54 , Alex Mizrahi wrote:


[…]

Apparently the postgres-jdbc DriverManager API has problems if the
'postgresql.jar' is not on the system classpath, which doesn't seem to be true for the Oracle JDBC classes.

The following uses the getConnection() method directly on the
org.postgresql.Driver:

(add-to-classpath "/opt/local/share/java/postgresql.jar")
(jcall "connect" (jnew "org.postgresql.Driver") "jdbc:postgresql:test" (jnew "java.util.Properties"))

I would recommend using this over messing with the ABCL classpath,
as you'll have to include "extra" instructions to people to use
your interface beyond the Lisp code you ship.

P.S. The "-jar" and "-cp" options to Java are always mutually exclusive.

Re: Connection to database via JDBC and classpath

Alex Mizrahi — 2012-05-18T12:54:51


It looks like you can't use both -cp and -jar.

Here's what works for me:

---
$ java -cp abcl.jar:postgresql.jdbc3.jar org.armedbear.lisp.Main

Armed Bear Common Lisp 1.0.1-svn-13932
Java 1.6.0_20 Sun Microsystems Inc.
OpenJDK 64-Bit Server VM
Low-level initialization completed in 1.024 seconds.
Startup completed in 3.393 seconds.
Type ":help" for a list of available commands.

CL-USER(1): (jstatic "forName" "java.lang.Class"  "org.postgresql.Driver")
#<java.lang.Class class org.postgresql.Driver {218C6982}>

CL-USER(6): (java:jstatic "getConnection" "java.sql.DriverManager" 
"jdbc:postgresql:jena_test" "alex" "xxxxxx")
#<org.postgresql.jdbc3.Jdbc3Connection 
org.postgresql.jdbc3.Jdbc3Connec.... {4FC0CB76}>
---

So, I specify both postgresql and abcl jars in -cp and load class 
org.armedbear.lisp.Main (it starts interpreter and repl).
Then, well, it works. I use older version of PostgreSQL driver, but I 
think it doesn't really matter.

HTH

Re: Connection to database via JDBC and classpath

Francisco Vides Fernández — 2012-05-18T12:25:03

El 18/05/12 13:28, Alex Mizrahi escribió:
I've also tried that. Started ABCL with 'java -cp $JDBC_JAR abcl.jar'
and Class.forName still didn't work. Am I missing some parameter?

Re: Connection to database via JDBC and classpath

Alex Mizrahi — 2012-05-18T12:21:48


This makes no difference:

#<JAVA-EXCEPTION com.hp.hpl.jena.db.RDFRDBException: Failure to 
instantiate DB Driver:PostgreSQL java.sql.SQLException: No suitable 
driver found for jdbc:postgresql://jena_test {27FEFFAC}>.

But everything works (without double slash) when jar is specified via 
java -cp

Re: Connection to database via JDBC and classpath

Alessio Stalla — 2012-05-18T12:10:26

I think that should be jdbc:postgresql://jena_test - note the double slash.

A.

Re: Connection to database via JDBC and classpath

Alex Mizrahi — 2012-05-18T11:57:59



Even this didn't work in my case.

(java:jnew "org.postgresql.Driver")
#<org.postgresql.Driver org.postgresql.Driver< at >48507269 {2B42FB92}>

(java:jstatic "registerDriver" "java.sql.DriverManager" (java:jnew 
"org.postgresql.Driver"))
NIL


(open-database)
; Evaluation aborted on #<JAVA-EXCEPTION 
com.hp.hpl.jena.db.RDFRDBException: Failure to instantiate DB 
Driver:PostgreSQL java.sql.SQLException: No suitable driver found for 
jdbc:postgresql:jena_test {6E18E546}>.

Re: Connection to database via JDBC and classpath

Alex Mizrahi — 2012-05-18T11:28:55


I've got it working once using something like java:jclass in SLIME REPL, 
but not it doesn't seem to work (in a slightly different environment).

Note that if jar is added to classpath via java commandline 
Class.forName will work fine. That's probably the easiest way to get it 
working.
Only loading jar dynamically via classloader is a problem.


Just tried it, doesn't seem to work either.

Re: One (probably) stupid question

Mark Evenson — 2012-05-18T11:18:06

[…]


Use the Java primitive for boolean truth bound to the constant 
JAVA:+TRUE+ instead of t.

Not a stupid question at all:  it should probably should go in our FAQ…

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!

Re: Connection to database via JDBC and classpath

Mark Evenson — 2012-05-18T11:06:52

[…]


[…]

One might try using the JSS:NEW operator which has a slightly more 
aggressive method of locating Java classes with the 
[java.sql.DriverManager API][1], which is the preferred way of loading 
JDBC drivers rather than the Class.forName() method.

[1]: http://docs.oracle.com/javase/6/docs/api/java/sql/DriverManager.html

For loading Oracle drivers, the following code works for me.  I would 
expect that it would for Postgres as well with suitable modification of 
the parameters.

(require 'abcl-contrib)
(require 'abcl-asdf)
(require 'jss)

(defparameter *driver-pathname*
   "~/dist/ojdbc6.jar")
(defparameter *driver-class*
   "oracle.jdbc.OracleDriver")

(defun ensure-driver ()
   (java:add-to-classpath *driver-pathname*)
   (#"registerDriver" 'java.sql.DriverManager (new *driver-class*)))

Re: Connection to database via JDBC and classpath

Alessio Stalla — 2012-05-18T10:14:20

On Fri, May 18, 2012 at 11:20 AM, Francisco Vides Fernández
<fvides-u/fcxpuwxnlHddKoEH+GZlaTQe2KTcn/< at >public.gmane.org> wrote:

Bummer. Classes might not be initialized (or whatever is the correct
technical term) when loaded, depending on how you load them. That
includes (not) running static initializer code. Evidently jclass is
using the wrong method for your use case.

As a workaround, you could try to force initialization of the class by
accessing some static field or method or ask for some metadata
(jclass-methods, jclass-name, ...). But I don't know if that's
guaranteed to work.

Or you can revert to Class.forName, but ensuring to use the overload
that takes an explicit classloader, and feeding it the one used by
ABCL (look in java.lisp to see how to retrieve it).

On the long term, though, jclass really needs to take an extra
argument to force initialization.

Alessio

Re: ABCL has an incorrect belief about hostname and cpu in its fasl storage

Mark Evenson — 2012-05-18T09:49:49

[…]

ASDF is indeed using its compile time values for computing the fasl 
location rather than runtime values (the abcl-bin-1.0.1 release you are 
running was compiled on solarisx86).

Since is ABCL is unique (?) in having platform-independent fasls, we 
need a bit of special treatment.  It looks like asdf-2.21 included in 
ABCL trunk might be a bit more intelligent about this, as it seems to 
have different code, but we will check it out.

This should mostly be an aesthetic, although annoying, problem or is 
there something here that really effects your desired usage of ABCL?

Filed as ticket [209][]; thanks for the report.

[209]: http://trac.common-lisp.net/armedbear/ticket/209

Re: sockets in CLISP

Pascal J. Bourguignon — 2012-05-18T09:47:34


It works well:


[pjb< at >kuiper :0 tmp]$ nc -t -l -p 49729 &
[2] 21094
[pjb< at >kuiper :0 tmp]$ clisp -q -ansi -norc -x '(defun socket-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))))' -x '(socket-fun)'
SOCKET-FUNThe color is red
NIL
[2]+  Done                    nc -t -l -p 49729
[pjb< at >kuiper :0 tmp]$ 


There's no problem with format.

But I'm wondering why you're asking a clisp question on an armedbear
mailing list?

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

Re: Connection to database via JDBC and classpath

Francisco Vides Fernández — 2012-05-18T09:20:38

El 18/05/12 00:21, Alessio Stalla escribió:
[snip]

Yes, that did the trick, but now I've the following code:
--------------8x--------------
(java:jclass "org.postgresql.Driver")
#<java.lang.Class class org.postgresql.Driver {67AFF9E8}>
;; the driver loads, yay!

(java:jstatic "getConnection" "java.sql.DriverManager"
"jdbc:postgresql://localhost:5432/test")
--------------8x--------------
Throws:

--------------8x--------------
Java exception 'java.sql.SQLException: No suitable driver found for
jdbc:postgresql://localhost:5432/test'.
   [Condition of type JAVA-EXCEPTION]
--------------8x--------------

But the equivalent java code works:
--------------8x--------------
public class JdbcConn
{
   public static void main(String[] args)
   {
      try
      {
     Class.forName("org.postgresql.Driver");
     java.sql.Connection c =
java.sql.DriverManager.getConnection("jdbc:postgresql://localhost:5432/test");
      }
      catch(Exception e)
      {
     e.printStackTrace(System.err);
      }
   }
}
------------