request timed out in seemingly trivial action

[jrwats]

So I have a recursive representation of a directory tree for
navigating files in my weblocks application. However, when I click on
a directory (to "open" it) that has a decent number of files (50+), I
get a request timed out error. When I simply go back, the webpage
looks as one would have expected with all the files listed underneath
(tabbed slightly to the right) of the directory. Below is the
relevant code for classes dir-tree and file:

(defgeneric on-select (widget)
(:method ((widget dir-tree-widget))
(when (not (eq widget (current-dir-tree-widget (photo-explorer
widget))))
(setf (current-dir-tree-widget (photo-explorer widget)) widget))
(setf (expanded widget) (not (expanded widget)))))

(defmethod render-widget-body ((obj dir-tree-widget) &key)
(let* ((class (if (expanded obj) "open" "closed"))
(action (function-or-action->action #L(on-select obj))))
(with-html
(:li (:div (:div :class class
:onclick (format nil "initiateAction(\"~A\",
\"~A\"); return false;"
action (session-name-string-
pair)))
(render-link action (name (dir-tree obj)))))
(with-html
(:ul :class class
(mapcar #'render-widget (children obj)))))))

(defmethod on-select ((file-widget file-widget))
(let ((photo-explorer (photo-explorer file-widget))
(parent (parent file-widget)))
(when (not (eq (current-dir-tree-widget photo-explorer) parent))
(setf (current-dir-tree-widget photo-explorer) parent))
(setf (url (photo-viewer photo-explorer)) (url-path (file file-
widget)))))

(defmethod render-widget-body ((obj file-widget) &key)
(with-html
(:li (render-link #L(on-select obj)
(name (file obj))))))

I originally was simply not outputting the html for any children of
dir-tree if it was not expanded, but switched to simply swapping the
DOM class and letting CSS take care of hiding the children (via
display: none;). This didn't solve the timeout issue. What am I
doing wrong here?

Thanks,
John Watson

[nunb]

Please could you post your code on paste.lisp.org?

And if you could do this in a single test.lisp file so that (load
"test.lisp") shows up a test page, that would make it *much* easier to
debug.

[Leslie P. Polzer]

On Nov 25, 10:35 pm, jrwats <jrw...@gmail.com> wrote:

> So I have a recursive representation of a directory tree for
> navigating files in my weblocks application.  However, when I click on
> a directory (to "open" it) that has a decent number of files (50+), I
> get a request timed out error.

Some questions:

Are you using -stable or -dev?
What Lisp implementation?
How long does it take until you see the request timeout?

Leslie

[jrwats]

I'm using weblocks-dev, sbcl 1.0.30, it takes roughly 10 seconds or so
before the page comes back with the request timeout. I forgot if I
mentioned, but what's interesting is once getting the error page, if I
click the back button to go to the page that timed out, it displays
the widgets as one would expect them to be displayed. Here's the
paste of everything as requested by nunb:
http://paste.lisp.org/display/91172

Note that the Photos page simply displays the pub/images/photos
directory so placing a few files in that particular directory will
help.

[Nandan]

sounds like a break or something that's timing out the session. do you
use emacs/slime or start the app at the command line? what happens if
you set weblocks::*catch-errors-p* to nil?

[jrwats]

> sounds like a break or something that's timing out the session. do you
> use emacs/slime or start the app at the command line? what happens if
> you set weblocks::*catch-errors-p* to nil?

I use emacs/slime to connect to the server running the webapp. If I
set setblock::*catch-errors-p* to nil, the error then pops up in the
slime debugger:

Your request timed out.
[Condition of type SIMPLE-ERROR]

Restarts:
0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Request
complete/idle" RUNNING {1005BEE6A1}>)

Backtrace:
0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
{1002DA8319}>)
1: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR {1005CAA931}>)
2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1005CAAD59}>)
3: (SWANK::CALL-WITH-BINDINGS ..)
4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {1005880591}>
#<CLOSURE (LAMBDA #) {1005CAAD59}>)
5: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR {1005CAA931}>)
6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1005CAAD19}>)
7: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR {1005CAA931}>
#<unavailable argument>)
8: (INVOKE-DEBUGGER #<SIMPLE-ERROR {1005CAA931}>)
9: ((FLET #:LAMBDA13) #<SIMPLE-ERROR {1005CAA931}>)
10: (SIGNAL #<SIMPLE-ERROR {1005CAA931}>)[:EXTERNAL]
11: (ERROR "Your request timed out.")[:EXTERNAL]
12: ((FLET #:LAMBDA69) #<unavailable argument>)
13: (SIGNAL #<COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR {1005CAA4F1}
>)[:EXTERNAL]
14: (ERROR COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR)[:EXTERNAL]
15: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(T)) ..)
16: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(T)) ..)[:EXTERNAL]
17: (WEBLOCKS::CALL-IN-WEBAPP #<AW::AW {1004B89561}> #<CLOSURE
(LAMBDA #) {1005B84109}>)
18: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(WEBLOCKS:WEBLOCKS-WEBAPP)) ..)
19: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T))
#<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:REQUEST
{1005B784C1}>)

[Leslie P. Polzer]

On Nov 27, 9:15 pm, jrwats <jrw...@gmail.com> wrote:
> I'm using weblocks-dev, sbcl 1.0.30, it takes roughly 10 seconds or so
> before the page comes back with the request timeout.  I forgot if I
> mentioned, but what's interesting is once getting the error page, if I
> click the back button to go to the page that timed out, it displays
> the widgets as  one would expect them to be displayed.  Here's the
> paste of everything as requested by nunb:http://paste.lisp.org/display/91172

Thanks, but it doesn't run properly. I've had to move several DEFCLASS
forms to the top, remove the call to compute the public files path and
am still faced with a missing function and/or widget:

UNDEFINED-FUNCTION: The function AW::CREATE-PHOTO-EXPLORER-WIDGET is
undefined.

Please test your source file to make sure it runs out of the box, this
will make it much easier for us to help you.

Leslie

[Nandan]

I annotated the paste with a re-arranged working version.

[Nandan]

This is what I found:

there is a first error (could not find system :aw while constructing a
file-path) which invokes the debugger, followed by a second, timeout
error.

Here is what I see in slime:

component "aw" not found
[Condition of type ASDF:MISSING-COMPONENT]

Restarts:
0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Request

prelude" RUNNING {11EE13D1}>)

Backtrace:
0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)

{119F9DAD}>)
1: (SWANK::DEBUG-IN-EMACS component "aw" not found)

2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION

SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {11F7D2E5}>)
3: (SWANK::CALL-WITH-BINDINGS ..)
4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {121C7C19}>
#<CLOSURE (LAMBDA #) {11F7D2E5}>)
5: (SWANK:INVOKE-SLIME-DEBUGGER component "aw" not found)

6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION

SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {11F7D2C5}>)
7: (SWANK:SWANK-DEBUGGER-HOOK component "aw" not found #<unavailable
argument>)
8: (INVOKE-DEBUGGER component "aw" not found)
9: ((FLET #:LAMBDA13) component "aw" not found)
10: (SIGNAL component "aw" not found)[:EXTERNAL]
11: (ERROR ASDF:MISSING-COMPONENT)[:EXTERNAL]
12: (ASDF:FIND-SYSTEM AW::AW T)
13: (WEBLOCKS:ASDF-SYSTEM-DIRECTORY AW::AW)
14: (WEBLOCKS:COMPUTE-PUBLIC-FILES-PATH AW::AW #<unavailable
argument>)
15: (AW::MAKE-PHOTOS-WIDGET)
16: (AW::MAKE-MAIN-PAGE)
17: (AW::INIT-USER-SESSION #<WEBLOCKS:WIDGET "root">)



If I do nothing, it is followed a few seconds later by:



Timeout occurred.
[Condition of type TIMEOUT]

Restarts:
0: [CONTINUE] Continue
1: [ABORT] Return to sldb level 1.
2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "Request
prelude" RUNNING {120B2A49}>)

Backtrace:
0: ("bogus stack frame")
1: ("foreign function: pthread_cond_wait")
2: ("foreign function: lutex_wait")
3: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CONDITION-WAIT]172))
4: (SB-THREAD:CONDITION-WAIT ..)
5: (SB-THREAD:CONDITION-WAIT ..)[:EXTERNAL]
6: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267))
7: (SB-THREAD::CALL-WITH-MUTEX ..)
8: ((LAMBDA (SWANK-BACKEND::TEST &OPTIONAL SWANK-BACKEND::TIMEOUT))
#<CLOSURE (LAMBDA #) {1223E34D}> NIL)
9: (SWANK::WAIT-FOR-EVENT (OR (:EMACS-REX . SWANK::_) (:SLDB-RETURN
2)) NIL)
10: (SWANK::SLDB-LOOP 1)
11: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
{119F9DAD}>)
12: (SWANK::DEBUG-IN-EMACS component "aw" not found)


The javascript in weblocks.js only knows the timeout symptom, so in
the browser, all you see is the ajax handler in weblocks.js carping
about a timeout.

I have annotated your paste with a version of aw.lisp that compiles,
and also the aw.sbclrc that I used (in conjunction with the directory
setup thru weblocks-intaller).

-- Nandan

[Nandan]

Try setting catch errors p to nil before the (start-weblocks) {or
equivalent} call, you should then see the first error in the slime
debugger.

[Nandan]

This version works well enough for me: http://paste.lisp.org/+1YCK/4

I put a few png and jpegs into /tmp/test but they didn't show, I'm
guessing that part of the code isn't written yet ;-)

The navigation, however, does get laid out decently enough..
http://imgur.com/JUgRq.png

[jrwats]

The "component 'aw not found" error is from (compute-public-files-path
'aw) failing since I didn't do a defsystem in the previous lisp paste.

New (working) paste: http://paste.lisp.org/display/91212
You'll still need to place a dummy .asd file in the same directory in
order for the "(compute-public-files-path 'aw)" to work.
(Alternatively you can use a dummy .asd file with the old paste)

The photos need to placed in a directory relative to the public files
path like so:
If (compute-public-files-path 'aw) is:
/home/you/workspace/weblocks/aw/pub.
Then put sample photos in:
/home/you/workspace/weblocks/aw/pub/images/photos

When there are photos you should see a directory layout similar to the
following (all depends on the CSS really):
http://imgur.com/N8FXG.png

Upon clicking a file (that is an image) it should show up:
http://imgur.com/P5wEG.jpg

Now if you place 50+ sample images in a given folder you should see a
timeout when attempting to "open" it. BTW the relevant css file I'm
using can be had here:
http://paste.lisp.org/display/91211

[jrwats]

Correction on last post, the newest paste should work w/out an .asd
file....

[Nandan]

> Now if you place 50+ sample images in a given folder you should see a
> timeout when attempting to "open" it.  BTW the relevant css file I'm
> using can be had here:http://paste.lisp.org/display/91211

Using that css, a blank aw.asd (`touch aw.asd`) and aw.lisp as posted
here http://paste.lisp.org/display/91212, I had no problem displaying
200+ files, on Darwin/OSX with sbcl 1.0.29 and weblocks-dev.

I navigated to localhost:8087, clicked on start AW, and then clicked
on the AW link.

http://imgur.com/7dLAn.png -- works even after I add 200+ images in
two separate subdirs, for a total of 600 inside pub/images/photos/ ..

[jrwats]

>
> Using that css, a blank aw.asd  (`touch aw.asd`) and aw.lisp as posted

> herehttp://paste.lisp.org/display/91212, I had no problem displaying

> 200+ files, on Darwin/OSX with sbcl 1.0.29 and weblocks-dev.
>
> I navigated to localhost:8087, clicked on start AW, and then clicked
> on the AW link.
>

> http://imgur.com/7dLAn.png-- works even after I add 200+ images in

> two separate subdirs, for a total of 600 inside pub/images/photos/ ..

Odd. I'm running with the following hardware:

vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : Quad-Core AMD Opteron(tm) Processor 2350 HE
stepping : 3
cpu MHz : 1994.999
cache size : 512 KB

And I am seeing timeouts. I assume there is a way to change how long
the server has to respond to label it a timeout?

[Nandan]

> Odd. I'm running with the following hardware:
> vendor_id       : AuthenticAMD

..

> model name      : Quad-Core AMD Opteron(tm) Processor 2350 HE

Odd indeed. Is there nothing on the ubuntu networking side that may be
blocking requests? iptables etc.

Are you adding the files to the directory after you've run your
webapp, or before? Perhaps it's worth exiting lisp, setting the # of
files in the directory and running the webapp (from scratch, from the
command line), once each for 20 and 400 files?

> And I am seeing timeouts.  I assume there is a way to change how long
> the server has to respond to label it a timeout?

If you're seeing timeouts on the server side (slime debugger) then
what is the backtrace?

If you're seeing timeouts on the browser (the "oops" message) you can
change the timeout period using Prototype's args in weblocks.js -- see
the lines below (/home/webapp/pub/scripts/):

function onActionFailure() {
alert('Oops, we could not complete your request because of an
internal error.');
}
... snip ...
function initiateActionWithArgs(actionCode, sessionString, args,
method) {
if (!method) method = 'get';
new Ajax.Request(getActionUrl(actionCode, sessionString, true),
{
method: method,
// I don't know the args but something should
go here.
onSuccess: onActionSuccess,
onFailure: onActionFailure,
parameters: args
});

}

[jrwats]

The stack trace is:

0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)

{1002DA8319}>)
1: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR {10064BF761}>)

2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION

SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10064BFB89}>)
3: (SWANK::CALL-WITH-BINDINGS ..)
4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {1005C1A8B1}>
#<CLOSURE (LAMBDA #) {10064BFB89}>)
5: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR {10064BF761}>)

6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION

SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10064BFB49}>)
7: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR {10064BF761}>
#<unavailable argument>)
8: (INVOKE-DEBUGGER #<SIMPLE-ERROR {10064BF761}>)
9: ((FLET #:LAMBDA13) #<SIMPLE-ERROR {10064BF761}>)
10: (SIGNAL #<SIMPLE-ERROR {10064BF761}>)[:EXTERNAL]

11: (ERROR "Your request timed out.")[:EXTERNAL]
12: ((FLET #:LAMBDA69) #<unavailable argument>)

Locals:
SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
13: (SIGNAL #<COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR {10064BF341}
>)[:EXTERNAL]
Locals:
SB-DEBUG::ARG-0 = 1
SB-DEBUG::ARG-1 = #<COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR
{10064BF341}>

14: (ERROR COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR)[:EXTERNAL]

Locals:
SB-DEBUG::ARG-0 = 1
SB-DEBUG::ARG-1 = COM.METABANG.TRIVIAL-TIMEOUT:TIMEOUT-ERROR

15: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(T)) ..)

Locals:
SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
SB-DEBUG::ARG-1 = #S(SB-PCL::FAST-METHOD-CALL ..)
SB-DEBUG::ARG-2 = #<AW::AW {1005D26181}>

16: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(T)) ..)[:EXTERNAL]

Locals:
SB-DEBUG::ARG-0 = 3
SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
SB-DEBUG::ARG-2 = #S(SB-PCL::FAST-METHOD-CALL ..)
SB-DEBUG::ARG-3 = #<AW::AW {1005D26181}>
17: (WEBLOCKS::CALL-IN-WEBAPP #<AW::AW {1005D26181}> #<CLOSURE
(LAMBDA #) {1005422849}>)
Locals:
SB-DEBUG::ARG-0 = #<AW::AW {1005D26181}>
SB-DEBUG::ARG-1 = #<CLOSURE (LAMBDA ()) {1005422849}>

18: ((SB-PCL::FAST-METHOD WEBLOCKS:HANDLE-CLIENT-REQUEST :AROUND
(WEBLOCKS:WEBLOCKS-WEBAPP)) ..)

Locals:
SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
SB-DEBUG::ARG-1 = #S(SB-PCL::FAST-METHOD-CALL ..)
SB-DEBUG::ARG-2 = #<AW::AW {1005D26181}>

19: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-REQUEST (T))
#<unavailable argument> #<unavailable argument> #<HUNCHENTOOT:REQUEST

{100540DB31}>)
20: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION
(HUNCHENTOOT:ACCEPTOR T)) ..)
21: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION
(WEBLOCKS:WEBLOCKS-ACCEPTOR T)) ..)
22: ((SB-PCL::FAST-METHOD HUNCHENTOOT:PROCESS-CONNECTION :AROUND
(HUNCHENTOOT:ACCEPTOR T)) ..)
23: ((LAMBDA ()))
24: ((FLET #:WITHOUT-INTERRUPTS-BODY-[BLOCK382]387))
25: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
26: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]267))
27: (SB-THREAD::CALL-WITH-MUTEX ..)
28: ((LAMBDA ()))
29: ("foreign function: #x4222F0")
30: ("foreign function: #x419237")

[jrwats]

[jrwats]

An additional note: my directories only 1 level deep with 50+ files
actually appear to work fine. It's the directories 2 levels deep that
appear to be causing the timeout...

I have a feeling I may have infinite recursion / loop somewhere... I'm
looking into that.

[Leslie P. Polzer]

On Nov 30, 7:05 am, jrwats <jrw...@gmail.com> wrote:

