Re: Memory Leak-.dll problem

[Doug Donalson]

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?


Yes we may.  Part of the concurrent scheduling is the fact that there will
be multiple non-identical entries within the concurrent group.  That is why
I went to the extra effort to put that in that manner.

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.
I would love to give you 5 lines of code that reproduce the problem but the
problem can't be recreated in 5 lines of code.  I also went to the extra
effort of making it possible for you to be able to compare two versions of
the sim, one with explicit removal of events from the event list and with
two comment lines, one without.  Sorry if I put too much in.

>   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.)
Marcus,  believe it or not, I am not a complete idiot.  You wanted specifics
and I gave them to you.  It should save you quite a bit of time to know that
the error occured with the updated dll's and not prior to them.

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.
As far as I can count, there are only 3 non-used procedures left in the
agent def and the modeSwarm combined.    Beyond that, there is the blank
raster, sorry I didn't know it would confuse you, and the BLT display which
I assumed you would want because it shows where memory should and should't
be consumed.

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.
That is why I provided the previous corrispondence.  I also provided enough
testing information to ensure that it was highly unlikly that there was any
other cause of the memory leak.  Hopefully saving you time.

7) SDG membership is intended to offset the need for vigilance in #1-#6.
Marcus, as soon as my income is greater that my outgo I will be happy to
join SDG.  In the mean time, 2.0.1 without the DLL's works fine so don't
bother with my stuff until I am a paying member.

----- Original Message -----
From: Marcus G. Daniels <address@hidden>
To: <address@hidden>
Sent: Wednesday, March 08, 2000 10:23 PM
Subject: Re: Memory Leak-.dll problem


>
> 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) >
>   >
>   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
>
>
>   >
>   >
>   >
>                   ==================================
>    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.
>


                  ==================================
   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.