After updating weblocks-dev, error: Unbound variable: HUNCHENTOOT:*SESSION*

[Keith M. Corbett]

I'm seeing odd behavior after updating to the latest weblocks-dev.
I've been using weblocks-dev rev 1447 since early May, now I'm trying
to catch up. I ran into a few minor issues which were easy to hack
around. Now this problem has me stumped.

When I try to get a Weblocks application page an error is raised:
Unbound variable: HUNCHENTOOT:*SESSION*

I see this running my own app, and also for the demos weblocks-demo
and weblocks-clsql-demo.

In the browser I see: SIMPLE-ERROR: Your request timed out.

I've uploaded the backtrace from CCL at URL: http://pastebin.com/m434b7543
but I don't know how useful it may be.

Any suggestions?

-Keith

[Leslie P. Polzer]

On Sun, Jun 28, 2009 at 04:28:10PM -0700, Keith M. Corbett wrote:
>
> I'm seeing odd behavior after updating to the latest weblocks-dev.
> I've been using weblocks-dev rev 1447 since early May, now I'm trying
> to catch up. I ran into a few minor issues which were easy to hack
> around. Now this problem has me stumped.

Are any of those minor issues worth fixing in upstream, or are they
directly related to your application?

> When I try to get a Weblocks application page an error is raised:
> Unbound variable: HUNCHENTOOT:*SESSION*
>
> I see this running my own app, and also for the demos weblocks-demo
> and weblocks-clsql-demo.

What version of Weblocks are you using?
The current tip, i.e. 1126/1d485a9?

Do you run your app with cookies enabled?

[Leslie P. Polzer]

Please try updating your tree, I've committed a fix that might be
beneficial to your problem as well in 3f21962fcd26.

[Keith M. Corbett]

On Jun 29, 6:10 am, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> Please try updating your tree, I've committed a fix that might be
> beneficial to your problem as well in 3f21962fcd26.

I pulled in the latest changes from weblocks-dev (including the one
you mentioned)

I ran an incremental build (asdf:operate asdf:load-op myapp)

but I got the same error.

Thinking I might need to rebuild Weblocks I did this

(asdf:operate 'asdf:load-op :weblocks :force t)

but compile failed with this error:

There is no applicable method for the generic function:
#<STANDARD-GENERIC-FUNCTION HUNCHENTOOT::ACCEPTOR-SHUTDOWN-P
#x30004185E83F>
when called with arguments:
(#<WEBLOCKS-ACCEPTOR #<error printing CONS #x3000443BFEB3>
[Condition of type SIMPLE-ERROR]

-Keith

[Keith M. Corbett]

On Jun 29, 4:03 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

> What version of Weblocks are you using?
> The current tip, i.e. 1126/1d485a9?

I have rev 1544, not 1126, and this appears to be the change you
recommended. I originally used hg clone to install weblocks-dev per
the instructions. Yesterday and today I used hg pull and hg update.
Here's what hg has to say now:

/usr/local/src/cl/weblocks-dev$ hg parents
changeset: 1544:3f21962fcd26
tag: tip
user: Leslie P. Polzer <pol...@gnu.org>
date: Mon Jun 29 12:03:15 2009 +0200
summary: Only reconfigure the tree in AJAX requests.

> Do you run your app with cookies enabled?

Yes, and Firefox shows cookies for weblocks from localhost where my
app is running.

-Keith

[Keith M. Corbett]

On Jun 29, 12:51 pm, "Keith M. Corbett" <kmcorb...@gmail.com> wrote:
> On Jun 29, 6:10 am, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
>
> > Please try updating your tree, I've committed a fix that might be
> > beneficial to your problem as well in 3f21962fcd26.
>
> I pulled in the latest changes from weblocks-dev (including the one
> you mentioned)
>
> I ran an incremental build (asdf:operate asdf:load-op myapp)
>
> but I got the same error.
>
> Thinking I might need to rebuild Weblocks I did this
>
>  (asdf:operate 'asdf:load-op :weblocks :force t)
>
> but compile failed with this error:

Red herring anyone? A clean rebuild of Weblocks worked.

But I'm still getting the original error. (500 timeout)

-Keith

[Leslie P. Polzer]

Keith M. Corbett wrote:

>> What version of Weblocks are you using?
>> The current tip, i.e. 1126/1d485a9?
>
> I have rev 1544, not 1126, and this appears to be the change you
> recommended. I originally used hg clone to install weblocks-dev per
> the instructions. Yesterday and today I used hg pull and hg update.
> Here's what hg has to say now:

Sorry, that id was bogus -- wrong repository context.

1544 is the one I meant.

Leslie

[Leslie P. Polzer]

Keith M. Corbett wrote:

> But I'm still getting the original error. (500 timeout)

I'd like to see how far the request handler gets.

Can you trace WEBAPP-UPDATE-THREAD-STATUS and paste
the output here?

[Keith M. Corbett]

On Jun 29, 2:23 pm, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

I traced the function while running my app from the Slime REPL in
Emacs. I get this in the *inferior-lisp* buffer:

0> Calling (WEBLOCKS:WEBAPP-UPDATE-THREAD-STATUS "Request prelude")
<0 WEBLOCKS:WEBAPP-UPDATE-THREAD-STATUS returned NIL
0> Calling (WEBLOCKS:WEBAPP-UPDATE-THREAD-STATUS "Request complete/
idle")
<0 WEBLOCKS:WEBAPP-UPDATE-THREAD-STATUS returned NIL

I saw the same trace results when I ran the Weblocks-demo from a shell
script under CCL in batch mode. Full log is at URL: http://pastebin.com/m433b7aff

-Keith

[Leslie P. Polzer]

I fixed two CCL-specific issues, one of which you ran into.

The demo works for me now on CCL again.

[Keith M. Corbett]

On Jun 29, 3:50 pm, "Leslie P. Polzer" <leslie.pol...@gmx.net> wrote:
> I fixed two CCL-specific issues, one of which you ran into.
>
> The demo works for me now on CCL again.

Same here. And my app works nowl.

Thanks Leslie!!

-Keith