> I have a feeling I may have infinite recursion / loop somewhere... I'm
> looking into that.

That was my initial suspicion. I suggest you check that and then get
back to us if it doesn't yield any results.

Leslie

[jrwats]

> That was my initial suspicion. I suggest you check that and then get
> back to us if it doesn't yield any results.
>

So when running the server on my local dev machine and accessing the
pages via localhost I'm not hitting the timeout when opening
directories (it does take a VERY long time however). I did some
profiling with slime and came up with the following:

64.499 | 5,112,120,256 | 2,559 | 0.025205 | WEBLOCKS:ASDF-
SYSTEM-DIRECTORY
4.392 | 12,602,960 | 852 | 0.005155 | WEBLOCKS:RENDER-
LINK
2.398 | 4,551,392 | 853 | 0.002812 | WEBLOCKS:WITH-
WIDGET-HEADER
0.436 | 40,036,800 | 2,559 | 0.000170 | WEBLOCKS:MAKE-LOCAL-
DEPENDENCY
0.211 | 10,698,848 | 2,559 | 0.000082 | WEBLOCKS:COMPUTE-
WEBAPP-PUBLIC-FILES-PATH
0.178 | 3,531,280 | 853 | 0.000209 | WEBLOCKS:RENDER-
WIDGET-BODY
0.110 | 16,581,440 | 852 | 0.000129 | WEBLOCKS::GENERATE-
ACTION-CODE
0.077 | 2,733,568 | 2,559 | 0.000030 | WEBLOCKS:COMPUTE-
PUBLIC-FILES-PATH
0.058 | 858,640 | 6,095 | 0.000009 | WEBLOCKS::CL-ESCAPE-
STRING
0.055 | 917,504 | 8,532 | 0.000006 |
WEBLOCKS:ATTRIBUTIZE-NAME
0.049 | 528,400 | 855 | 0.000057 | WEBLOCKS:DOM-ID
0.039 | 4,035,344 | 852 | 0.000046 | WEBLOCKS:MAKE-
ACTION-URL
0.039 | 24,240 | 857 | 0.000046 | WEBLOCKS:WEBAPP-
UPDATE-THREAD-STATUS
0.030 | 374,336 | 852 | 0.000035 | WEBLOCKS:REQUEST-
URI-PATH
0.029 | 6,406,272 | 2,559 | 0.000011 | WEBLOCKS:PUBLIC-
FILE-RELATIVE-PATH
0.020 | 0 | 853 | 0.000023 | WEBLOCKS:WIDGET-
PREFIX-FN
0.016 | 3,596,400 | 853 | 0.000019 | WEBLOCKS:DOM-
CLASSES
0.010 | 0 | 857 | 0.000011 | WEBLOCKS:UPDATE-
THREAD-STATUS
0.009 | 0 | 1,708 | 0.000005 | WEBLOCKS::ENSURE-
DOM-ID
0.000 | 0 | 852 | 0.000000 | AW::NAME


There's more functions, but what's most pertinent is:
a) ASDF-SYSTEM-DIRECTORY being called 2.5k times and taking 64.5
seconds (seemingly corresponding with the calls to COMPUTE-WEBAPP-
PUBLIC-FILES-PATH)
b) make-photos-widget never being called (allegedly)

make-photos-widget is the only function that calls compute-public-
files-path:


