pg-dot-lisp lets you access the PostgreSQL object-relational DBMS
from Common Lisp. The code implements the client part of the
socket-level frontend/backend protocol, rather than providing a
wrapper around the libpq library. The module is capable of type
coercions from a range of SQL types to the equivalent Lisp type.
The only non portable code is the use of 'socket-connect' and
(optional) some way of accessing the Unix crypt() function. Works with
CMUCL, SBCL, CLISP, OpenMCL, Allegro CL, Lispworks, MCL and ArmedBear
Lisp. Not working: CormanLisp has socket support but not for binary
I/O; ECL corrupts data on binary sockets streams.
=== Version 0.19, 2003-10-10 ===========================================
- new multi-file organization: split out the system-dependent parts
and the tests into separate files. An ASDF system description is
provided in the file pg.asd.
- change to WITH-PG-TRANSACTION: the previous version would abort the
current transaction upon encountering an error, which made
debugging difficult. The new version (thanks to Daniel Barlow)
maintains the transaction open until you have exited the debugger.
- support for connecting to PostgreSQL using a local socket instead
of using TCP/IP, when you're on the same host as the backend. To
enable, use a NIL host argument to PG-CONNECT. This makes it
possible to connect to the database without enabling TCP/IP
connections in the backend ("-i" option), and (depending on the
access configuration parameters specified in pg_hba.conf) possibly
without supplying a password. This is currently only supported for
CMUCL and SBCL.
- parser support for the INTERVAL type (you get this by subtracting
two timestamps). They are coerced by pg-dot-lisp to a number of
seconds, represented in floating point.
- new configuration variable *PG-CLIENT-ENCODING*, that supports
client-side encoding of text data, as per
<http://www.postgresql.org/docs/7.3/static/multibyte.html>.
Function PG-CLIENT-ENCODING, and corresponding setf
function, that allows you to retrieve and modify the current client
encoding.
- new configuration variable *PG-DATE-STYLE* that allows you to
change the style in which date types are printed. Function
PG-DATE-STYLE that allows you to retrieve (and modify via its SETF
function) the current backend's date style.
- CMUCL: loading the file cmucl-install-subsystem.lisp (as a user who
has write access to the directory where CMUCL is installed) will
cause this package to be installed as a CMUCL "subsystem", that can
thereafter be loaded by saying "(require :pg)".
- SBCL: fix for new sb-bsd-sockets
- support for a new Common Lisp implementation, Armed Bear Lisp for
the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
>>>>> "ecm" == Eric Marsden <········@laas.fr> writes:
ecm> pg-dot-lisp lets you access the PostgreSQL object-relational DBMS
ecm> from Common Lisp. The code implements the client part of the
ecm> socket-level frontend/backend protocol, rather than providing a
ecm> wrapper around the libpq library. The module is capable of type
ecm> coercions from a range of SQL types to the equivalent Lisp type.
it might be worth adding that it can be downloaded from
<URL:http://www.chez.com/emarsden/downloads/>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden wrote:
> - support for a new Common Lisp implementation, Armed Bear Lisp for
> the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
>
Can somebody give me more information about this Armed Bear Lisp?
Couldn't find anything in Google.
TIA
--
Ivan Toshkov
email: ··········@last-name.org
"Ivan Toshkov" <·······@hotmail.com> wrote in message
···················@ID-207269.news.uni-berlin.de...
> Eric Marsden wrote:
> > - support for a new Common Lisp implementation, Armed Bear Lisp for
> > the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
> >
>
> Can somebody give me more information about this Armed Bear Lisp?
> Couldn't find anything in Google.
First result for me:
http://armedbear-j.sf.net/
It's an extension language for J (a Java editor) which apparently supports
61% of Common Lisp (well, at least according to the GCL ANSI test suite).
alex
Hi,
Ivan Toshkov wrote:
> Eric Marsden wrote:
>
>> - support for a new Common Lisp implementation, Armed Bear Lisp for
>> the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
>
>
> Can somebody give me more information about this Armed Bear Lisp?
> Couldn't find anything in Google.
It is the first time I hear something about this "Armed Bear Lisp" so I
don't know much about it too, but I was able to find something on the
net: http://armedbear-j.sourceforge.net/
I'm not sure if it is the same thing since this is mainly a text editor
but looking at the page you can find the following:
"This release officially introduces j's new built-in extension language,
which has been lurking in the code since version 0.18.1. At that time,
the language itself was an ad-hoc, bug-ridden and slow implementation of
half of Common Lisp. Since then, it has gotten faster (by a factor of
2), and it's now up to 61% of Common Lisp (it passes 7918 of the 12842
tests in the GCL ANSI test suite). I don't think it's particularly
bug-ridden, but it's still very ad hoc, in terms of exactly what
features have been implemented."
If someone knows what exactly this Armed Bear Lisp is, I'm also curious
about it.
Best Regards,
Jorge
--
Jorge Tavares
http://www.dei.uc.pt/~jast
"Evolution is the best engineer."
Jorge Tavares wrote:
>
> Hi,
>
> Ivan Toshkov wrote:
>
>> Eric Marsden wrote:
>>
>>> - support for a new Common Lisp implementation, Armed Bear Lisp for
>>> the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
>>
>>
>>
>> Can somebody give me more information about this Armed Bear Lisp?
>> Couldn't find anything in Google.
>
>
> It is the first time I hear something about this "Armed Bear Lisp" so I
> don't know much about it too, but I was able to find something on the
> net: http://armedbear-j.sourceforge.net/
Thanks! I found it too, but discarded it, when I saw it was an editor.
I hope this will teach me a lesson. ;)
--
Ivan Toshkov
email: ··········@last-name.org
I played around a little bit with it this evening.
Go to http://armedbear-j.sourceforge.net/.
Download j-0.20.1-binary.zip or equivalent.
Get j.jar out of the distribution.
Get Java 1.4 or later.
Run "java -cp j.jar org.armedbear.lisp.Main"
You get Common Lisp with macros, some of "format", no CLOS, and a way
to get to any java classes, methods, etc. in your classpath. Pretty
cool. If he advertised this more here he'd probably get more help with
the Lisp part.
Ivan Toshkov <·······@hotmail.com> wrote:
>Eric Marsden wrote:
>> - support for a new Common Lisp implementation, Armed Bear Lisp for
>> the JVM. Tested with IBM 1.4, Sun 1.4 and gij 3.3 virtual machines.
>>
>
>Can somebody give me more information about this Armed Bear Lisp?
>Couldn't find anything in Google.
>
>TIA
······@bellsouth.net (Ralph Richard Cook) wrote in message news:<················@newsgroups.bellsouth.net>...
> I played around a little bit with it this evening.
> Go to http://armedbear-j.sourceforge.net/.
> Download j-0.20.1-binary.zip or equivalent.
> Get j.jar out of the distribution.
> Get Java 1.4 or later.
> Run "java -cp j.jar org.armedbear.lisp.Main"
If you get the latest version from CVS it does have CLOS
and a much richer set of pre-defined macros. (The download is
a couple of months old....)
Btw, I am porting LISA:
http://lisa.sourceforge.net
to Armed Bear Lisp .... I am getting close to the end line,
- Mike
·······@hipaaccelerator.com (Mike Beedle) wrote in message news:<····························@posting.google.com>...
> ······@bellsouth.net (Ralph Richard Cook) wrote in message news:<················@newsgroups.bellsouth.net>...
> > I played around a little bit with it this evening.
> > Go to http://armedbear-j.sourceforge.net/.
> > Download j-0.20.1-binary.zip or equivalent.
> > Get j.jar out of the distribution.
> > Get Java 1.4 or later.
> > Run "java -cp j.jar org.armedbear.lisp.Main"
>
>
> If you get the latest version from CVS it does have CLOS
> and a much richer set of pre-defined macros. (The download is
> a couple of months old....)
>
> Btw, I am porting LISA:
> http://lisa.sourceforge.net
> to Armed Bear Lisp .... I am getting close to the end line,
>
> - Mike
Btw, I called the above port "JLisa" and it is on its way to
be a SourceForge project.
The motivation is to provide a GPL-licensed tool similar to Jess:
http://herzberg.ca.sandia.gov/jess/
but of course much more powerful:
Lisp + Lisa >> Jess
(I'll post a message when JLisa is more organized...)
- Mike
"Don't worry about what anybody else is
going to do. The best way to predict
the future is to invent it."
Alan Kay
·······@hipaaccelerator.com (Mike Beedle) writes:
> ······@bellsouth.net (Ralph Richard Cook) wrote in message news:<················@newsgroups.bellsouth.net>...
> > I played around a little bit with it this evening.
> > Go to http://armedbear-j.sourceforge.net/.
> > Download j-0.20.1-binary.zip or equivalent.
> > Get j.jar out of the distribution.
> > Get Java 1.4 or later.
> > Run "java -cp j.jar org.armedbear.lisp.Main"
>
>
> If you get the latest version from CVS it does have CLOS
> and a much richer set of pre-defined macros. (The download is
> a couple of months old....)
Prompted by Ralph's post, I gave AB a try a few days ago, and even
though it was the download version, which I'm happy to hear is
outdated, it felt like a real CL, missing features notwithstanding. I
also liked that the CL part stands on its own feet, i.e. one can get a
smallish (~400kB) jar file without the editor, and that the Lisp->Java
API is very close to (a subset of) jLinker's.
What I couldn't figure out was (1) how to call Lisp from Java (2)
whether there's a way to deliver your Lisp application in any other
way than packaging your Lisp source files in a jar and have them
loaded by AB (3) how to call Java methods without always having to
spell out their full package names (4) if AB was really just an
interpreter (from a cursory look at the sources, I had this feeling).
I'm also curious about the potential uses of AB. It is cool, for sure,
but what's in it for a Lisp person (perhaps one who is compelled to
write Java programs in his day job), other than giving them the
ability to distribute their open source Lisp apps or libraries (which
may use the zillions of existing Java libs) thinly disguised as Java
apps/libraries? Note that I'm not saying this is not already a great
feat.
Andras
>>>>> "sa" == Simon Andr�s <······@math.bme.hu> writes:
sa> I also liked that the CL part stands on its own feet, i.e. one
sa> can get a smallish (~400kB) jar file without the editor
it should also be possible to produce the holy grail of a standalone
executable, using gcj. This isn't currently possible with gcj-3.3 due
to missing bits in the GNU Classpath libraries.
sa> What I couldn't figure out was (1) how to call Lisp from Java
hoping I will be excused for posting Java code to cll; here's a simple
example. There are more in the sources of the J editor.
,---- CallLisp.java ---
| import org.armedbear.lisp.Interpreter;
|
| class CallLisp {
|
| public static void main (String args[])
| {
| if (args.length != 1) {
| System.err.println ("Usage: CallLisp lisp-expr");
| System.exit (1);
| }
| try {
| System.out.println (Interpreter.evaluate(args[0]));
| } catch (Throwable e) {
| e.printStackTrace();
| }
| }
| }
`----
which can be compiled and executed as follows:
,----
| % javac -classpath $HOME/lib/j.jar CallLisp.java
| % java -classpath $HOME/lib/j.jar:. CallLisp "(+ 1 2)"
| ; Loading file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/boot.lisp ...
| ; Loaded file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/boot.lisp (2.618 seconds)
| ; Loading file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/j.lisp ...
| ; Loaded file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/j.lisp (0.221 seconds)
| 3
| % java -classpath $HOME/lib/j.jar:. CallLisp "(/ 1 0)"
| ; Loading file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/boot.lisp ...
| ; Loaded file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/boot.lisp (2.616 seconds)
| ; Loading file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/j.lisp ...
| ; Loaded file:/home/emarsden/lib/j.jar!/org/armedbear/lisp/j.lisp (0.221 seconds)
| org.armedbear.lisp.ConditionThrowable
| at org.armedbear.lisp.Fixnum.divideBy(Unknown Source)
| at org.armedbear.lisp.Primitives.dispatch(Primitives.java:164)
| at org.armedbear.lisp.Function.execute(Unknown Source)
| at org.armedbear.lisp.Primitive.execute(Unknown Source)
| at org.armedbear.lisp.Lisp.funcall(Lisp.java:104)
| at org.armedbear.lisp.Lisp.eval(Lisp.java:361)
| at org.armedbear.lisp.Interpreter.evaluate(Interpreter.java:550)
| at CallLisp.main(CallLisp.java:13)
`----
sa> loaded by AB (3) how to call Java methods without always having to
sa> spell out their full package names (4) if AB was really just an
sa> interpreter (from a cursory look at the sources, I had this feeling).
I expect that (3) wouldn't be too difficult to implement (requires
fiddling with the Java introspection API). Re (4), Armed Bear Lisp is
currently an interpreter, but Peter Graves has a mostly-working Lisp
to JVM bytecode compiler, that speeds things up by a factor of around
10.
sa> I'm also curious about the potential uses of AB. It is cool, for sure,
sa> but what's in it for a Lisp person (perhaps one who is compelled to
sa> write Java programs in his day job), other than giving them the
sa> ability to distribute their open source Lisp apps or libraries (which
sa> may use the zillions of existing Java libs) thinly disguised as Java
sa> apps/libraries? Note that I'm not saying this is not already a great
sa> feat.
indeed, I think this is already a great feat.
You can also see it as a useful (and very standards-compliant) Common
Lisp implementation that runs anywhere you have a JVM.
<URL:http://www.cliki.net/Armed+Bear+Lisp>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Eric Marsden <········@laas.fr> writes:
[a lot of useful info on ABCL]
Thanks! Looks like it's time to
(push :armed-bear *common-lisp-implementations*).
Yet another sign that CL is doing quite well for a dead language!
Besides, although I wasn't initially very much interested in J proper
(as opposed to its CL implementation), on second thought it seems it
deserves attention as the first incarnation of CL-Emacs. I never
expected it coming from the Java direction.
Andras
Hi Eric Marsden,
> it should also be possible to produce the holy grail of a standalone
> executable, using gcj. This isn't currently possible with gcj-3.3 due to
> missing bits in the GNU Classpath libraries.
Just remember people this Holy Grail may require you to GPL any code you
distribute that so called dynamically links to ArmedBear Lisp.
<http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL>
A consequence is that if you choose to use GPL'd Perl modules or Java
classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on.
The Free Software Foundation has an expansive view of what is considered
linking to GPLed code.
Regards,
Adam
Adam Warner <······@consulting.net.nz> writes:
> Just remember people this Holy Grail may require you to GPL any code you
> distribute that so called dynamically links to ArmedBear Lisp.
> <http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL>
>
> A consequence is that if you choose to use GPL'd Perl modules or Java
> classes in your program, you must release the program in a
> GPL-compatible way, regardless of the license used in the Perl or Java
> interpreter that the combined Perl or Java program will run on.
I think Peter is open to the idea of LGPLing ABL, but don't quote me
on it: I may be misremembering. It certainly wouldn't hurt to ask
him, though.
> The Free Software Foundation has an expansive view of what is considered
> linking to GPLed code.
For what it's worth, note that the FSF's opinion doesn't matter too much
(except insofar as it influences the opinion of the copyright holder)
because they're not the copyright holder. But you're right, this is a
concern for Lisp environments.
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro