tentative fix for a bug which Alon saw which causes hell when less than sizeof(int) bytes are received in the first read on a packet

I made GetBytesRequired() return the number of bytes required to make m_nByteCount pass through sizeof(int) bytes always. So if 4 were asked for and only 1 returned then it asks for three and so on.  I also moved the logic of ::Fill around so it only figures out message length when it can *and* needs to which is ONLY when m_nByteCount is sizeof(int)
adding more debug info to help nail the Alon bug
removed comments indicating bug avoidance
pmn puts putative fix for wildcard registration bug raised by Josh Leighton

There was a case in which
a) wc subscription
b) subscription
c) notify
would not result in the notification invoking the primed wc subscription. The solution proposed here moves the logic of looking for new wc matches into Notify when the DBVar is being written for the first time.  Originally it was in GetorMakeVar() which was a funny place for it and made understanding what was going on slightly harder than it should be.

Yep that was it.  It seems that registering for a variable before it is ever posted to will prevent pShare from picking it up as a wildcard share.

On Wed, May 29, 2013 at 12:19 PM, Michael Benjamin <mikerb@mit.edu> wrote:

Hmm... good question. You can verify this hunch quickly by locally editing
ivp/src/uPokeDB/PokeDB.cpp to block out that registering:

void PokeDB::registerVariables()
{
#if 0
  unsigned int i, vsize = m_varname.size();
  for(i=0; i<vsize; i++)
    m_Comms.Register(m_varname[i], 0);
#endif

  m_Comms.Register("DB_UPTIME", 0);
  m_Comms.Register("DB_TIME", 0);

}

Mike

On Wed, 29 May 2013, Josh Leighton wrote:

I tried uTimerScript and that worked fine.  I'm pretty sure other
applications work as well, because I was using wildcard shares to bridge
back VIEW_* from the vehicle previously.  Could it somehow be related to
uPokeDB subscribing to the variable before it publishes to it?

On Wed, May 29, 2013 at 12:01 PM, Michael Benjamin <mikerb@mit.edu> wrote:

That's really strange then. There should be no difference in how a
variable got poked/written to the DB. What about other MOOS Apps? Are think
published by your own vanilla apps getting shared? I wonder what's
different about umm?

Mike

On Wed, 29 May 2013, Josh Leighton wrote:

 pShare should automatically do a wildcard share on X_* but it does not
work
when I use upokedb to create the variable.  Umm works fine though.
On May 29, 2013 11:54 AM, "Michael Benjamin" <mikerb@mit.edu> wrote:

Ok, I'm missing something then. What part is not working?
Mike

On Wed, 29 May 2013, Josh Leighton wrote:

 I do see output like you described, but the variable shows up just fine
in

uXMS.

On Wed, May 29, 2013 at 11:50 AM, Michael Benjamin <mikerb@mit.edu>
wrote:

 Ok thanks. And when you poke, do you see something like:

PRIOR to Poking the MOOSDB
  VarName               (S)ource    (T)ime      VarValue
  ----------------      ----------  ----------   -------------
  X_A

AFTER Poking the MOOSDB
  VarName               (S)ource    (T)ime      VarValue
  ----------------      ----------  ----------   -------------
  X_A                    uPokeDB     18.54       "hello"

And the value of X_A is not showing up as "hello" in a scope?

R/Mike

On Wed, 29 May 2013, Josh Leighton wrote:

 Same pShare setup as Paul described, though I am using uXMS instead of
umm

 to monitor all variables.

Using umm: umm -p=X_A

Using uPokeDB: uPokeDB X_A="hello" and accepting default host and
port.

I am working out of the moos-ivp trunk, though with the core-moos and
essential-moos git devel branches.  I rebuilt uPokeDB today against
the
core-moos devel, though I was encountering the same issues before.

On Wed, May 29, 2013 at 11:34 AM, Michael Benjamin <mikerb@mit.edu>
wrote:

 Hi Josh -

Can you tell me how you are using uPokeDB?

Mike

On Wed, 29 May 2013, Josh Leighton wrote:

 Okay I tried your steps and that seemed to work.  I think I have
traced

 the

problem to uPokeDB.  If I poke a variable using umm it works fine,
but
using uPokeDB it does not.  Poking with umm after it has been poked
by
uPokeDB also does not work.  Any idea what the problem is?

On Wed, May 29, 2013 at 10:42 AM, Paul Newman <
pnewman@robots.ox.ac.uk

 **

wrote:

 Hello Josh, thanks for getting back to me. So I tried to replicate
your

 conditions but could not reproduce the problem. Here is what I did
Merge branch 'refs/heads/AlonBug' into V10-rc1
Merge branch 'refs/heads/wildcardbug' into V10-rc1
fixed some noisy compiles
fixing unsigned /int comparison issue
adding bounce functionality
making time displayed for delay truly in ms
double log bug discovered - pushed to new branch
added SetMOOSName
Merge branch 'refs/heads/wildcardbug' into V10-rc1
Merge branch 'refs/heads/doublelogbug' into V10-rc1
removing old debug printing
adding change  to app casting sent by Mikerb on 23rd July
ignoring DS_Store files
ignore
Merge branch 'refs/heads/master' into devel
commenting tidy