Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Stephan Bergmann
On 11/16/2011 06:45 AM, Kohei Yoshida wrote: I would encourage you to not do this style of implicit inlining in your code, sure, but I wouldn't want you go wild and start editing a bunch of headers just for the sake of it. While we are at it: Not inlining functions can be especially beneficial

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Kohei Yoshida
On Wed, 2011-11-16 at 00:36 -0500, Kevin Hunter wrote: > Thanks for the info. Would you like me to do similar, as I note them > while working on/learning notes? I would encourage you to not do this style of implicit inlining in your code, sure, but I wouldn't want you go wild and start editing

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Kevin Hunter
At 12:28am -0500 Wed, 16 Nov 2011, Kohei Yoshida wrote: On Wed, Nov 16, 2011 at 12:21 AM, Kevin Hunter wrote: From the curious cat: why? Because that made it easier to debug whatever I was debugging. Plus, I don't believe in those implicitly inline methods, especially in headers that are inc

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Kohei Yoshida
Hi Kevin, On Wed, Nov 16, 2011 at 12:21 AM, Kevin Hunter wrote: > From the curious cat: why? Because that made it easier to debug whatever I was debugging. Plus, I don't believe in those implicitly inline methods, especially in headers that are included by millions. Imagine if you have to re-

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Kevin Hunter
At 3:21pm -0500 Tue, 15 Nov 2011, Kohei Yoshida wrote: sc/inc/cell.hxx |4 ++-- sc/source/core/data/cell2.cxx | 10 ++ 2 files changed, 12 insertions(+), 2 deletions(-) New commits: commit 87be97a31d8686e3e6e976bb5585b32c096ca19d Author: Kohei Yoshida Date: Tue

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-14 Thread Kohei Yoshida
Hi Eike, On Mon, 2011-11-14 at 15:04 +0100, Eike Rathke wrote: > IMHO (correct me if I'm wrong) for the sorted range lookup Excel returns > #N/A if the search is of type Text and the last element found for > less_or_equal is of type Number. Yup, you're right! Tested with Excel 2007, and Excel

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-14 Thread Eike Rathke
Hi Kohei, On Friday, 2011-11-11 12:17:21 -0500, Kohei Yoshida wrote: > > > commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 > > > Removing the mixed comparison flag, which is no longer needed. > > > > Isn't that needed for MATCH and ([HV])LOOKUP with mixed data such as > > 1,2,3,b,c,d when qu

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-11 Thread Kohei Yoshida
On Fri, 2011-11-11 at 15:41 +0100, Eike Rathke wrote: > Hi Kohei, > > On Thursday, 2011-11-10 12:49:29 -0800, Kohei Yoshida wrote: > > > commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 > > Author: Kohei Yoshida > > Date: Thu Nov 10 15:45:53 2011 -0500 > > > > Removing the mixed comparison

Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-11 Thread Eike Rathke
Hi Kohei, On Thursday, 2011-11-10 12:49:29 -0800, Kohei Yoshida wrote: > commit eaea417bfdf8d06df2b7f2e42c904c32ce77e871 > Author: Kohei Yoshida > Date: Thu Nov 10 15:45:53 2011 -0500 > > Removing the mixed comparison flag, which is no longer needed. > > This flag was introduced