On 2012-10-15 5:32 PM, Robert O'Callahan wrote:
On Tue, Oct 16, 2012 at 4:18 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
Sure, I was not suggesting that. What I was suggesting was to take our
implementation of the TimeStamp class for Windows and use the same ideas in
the NSPR
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
In some cases in the past (such as bug 563082), we've needed to change the
semantics of some of the NSPR functions to make them work better for some
things, such as more precise time measurements, but we've had to
On 2012-10-11 8:52 PM, Wan-Teh Chang wrote:
Ehsan wrote:
It is entirely unreasonable to render ourselves unable to modify
our imported code (just look at the current situation with NSPR
which causes developers to go through huge pain in order to work
around things which would be very simply
On 10/12/2012 10:25 AM, Ehsan Akhgari wrote:
Do we require to maintain source or binary compatibility, or both?
Also, is it acceptable for us to add new preprocessor definitions such
as NO_NSPR_10_SUPPORT to optionally remove some of the NSPR feature
which we would like Gecko to avoid,
Randell quoted:
Ehsan wrote:
It is entirely unreasonable to render ourselves unable to modify
our imported code (just look at the current situation with NSPR
which causes developers to go through huge pain in order to work
around things which would be very simply dealt with if only we
had
Ehsan wrote:
It is entirely unreasonable to render ourselves unable to modify
our imported code (just look at the current situation with NSPR
which causes developers to go through huge pain in order to work
around things which would be very simply dealt with if only we
had the option of
6 matches
Mail list logo
