[muscle] SV: Re: 2.43?

  • From: "David Svanberg" <ds@xxxxxxxxxxx>
  • To: <muscle@xxxxxxxxxxxxx>
  • Date: Wed, 13 Aug 2003 08:58:56 +0200

>So if whomever is in charge of the VC++ projects wants them included in the
v2.43 release

That would still be Vitaliy Mikitchenko - do you, Vitaliy, have some cool
project settings availiable?


-----Opprinnelig melding-----
Fra: muscle-bounce@xxxxxxxxxxxxx [mailto:muscle-bounce@xxxxxxxxxxxxx]På;
vegne av Jeremy Friesner
Sendt: 13. august 2003 08:25
Til: muscle@xxxxxxxxxxxxx
Emne: [muscle] Re: 2.43?

Hey David,

> When can we expect 2.43=3F
> What's new & what's retired...

Funny you should ask... just today I found a big fat efficiency-bug in the
class (it made AddTail() and AddHead() into O(N) operations -- they should
amortized O(1)), and so I was planning to release a v2.43 with the fix in a
days (probably sometime this weekend).  So if whomever is in charge of the
VC++ projects wants them included in the v2.43 release, the next day or two
would be a good time to send them to me.  :^)

FWIW, here is my current change list for v2.43:

2.43 -
  - Added an optional (count) argument to String::Append() and
  - Added a DisconnectSession() method to the AbstractReflectSession class.
    Calling this method force-disconnects the session's TCP connection.
  - PR=5FCOMMAND=5FSETDATA now processes multiple sets to the same node in
    a single Message.
  - Added a (numPreallocSlots) argument to the Queue::EnsureSize() method,
    so you can specify how many extra slots to preallocate in the event
    of an array reallocation.
  - Added SetSignalHandle(), SetSignalValue(), and SetReplyThreadID()
    methods to the Win32MessageTransceiverThread class.
  * Fixed a bug in Hashtable::Clear() that could cause crashes under
    certain circumstances (iterators weren't being unregistered reliably).
  * Fixed a bug in the Queue class that was disabling
    making AddHead() and AddTail() calls VERY inefficient -- O(N) instead
    of amortized O(1).  Oops!
  * The Win32 implementation of GetHumanReadableTimeString() was returning
    date strings 369 years too early.  Fixed.


Other related posts: