[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?
/David
-----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
Queue
class (it made AddTail() and AddHead() into O(N) operations -- they should
be
amortized O(1)), and so I was planning to release a v2.43 with the fix in a
few
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
String::Prepend().
- 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
queue-slot-preallocation,
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.
-Jeremy
Other related posts:
