[Seaside-dev] filters initialization with request context?

[Sebastian Sastre]

> > and aTransaction goes and try to commit but all its 
> instVars are in nil.
> > Is this a continuation effect of not copying those after 
> evaluating aBlock? how
> > would you do something like this?
> 
> That look weird. It could well be an effect of full continuations, but
> then again I don't see how aTransaction ends up in the stack. Do you
> register that object for backtracking?
> 
no, my components are not aware they're working inside a transaction so they
don't hold it nor register for backtrack. The only who knows the transaction (in
a temp var) is the pool. I think you're familiar with OmniSupport ;)

> Could you try to update to the latest code to see if the problem
> persists? Evaluate "WADevelopment updateWorkingCopies" until it
> doesn't throw errors anymore. Evaluate it again, and close with
> "WADevelopment recompile" and "WAAdmin initialize".
> 
I've tried a couple of times, get stuck, then I've tried updating pharo and then
executing WADevelopment updateWorkingCopies. It's complaining about WAError not
present I press proceed it contiues then it at some point does a dnu #uppercase

thanks,
sebastian

> Cheers,
> Lukas
> 
> -- 
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev