[Slrl] [sldev] Flow of execution while debugging the Source code

Lawson English lenglish5 at cox.net
Mon Nov 12 07:26:44 PST 2007

Kundanv Indigo wrote:
> Hi
>    I have been trying to trace out the flow in which the files are 
> being executed when we debug the Secondlife Viewer code,
> Please can you help me to know the flow of  execution, or suggest me 
> where to start and the eligibility to trace out the functionality of 
> each file.
> Thanks Everyone!!!!!

You might want to look at the libsl code to get a feel for what the 
Second LIfe code is supposed to be doing.

An example:

startup_idle() is a 2000+ line function in llstartup.cpp that is best 
described as a 20-case (more or less) switch statement with all the 
cases listed in a single enum in the .h file. Why this was NOT 
implemented as a switch statement about 40 lines long, instead of  a 
2000-line series of 20 if blocks of this form:

if(login_stage_num == g->getLogin()){blah; blah; return}

is beyond me. But there you go. startup_idle() is  2000 lines of if 
blocks in a row. Now, what these actually DO, is rather convoluted since 
the stages (not states, despite the name given)  involve the login 
dialog boxes, the GUI progress bar, the login process itself, and the 
initialization of the initial state of the avatar, client side. An 
easier way to understand the login PROCESS is to look at libsl's 
implementation, which puts all the parameters for the login process in a 
single spot, which then gets fed to another function in their network code.

I'm looking at implementing the current login process in a python module 
as part of the AWG's task of testing the NEW login protocols that Zero 
and friends are working on. It falls under  VAG below, which eventually 
may implement as much of the message-passing of the client as we can 
figure out, in order to facilitate testing of the various aspects of the 
AW Groupies plans over the next few years, which go a bit beyond the 
Linden's vision of what the AWG is supposed to be doing. This test 
harness might in turn be used to implement a "clean room" type client 
from scratch if someone has issues with looking at GPL code or simply 
likes the idea of having a client that isn't a series of bandaides 
layered on bandaides (thousands, I suspect).


If you have an interest in helping with the multi-process client (aka 
the modular, test-harness client), please joint the above VAG.

If you have an interest in the AWG/AW Groupie work, in general, please 
contact Zha Ewry, Tree Kyomoon or myself in-world for an invite into our 
odd little group.



Lawson (Saijanai Kuhn )
Slrl mailing list
Slrl at list.academ-x.com

More information about the SLDev mailing list