Hello
Using CMUCL 18c
- Suppose I have
(defmethod g+ ((x my-time) (y number))
(add-time x (make-time :seconds y)))
I've tried
(compile 'g+)
This terminated with
Error in function C::GET-LAMBDA-TO-COMPILE:
#<Standard-Generic-Function G+ (1) {489DBB29}> was defined in a
non-null environment.
Is it possible to compile methods in the simple manner as ordinary
functions
(e.g. introduced with DEFUN) ?
- How I can revert WHEN macro if I accidentally clobbered it ?
* (when t "foo")
Cannot funcall macro functions.
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
("DEFUN (SETF MACRO-FUNCTION)" #<unavailable-arg>
#<unavailable-arg>)[:OPTIONAL]
0]
Best regards
--
Vladimir Zolotych ······@eurocom.od.ua
"Vladimir V. Zolotych" schrieb:
> Using CMUCL 18c
>
> - Suppose I have
>
> (defmethod g+ ((x my-time) (y number))
> (add-time x (make-time :seconds y)))
>
> I've tried
>
> (compile 'g+)
>
> This terminated with
>
> Error in function C::GET-LAMBDA-TO-COMPILE:
> #<Standard-Generic-Function G+ (1) {489DBB29}> was defined in a
> non-null environment.
Yes, same thing here. Strange I never ran into this before.
Did you get any responses by e-mail?
> Is it possible to compile methods in the simple manner as ordinary
> functions
> (e.g. introduced with DEFUN) ?
Put the DEFMETHOD form in a file, and use COMPILE-FILE and LOAD
to compile and load the file.
Michael
--
"Vladimir V. Zolotych" <······@eurocom.od.ua> wrote
> Using CMUCL 18c
>
> - Suppose I have
>
> (defmethod g+ ((x my-time) (y number))
> (add-time x (make-time :seconds y)))
>
> I've tried
>
> (compile 'g+)
>
> This terminated with
>
> Error in function C::GET-LAMBDA-TO-COMPILE:
> #<Standard-Generic-Function G+ (1) {489DBB29}> was defined in a
> non-null environment.
>
> Is it possible to compile methods in the simple manner as ordinary
> functions
> (e.g. introduced with DEFUN) ?
I use this:
(funcall
(compile nil
(list 'lambda ()
'(defmethod g+ ((x integer) (y integer))
(add-time x (make-time :seconds y))))))
And I get this for g+
0: 55 push ebp
1: 89E5 move ebp, esp
3: 50 push eax
4: 68E4344F21 push 214F34E4 ; :seconds
9: B502 moveb ch, 2
11: 8B45FC move eax, [ebp-4]
14: FF15D0344F21 call [214F34D0] ; make-time
20: B502 moveb ch, 2
22: C9 leave
23: FF25A8344F21 jmp [214F34A8] ; add-time
29: 90 nop
I didn't tried with CMUCL but it should work.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> (funcall
> (compile nil
> (list 'lambda ()
> '(defmethod g+ ((x integer) (y integer))
> (add-time x (make-time :seconds y))))))
Why do you cons a fresh list when the contents are constant?
Is it a style issue, or does COMPILE modify the list?
"Kalle Olavi Niemitalo" <···@iki.fi> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > (funcall
> > (compile nil
> > (list 'lambda ()
> > '(defmethod g+ ((x integer) (y integer))
> > (add-time x (make-time :seconds y))))))
>
> Why do you cons a fresh list when the contents are constant?
> Is it a style issue, or does COMPILE modify the list?
It's just a quick and dirty simple example of how to dynamically compile a
method, not real code.
Marc
Marc Battyani wrote:
>
> I didn't tried with CMUCL but it should work.
Unfortunately not.
Compilation (cmucl 18c) ends up with "bad signature".
#<Standard-Method G+ (INTEGER INTEGER) {489022DD}>
So the following call
* (g+ x1 10)
terminates with error.
Error in function PCL::|(FAST-METHOD NO-APPLICABLE-METHOD (T))|:
No matching method for the generic-function
#<Standard-Generic-Function G+ (1) {48901F89}>,
when called with arguments (#S(MY-TIME :HOURS 12 :MINUTES 0 :SECONDS 0)
10).
Beside that I don't understand things like
(lambda () (defmethod g+ ...)).
What does it mean ?
Things like
(setf (symbol-function 'foo)
(compile nil '(lambda (x) (1+ x)))
more readable for me.
--
Vladimir Zolotych ······@eurocom.od.ua
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
>
> Compilation (cmucl 18c) ends up with "bad signature".
>
That's because his example was compiling a method that specialised on
two integers, while your method was different. I think you're meant
to have put your method where his was.
Some kind of semi-general thing is this:
(defmacro compiling-tlfs (&body tlfs)
`(funcall (compile nil '(lambda ()
,@tlfs))))
Now you can just say
(compiling-tlfs
(defmethod ...))
--tim
Tim Bradshaw wrote:
>
> That's because his example was compiling a method that specialised on
> two integers, while your method was different. I think you're meant
> to have put your method where his was.
Yes, it was my mistake.
Can I ask you (about the discussed example
with (defmethod g+...)
1) What time COMPILED FUNCTION was produced for G+ at?
(e.g. what time definition of the method G+ converted
to compiled form at ?)
For example: for (compile 'foo) all this e.g. converting
function def. into compiled function and replacing
function definition of symbol G+ take place at the same time -
during execution of (compile 'foo) form.
2) What time function definition of symbol G+ was replaced with
new compiled function at ?
Probably I understand things wrong. If so just ignore my post.
I'll read, think, try.
--
Vladimir Zolotych ······@eurocom.od.ua
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
>
> 1) What time COMPILED FUNCTION was produced for G+ at?
> (e.g. what time definition of the method G+ converted
> to compiled form at ?)
Well, I think that's unclear. There really isn't any visible compiled
function here. G+ is a generic function, not a function, so its
function definition is (presumably) some knd of dispatch code which
picks an appropriate method. That function is (presumably) already
compiled.
What is happening is that the DEFMETHOD form will expand to something
(something unspecified), and, presumably, if that expansion is
compiled then the method body will get compiled, and attached to the
generic function in the appropriate way.
`Normally' this all happens as part of file compilation, but the trick
that's being done is to rely on the property of COMPILE that if you
give it the source of a function (something that looks like (LAMBDA
(...) ...)) then it will compile that and return the compiled
function, so if you put the DEFMETHOD in there, *it* will be compiled,
and then calling the function will cause the DEFMETHOD to be
evaluated.
This is a really bad explanation, sorry. I should also add that all
of this could happen differently, it's really implementation-defined
to a great extent.
> 2) What time function definition of symbol G+ was replaced with
> new compiled function at ?
>
The function definition of G+ never changes. What happens is that a
new (compiled, you hope) method gets attached to it.
--tim
"Vladimir V. Zolotych" <······@eurocom.od.ua> wrote
> Marc Battyani wrote:
> >
> > I didn't tried with CMUCL but it should work.
>
> Unfortunately not.
>
> Compilation (cmucl 18c) ends up with "bad signature".
>
> #<Standard-Method G+ (INTEGER INTEGER) {489022DD}>
I don't use CMUCL but this signature seems OK for me.
It's a method that takes 2 integers. What do you expect ?
PSD 520 > (funcall (compile nil (list 'lambda () '(defmethod g+ ((x integer)
(y integer))
(add-time x (make-time
:seconds y))))))
#<standard-method g+ nil (integer integer) 20416C5C>
PSD 521 > (defmethod g+ ((x integer) (y integer))
(add-time x (make-time
:seconds y)))
#<standard-method g+ nil (integer integer) 20408A6C>
The method signature is the same but in the first case the method is
compiled.
> So the following call
>
> * (g+ x1 10)
>
> terminates with error.
>
> Error in function PCL::|(FAST-METHOD NO-APPLICABLE-METHOD (T))|:
> No matching method for the generic-function
> #<Standard-Generic-Function G+ (1) {48901F89}>,
> when called with arguments (#S(MY-TIME :HOURS 12 :MINUTES 0 :SECONDS 0)
> 10).
PSD 522 > (g+ 1 2)
Error: Undefined function make-time called with arguments (:seconds 2).
...
For me it works, it has found the method (but not the make-time function in
it)
> Beside that I don't understand things like
>
> (lambda () (defmethod g+ ...)).
> What does it mean ?
It's a just function that makes a defmethod.
This function is useless except to get a compiled method which is what was
asked.
I don't see what you don't understand. (?)
> Things like
>
> (setf (symbol-function 'foo)
> (compile nil '(lambda (x) (1+ x)))
>
> more readable for me.
It's not the same thing, I don't want to give a name to the function, I just
want to call it to get the compiled method.
Marc
Marc Battyani wrote:
>
> It's a method that takes 2 integers. What do you expect ?
You're right.
It was my mistake. I've used your code with signature
with two integers but call it with MY-TIME as the first arg.
> It's not the same thing, I don't want to give a name to the function, I just
> want to call it to get the compiled method.
Suppose I have
(defun foo (x y)
(+ x y))
when I call
(compile 'foo)
function definition of FOO converted to COMPILED FUNCTION
and function definition of the symbol FOO was replaced
with new compiled function.
I can't apply this terminology to your code.
--
Vladimir Zolotych ······@eurocom.od.ua
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> Marc Battyani wrote:
> >
> > I didn't tried with CMUCL but it should work.
>
> Unfortunately not.
Oh, it works all right. It just doesn't match your erroneous
expectations:
> Compilation (cmucl 18c) ends up with "bad signature".
>
> #<Standard-Method G+ (INTEGER INTEGER) {489022DD}>
Given that Marc used this form
(funcall
(compile nil
(list 'lambda ()
'(defmethod g+ ((x integer) (y integer))
(add-time x (make-time :seconds y))))))
What "signature" other than (integer integer) would you expect?
If you instead use your defmethod form, and cut out the unneeded use
of list, etc., you get
(funcall
(compile nil
#'(lambda ()
(defmethod g+ ((x my-time) (y number))
(add-time x (make-time :seconds y))))))
which works in any compliant Common Lisp.
> Beside that I don't understand things like
>
> (lambda () (defmethod g+ ...)).
>
> What does it mean ?
My form above does the following:
- It creates an anonymous function (=> lambda) with zero arguments,
that when called will execute the defmethod form, i.e. define the
method you want:
#'(lambda ()
(defmethod g+ ((x my-time) (y number))
(add-time x (make-time :seconds y))))))
- It now invokes compile, which when passed two arguments, the first
being nil, will compile the anonymous function passed as the second
argument, and return it. During the compilation of the function,
the defmethod form will get expanded, and all functions "created" by
this will also get compiled, which is what we want.
- We then funcall the compiled anonymous function, in order to execute
the defmethod form directly.
Of course this assumes that defmethod does create any functions, which
is in no way guaranteed: Your implementation is completely free to
use other mechanisms to define methods, as long as it preserves
correct semantics.
> Things like
>
> (setf (symbol-function 'foo)
> (compile nil '(lambda (x) (1+ x)))
This might be more readable, but has completely different effects,
since it changes the symbol-function of 'foo. Please beware of the
difference of the generic function (i.e. #'g+), and the method that
that generic function contains. This BTW is why your previous attempt
of doing (compile 'g+) is unlikely to do what you want to do
(i.e. compile the method body), since it attempts to compile the
generic function, and what effects that has on method bodies is
completely unspecified.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" wrote:
>
> Oh, it works all right. It just doesn't match your erroneous
> expectations:
Yes, it was my mistake, all works fine in CMUCL 18c.
> - It now invokes compile, which when passed two arguments, the first
> being nil, will compile the anonymous function passed as the second
> argument, and return it. During the compilation of the function,
> the defmethod form will get expanded, and all functions "created" by
> this will also get compiled, which is what we want.
>
> - We then funcall the compiled anonymous function, in order to execute
> the defmethod form directly.
This last step unclear to me most of all. I already have "all functions
compiled". What else I might want to have ?
BTW Your MaiSQL helps me much, I'm using it
with pleasure. Thanks.
--
Vladimir Zolotych ······@eurocom.od.ua
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> > - It now invokes compile, which when passed two arguments, the first
> > being nil, will compile the anonymous function passed as the second
> > argument, and return it. During the compilation of the function,
> > the defmethod form will get expanded, and all functions "created" by
> > this will also get compiled, which is what we want.
> >
> > - We then funcall the compiled anonymous function, in order to execute
> > the defmethod form directly.
>
> This last step unclear to me most of all. I already have "all functions
> compiled". What else I might want to have ?
While the function that contains the defmethod form has compiled, the
defmethod form has of course not been evaluated, since the function it
was contained in has never been called. Let's ignore for the moment all
the defmethod stuff, and try something much simpler:
* #'(lambda () (format t "I've been evaluated.~%"))
#<Interpreted Function (LAMBDA ()
(FORMAT T "I've been evaluated.~%")) {480DEA91}>
* (compile nil *)
Compiling LAMBDA NIL:
Compiling Top-Level Form:
#<Function "LAMBDA NIL" {480EB499}>
NIL
NIL
* (funcall *)
I've been evaluated.
NIL
I.e. we created an anonymous function, then we compiled that function
and got a new compiled function, and finally we invoked that compiled
function, and only now does the body of the function get evaluated,
though it has been compiled beforehand by the call to compile (see the
HyperSpec for this usage of compile, and its semantics[1]). Nothing
surprising here, I suspect.
Now let's do the same with an inner function, to see why we do all of
this anonymous function compiling in the first place:
* #'(lambda () (format t "I've been evaluated.~%") #'(lambda (x y) (+ x y)))
#<Interpreted Function (LAMBDA ()
(FORMAT T "I've been evaluated.~%")
#'(LAMBDA (X Y) (+ X Y))) {48105D51}>
* (funcall *)
I've been evaluated.
#<Interpreted Function (LAMBDA (X Y) (+ X Y)) {4810BD71}>
So if we skip the compilation of the outer function, and invoke it
directly, the inner function it returns is also interpreted. However
if we compile the outer function, and invoke that compiled function,
the inner function it returns has also been compiled during
compilation of the outer function:
* (compile nil **)
Compiling LAMBDA NIL:
Compiling Top-Level Form:
#<Function "LAMBDA NIL" {481208D1}>
NIL
NIL
* (funcall *)
I've been evaluated.
#<Function "LAMBDA NIL" {48120931}>
So now let's see the interaction of this mechanism with a defining
form, like defun:
* #'(lambda () (format t "I've been evaluated.~%") (defun foo (x y) (+ x y)))
#<Interpreted Function (LAMBDA ()
(FORMAT T "I've been evaluated.~%")
(DEFUN FOO (X Y) (+ X Y))) {48125611}>
* (fboundp 'foo)
NIL
* (compile nil **)
Converted FOO.
Compiling LAMBDA NIL:
Compiling Top-Level Form:
#<Function "LAMBDA NIL" {48137031}>
NIL
NIL
* (fboundp 'foo)
NIL
* (funcall **)
I've been evaluated.
FOO
* (fboundp 'foo)
T
* (symbol-function 'foo)
#<Function FOO {481370A1}>
So foo is only defined once we funcall the function, i.e. when the
defun form gets evaluated, not when it just gets compiled. Note also
that we got a compiled function as the symbol-function of foo, since
we compiled the outer function, and hence the inner function that gets
placed into symbol-function of foo by defun also got compiled. If we
don't compile the outer function, we get this:
* (fmakunbound 'foo)
FOO
* #'(lambda () (format t "I've been evaluated.~%") (defun foo (x y) (+ x y)))
#<Interpreted Function (LAMBDA ()
(FORMAT T "I've been evaluated.~%")
(DEFUN FOO (X Y) (+ X Y))) {4813D3B9}>
* (fboundp 'foo)
NIL
* (funcall **)
Converted FOO.
I've been evaluated.
FOO
* (fboundp 'foo)
T
* (symbol-function 'foo)
#<Interpreted Function FOO {48144231}>
A similar thing happens with the defmethod form (_if_ your
implementation of CLOS really uses functions to capture method bodies,
and not something else entirely), with the difference that defmethod
doesn't influence the symbol-function of foo (at least not directly),
but rather some imaginary symbol-method-function, i.e. instead of
(setf (symbol-function 'foo)
#'(lambda (x y) (+ x y)))
that the defun form expands to, we might get
(progn
;; Create the GF if it doesn't exist already
(ensure-generic-function 'foo)
;; Add/Replace the method and its function
(setf (symbol-method-function 'foo '() '(integer integer))
#'(lambda (x y) (+ x y)))
Actually both the defun case and the defmethod case are much more
complex, e.g. defun would probably use fdefinition instead of
symbol-function, and the defmethod case deals with method-objects,
and not (only) with functions, and both would probably do a lot of
implementation-specific book-keeping stuff. But let's ignore that for
the moment.
> BTW Your MaiSQL helps me much, I'm using it
> with pleasure. Thanks.
Glad to be of service. If you are still using the release version,
you might want to update to the one in the public CVS repository,
since that fixes a couple of bugs and problems with newer releases of
MySQL. See the MaiSQL entry in CLiki (http://ww.telent.net/cliki/)
for details on accessing the CVS repository.
Regs, Pierre.
Footnotes:
[1] Here a short summary:
(compile 'foo) is (more or less) equivalent to
(setf (symbol-function 'foo)
(compile nil (symbol-function 'foo)))
(compile nil <function form>) takes the anonymous function given
by <function form>, creates a compiled version of it, and
returns that. Nota bene: The original function is not
destructively modified in that process!
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de> on Thu, 22 Mar 2001 12:44:46
-0600, "Pierre R. Mai" <····@acm.org> wrote:
> Glad to be of service. If you are still using the release version, you
> might want to update to the one in the public CVS repository, since that
> fixes a couple of bugs and problems with newer releases of MySQL. See
> the MaiSQL entry in CLiki (http://ww.telent.net/cliki/) for details on
> accessing the CVS repository.
Speaking of MaiSQL, I know that there were some plans to re-merge it with
UncommonSQL. What exactly is the status now?
I'm making debian packages with cl-controller support of IMHO and
UncommonSQL, btw.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
"Rahul Jain" <·····@rice.edu> writes:
> Speaking of MaiSQL, I know that there were some plans to re-merge it with
> UncommonSQL. What exactly is the status now?
It is not done, and I'm starting to wonder if it will ever get done.
USQL has been collecting code from several different sources and has
grown to support a few more platforms and databases. The MySQL
support in MaiSQL would be nice to port over.
As a maintainer of USQL, I'm more concerned with making sure that
USQL's debt to Pierre Mai, and MaiSQL, is acknowledged, than I am with
making them the same code base. I think with the type of work Pierre
is doing, as well as the work we are doing, having seperate code bases
suits both our needs well enough.
> I'm making debian packages with cl-controller support of IMHO and
> UncommonSQL, btw.
That would be nice to have in the upstream for IMHO and USQL since we
use Debian as our primary deployment platform for our product based on
IMHO and USQL. General cl-controller support would also rock for
other platforms, like Solaris.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
From: Pierre R. Mai
Subject: Re: MaiSQL and UncommonSQL (Was Re: compiling methods)
Date:
Message-ID: <874rwke4xc.fsf@orion.bln.pmsf.de>
Craig Brozefsky <·····@red-bean.com> writes:
> As a maintainer of USQL, I'm more concerned with making sure that
> USQL's debt to Pierre Mai, and MaiSQL, is acknowledged, than I am with
> making them the same code base. I think with the type of work Pierre
> is doing, as well as the work we are doing, having seperate code bases
> suits both our needs well enough.
I've more or less come to the same conclusion. For example we've
found Common SQL's OO and functional interfaces not to be terribly
well suited to the work we've been doing, so that part of Common SQL
is fairly low on my TODO list. OTOH on top of my TODO list is work to
replace the FFI interfaces to PostgreSQL and MySQL with direct socket
interfaces (along the lines of Pg by Eric Marsden), for a number of
reasons, among them self-contained save-lisp support for images
containing MaiSQL.
And then there's the problem that MaiSQL as a whole has been
relatively low on my global TODO list during the past year or two,
although that has changed somewhat in the last couple of months.
Furthermore just like USQL is part of a larger framework of packages
(like IMHO) at OnShore, MaiSQL is mostly used as part of our internal
framework of packages, so merging both would require a number of
internal adjustments on one or both sides, while gaining little.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> I've more or less come to the same conclusion. For example we've
> found Common SQL's OO and functional interfaces not to be terribly
> well suited to the work we've been doing, so that part of Common SQL
> is fairly low on my TODO list. OTOH on top of my TODO list is work to
> replace the FFI interfaces to PostgreSQL and MySQL with direct socket
> interfaces (along the lines of Pg by Eric Marsden), for a number of
> reasons, among them self-contained save-lisp support for images
> containing MaiSQL.
I would be interested in support the native postgres (socket-based)
interface under USQL as well, and had starting some hackage on that
front, but since it's not an immediate "business need" for us at the
moment, it's low on my TODO list as well.
More important for me at this time is getting USQL running on
LispWorks linux as well as windoze, and this is 99% of the way there.
I'm hoping to do a release of USQL with those platforms supported
shortly.
We've also added a "metadata" system which integrates with the
existing OO interface, limited support for schema versioning,
connection pooling, optimized the oracle driver a bit, and added
"delete rules" for join slots in view-class instances.
> Furthermore just like USQL is part of a larger framework of packages
> (like IMHO) at OnShore, MaiSQL is mostly used as part of our internal
> framework of packages, so merging both would require a number of
> internal adjustments on one or both sides, while gaining little.
Exactly.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
Craig Brozefsky wrote:
> "Pierre R. Mai" <····@acm.org> writes:
>
>> I've more or less come to the same conclusion. For example we've
>> found Common SQL's OO and functional interfaces not to be terribly
>> well suited to the work we've been doing, so that part of Common SQL
>> is fairly low on my TODO list. OTOH on top of my TODO list is work to
>> replace the FFI interfaces to PostgreSQL and MySQL with direct socket
>> interfaces (along the lines of Pg by Eric Marsden), for a number of
>> reasons, among them self-contained save-lisp support for images
>> containing MaiSQL.
>
> I would be interested in support the native postgres (socket-based)
> interface under USQL as well, and had starting some hackage on that
> front, but since it's not an immediate "business need" for us at the
> moment, it's low on my TODO list as well.
>
> More important for me at this time is getting USQL running on
> LispWorks linux as well as windoze, and this is 99% of the way there.
> I'm hoping to do a release of USQL with those platforms supported
> shortly.
What's the situation with the ODBC module for UncommonSQL?
I've written a mail to Jesse and later to you but I didn't get any response.
Should I count that as a "No interest" from your side?
Regards,
Jochen Schmidt
Jochen Schmidt <···@dataheaven.de> writes:
> > More important for me at this time is getting USQL running on
> > LispWorks linux as well as windoze, and this is 99% of the way there.
> > I'm hoping to do a release of USQL with those platforms supported
> > shortly.
>
> What's the situation with the ODBC module for UncommonSQL?
> I've written a mail to Jesse and later to you but I didn't get any response.
> Should I count that as a "No interest" from your side?
Hmm, I've responded twice to it, the first time saying "Yes, we are
interested." and the second time confirming that interest and listing
several things that need be done before it can be completely
integrated. Here is the second email I sent, is perhaps the address
wrong? That is what gnus gave me.
From: Craig Brozefsky <·····@onshore.com>
Subject: Re: ODBC Module for UncommonSQL
To: Jochen Schmidt <···@UserDoms1.FreeCity.de>
Date: 23 Mar 2001 11:24:27 -0600
Jochen Schmidt <···@UserDoms1.FreeCity.de> writes:
> Hello,
> You may have heard from my work of merging SQL-ODBC and UncommonSQL.
> I want to ask if there is an interest of you to put (at least parts) of this
> work into the official UncommonSQL.
I have had a chance to look at the work you've done, and I think that
there are some issues we need to resolve before totally integrating it
with the main branch of USQL.
1. The SQL-ODBC package should be distributed seperately because of
it's license. It has a clause:
;;; o No fees or compensation are charged for use, copies, or
;;; access to this software. You may charge a nominal
;;; distribution fee for the physical act of transferring a
;;; copy, but you may not charge for the program itself.
which is not compatible with the rest of USQL's license. For this
reason it shoudl be distributed seperately.
2. There is some repeat code in the dbms/odbc/sql subdirectory which
would need to get cleaned up. Specifically, all the defgeneric and
other definitions should not be repeated in the dbms driver for
ODBC. Also, the lispworks for windows glue code shoudl prolly be
shared with other USQL modules, tho I'm not sure where we should
put it yet.
3. Testing for other platforms and lisp systems would be needed.
If you are interested in doing some of this work I can give you write
access to the CVS archive for USQL.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
Craig Brozefsky wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>>
>> What's the situation with the ODBC module for UncommonSQL?
>> I've written a mail to Jesse and later to you but I didn't get any
>> response. Should I count that as a "No interest" from your side?
>
> Hmm, I've responded twice to it, the first time saying "Yes, we are
> interested." and the second time confirming that interest and listing
> several things that need be done before it can be completely
> integrated. Here is the second email I sent, is perhaps the address
> wrong? That is what gnus gave me.
It seems that gnus has resolved my domain "dataheaven.de" further than it
should. My domain "dataheaven.de" is hosted by a service-provider named
"FreeCity". Please use the emailadress ···@dataheaven.de as the other domain
forwards no email to me.
> From: Craig Brozefsky <·····@onshore.com>
> Subject: Re: ODBC Module for UncommonSQL
> To: Jochen Schmidt <···@UserDoms1.FreeCity.de>
> Date: 23 Mar 2001 11:24:27 -0600
>
> Jochen Schmidt <···@UserDoms1.FreeCity.de> writes:
>
>> Hello,
>> You may have heard from my work of merging SQL-ODBC and UncommonSQL.
>> I want to ask if there is an interest of you to put (at least parts) of
>> this work into the official UncommonSQL.
>
> I have had a chance to look at the work you've done, and I think that
> there are some issues we need to resolve before totally integrating it
> with the main branch of USQL.
>
> 1. The SQL-ODBC package should be distributed seperately because of
> it's license. It has a clause:
>
> ;;; o No fees or compensation are charged for use, copies, or
> ;;; access to this software. You may charge a nominal
> ;;; distribution fee for the physical act of transferring a
> ;;; copy, but you may not charge for the program itself.
>
> which is not compatible with the rest of USQL's license. For this
> reason it shoudl be distributed seperately.
I've seen this license statement a little bit to late - but perhaps we
could contact Paul Meurer if he grants us special rights for using parts of
his work?
> 2. There is some repeat code in the dbms/odbc/sql subdirectory which
> would need to get cleaned up. Specifically, all the defgeneric and
> other definitions should not be repeated in the dbms driver for
> ODBC.
As I remember I stated this in one of my postings or emails - Yes you're
right this should be done. First I planned to use only the code in
dbms/odbc/odbc but there was some code in dbms/odbc/sql which is referenced
in dbms/odbc/odbc. If I remember right, then it should be easy to cut
dbms/odbc/sql away - I'll perhaps take a look at it this weekend.
> Also, the lispworks for windows glue code shoudl prolly be
> shared with other USQL modules, tho I'm not sure where we should
> put it yet.
I've not looked at it for some time but it is possible that we have to add
some lines of code to get it working with windows - it is only tested under
LispWorks Enterprise for linux so far. I can take a look but I cannot
promise anything because I have no chance to test it under windows.
(Perhaps it runs in the Personal Edition for windows...)
> 3. Testing for other platforms and lisp systems would be needed.
Yes. It should be (theoretically) possible to get it running on ACL, MCL
and CormanLisp as this are the platforms that are supported by SQL-ODBC.
I had somewhere around 70 hits on my page shortly after announcing the
ODBC-module. Maybe some people have actually tried it with other platforms
and/or databases...
> If you are interested in doing some of this work I can give you write
> access to the CVS archive for USQL.
I will not have much time so it is maybe easier if I send you the changes
directly. I've tried to minimize changes in SQL-ODBC and UncommonSQL so
this should be no real problem.
Perhaps I've the time this weekend to clean the code a little bit up and to
contact Paul Meurer.
Regards,
Jochen
In article <··············@orion.bln.pmsf.de> on Fri, 23 Mar 2001 12:06:07
-0600, "Pierre R. Mai" <····@acm.org> wrote:
> Furthermore just like USQL is part of a larger framework of packages
> (like IMHO) at OnShore, MaiSQL is mostly used as part of our internal
> framework of packages, so merging both would require a number of
> internal adjustments on one or both sides, while gaining little.
Ok, thanks for the input.
Craig, supporting cl-controller is actually quite simple, so I could send
you the diffs once I finish testing the packages.
extra lines to make the news server accept the message
extra lines to make the news server accept the message
extra lines to make the news server accept the message
extra lines to make the news server accept the message
extra lines to make the news server accept the message
extra lines to make the news server accept the message
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
"Pierre R. Mai" wrote:
Thanks.
I understood your perfect explanation.
>
> (setf (symbol-function 'foo)
> #'(lambda (x y) (+ x y)))
>
> [snip]
>
> (progn
> ;; Create the GF if it doesn't exist already
> (ensure-generic-function 'foo)
> ;; Add/Replace the method and its function
> (setf (symbol-method-function 'foo '() '(integer integer))
> #'(lambda (x y) (+ x y)))
This above is point of my misunderstanding. Probably my
C/C++ etc. experience prevents to understand it.
I like Lisp more and more and such explanations reinforce
my sympathy for it.
--
Vladimir Zolotych ······@eurocom.od.ua