Re: perplexing error

--- will <[email protected]> wrote:
> 
> The stack trace you're getting back is a bit off.  The line that's dying
> is your debug line:
> 
> >         exported.write_message("we are at the limit." % text) #debug
> 
> The text parameter isn't getting converted and stuck in the "we are at the
> limit." string.  If you fix that it'll either work, or you'll move on to
> the next problem (whatever that may be).
> 
> I'm not entirely sure why the stack trace is off.  Explain the steps in
> your development process that led up to this error.  Does this happen
> exactly like this with a fresh launch of Lyntin (i.e. you launch Lyntin,
> you connect to the mud, and it kicks this up) or only after you've done
> #load a few times?
> 

Reloading modules definitely throws off the line numbering, but
as far as I can tell that seems to be a python thing.  If I make
more than trivial changes I do a shutdown/restart so things 
line up again.

While we're on the subject, does anyone have a way to calculate
dependencies and reload them in the right order?  I have a custom reload
command that has a hand-built list, but I have to update it every time
I add a module or change an import.  The problem is that modules can
end up passing around objects from common classes that were redefined.
This happens even though I expire all old instances, the class that
inherits from the old version is still around and can create new 
instances that derive from 'old' classes.

I have 150+ classes spread over 20 modules, so getting the right
reload order is a bit of a pain.

-Razen

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com


-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54