Generated by StatCvs v0.2-dev
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Summary Period: 2001-11-20 to 2001-11-13 (Commits 6895-6944 of 12744)
Updated apps to preferred coding technique and
changed some basics which look like an over flow
from copy and pasting from the simple1 app.
52 lines of code changed in:
Small fix in csObject::SetName() with relation to the debugging
graph.
4 lines of code changed in:
fixed errors
363 lines of code changed in:
converted Christopher Nelson's AWS documentation (from http://staff.bbhc.org/christophern/aws) to texinfo
18 lines of code changed in:
added unistd.h and CS_SYSDEF_PROVIDE_PATH, before it failed compiling what noone noticed since it never was compiled due to the cssys.mak problem
2 lines of code changed in:
this fix will actually make use of the replacements of general/* in their respective subdirectories like unix/ etc. .
Problem was that sorting put the general directory in front of unix directory for instance and if instpath.cpp (for example) is requested to compile its taken from the general directory.
Note that this fix is considered a hack (by Eric (and me too - thats why i consulted him first:))
2 lines of code changed in:
- Changed the behaviour of iRegion::FindBla() routines (i.e.
FindSector(), ...). These functions no longer increase the ref
count of the returned objects. This is an undesired behaviour
which caused a memory leak in some cases.
- Fixed a problem in the thing loader which would not check
the current region to loads it's material.
- Reverted the memory leak fix with textures. This was in fact not
a bug and my fix caused crashes.
35 lines of code changed in:
- Added iEngine::RemoveObject() which is a conveniance function to
'remove' a CS object from the engine. This will not clear the
object but it will remove all references to that object that the
engine itself keeps. This function works for: iSector, iCollection,
iMeshWrapper, iMeshFactoryWrapper, iCameraPosition, iDynLight,
iMaterialWrapper, and iTextureWrapper. In addition this function
also knows about iCurveTemplate and iPolyTxtPlane from the thing
environment and will be able to clean those up too.
This function will also remove the object from the region it may be
in.
- Made csMaterial::SetTextureWrapper() safer by first
incrementing the new texture before decrementing the old one.
Did the same for csMaterialWrapper::SetMaterial() and
csMaterialWrapper::SetMaterialHandle(). Also did the same
for csTextureWrapper::SetTextureHandle().
- Fixed a memory leak with textures. The texture which is associated
with a material had one ref too many.
172 lines of code changed in:
fixed a circular reference between the map loader and the syntax services
plugin
6 lines of code changed in:
Temporarily disabled new AWS documentation on account of the significant
number of Texinfo mark-up errors and problems. Will re-enable this when
I have the time to clean up the problems.
2 lines of code changed in:
converted Christopher Nelson's AWS documentation (from http://staff.bbhc.org/christophern/aws) to texinfo
681 lines of code changed in:
small robustness patch in addition to the patches yesterday
2 lines of code changed in:
made cs-config generation robust to wrong file attributes (non executabl)
1 lines of code changed in:
forgot interface files
2 lines of code changed in:
changed aws to use vfs instead of fopen
91 lines of code changed in:
- Added the notion of types to the csDebuggingGraph tool.
This means that you can now also indicate the type of the
object in the graph. This is purely to make the dump
easier to read. Use DG_TYPE to set the type.
- Added DG_TYPE to lots of common csObject's in the engine.
- Reverted part of Martin's changes to csObject because
this causes problems in some cases. i.e. re-added ObjReleaseOld().
113 lines of code changed in:
made the following changes:
- fixed a bug in csMovableSectorList where it would IncRef an object that is
not stored at all.
- removed ObjReleaseOld and the special destructor behaviour from csObject
since it is no longer needed.
- fixed an old bug in the constructors of csObject and csConfigFile. When I
changed these functions some time ago, I made the wrong assumption that
it is possible to call one constructor from another one to handle common
work. Instead, this creates another instance of the class on the stack,
which is of course not the desired behaviour.
27 lines of code changed in:
Small change.
0 lines of code changed in:
Added RemoveCurveTemplate() and RemovePolyTxtPlane() to
iThingEnvironment. The region code will now also correctly
clean up curve templates and polytxt planes from the thing
environment using these functions. Another memory leak
fixed :-)
58 lines of code changed in:
Reverted accidental commit.
1 lines of code changed in:
Fixed a significant memory leak on sectors. Every time a
mesh would move to a different sector a ref count would
be increased without it being decreased ever.
5 lines of code changed in:
Fixed a memory leak on dynamic and static lights in the object
iterator in the engine.
15 lines of code changed in:
- Added some additional DG_DESCRIBE0 statements to some
constructors of engine objects in order to be able to do
better debugging using the csDebuggingGraph.
- Made csDebuggingGraph a little bit more relaxed so that it
no longer requires object_reg to be non-NULL. If object_reg
is NULL it will simply do nothing.
26 lines of code changed in:
fixed stupid bug
1 lines of code changed in:
More cleanup of the output of csDebuggingGraph::Dump(). Added
curly brackets for the children to group children more clearly.
25 lines of code changed in:
Made output of csDebuggingGraph::Dump() a little nicer in the
case where you have a pointer back to a parent that is already
mentioned in this recursion level. In this case we simply print
out the pointer and the timestamp of the link and add '<-' to
indicate the information can be found upwards.
19 lines of code changed in:
Fixed a memory leak in the parsing of KEY statements in the loader.
40 lines of code changed in:
- Removed csDebuggingGraph::AddInterface() and instead added
a 'bool scf' parameter to AddObject().
- Rewrote the graph debugging tool to also allow adding of links
between objects that don't exist (yet). Also added timestamp's
to object and link creation in order to better evaluate
strange situations like a link being created before some object
was added and so on.
- Removed the 'exact' mode from the csDebuggingGraph. The mode
is now always exact.
- Since the output from csDebuggingGraph is now a little bit more
complex here follows a little explanation:
R(0) 00A136D8(r1,t17) csObject(ps) (fil.cpp,111) #p=0 #c=97
C(20) 00A280C8(r5,t18) csObject(txt.jpg) (fil.cpp,111) #p=1 #c=0
P(19) 00A136D8(r1,t17) csObject(ps) (REF)
C(23) 00A02190(r2,-t21) csObject(mat) (BAD LINK!)
Every line corresponds with an object. The first character is either
'R' (root), 'C' (child), or 'P' (parent) depending on the type
of link it is. The number directly after this type is the timestamp
when the link was created (not the object!).
After that follows the pointer to the object in hexadecimal notation.
Directly after this (between brackets) is the ref count 'r...' (only
for SCF objects) and the timestamp 't...' when the object was
created. If there is a '-' in front of the 't...' then the object
is currently deleted again.
After this follows the user-defined description of the object.
Then there are three possibilities:
- (REF): the object is a valid link but it already expanded
elsewhere in the graph. In that case you can find the
expansion of that object by looking for the pointer again.
In the example above (REF) occurs for the reference to the
parent since we are already in the expansion of the parent.
- (BAD LINK!) this is a link to an object that no longer exists.
This is an error situation and most often indicates a bug
in the code (or else a bug in the placement of the DG_...
macros).
- Otherwise the file and linenumber where the object was added
to the debug graph is shown and the number of parents and
children. The object is then expanded to show all its
parents and children.
231 lines of code changed in:
changed cs-config to report errors on stderr
4 lines of code changed in:
Fixed a memory leak in csEngine::SelectRegion(). It did a new
csRegion and then added this region to the regions vector. This
made the ref count equal to 2 but it should be one as the only
ref is the one from the regions vector. So added an additional
DecRef().
6 lines of code changed in:
- Added DG_ADDI and csDebuggingGraph::AddInterface() with which you
can add an SCF interface (instance of iBase) to the debug graph.
This will make no difference except that when the graph is
dumped the ref-count will be shown.
- Fixed a bad bug in csDebuggingGraph where it would fail to
properly unlink objects if objects were created and deleted
and happened to get the same pointer (which is not too unlikely).
81 lines of code changed in:
added to vfs:
- recursive resolution of var's
- support for platform-specific built-in vars
43 lines of code changed in:
Fixed a bug in csDebuggingGraph so that it is also able to
remove links between two objects if one or both of the objects are
already deleted. This fixes a number of invalid bad links I got
during debugging csObject.
13 lines of code changed in:
Update.
32 lines of code changed in:
Eric Sunshine fixed snapshot.py so that its removefile() function correctly
removes symbolic links even if the link is invalid.
12 lines of code changed in:
- Added a new define CS_USE_GRAPHDEBUG which is disabled by default
and which you can enable in include/csutil/debug.h. This define
enables the DG_... macros. Otherwise these macros will do
nothing.
- Added some DG_... defines to csObject code in an effort to find
a bug that is pestering CEL.
26 lines of code changed in:
Relaxed the restriction in RemoveParent() and RemoveChild() that
both objects had to be present in the graph.
7 lines of code changed in:
Improved output quality of dump a bit.
3 lines of code changed in:
Fixed a few bad bugs in csDebuggingGraph which actually prevented
it from working properly with high number of objects (> 100).
67 lines of code changed in:
Small bug fix.
1 lines of code changed in:
Added the ability to attach a new description to an object
in the debug graph.
46 lines of code changed in:
- WARNING! Dirty hack ahead!
To make the new csDebuggingGraph debugging tool work nicely in
all places (and especially the place where I plan to use it:
csObject) I need a global pointer to the object registry (csObject
has no access to the object registry). I see no other solution at
this moment then to add this global pointer to the only other
global object we already have: iSCF::SCF. This is of course very
very dirty so I only make this pointer available in debug mode.
This means that it is not possible to misuse this pointer because
it will not be there in release/optimize mode. To initialize
this pointer you must call csDebuggingGraph::SetupGraph() with
a correct object registry. Later on you can then use
csDebuggingGraph methods with a NULL object_reg pointer in which
case it will get it from iSCF::SCF.
I also added new DB_... macros which don't have an object_reg
pointer. These macros will only work in debug mode. In optimize
or release mode they will produce no code.
124 lines of code changed in:
Formatting.
4 lines of code changed in:
- It is very hard to properly debug the huge graph or tree structures
that are used a lot in Crystal Space. Using 'printf' just doesn't
cut it (too much information) and a debugger is hardly better.
That's why a new static class is added (csDebuggingGraph) which
helps with debugging any kind of graph or tree. Using that class
you can build a debug-graph of any kind of pointer with description.
Later you can dump the resulting graph given a good idea on how
everything is linked together. To use it you basically use macros
like this:
DG_ADD (object_reg, pointer1, "Object 1");
DG_ADD (object_reg, pointer2, "Object 2");
DG_ADD (object_reg, pointer3, "Object 3");
DG_LINK (object_reg, pointer1, pointer2);
DG_ADDCHILD (object_reg, pointer2, pointer3);
DG_REM (object_reg, pointer2);
csDebuggingGraph::Dump (object_reg);
You can issue such commands in the constructors/destructors
of the objects you want to debug.
Note that this tool has two modes. With exact mode (default)
the graph will exactly follow the commands that are issued. This
means that if you remove an object (DG_REM) without removing
links to it (DG_REMCHILD, DG_REMPARENT, ...) then the graph will
be invalid and the Dump will show the invalid links. This is
VERY useful for debugging.
With non-exact mode you can let this graph do the maintenance
of removing dead links on its own. When you remove an object
in this scenario all links (parent or child) to that object will
be removed automatically. This means that the debug graph cannot
get invalid in this scenario (although the real graph you are
debugging can).
- Added a new command 'debuggraph' to bugplug. This will call
csDebuggingGraph::Dump() so you can use it to dump the graph
that is in memory. It is assigned to the ctrl-g key.
665 lines of code changed in:
Update.
1 lines of code changed in:
made cs-config to fail if It can't detect the libs
17 lines of code changed in:
Fixed a formatting problem.
1 lines of code changed in:
Fixed a bad bug in csObject destructor. It appears that it could
happen that a given object was destructed twice! This is caused
by a weird construct around ObjReleaseOld(). To prevent deletion
I had to add an additional IncRef() to the object being deleted.
See the comment with ObjReleaseOld() for more detailed information.
16 lines of code changed in:
Update.
2 lines of code changed in:
Small comment fix.
1 lines of code changed in:
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Generated by StatCvs v0.2-dev