On 2012-10-15 5:32 PM, Robert O'Callahan wrote:
On Tue, Oct 16, 2012 at 4:18 AM, Ehsan Akhgari wrote:
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 implementation of that function, for
On Tue, Oct 16, 2012 at 4:18 AM, Ehsan Akhgari wrote:
> 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 implementation of that function, for callers who prefer to use the
> PRTime API.
On 2012-10-14 6:57 PM, Robert O'Callahan wrote:
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:
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
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari wrote:
> 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 implement
> our own APIs
On 2012-10-12 8:15 PM, Wan-Teh Chang wrote:
Hi Ehsan,
If you work in Mountain View, I'd like to meet with you to discuss our
options for the OpenBSD integer types problem (bug 634793). (One of
the options is to accept the requested change.) I am sure we can avoid
a Mozilla local patch for this p
Hi Ehsan,
If you work in Mountain View, I'd like to meet with you to discuss our
options for the OpenBSD integer types problem (bug 634793). (One of
the options is to accept the requested change.) I am sure we can avoid
a Mozilla local patch for this problem.
I came from the era of Unix balkaniza
On 2012-10-12 12:18 PM, Wan-Teh Chang wrote:
Hi Ehsan,
Thank you for your reply.
Hi! Thank you for your swift replies too! :-)
On Fri, Oct 12, 2012 at 7:25 AM, Ehsan Akhgari wrote:
Do we require to maintain source or binary compatibility, or both?
As BDS said, both are required in gene
Hi Ehsan,
Thank you for your reply.
On Fri, Oct 12, 2012 at 7:25 AM, Ehsan Akhgari wrote:
>
> Do we require to maintain source or binary compatibility, or both?
As BDS said, both are required in general. Source compatibility can be
broken if it is not disruptive, and that's often hard to assess
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, without changing the
> defau
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, withou
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 deal
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 f
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 w
On Thu, Oct 11, 2012 at 06:38:57PM -0400, Ehsan Akhgari wrote:
> On 2012-10-11 6:36 PM, Mike Hommey wrote:
> >On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote:
> >>On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari
> >>wrote:
> >>>What I really don't want us to do is to prohibit people
On 2012-10-11 6:36 PM, Mike Hommey wrote:
On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote:
On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari wrote:
What I really don't want us to do is to prohibit people from fixing things
in the imported code. That is the absolute worst situation
On Thu, Oct 11, 2012 at 06:14:51PM -0400, Ted Mielczarek wrote:
> On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari
> wrote:
> > What I really don't want us to do is to prohibit people from fixing things
> > in the imported code. That is the absolute worst situation we can face with
> > a given pie
On Thu, Oct 11, 2012 at 4:20 PM, Ehsan Akhgari wrote:
> What I really don't want us to do is to prohibit people from fixing things
> in the imported code. That is the absolute worst situation we can face with
> a given piece of code, as we already have learned painfully.
This should absolutely b
On 2012-10-11 3:16 PM, Randell Jesup wrote:
In Bug 794510, ehsan said in response to me:
Isaac makes a good point; we should clearly mark imported code, both for our
own purposes and for scripts. Biesi and I were commiserating about the lack of
a standard for this ("third_party/blah" such as n
18 matches
Mail list logo