(defun make-photos-widget ()
(let ((photo-viewer (make-instance 'photo-viewer-widget)))
(make-instance
'photos
:photo-viewer photo-viewer
:photo-explorer (create-photo-explorer-widget #p"images/
photos/" (compute-public-files-path 'aw) photo-viewer))))

and it also HAS to be called (I think) given that that is the function
that creates the photos page we're rendering:

(defun make-main-page ()
(make-navigation "Main Menu"
(list "Photos" (make-photos-widget) "photos")
(list "Main" (make-main-widget) "main")
(list "Nav-test" (make-nav-test) "nav-test")))

So I'm a bit stumped, but I figured I'd at least update everyone with
my findings. I'm going to keep on digging/hacking to see what I can
figure out.

I do have a question regarding widget "dirtiness" and circular
references. So my dir-tree and file widgets all have a photo-explorer
widget as a class member so that the on-select methods (when
specialized on dir-tree and file) may easily access the photo-explorer
widget to set pertinent items. Does this circular referencing make
cause things to be labeled as dirty and to be re-rendered over and
over?

[Phil Marneweck]

I often have a different input view when adding a record compared to
when I am editing a record in the grid view. It usally has to do with
values that may not be changed after creation because they are used as
keys nad/or foreign keys else where.

I propose to add a new-item-form-view to dataedit-mixin for this
purpose. This view will be used in dataedit-create-new-item-widget for
adding new records if supplied else it will fall back on the
item-form-view supplied.


I just wanted to know if other people had the same requirement.


Regards

[Leslie P. Polzer]

On Dec 7, 5:40 am, jrwats <jrw...@gmail.com> wrote:
> > That was my initial suspicion. I suggest you check that and then get
> > back to us if it doesn't yield any results.
>
> So when running the server on my local dev machine and accessing the
> pages via localhost I'm not hitting the timeout when opening
> directories (it does take a VERY long time however).  I did some
> profiling with slime and came up with the following:
>
>     64.499 | 5,112,120,256 |  2,559 |   0.025205 | WEBLOCKS:ASDF-
> SYSTEM-DIRECTORY

Are you running this under Windows by any chance?

If yes, read this: http://groups.google.com/group/weblocks/msg/e182769e577e8e2c

This modification is not in -dev, yet.

> I do have a question regarding widget "dirtiness" and circular
> references. So my dir-tree and file widgets all have a photo-explorer
> widget as a class member so that the on-select methods (when
> specialized on dir-tree and file) may easily access the photo-explorer
> widget to set pertinent items.  Does this circular referencing make
> cause things to be labeled as dirty and to be re-rendered over and
> over?

Good question, but no, we have proper circularity detection in this
place.

Leslie

[Leslie P. Polzer]

Yes, and I approve such an extension.

In general the current gridedit has way too little functionality
for common requirements. Another example for this is the problem
of managing objects of differing types (with different add/edit
view, consequently) in one grid.

Leslie

[Phil Marneweck]

I think add/edit/delete and view should not "just" be tied to the
differing object types but to its own "model" so that these properties
may be set based on security and other requirements as well.

Other features I would like to see:

A column/field based drill down would simplify "data based" navigation
in a data hierarchy. If you click on the field value in the grid instead
of opening the selected record you are taken to another grid based on
the value of the field.

Being able to add additional (to edit/delete) actions to a record in a
grid to kick of record based actions and/or navigation.

> --
>
> You received this message because you are subscribed to the Google Groups "weblocks" group.
> To post to this group, send email to webl...@googlegroups.com.
> To unsubscribe from this group, send email to weblocks+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
>
>

[nunb]

> A column/field based drill down would simplify "data based" navigation
> in a data hierarchy. If you click on the field value in the grid instead
> of opening the selected record you are taken to another grid based on
> the value of the field.

Do you propose to add the onclick to the td instead of the tr?

It should be possible to do this, but I doubt it's a general
requirement, a specific grid-widget would suffice. In fact, you don't
have to reuse grids (unless you want to use defviews to specify
presentations) -- you could create a custom :table based widget for
that..

> Being able to add additional (to edit/delete) actions to a record in a
> grid to kick of record based actions and/or navigation.

How would these be triggered? The current system adds a select
checkbox to the first td in each row, and then the common-ops can
refer to those using dataedit-get-selected-items or similar (which
implies you need a button for each type of action, in the absence of
js I believe links are rendered within each row).

[nunb]

> > Being able to add additional (to edit/delete) actions to a record in a
> > grid to kick of record based actions and/or navigation.
>
> How would these be triggered? The current system adds a select
> checkbox to the first td in each row, and then the common-ops can
> refer to those using dataedit-get-selected-items or similar (which
> implies you need a button for each type of action, in the absence of
> js I believe links are rendered within each row).

Another refinement (don't know how if others would like it) is to have
specific actions for specific rows in the grid. Is that what you meant
by record-based?

Currently the way it works is that if a record/row is checked, and you
click on the common-ops button, the responding function can make its
own decision as to whether or not to apply the operation to that row.

If we tie specific actions to each row, then where would we specify
these and what would the UI look like? In the non-js case it could
degrade similarly to what drilldown now does: display a href with the
operation name as the last column in that row. But this is uglier than
the checkbox/single-button UI, imho.

[Phil Marneweck]

On Mon, 2009-12-07 at 03:33 -0800, nunb wrote:
> > A column/field based drill down would simplify "data based" navigation
> > in a data hierarchy. If you click on the field value in the grid instead
> > of opening the selected record you are taken to another grid based on
> > the value of the field.
>
> Do you propose to add the onclick to the td instead of the tr?
>
> It should be possible to do this, but I doubt it's a general
> requirement, a specific grid-widget would suffice. In fact, you don't
> have to reuse grids (unless you want to use defviews to specify
> presentations) -- you could create a custom :table based widget for
> that..
>

Would a link presentation in the table view that "has access to"/"knows
about the row data" not suffice? That should be generic enough?

>
> > Being able to add additional (to edit/delete) actions to a record in a
> > grid to kick of record based actions and/or navigation.
>
> How would these be triggered? The current system adds a select
> checkbox to the first td in each row, and then the common-ops can
> refer to those using dataedit-get-selected-items or similar (which
> implies you need a button for each type of action, in the absence of
> js I believe links are rendered within each row).

They should work like the current edit/delete buttons. If its too many
buttons for your comfort maybe the "user defined actions" should be a
drop down list with a single action button/link.

[jrwats]

> > 64.499 | 5,112,120,256 | 2,559 | 0.025205 | WEBLOCKS:ASDF-
> > SYSTEM-DIRECTORY
>
> Are you running this under Windows by any chance?

Nope.

> If yes, read this:http://groups.google.com/group/weblocks/msg/e182769e577e8e2c
>

I'll test it out though...

Thanks!

[jrwats]

> Are you running this under Windows by any chance?
>
> If yes, read this:http://groups.google.com/group/weblocks/msg/e182769e577e8e2c

Just tried the memoization trick... can't figure out why, but it
didn't help much.
Here's my profiling results:
( http://paste.lisp.org/display/91752 for the whole enchilada)

seconds | calls | name
---------------------------------------
57.166 | 2,280 | WEBLOCKS:ASDF-SYSTEM-DIRECTORY
56.117 | 4,560 | AW::CACHED-SYSDEF-CENTRAL-REGISTRY-SEARCH
4.212 | 759 | WEBLOCKS:RENDER-LINK
2.198 | 760 | WEBLOCKS:WITH-WIDGET-HEADER
0.534 | 2,280 | WEBLOCKS:MAKE-LOCAL-DEPENDENCY
0.187 | 760 | WEBLOCKS:RENDER-WIDGET-BODY
0.134 | 2,280 | WEBLOCKS:COMPUTE-PUBLIC-FILES-PATH
0.128 | 2,280 | WEBLOCKS:COMPUTE-WEBAPP-PUBLIC-FILES-PATH
0.110 | 759 | WEBLOCKS::GENERATE-ACTION-CODE
0.077 | 5,444 | WEBLOCKS::CL-ESCAPE-STRING
0.060 | 759 | WEBLOCKS:REQUEST-URI-PATH
0.057 | 760 | WEBLOCKS:DOM-CLASSES
0.049 | 759 | WEBLOCKS:MAKE-ACTION-URL
0.044 | 7,602 | WEBLOCKS:ATTRIBUTIZE-NAME
0.029 | 759 | (SETF WEBLOCKS:WEBAPP-SESSION-VALUE)
0.019 | 1,522 | WEBLOCKS::ENSURE-DOM-ID
0.019 | 2,280 | WEBLOCKS:PUBLIC-FILE-RELATIVE-PATH
0.010 | 759 | WEBLOCKS:LOG-UI-ACTION
0.010 | 759 | AW::NAME
0.010 | 760 | WEBLOCKS:WIDGET-SUFFIX-FN
0.010 | 763 | WEBLOCKS:AJAX-REQUEST-P
0.010 | 802 | WEBLOCKS:SESSION-NAME-STRING-PAIR
0.009 | 759 | WEBLOCKS:LOG-LINK
0.009 | 762 | WEBLOCKS:DOM-ID
0.008 | 3,098 | WEBLOCKS:CURRENT-WEBAPP
0.008 | 759 | WEBLOCKS:MAKE-ACTION

It seems to me like render-link is running at the expected amount
(there are 612 photos in the directory tree), but 4 seconds seems a
little costly. Obviously, the elephant in the room is still ASDF-
SYSTEM-DIRECTORY (and I'm running Ubuntu).

[Leslie P. Polzer]

Okay, I see.

Try memoizing either make-local-dependency or compute-public-files-
path.
Or for starters just set a literal public files path in DEFWEBAPP.

Leslie

[jrwats]

> Try memoizing either make-local-dependency or compute-public-files-
> path.
> Or for starters just set a literal public files path in DEFWEBAPP.

Looks better:

seconds | calls | sec/call | name
------------------------------------------
7.585 | 1,411 | 0.005375 | WEBLOCKS:RENDER-LINK
4.025 | 1,412 | 0.002851 | WEBLOCKS:WITH-WIDGET-HEADER
0.803 | 4,237 | 0.000189 | WEBLOCKS:ASDF-SYSTEM-DIRECTORY
0.659 | 4,236 | 0.000156 | WEBLOCKS:MAKE-LOCAL-DEPENDENCY
0.278 | 4,237 | 0.000066 | WEBLOCKS:COMPUTE-WEBAPP-PUBLIC-FILES-
PATH
0.223 | 1,412 | 0.000158 | WEBLOCKS:RENDER-WIDGET-BODY
0.210 | 1,411 | 0.000149 | WEBLOCKS::GENERATE-ACTION-CODE
0.200 | 4,237 | 0.000047 | WEBLOCKS:COMPUTE-PUBLIC-FILES-PATH
0.103 | 14,123 | 0.000007 | WEBLOCKS:ATTRIBUTIZE-NAME
0.057 | 10,113 | 0.000006 | WEBLOCKS::CL-ESCAPE-STRING
0.049 | 1,411 | 0.000034 | WEBLOCKS:MAKE-ACTION-URL
0.047 | 8,474 | 0.000006 | AW::CACHED-SYSDEF-CENTRAL-REGISTRY-
SEARCH
0.040 | 1,411 | 0.000028 | WEBLOCKS:REQUEST-URI-PATH
0.029 | 4,236 | 0.000007 | WEBLOCKS:PUBLIC-FILE-RELATIVE-PATH
0.028 | 1,414 | 0.000019 | WEBLOCKS:DOM-ID
0.024 | 1,412 | 0.000017 | WEBLOCKS:DOM-CLASSES

It's a shame rendering 1,400 links takes 7 seconds, but I think that's
the cost of closures unless i'm mistaken

[Leslie P. Polzer]

> It's a shame rendering 1,400 links takes 7 seconds, but I think that's
> the cost of closures unless i'm mistaken

I'm not entirely convinced of that and will check this out.

Leslie

[Leslie P. Polzer]

On Dec 12, 9:08 am, "Leslie P. Polzer" <s...@viridian-project.de>
wrote:

> > It's a shame rendering 1,400 links takes 7 seconds, but I think that's
> > the cost of closures unless i'm mistaken
>
> I'm not entirely convinced of that and will check this out.

Revision caf62ebf2d1b fixes RENDER-LINK speed.

Leslie

[Rayservers]

Leslie, you are super. Could you email me offlist with your PGP key?

I meant to email the list, I created a "Foo Bar" application... and its posted
here https://freedom.rayservers.com/Foo+Bar+Application. An email challenge
authentication.

I have not had time in the past week or so to work on it further. I seem to be
grokking the widget paradigm, although I will admit I did not use any of the
continuity based code since the widget paradigm provides adequate per-session
continuity control. I have not yet had the using the continuations based
enlightenment experience although I certainly comprehend the concept.

Cheers,

---Venkat.

[Leslie P. Polzer]

Rayservers wrote:
> Leslie, you are super. Could you email me offlist with your PGP key?

Done!

> I have not had time in the past week or so to work on it further. I seem to be
> grokking the widget paradigm, although I will admit I did not use any of the
> continuity based code since the widget paradigm provides adequate per-session
> continuity control. I have not yet had the using the continuations based
> enlightenment experience although I certainly comprehend the concept.

You certainly don't need continuations to be effective at Weblocks
programming.

One thing you might find highly useful in any case is the family of DO-DIALOG,
DO-CONFIRMATION and DO-INFORMATION which makes use of continuations but
doesn't really look like them.

Leslie

[Rayservers]

On 12/14/09 10:07, Leslie P. Polzer wrote:
>
> Rayservers wrote:
>> Leslie, you are super. Could you email me offlist with your PGP key?
>
> Done!

Thanks! I've sent mine.

>
>> I have not had time in the past week or so to work on it further. I seem to be
>> grokking the widget paradigm, although I will admit I did not use any of the
>> continuity based code since the widget paradigm provides adequate per-session
>> continuity control. I have not yet had the using the continuations based
>> enlightenment experience although I certainly comprehend the concept.
>
> You certainly don't need continuations to be effective at Weblocks
> programming.
>
> One thing you might find highly useful in any case is the family of DO-DIALOG,
> DO-CONFIRMATION and DO-INFORMATION which makes use of continuations but
> doesn't really look like them.

A continuation system is, at the bottom of it, a way of persisting and
maintaining state in an inherently stateless protocol. The continuation
parameter serves as that. I've put my understanding down in my own words here.

How would you distinguish this from maintaining state in the widget (what I did)
or a database? (I'm trying to ask the question here, so that the comprehension
gets crystallized. Its been a while since I looked at the cl-cont code). If this
is not the correct question to ask, what would that critical difference be?

In a financial system via a stateless protocol, one would have to create
idempotent transactions...

Cheers,

---Venkat.

[Leslie P. Polzer]

Rayservers wrote:

> A continuation system is, at the bottom of it, a way of persisting and
> maintaining state in an inherently stateless protocol. The continuation
> parameter serves as that. I've put my understanding down in my own words here.

Yes. That's a quite abstract definition but I can't find anything wrong
with it.

> How would you distinguish this from maintaining state in the widget (what I did)
> or a database?

Continuations maintain the state of the code execution flow. They come
in handy when your state is best modelled by a continuation function
("what code will I execute next").

Often an alternative is easier to comprehend and use. Let's take a "Wizard"
page flow as example. If there's a linear relationship between pages then
we can just model them with a list of widgets and a pointer to the current.
However if we have a tree relationship where a page can be reached by
multiple predecessor it's way easier to just call the continuation from the
"Back" link that restores the previous widget.

Of course you could also directly store the widget here, but keep in mind that
this is a simplified case; you might want to do other things programmatically
besides restoring the previous widget, and we all know that functions do that
best. Without continuations you could only store the old data and let a
generalized function interpret that while with continuations you just keep
old of the rest of the computation.

Leslie

[Ian Eslick]

To throw in my two cents on the utility of continuations... :)

1) They are a compact way of representing complex, stateful control flow (page-to-page) that otherwise would be represented in explicit state variables and generalized functions, as Leslie observed.

2) I've come to the conclusion that they are nice theoretically, but that they are overkill for most operations you tend to perform in web pages. In dialogs and do-widget you are basically modeling a stack and when something goes wrong, peering through the continuation structures to make sense of what is going on is difficult. It took me awhile to get the knack of this. Now I pretty much only use it for trivial cases like dialogs.

3) Apps with state are tough in general to make robust and user-friendly. I tend to use a semi-stateless, REST style approach where my urls define a general page context (like editor/document) but then use server side state via AJAX/closures to represent what's going on within the editor for that document. If you hit the back button, you go back to the prior document, if you go forward again, you are returned to the same editor state so people quickly get that back/forward navigates documents, and that local links/buttons manipulate your view of that document.

For me the biggest asset of weblocks has been the excellent infrastructure for supporting AJAX via server side modification of client widget, the widget architecture (now that the navigation has been cleaned up). Except for prototyping or rare cases where it worked out, I don't use the generic widgets and views but should probably revisit that now that the team has spent the better part of the last year improving them!

Best,
Ian

[Rayservers]

Hi Leslie and Ian,

Thank you both for your clarifications.

It seems then, that the crucial advantage is that one can write a bunch of
simple widgets and use the continuation code to keep track of how the user walks
through them**. This frees up the programmer from having to create a super
widget (what I did) that stores the state in the class instance and the render
methods get complex.

Now, one of the things I needed to figure out, is how to refresh the widget tree
when one widget changes something like login state in an AJAX call. The login
widget I wrote seemed to be fine regarding AJAX as the navigation was already built.

Just for your information, the GBBopen "blackboard" thinking regarding dynamic
reordering of execution is very powerful in complex problem solving. It seems to
me that the weblocks approach is that applied to user interfaces while
maintaining continuity.

Ian, I have followed Elephant on the side, so many features of it are similar to
a persistent blackboard. So many collisions even in the name space of libraries.
It seems that a cross pollination of the two projects would be wonderful and
result in DRY amongst some very talented lisp programmers.

** Is there an example of this somewhere? So then the continuation parameter
that is passed on in the continuation is the previous widget?

Weblocks (and Elephant) are tightly coupled to the data and data on disk. I
intend to break this model - the software should run just fine of a CDrom boot.
The UI is a view into the data, the real meat of the program will not even have
a view. What I mean by that is, that its like the entire suite of software that
makes email (or X Windows desktop) possible. You have the Thunderbird email
client as the UI - thats Weblocks. There is an IMAP server it talks to, and SMTP
that talks to others, etc. The richness of that environment is greater than
anything that MVC tied to an SQL db provides, although obviously this can be
approximated as it has by so many webmail applications that have become an email
universe unto themselves.

Cheers,

---Venkat.

[jrwats]

Changes certainly fix render-link. Thank you! What's odd (as I have
no clue how this could be happening given that the memoization appears
to be working) cached-sysdef-central-registry-search is still taking a
boatload of time:

CL-USER> (weblocks:reset-sessions)
seconds | consed | calls | sec/call | name
----------------------------------------------------------
4.431 | 306,962,624 | 612 | 0.007240 | AW::CACHED-SYSDEF-
CENTRAL-REGISTRY-SEARCH
0.093 | 1,398,512 | 97 | 0.000959 | WEBLOCKS:RENDER-LINK
0.065 | 4,750,048 | 306 | 0.000212 | WEBLOCKS:MAKE-LOCAL-
DEPENDENCY
0.064 | 5,164,592 | 2 | 0.031995 | WEBLOCKS:REDIRECT
0.058 | 4,623,040 | 7 | 0.008345 | AW::MAKE-CHILDREN
0.041 | 586,048 | 307 | 0.000134 | WEBLOCKS:COMPUTE-
PUBLIC-FILES-PATH
0.028 | 1,170,816 | 111 | 0.000249 | AW::AWLOG

AW> (hash-keys *asdf-cache*)
("weblocks-prevalence" "bordeaux-threads" "cl-prevalence" "s-sysdeps"
"s-xml"
"cl-ppcre" "metatilities" "asdf-system-connections" "metabang-bind"
"cl-containers" "metatilities-base" "moptilities" "closer-mop"
"weblocks"
"weblocks-memory" "trivial-timeout" "salza2" "f-underscore"
"anaphora" "md5"
"cl-cont" "fare-matcher" "fare-utils" "cl-fad" "sb-posix" "sb-grovel"
"parenscript" "cl-who" "cl-json" "puri" "hunchentoot" "usocket"
"sb-bsd-sockets" "split-sequence" "rfc2388" "cl+ssl" "flexi-streams"
"trivial-gray-streams" "cffi" "babel" "alexandria" "trivial-features"
"cl-base64" "chunga")

Any ideas?

[jrwats]

> AW> (hash-keys *asdf-cache*)
> ("weblocks-prevalence" "bordeaux-threads" "cl-prevalence" "s-sysdeps"
> "s-xml"
>  "cl-ppcre" "metatilities" "asdf-system-connections" "metabang-bind"
>  "cl-containers" "metatilities-base" "moptilities" "closer-mop"
> "weblocks"
>  "weblocks-memory" "trivial-timeout" "salza2" "f-underscore"
> "anaphora" "md5"
>  "cl-cont" "fare-matcher" "fare-utils" "cl-fad" "sb-posix" "sb-grovel"
>  "parenscript" "cl-who" "cl-json" "puri" "hunchentoot" "usocket"
>  "sb-bsd-sockets" "split-sequence" "rfc2388" "cl+ssl" "flexi-streams"
>  "trivial-gray-streams" "cffi" "babel" "alexandria" "trivial-features"
>  "cl-base64" "chunga")
>
> Any ideas?

I'm an idiot. It wasn't caching the very system I was looking for (aw
is the name of the webapp). So I added a symbolic link in the /usr/
local/lib/sbcl/site-systems folder to the webapp's .asd file. That
did the trick. I suppose the other option is to add the director to
the asdf:*central-registry*.

I was under the false impression that simply loading the .asd and
relevant package files (along with the entire webapp eventually) into
the lisp interpreter would update asdf such that it'd return the
correct path when querying for a system.

The times now are:

seconds | consed | calls | sec/call | name
---------------------------------------------------------

0.471 | 4,794,432 | 310 | 0.001518 | WEBLOCKS:RENDER-LINK
0.419 | 22,274,896 | 2,316 | 0.000181 | AW::AWLOG
0.145 | 13,334,848 | 982 | 0.000148 | WEBLOCKS:MAKE-LOCAL-
DEPENDENCY
0.059 | 4,379,008 | 996 | 0.000059 | WEBLOCKS:COMPUTE-
WEBAPP-PUBLIC-FILES-PATH
0.051 | 5,967,056 | 310 | 0.000166 | WEBLOCKS::GENERATE-
ACTION-CODE
0.046 | 4,647,600 | 7 | 0.006630 | AW::MAKE-CHILDREN
0.044 | 37,536 | 3,259 | 0.000014 | WEBLOCKS:ATTRIBUTIZE-
NAME
0.036 | 1,750,384 | 320 | 0.000112 | WEBLOCKS:DOM-CLASSES
0.035 | 1,445,936 | 997 | 0.000035 | WEBLOCKS:COMPUTE-
PUBLIC-FILES-PATH

Thanks to everyone for all the help!

[Leslie P. Polzer]

I'm glad you've made it and I hope you'll make good progress with your
photo app. Can I ask you to submit a patch that integrates the ASDF
caching into weblocks-dev?

Leslie

[Leslie P. Polzer]

On Dec 14, 11:32 pm, Rayservers <rayserv...@gmail.com> wrote:
> Hi Leslie and Ian,
>
> Thank you both for your clarifications.

Sorry for the delay. Everyone seems to be ravaging the subject lines
these
days which confuses the hell out of me.

> It seems then, that the crucial advantage is that one can write a bunch of
> simple widgets and use the continuation code to keep track of how the user walks
> through them**. This frees up the programmer from having to create a super
> widget (what I did) that stores the state in the class instance and the render
> methods get complex.

It really depends on your particular needs but that does sound like
it, yeah.

> Now, one of the things I needed to figure out, is how to refresh the widget tree
> when one widget changes something like login state in an AJAX call. The login
> widget I wrote seemed to be fine regarding AJAX as the navigation was already built.

Are you talking about bug #6?

http://bitbucket.org/S11001001/weblocks-dev/issue/6/change-in-navigation-structure-is-not-considered-on-ajax

> ** Is there an example of this somewhere?

Of what exactly?

> So then the continuation parameter that is passed on in the continuation is
> the previous widget?

Continuations are always functions. Consider:

(require :cl-cont)

(use-package :cl-cont)

(with-call/cc
(format t "before continuation capture~%")
(let ((result (let/cc k (funcall k 5))))
(format t "after continuation capture; result: ~S~%" result)))

K equals

(lambda (arg)
(let ((result arg))
(format t "after continuation capture; result: ~S~%" result)))

Funcalling K inside the LET/CC will work as you expect, resuming
the continuation. If K is not called in the LET/CC it will not be
executed
at all.

Leslie

[jrwats]

Sure thing. I'm going to be on vacation (i.e. not doing "work" work)
from the 19th to the 29th, so I should have plenty of time to do so.

BTW - I use google groups to browse this and hitting Reply
automatically changes the subject of the thread. Luckily this
particular micro-thread is dying, so you'll only have two on this :)

[jrwats]