Don Cohen wrote:
> Lou Vanek:
> Clsql's loop macro doesn't work on Clisp (but it's not needed).
> What particular thing doesn't work and what is it used for?
This is the loop macro:
http://clsql.b9.com/manual/loop-tuples.html
There are tons of other ways to iterate over a set of records, but they
might not be as pretty. I wrote a simple example of iteration in the tarball
(included mysql tutorial). It's not as elegant as using a loop macro, though.
> Devon Sean McCullough:
> > > Gee, would you send me all the non-CLISP sources, patched or original,
> > > that went into your working CLSQL package? If I get it to work here
> > > I'll send back the fixes.
> Lou Vanek:
> > Sure. I'll pack up a tar ball, give it a shake or two, and email it to you.
> > Give me some time to put it together because a code review is in process!
> Better yet, post it on a web page, or send me a copy and I'll do so.
I've sent the tarball to Devon and am awaiting his feedback to see if it works
for him. I wasn't planning on posting the code until I was sure it worked
for somebody besides myself. If you want a copy I'd be glad to send it if you
would be willing to let me know if it works any better than the current clsql /
cffi packages. Then I'll post it, knowing that I haven't overlooked
something obvious. I don't like to inflict bad code on others if I can avoid it,
especially if somebody's willing to give it a quick run first. The tarball is
not set up to be used by lisp newbies, though, because installation instructions
are sparse. Send email to vanek AT acd DOT net if interested. The changes I made
make it possible to use mysql, but any program that needs to use uffi would
benefit since most of the patches are for the uffi-compatibility module.
I was hoping that the cffi maintainers would propagate my patch but their darcs
repository shows that they haven't. I prefer giving the cffi folks a chance to
apply the changes but if nothing is going to break loose soon...

> > This is what trace does. See the options in impnotes 25.2.5
>
> It seems to me that there is a small confusion.
> One may use fwrapper to create a utility like trace. But this is not the only
> possible use of fwrapper. In my opinion, the real place for fwrappers is in
> modification of behaviour of black-boxes. Say you have black-box A, which uses
> black-box B. Modifying behaviour of B leads to a new behaviour of A. This
> scenario is not about tracing or debugging. One cannot use trace for this, right?
>
> Trace traces execution of a given function, i.e. function is executed. But when
> you make a wrapper for a function in ACL, there might be no execution of a
> wrapped function. And a wrapped function can be itself a wrapped function.
My point was that trace is more general that it looks.
It can be used to modify a function arbitrarily, including not
evaluating the original code at all.
That said, the advice facility available in other places (originally
interlisp, I believe) still has some advantages, in particular for the
case where different users/uses want to change the same function for
different purposes. However, such uses cannot really be independent
of each other anyway, e.g., one has to decide whether to call the
other.

Sam Steingold writes:
> > > the idea behind this behavior is that MYPKG may be defined in start.lisp
> > > and if loading start.lisp fails, MYPKG cannot be assumed to exist.
> > That makes some sense. On the other hand, MYPKG might be defined
> > before the previous saveinitmem.
> then you can pass "-p" before "-i"
No, that does not work. It looks to me like the -p and -i in either
order translate to (progn (load file)(setf *package* package)) and the
abort from the load causes the package to be ignored. That's why I
suggested the unwind-protect.
test.lsp:
(print *package*)
(defpackage "TEST")
(in-package "TEST")
(lisp::print lisp::*package*)
(lisp::loop (lisp::print (lisp::eval (lisp::read))))
transcript:
# /tmp/clisp-2.38/clisp -p FFI -i /tmp/test.lsp -q
;; Loading file /tmp/test.lsp ...
#<PACKAGE COMMON-LISP-USER>
#<PACKAGE TEST>
*** - Ctrl-C: User break
The following restarts are available:
SKIP :R1 skip (LOOP #)
STOP :R2 stop loading file /tmp/test.lsp
ABORT :R3 ABORT
Break 1 TEST[2]> abort
[1]> *package*
#<PACKAGE COMMON-LISP-USER>
[2]>
> > In any case the unwind-protect version seems to make sense.
> CL is not scheme.
> in scheme a failed form prints an error and returns to the top level.
> in lisp a failed form drops you into the debugger.
> command line options are shortcuts to the REPL and behave accordingly.
I don't understand the point of this. Couldn't the command line
arguments be viewed as a shortcut for the unwind-protect form I
suggest instead of the progn form that now seems to be executed?
> > I suppose another possibility would be some way to change the global
> > binding of *package* (or if you want to generalize, a way to change
> > arbitrary other bindings of arbitrary special variables). Is that now
> > supported?
>
> that's what -p does: (setq *package* (find-package arg))
And this would do what I want if the load function did not rebind
*package*. What I'm asking for is something that I could put in
a file to be loaded that would affect the binding of *package* outside
the load. Or more generally,
(defvar foo 1)
(let ((foo 2)) (global-setf foo 3))
;; now foo = 3
or even more generally,
(let ((foo 1))
(let ((foo 2))
(let ((foo 3))
(something here that causes the desired result below))
(print foo))
(print foo))
=>
5
6

Lou Vanek:
Clsql's loop macro doesn't work on Clisp (but it's not needed).
What particular thing doesn't work and what is it used for?
Devon Sean McCullough:
> > Gee, would you send me all the non-CLISP sources, patched or original,
> > that went into your working CLSQL package? If I get it to work here
> > I'll send back the fixes.
Lou Vanek:
> Sure. I'll pack up a tar ball, give it a shake or two, and email it to you.
> Give me some time to put it together because a code review is in process!
Better yet, post it on a web page, or send me a copy and I'll do so.

> * Don Cohen <qba-fbheprsbetr-kk@...> [2006-05-22 08:49:27 -0700]:
>
> Sam Steingold writes:
> > the idea behind this behavior is that MYPKG may be defined in start.lisp
> > and if loading start.lisp fails, MYPKG cannot be assumed to exist.
> That makes some sense. On the other hand, MYPKG might be defined
> before the previous saveinitmem.
then you can pass "-p" before "-i"
> In any case the unwind-protect version seems to make sense.
CL is not scheme.
in scheme a failed form prints an error and returns to the top level.
in lisp a failed form drops you into the debugger.
command line options are shortcuts to the REPL and behave accordingly.
> I suppose another possibility would be some way to change the global
> binding of *package* (or if you want to generalize, a way to change
> arbitrary other bindings of arbitrary special variables). Is that now
> supported?
that's what -p does: (setq *package* (find-package arg))
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://openvotingconsortium.orghttp://jihadwatch.orghttp://memri.orghttp://honestreporting.comhttp://iris.org.ilhttp://mideasttruth.com
UNIX, car: hard to learn/easy to use; Windows, bike: hard to learn/hard to use.

Pascal Bourguignon writes:
> #!/usr/local/bin/clisp -ansi -q -on-error debug
You're right that I can get interaction this way
(even better with -repl since I then stay in lisp even if I return
from the last form in the file) but I still don't end up in the
package I wanted.
/tmp/test.lsp:
#! /tmp/clisp-2.38/clisp -on-error debug
(print *package*)
(defpackage "TEST")
(in-package "TEST")
(lisp::print lisp::*package*)
(lisp::loop (lisp::print (lisp::eval (lisp::read))))
transcript:
# /tmp/test.lsp
#<PACKAGE COMMON-LISP-USER>
#<PACKAGE TEST>
*** - Ctrl-C: User break
The following restarts are available:
SKIP :R1 skip (LOOP #)
STOP :R2 stop loading file /tmp/test.lsp
ABORT :R3 ABORT
Break 1 TEST[2]> abort
[1]> *package*
#<PACKAGE COMMON-LISP-USER>
[2]>
Sam Steingold writes:
> the idea behind this behavior is that MYPKG may be defined in start.lisp
> and if loading start.lisp fails, MYPKG cannot be assumed to exist.
That makes some sense. On the other hand, MYPKG might be defined
before the previous saveinitmem.
In any case the unwind-protect version seems to make sense.
I suppose another possibility would be some way to change the global
binding of *package* (or if you want to generalize, a way to change
arbitrary other bindings of arbitrary special variables).
Is that now supported?

> * Don Cohen <qba-fbheprsbetr-kk@...> [2006-05-21 10:11:23 -0700]:
>
> Here's a long standing problem that I only now begin to think of as a
> clisp bug. Let's see what the rest of you think.
> Consider a batch file with a command like
> clisp -i start.lsp -p MYPKG
> The behavior I see suggests that this is interpreted as something like
> (progn (load "start.lsp")(in-package "MYPKG"))
>
> The problem is that if the load breaks and the user aborts then he
> doesn't end up in MYPKG. One common case is that the load actually
> goes into a user interaction loop in which the code expects to be in
> MYPKG. In the case where the user is not actually a programmer one
> usually tries to catch errors, but it's sometimes useful (esp. for
> debugging) to break. At that point you might want to abort and
> restart, or the user might abort accidentally and want to restart.
> In that situation it would be nice to be in MYPKG after the abort.
>
> I think I'd prefer to do the in-package first. That's actually what
> I would have expected. The only problem I see is that such a change
> could break some existing working code.
> How about unwind-protect instead of progn?
the idea behind this behavior is that MYPKG may be defined in start.lisp
and if loading start.lisp fails, MYPKG cannot be assumed to exist.
--
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://memri.orghttp://camera.orghttp://ffii.orghttp://dhimmi.comhttp://truepeace.orghttp://palestinefacts.org
Money does not "play a role", it writes the scenario.