Thanks very much! I can't reproduce it yet, but am trying. One thing I
forgot to mention: I can still interact with website in one browser while
factor itself has closed and task manager doesn't list any factor instances,
a vital fact... :)
On Sat, Jul 10, 2010 at 1:12 PM, Slava Pestov <sl...@factorcode.org> wrote:
> On Sat, Jul 10, 2010 at 2:25 PM, Jim mack <j...@less2do.com> wrote:
> > Thanks, Slava
> >
> > Would the responder then have a namespace in common among HTTP threads
> using
> > an explicit bind? Sure, thanks.
>
> That's one option, yes, or you can store the data in the responder
> directly. It takes a bit of boilerplate at the moment, perhaps at some
> point in the future it can be streamlined:
>
> TUPLE: my-web-app < dispatcher data ;
>
> : <my-web-app> ( -- responder )
> my-web-app new-dispatcher
> <blah-action> "blah" add-responder
> ... ;
>
> M: my-web-app call-responder*
> [ my-web-app set ] [ call-next-method ] bi ;
>
> Then your action can do
>
> my-web-app get data>>
>
> Of course you can name your slots anything, not just 'data'.
>
> > Mostly I was trying to take advantage of the 'look in a chain of assocs
> > until you find it' functionality, and thought I could do so with a
> > combination of make-assoc and bind fairly cheaply. I had a list of
> general
> > replacements, and specific ones, and ones that change rapidly, and
> thought
> > that chaining would be 'better' than cloning & adding specifics each
> time.
>
> If you have a sequence of assocs, you can search for a key using the
> 'assoc-stack' word. This is the word that is used to implement 'get'.
>
> > The only odd problem I've had so far, that I don't have pinned down
> enough
> > to report, is that occasionally chrome and firefox on an xp box where I
> do
> > most development (day job) will clearly be interacting with a different
> > webserver. Usually I've been in both, correctly interacting, then make
> some
> > change (or possibly have a crash). I'll restart factor & the primary
> > browser (usually chrome) and it initializes properly, but the other
> browser
> > (usually ff), which was open all along, still retains the old in-mem
> data.
> > I can interact with it successfully, and it is clearly the version from
> > before the factor restart, but task manager does not list factor. I can
> > even close all ff windows and restart ff and still have this happening,
> > although as I type that I realize I didn't check the task manager to make
> > sure some hidden ff process wasn't keeping it open.
>
> This sounds like a problem in http.server's handling of cache control
> headers. A couple of people have reported similar issues in the past
> on the Factor web site. Let me know if you find a test case.
>
> Slava
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Jim
"I'm for extending the working Medicare program for our seniors all the way
back to contraception, so Americans can concentrate on living their lives
without fear of changing a job, going bankrupt from deductibles or fighting
HMO bureaucracy."
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
