[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memory Leak-.dll problem
From: |
Marcus G. Daniels |
Subject: |
Re: Memory Leak-.dll problem |
Date: |
08 Mar 2000 22:23:12 -0800 |
User-agent: |
Gnus/5.070084 (Pterodactyl Gnus v0.84) Emacs/20.4 |
D3> All right, do we agree I've done my homework now?
At some point relatively soon I'll find what the problem is, but Swarm
2.1 is frozen and I have other priorities right now.
The point that I would really like to have understood (one that seems
to keep getting missed by various people) is that a good bug report
is one that immediately demonstrates wrong behavior in a clear and
direct way.
What does this mean?
1) Bugs reports that use example programs that have dynamics and
that have no particular point at which a bad thing happens are
not ideal. It means that I have to figure out how to control the
dynamics which is almost always harder for me than it is for the
person working with the model. This example program is like
this, I mean, do we really need dynamic scheduling per "-log
([randomDeathGenerator getDoubleSample])*10+1000" instead a
constant?
2) Bug reports that have domain semantics (like this one), mean that
I have to wade into a semantic space and try to figure out what
your point is -- what is relevant and what is not. That means
time that isn't spent on other general things for the user
community at large. In this program we find domain semantics.
3) Bug reports that have lots of irrelevant code (even if it is not
domain-specific) again mean I sink time into filtering tasks that
I am not the ideal person for. In this program we find ProbeDisplays,
Graphs, and a kind-of-deactivated Raster thingey. It all adds up
4) While it is helpful to know "this didn't happen before and now
it does" -- that alone does not mean there is a bug. (Yes, I think
there is one in this case.)
5) If you believe there is a bug lurking based on a change in the
phenomenology of your model and you have several constraints and
specific hypothesis (or a few), often the easiest way to demonstrate
the problem is to write a small program from scratch. It's easier
than you might think.
6) It is not reasonable to expect me or any maintainer-like
person to remember details of previous discussions about a given
application. Bug reports should have explicit, minimal and
sufficient context provided.
7) SDG membership is intended to offset the need for vigilance in #1-#6.
==================================
Swarm-Support is for discussion of the technical details of the day
to day usage of Swarm. For list administration needs (esp.
[un]subscribing), please send a message to <address@hidden>
with "help" in the body of the message.