Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 12:03 AM, Andrea Pescetti wrote:
> On 11/02/2013 Hagar Delest wrote:
>> No real problem with reinstalling extensions after a major upgrade, I've
>> done that too.
>> But there is a difference between the mere inconvenience of reinstalling
>> extensions and losing them completely (waiting that someone dare update
>> them).
> 
> The real issue is here indeed. Reinstalling won't be perceived as a big
> problem. But the fact that reinstalling the same extension won't work
> will be a problem.
> 
> Most of the extensions hosted on extensions.openoffice.org won't be
> updated, and extensions.openoffice.org does not support filtering by
> version (and anyway the information would be missing in current
> releases). The top five extensions at
> http://extensions.openoffice.org/en/most_popular
> total 1 million downloads per year, which could give some backing to the
> nightmare support scenario Hagar envisions.
> 
> Ariel posted to the API list saying that the two reasonable options in
> his opinion are either to keep or revert his entire change (Hagar,
> please note that Ariel asked not to start a discussion here and now, and
> mentioned he cannot be responsive at the moment; anyway...). But if
> there is a way, even using redundant code, to still support the old and
> new toolbar handling this would be very useful to end-users. From the
> FOSDEM talks I understood there could the possibility to still support
> both mechanisms (and of course, warn users when the "deprecated" one is
> used).

maybe you understand it wrong, no warning. If we support both the
underlying code would be more complex, slower and more ugly to maintain.
and Ariel pointed already out that he is not willing to support both
based on this fact. Either the old or the new mechanism, or somebody
else step forward and implement the change.

The whole discussion is really based on assumption. We can ask our
friends of SourceForge to analyze by a script all extensions and check
if they contain an Addon.xcu or not. All developers, maintainers of
extensions with Addon.xcu can we contact and can inform them about the
proposed change and how to adapt the xcu.

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 12:41 AM, Rob Weir wrote:
> On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest  
> wrote:
>> Le 11/02/2013 22:46, Rob Weir a écrit :
>>>
>>> My impression was that even if we made no changes, from the user's
>>> perspective, they would lose all extensions.  This is due to the
>>> change in base directory for the profile.  So all extensions would be
>>> lost and need to be reinstalled.  So there will be no doubt in the
>>> user's mind, even if they do not read the release notes, that the
>>> extensions are gone.
>>> [...]
>>>
>>> Again, my impression is that users will lose their extensions and need
>>> to reinstall them, even if we do not make any API changes.
>>> [...]
>>>
>>> I think a "clean break" with the past profile helps us avoid the
>>> current generation of crash issues.  We get to start clean rather than
>>> deal with the many upgrade paths:
>>
>>
>> No real problem with reinstalling extensions after a major upgrade, I've
>> done that too.
>> But there is a difference between the mere inconvenience of reinstalling
>> extensions and losing them completely (waiting that someone dare update
>> them).
>>
> 
> Is that what we're really facing?  Are you saying that extension
> author will not update their extensions if they become incompatible?
> Is that what we think?
> 
> I agree that this would be a bad situation.  But is it the likely
> situation we would face?  The authors of the top extensions would not
> update?

If that is the case than we can stop to talk about extensions at all. I
would not spent any further minute to make the life of extension
developers easier.

Juergen

Re: Google Summer of Code 2013: Coming sooner than you think

[Jürgen Schmidt]

On 2/11/13 8:34 PM, Rob Weir wrote:
> Google announced the timeline for the 2013 program today:
> 
> http://www.google-melange.com/gsoc/events/google/gsoc2013
> 
> The ASF has applied as a mentoring organization in the past.  I assume
> we will again this year.   If so there would be a limited number of
> slots for Apache, which mentors (volunteers that lead the GSoC
> project) in individual projects to fill.
> 
> My recommendation is to *not* wait for an ASF announcement calling for
> proposals, but to start thinking about possible projects now.  My
> guess is we'll need to have proposals ready before April.  So this
> this is coming sooner than you think.
> 
> I mentored a student in the ODF Toolkit project last summer, so feel
> free to ask me what is involved.
> 

yes, probably a good ideato start early. I am interested to mentor a
Eclipse plugin project similar to the NetBeans plugin.

Juergen

Re: Updating Java libraries

[Herbert Dürr]

On 2013/02/11 8:06 PM, Michael Lam wrote:

It is partially to address the JDK issue but there have been
improvements in HSQLDB for both performance and conformance that would
be helpful which is why I lean more towards updating to the latest
rather than patching the existing.


Absolutely! The JDK/JRE issue alone proves that an update is overdue.

I just wanted to answer your question why in the AOO codebase external 
dependencies are sometimes patched instead of being simply upgraded to 
the latest released version.



I understand it would be difficult to
constantly update to the latest release of a dependent project both in a
quality and release standpoint. With adequate planning and testing, the
code should also allow for an update to the latest without too many
gotchas.


Thanks again for working on this!

Herbert

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Tue, Feb 12, 2013 at 4:11 AM, Jürgen Schmidt  wrote:
> On 2/12/13 12:41 AM, Rob Weir wrote:
>> On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest  
>> wrote:
>>> Le 11/02/2013 22:46, Rob Weir a écrit :

 My impression was that even if we made no changes, from the user's
 perspective, they would lose all extensions.  This is due to the
 change in base directory for the profile.  So all extensions would be
 lost and need to be reinstalled.  So there will be no doubt in the
 user's mind, even if they do not read the release notes, that the
 extensions are gone.
 [...]

 Again, my impression is that users will lose their extensions and need
 to reinstall them, even if we do not make any API changes.
 [...]

 I think a "clean break" with the past profile helps us avoid the
 current generation of crash issues.  We get to start clean rather than
 deal with the many upgrade paths:
>>>
>>>
>>> No real problem with reinstalling extensions after a major upgrade, I've
>>> done that too.
>>> But there is a difference between the mere inconvenience of reinstalling
>>> extensions and losing them completely (waiting that someone dare update
>>> them).
>>>
>>
>> Is that what we're really facing?  Are you saying that extension
>> author will not update their extensions if they become incompatible?
>> Is that what we think?
>>
>> I agree that this would be a bad situation.  But is it the likely
>> situation we would face?  The authors of the top extensions would not
>> update?
>
> If that is the case than we can stop to talk about extensions at all. I
> would not spent any further minute to make the life of extension
> developers easier.
>

I don't know.  I was asking a question.  But I think this is an
important question:  Why would an extension author not update their
extension for AOO 4.0?  Some hypothetical answers:

1) The extension is unmaintained

2)  The author cannot be located or we have no way to notify them of changes

3) It is not clear to the author what technical changes are needed

4) There is not sufficient calendar time for the extension author to
make the needed changes before we release, or the work required is too
much for the author to fit into his schedule

5) The author attempts changes but they don't work or they introduce
new problems

6) The results of not making the changes is not clear, so the author
mistakenly thinks they are optional changes

7) Author has technical or account issues with the extensions website
and is unable to upload a new version, and does not know where to get
help.

These are all possible concerns, but I think most of them can be
managed with good communications and advance notice.

There is also the possibility of:

8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.

What is totally unclear to me is whether we are facing #8 only, or
whether we have any of the other concerns.

One option for #8 is to add a nice new feature or capability to the
API so extension author will *want* to update.

-Rob

> Juergen

Performance test comparisons

[Rob Weir]

I did some tests to see how we were doing, comparing AOO 3.4.1 on
Windows against OOo 3.3.0.  And since LibreOffice claims that their
4.0 release is much faster and leaner, I tested them as well, to see
if we could learn anything.

I just did a basic test, seeing how long it took to load a large text
document, in this case the ODF 1.2 specification.  I looked at memory
consumed and the number of seconds to load.  I loaded the document
once to reduce the impact of disk caching and then repeated 5 times
and took the average.  All tests done on identical hardware.

Memory use (KB for soffice.bin):

OOo 3.3.0:133,472
AOO 3.4.1:   129,928
LO 4.0: 165,796

Load time for ODF 1.2 specification (seconds, average of 5 loads)

OOo 3.3.0:16.0
AOO 3.4.1:20.9
LO 4.0:  23.7


Does anyone have any other good test documents for doing performance
tests of OpenOffice?

Regards,

-Rob

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Joost Andrae]

Hi,

in the moment I have just one question in mind:

Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu 
like presentation-minimizer.oxt ?




8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.

What is totally unclear to me is whether we are facing #8 only, or
whether we have any of the other concerns.

One option for #8 is to add a nice new feature or capability to the
API so extension author will *want* to update.


Kind regards, Joost

Re: Performance test comparisons

[David Gerard]

On 12 February 2013 12:42, Rob Weir  wrote:

> I just did a basic test, seeing how long it took to load a large text
> document, in this case the ODF 1.2 specification.  I looked at memory
> consumed and the number of seconds to load.  I loaded the document
> once to reduce the impact of disk caching and then repeated 5 times
> and took the average.  All tests done on identical hardware.


http://neowiki.neooffice.org/index.php/NeoOffice_Performance_Comparison
is old, but may be useful for developing a good list of benchmarks.
Note the MS Word column.


- d.

Re: Draft blog post: $21 million per day

[Rob Weir]

Good morning.  It is posted now.

The URL is:  http://blogs.apache.org/OOo/entry/21_million_per_day

Regards,

-Rob

On Sat, Feb 9, 2013 at 8:54 AM, Sally Khudairi  wrote:
> Thanks so much, Rob. I'd prefer we go out at 8AM ET on Tuesday. I think
> we'll get the most media attention during the business week, and also give
> the international press a chance to cover us as well.
>
> I'll keep everyone abreast of developments on our end.
>
> Kind regards,
>
> Sally
>
>
> [From the mobile; kindly excuse spelling/spacing/auto-correct anomalies]
>
>
> - Reply message -
> From: "Rob Weir" 
> To: "Sally Khudairi" 
> Cc: , "Sally Khudairi" 
> Subject: Draft blog post: $21 million per day
> Date: Sat, Feb 9, 2013 8:28 AM
>
>
> On Sat, Feb 9, 2013 at 6:25 AM, Sally Khudairi 
> wrote:
>> Rob, et.al. --is there a preferred day/time you'd like to go live with
>> this?
>>
>> Given that you, Don, and I all live in the snow-socked East Coast, should
>> we
>> give ourselves some blizzard recovery time or just go ahead (say, on
>> Tuesday)?
>>
>
> Snow should end for us my mid-afternoon today.  State has a ban on
> driving so roads are empty. USPS has suspended mail delivery.   But we
> didn't lose electricity.  So I can publish this anytime.  But if
> Tuesday 8am EST works well, I can aim for that.
>
> -Rob
>
>> Thanks in advance,
>>
>> Sally
>>
>>
>> [From the mobile; kindly excuse spelling/spacing/auto-correct anomalies]
>>
>>
>> - Reply message -
>> From: "Rob Weir" 
>> To: 
>> Cc: "Sally Khudairi" 
>> Subject: Draft blog post: $21 million per day
>> Date: Thu, Feb 7, 2013 7:39 PM
>>
>>
>> https://blogs.apache.org/preview/OOo/?previewEntry=21_million_per_day
>>
>> Hoping to publish early next week.
>>
>> Regards,
>>
>> -Rob

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 1:42 PM, Joost Andrae wrote:
> Hi,
> 
> in the moment I have just one question in mind:
> 
> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> like presentation-minimizer.oxt ?

well the extensions where we have the source code can be changed by
volunteers. Maybe directly at Apache or as Google code project when
there are license incompatible dependencies.

Everything else is unclear and I doubt that Oracle has interest in
updating them. And nobody else can do that.

The best thing would be to start new projects providing similar
functionality but where the code is available and under a proper license.

Unmaintained extensions are a general problem and should not have
influence on any decision.

Juergen


> 
>>
>> 8) Inconvenience -- it is natural for anyone to complain about needing
>> to do additional work where they don't see the advantage.  So it is
>> natural that we will expect complaints, followed in the end by
>> conformance with the required changes.
>>
>> What is totally unclear to me is whether we are facing #8 only, or
>> whether we have any of the other concerns.
>>
>> One option for #8 is to add a nice new feature or capability to the
>> API so extension author will *want* to update.
> 
> Kind regards, Joost
> 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rory O'Farrell]

On Tue, 12 Feb 2013 14:07:59 +0100
Jürgen Schmidt  wrote:

> On 2/12/13 1:42 PM, Joost Andrae wrote:
> > Hi,
> > 
> > in the moment I have just one question in mind:
> > 
> > Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> > like presentation-minimizer.oxt ?
> 
> well the extensions where we have the source code can be changed by
> volunteers. Maybe directly at Apache or as Google code project when
> there are license incompatible dependencies.
> 
> Everything else is unclear and I doubt that Oracle has interest in
> updating them. And nobody else can do that.
> 
> The best thing would be to start new projects providing similar
> functionality but where the code is available and under a proper license.
> 
> Unmaintained extensions are a general problem and should not have
> influence on any decision.

There are already reports on incompatabilities with LibO 4.0 and some existing 
extensions.  

One thread, for example, at
http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595

Might there be possibility for a shim to be written to sit between Addons.xcu 
and AOO 4.0?

-- 
Rory O'Farrell 

Re: pdf export option for FilterData and ExportFormFields

[Peter Eberlein]

Hi Andrea,

Am 05.02.2013 22:34, schrieb Andrea Pescetti:


Do you mean that not only you wish that OpenOffice export fields as
"enterable fields" (which it already does) but that the PDF file
produced by OpenOffice should also support the ability to save form
content? But is this ability a document property or something that
depends on the PDF reader being used?

Yes, I mean the ability to save the content of form fields. And as I see 
now here [1], it doesn't seem to be a legal issue of Adobe®.

It's a document property and doesn't depend on the reader.

Regards

Peter

[1] 
http://www.foxitsoftware.com/company/press.php?action=view&page=20080508aw3E.html

Re: Draft blog post: $21 million per day

[Sally Khudairi]

Posted https://twitter.com/TheASF/status/301315097794596867

...as well as sent to our media/analyst list :-)

Cheers,
Sally

  From: Sally Khudairi 
>To: Rob Weir ; dev@openoffice.apache.org 
>Cc: Sally Khudairi  
>Sent: Thursday, 7 February 2013, 23:21
>Subject: Re: Draft blog post: $21 million per day
>  
>
>Thank you, Rob. This is great. I'm happy to support this with a tweet from 
>@TheASF as well as send to our dedicated media/analyst list.
>
>Keep up the great work!
>
>-Sally
>
>
>[From the mobile; kindly excuse spelling/spacing/auto-correct anomalies]
>
>
>- Reply message -
>From: "Rob Weir" 
>To: 
>Cc: "Sally Khudairi" 
>Subject: Draft blog post: $21 million per day
>Date: Thu, Feb 7, 2013 7:39 PM
>
>
>https://blogs.apache.org/preview/OOo/?previewEntry=21_million_per_day
>
>Hoping to publish early next week.
>
>Regards,
>
>-Rob
>
>
>   

Re: Performance test comparisons

[Rob Weir]

On Tue, Feb 12, 2013 at 7:53 AM, David Gerard  wrote:
> On 12 February 2013 12:42, Rob Weir  wrote:
>
>> I just did a basic test, seeing how long it took to load a large text
>> document, in this case the ODF 1.2 specification.  I looked at memory
>> consumed and the number of seconds to load.  I loaded the document
>> once to reduce the impact of disk caching and then repeated 5 times
>> and took the average.  All tests done on identical hardware.
>
>
> http://neowiki.neooffice.org/index.php/NeoOffice_Performance_Comparison
> is old, but may be useful for developing a good list of benchmarks.
> Note the MS Word column.
>

Thanks.  That looks like some interesting scenarios, but I don't see
any links to the actual documents.  But perhaps enough info to create
our own based on the description.

-Rob

>
> - d.

Re: Will AOO write .docx?

[Regina Henschel]

Regina Henschel schrieb:


I have written to Mathias Stürmer and ask, how to get the patches.



I have got a private answers and waiting for the permission to share it.

Kind regards
Regina

Re: Performance test comparisons

[inge]

On Tuesday, February 12, 2013 07:42:49 Rob Weir wrote:
> I did some tests to see how we were doing, comparing AOO 3.4.1 on
> Windows against OOo 3.3.0.  And since LibreOffice claims that their
> 4.0 release is much faster and leaner, I tested them as well, to see
> if we could learn anything.
> 
> I just did a basic test, seeing how long it took to load a large text
> document, in this case the ODF 1.2 specification.  I looked at memory
> consumed and the number of seconds to load.  I loaded the document
> once to reduce the impact of disk caching and then repeated 5 times
> and took the average.  All tests done on identical hardware.
> 
> Memory use (KB for soffice.bin):
> 
> OOo 3.3.0:133,472
> AOO 3.4.1:   129,928
> LO 4.0: 165,796
> 
> Load time for ODF 1.2 specification (seconds, average of 5 loads)
> 
> OOo 3.3.0:16.0
> AOO 3.4.1:20.9
> LO 4.0:  23.7

And what were the values for Calligra Words 2.6.0?  ;)
 
> Does anyone have any other good test documents for doing performance
> tests of OpenOffice?
> 
> Regards,
> 
> -Rob

Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work

[Steve Lee]

Andrew

I think that binaries URL should be he following, at least for accessing
the binaries.

http://ci.apache.org/projects/openoffice/#w7ia2

As you point out however they are not there yet. Do you have an ETA?

After Stuart's post of the NVDA list there has been quite a bit of
discussion and enthusiasm from some NVDA people on Twitter so others may
come looking.

https://twitter.com/jcsteh/status/301051115502448641

Steve
OpenDirective

On 10 February 2013 01:14, Andrew Rist  wrote:

> Do you all know about this?
> http://ci.apache.org/builders/**aoo-w7ia2/
> We now have an automatic build of the ia2 branch running nightly. (and
> successfully)
> It is not loading up install bits for some reason, but I'll look at that
> and fix it.
>
> If you want to see the status of the latest build look for "Windows ia2
> Branch" on this page:
> http://ci.apache.org/projects/**openoffice/
> that page links to the build logs  projects/openoffice/buildlogs/**w7ia2/log/wntmsci12.pro.build.**html>
> and the buildbot log 
> >,
> and should have the latest build of the install packages.
>
> Andrew
>
>
>
>
> On 2/9/2013 10:05 AM, V Stuart Foote wrote:
>
>> Steve,
>>
>> Nothing substantive yet in working through the Windows build of the ia2
>> branch. Should we build against Linux and OSX and be testing for impact on
>> ATK/AT-SPI and NSAccessibility User Interface?
>>
>> And, with QA and testing of the ia2 branch proceeding what mechanism
>> should folks use for reporting and tracking issues on the ia2 branch builds?
>>
>> Should we stay with PM and ML exchanges, or start to use Bugzilla at
>> issues.apache.org/ooo?  I believe that starting with BZ tracking now
>>  provides continuity upon merge of branch back into AOO4.00.
>>
>> And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2
>> release planning wiki that  QA participants and casual users report in
>> Bugzilla categorized for consistency as against:
>>
>> Product: UI
>> Component: AccessBridge
>> Version: AOO4.00-dev
>>
>> Stuart
>>
>> =-=-=
>>
>> Sidebar--the legacy IAccessible2 enhancement bug could probably be revised
>> https://issues.apache.org/ooo/**show_bug.cgi?id=107914
>>
>> And here is a generic BZ search for accessibility issues
>> https://issues.apache.org/ooo/**buglist.cgi?query_format=**
>> advanced&resolution=---&short_**desc=msaa%20accessible%**
>> 20iaccessible%20iaccessible2%**20accessibility&short_desc_**
>> type=anywordssubstr&order=**component%2Cpriority%2Cbug_**
>> severity&query_based_on=
>>
>>
>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Jürgen Schmidt]

On 2/12/13 2:15 PM, Rory O'Farrell wrote:
> On Tue, 12 Feb 2013 14:07:59 +0100
> Jürgen Schmidt  wrote:
> 
>> On 2/12/13 1:42 PM, Joost Andrae wrote:
>>> Hi,
>>>
>>> in the moment I have just one question in mind:
>>>
>>> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
>>> like presentation-minimizer.oxt ?
>>
>> well the extensions where we have the source code can be changed by
>> volunteers. Maybe directly at Apache or as Google code project when
>> there are license incompatible dependencies.
>>
>> Everything else is unclear and I doubt that Oracle has interest in
>> updating them. And nobody else can do that.
>>
>> The best thing would be to start new projects providing similar
>> functionality but where the code is available and under a proper license.
>>
>> Unmaintained extensions are a general problem and should not have
>> influence on any decision.
> 
> There are already reports on incompatabilities with LibO 4.0 and some 
> existing extensions.  
> 
> One thread, for example, at
> http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595
> 
> Might there be possibility for a shim to be written to sit between Addons.xcu 
> and AOO 4.0?

I don't know, I haven't looked into it but I know that they have changed
API's more radical. No surprise for me.

Juergen

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rory O'Farrell]

On Tue, 12 Feb 2013 15:06:27 +0100
Jürgen Schmidt  wrote:

> On 2/12/13 2:15 PM, Rory O'Farrell wrote:
> > On Tue, 12 Feb 2013 14:07:59 +0100
> > Jürgen Schmidt  wrote:
> > 
> >> On 2/12/13 1:42 PM, Joost Andrae wrote:
> >>> Hi,
> >>>
> >>> in the moment I have just one question in mind:
> >>>
> >>> Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu
> >>> like presentation-minimizer.oxt ?
> >>
> >> well the extensions where we have the source code can be changed by
> >> volunteers. Maybe directly at Apache or as Google code project when
> >> there are license incompatible dependencies.
> >>
> >> Everything else is unclear and I doubt that Oracle has interest in
> >> updating them. And nobody else can do that.
> >>
> >> The best thing would be to start new projects providing similar
> >> functionality but where the code is available and under a proper license.
> >>
> >> Unmaintained extensions are a general problem and should not have
> >> influence on any decision.
> > 
> > There are already reports on incompatabilities with LibO 4.0 and some 
> > existing extensions.  
> > 
> > One thread, for example, at
> > http://forum.openoffice.org/en/forum/viewtopic.php?f=101&t=59595
> > 
> > Might there be possibility for a shim to be written to sit between 
> > Addons.xcu and AOO 4.0?
> 
> I don't know, I haven't looked into it but I know that they have changed
> API's more radical. No surprise for me.
> 

The posting was just for information; it will be interesting to monitor how 
serious a problem it is for their implementation, and how they cope with it.

-- 
Rory O'Farrell 

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Ariel Constenla-Haile]

On Tue, Feb 12, 2013 at 01:42:42PM +0100, Joost Andrae wrote:
> Hi,
> 
> in the moment I have just one question in mind:
> 
> Who's going to adapt the Sun/Oracle extensions that contain
> Addons.xcu like presentation-minimizer.oxt ?

This extension does not provide a toolbar of its own, it uses only
menubar merging.


This is the situation of Oracle extensions:

* No longer maintained:

- Oracle PDF Import Extension (Nr. 1 in popularity)
  http://extensions.openoffice.org/en/project/pdfimport
  2008-Oct-29
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.0"
  Reading the comments on the extension site, it seems quite broken.
  Link to the old OOo mailing list should be removed
  Incompatible license in dependencies

- MySQL Connector for OpenOffice.org (Nr. 13 in popularity)
  http://extensions.openoffice.org/en/project/mysql_connector
  2011-Jan-05
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.1"
  Incompatible license in dependencies

- Oracle Report Builder (Nr. 15 in popularity)
  http://extensions.openoffice.org/en/project/reportdesign
  2010-Dec-14
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.2"
  Incompatible license in dependencies


* Still maintained:

- Oracle Presenter Console (Nr. 22 in popularity)
  http://extensions.openoffice.org/en/project/presenter-screen
  2010-Nov-25
  No Addons.xcu
  Only OpenOffice.org-minimal-version value="3.3"
  Compatible license

- Oracle Presentation Minimizer (Nr. 35 in popularity)
  http://extensions.openoffice.org/en/project/PresentationMinimizer
  2010-Nov-21
  Addons.cxu but *only* with "OfficeMenuBarMerging" node
  Only OpenOffice.org-minimal-version value="2.3"
  Compatible license

- Sun Wiki Publisher
  http://extensions.services.openoffice.org/en/project/wikipublisher
  2009-Jun-09
  Addons.cxu but *only* with "OfficeMenuBarMerging" node
  Only OpenOffice.org-minimal-version value="3.0"
  Compatible license



Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpxmpVJMhKE6.pgp
Description: PGP signature

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti]

On 11/02/2013 Andre Fischer wrote:

On 11.02.2013 17:10, Andrea Pescetti wrote:

A specification may need to leave room for implementation-defined
behavior. Look at the C or C++ standard for example.

Do you know of any example where this is actually a good thing?


It is good for developers who need to implement the standard, but indeed 
not for users!


Regards,
  Andrea.

Re: Calc behavior: result of 0 ^ 0

[Donald Whytock]

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

OT: Calc behavior: result of 0 ^ 0

[Dennis E. Hamilton]

I want to circle back and complete the relationship, if any, between the 
specifications of computations procedures and mathematics.

First, there is no prohibition between defining any number of algorithms as 
computations on computer-representations of numbers.  Mathematics allows all 
sort of functions, including ones that rules can't be written down for.  And 
computational algorithms are some of those that do have written-down rules that 
can be followed by a computer.

The problem that is being seen here is what happens when (1) 
mathematically-defined functions are appealed to as the ideal that the computed 
procedure is intended to approach in some agreeable degree of approximation.  
This shows up in the description that is provided and in the notation and names 
that are used.

When the computational functions are casually identified with mathematical ones 
and nothing more is said, what's left hanging are two things: (1) anything 
about *mathematical* edge cases and places where the mathematical function is 
undefined, and (2) difficulties where limitations of the computer 
representation of arithmetic prevent a result with some expected degree of 
reliability.  (1) can be finessed by providing computationally-convenient 
results for edge cases, and a mathematically-precise definition can be provided 
in definition for the resulting modification.  If a standard dictates such a 
definition, so be it.  

The POWER(x,y) computational function specified for OpenFormula is not the 
mathematical one anyhow.  It is an approximation (sometimes quite good) for 
some limited cases of the mathematically-allowed (x,y).  It can be defined to 
be a (limited) variant covering places where mathematics has nothing to offer, 
so long as there is agreement on what the variant is.

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Monday, February 11, 2013 14:24
To: dev@openoffice.apache.org
Subject: RE: Calc behavior: result of 0 ^ 0

This is not a vote.  There is a statement about what is acceptable 
mathematically that I cannot leave unchallenged.  However, that is different 
than what might or might not be acceptable computationally for a give case and 
I continue to refrain from reiterating any argument about that.

 - Dennis

MATHEMATICAL RIGHT/WRONG-NESS

I'm sorry, I will not accept that 0^0 = 1 as a definition is "not wrong 
mathematically."  It is not right mathematically either.  That it is convenient 
to assume 0^0 = 1 in certain contexts of mathematical *application* is 
different than making it part of the laws of number theory.

The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 
as well or else standard mathematics is inconsistent.  But 0/0 = 1 (or any 
fixed value) makes mathematics unavoidably inconsistent anyhow (as the 
well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 
demonstrate).  There is no escaping the fact that x/0 needs to be undefined and 
that includes 0/0, so 0^0 needs to go along.

Let us not confuse computational expedient or algorithmic simplicity with 
mathematical rigor.  When a computer arithmetic had no provision for coding 
errors and indefinable cases, computational concessions were unavoidable (as is 
the case for integer types in common programming languages).  That is not the 
case with spreadsheets, which do include error values, nor is it the case with 
modern floating-point arithmetic implementations (and the standards they 
satisfy).  

I understand Knuth's argument (and its form in "Concrete Mathematics" and in 
"Art of Computer Programming").  But adding rules to *mathematics* that make 
the standard model of arithmetic inconsistent is not mathematically 
justifiable.  It is very handy, in certain contexts relying on mathematical 
definitions, to define the x^0 case to always be 1 regardless of x.  In the 
case of the binomial theorem, it appears to be an appropriate simplification in 
providing algorithms that are "easier" to reason about in some respect.  That 
context is specifically (a+b)^n by polynomial expansion and in this context the 
particular case of n = 0 and b = -a is perhaps not all that interesting in 
comparison to the serious cases.  

Unfortunately, the computation, POWER(x,0) has no mathematical context.  It is 
not known what POWER(x,0) is being used for, and what the nature of x is. 

Although the standards for C and C++ have division by 0 to be undefined, there 
is not such clarity for pow(x,y).  The ANSI/ISO Standards for C thought of as 
C90 define pow(x,y) to be a domain error if the "result cannot be represented 
when x is zero and y is less than or equal to zero."  Even so, Plauger's 1992 
"The Standard C Library" has pow(x,0.0) return 1.0 so long as x is neither NaN 
nor an Inf.  Harbison and Steele's "C: A Reference Manual", 4th (1995) edition 
simply assert that pow(0.0,0.0) is a domain error.  The ISO C99 specification 
says that "a

RE: Calc behavior: result of 0 ^ 0

[Dennis E. Hamilton]

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has been
a subsequent review and, as Don points out, the discussion has been lengthy
and vocal. 

The objective is to achieve consensus.  I believe it is clear that there is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on 
the Community Wiki at 

.

It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one of the 
implementation-defined results that is permitted by ODF 1.2 OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
permitted as the implementation-defined result.  This is also compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

A patch to implement this proposal is already included in the SVN.  
If the proposal is not accepted as the result of CTR review, the 
Issue will be closed and the patch reverted.
 
 - Dennis

-Original Message-
From: Donald Whytock [mailto:dwhyt...@gmail.com] 
Sent: Tuesday, February 12, 2013 09:20
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

Re: Mwiki is moved into maintenance mode.

[janI]

When I look at the preceding mail in this thread, I see a lot of god
suggestionsbut it seems its all still open, or did I miss a point.

Regarding streamlining Mwiki,
   - there are no real proposals to reduce the number of catagories
   - it seems that everybody agrees on marking old pages (with "outdate" or
"needs update" marker), however the definition of these pages seems to be a
discussion point.

Regarding moving cwiki to wiki.
   - There seemed to be general consensus to move the pages, however there
seems to be a discussion whether to keep Cwiki as "scratch paper".
   - It is also remarkable (at least to me), that there seems to be a big
difference in saying and doingmeaning that our cwiki still get new
pages, even from people who I understood supported a move.

   - For the actual transfer, there seems to several options, from the most
radical (and interesting):  Freeze, build a new wiki (and web), to more or
less do nothing.

I have also noted, that no one have opted to help with this undertaking.

So I assume that, due to the fact that its hard to impossible to see what
to do and be within consensus, it is simpler to do nothing ?

Rgds
Jan I.

Ps. being a developer I do not see the filter (cwiki -> mwiki) as a major
challenge, compared with changing the will/habit of people :-)


On 9 February 2013 19:16, David Gerard  wrote:

> On 8 February 2013 21:52, Andrea Pescetti  wrote:
>
> >> - Move cwiki to mwiki.
> >> this has been discussed/decided earlier, but might need a positive
> >> decision.
>
> > I agree, we can progressively move stuff by turning pages into redirects
> to
> > the MWiki. This may take time but could be the less problematic way (for
> > example, I had created the FOSDEM pages on the cwiki but they should be
> > moved to the mwiki since other FOSDEM pages are archived there). A
> drastic
> > redirect could confuse people who are actively working on some pages,
> like
> > the logo discussions.
> > Is there some filter to allow smooth translation of cwiki syntax?
>
>
> There appear to be no commonly-available filters to move pages in bulk
> from Confluence to MediaWiki, preserving links and formatting.
>
> The general problem is that anyone who moves a wiki from one engine to
> another does the job precisely once, so there's no-one who really
> maintains a good converter script, and the knowledge doesn't
> accumulate (as it does in an ongoing open-source project).
>
> That said, there are people who do want to move from Confluence to
> MediaWiki and end up doing it by a quick hack without the knowledge
> accumulating. So if you do go for an automated method and come up with
> a script, please do put the details and script up on
> http://mediawiki.org , and others with the same problem in the future
> will be grateful.
>
>
> - d.
>

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so
far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.

Has the patch been vetoed, and if so on what basis?

Pedro.



>
> Da: Dennis E. Hamilton 
>A: dev@openoffice.apache.org 
>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'  
>Inviato: Martedì 12 Febbraio 2013 13:11
>Oggetto: RE: Calc behavior: result of 0 ^ 0
> 
>RESOLUTION OF THE PROPOSAL
>
>The proposed change was made under CTR (Commit then Review). There has been
>a subsequent review and, as Don points out, the discussion has been lengthy
>and vocal. 
>
>The objective is to achieve consensus.  I believe it is clear that there is
>no consensus on the proposed change and the proposal fails.
>
>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>and adjust the Bugzilla issue.
>
>THE ESSENCE OF THE PROPOSAL
>
>The proposal is to enact the breaking change as described on 
>the Community Wiki at 
>
>.
>
>It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
>Support.
>
>"Exponentiation
>
>"The current version of Calc produces 1 for POWER(0,0).  This is one of the 
>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>
>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>permitted as the implementation-defined result.  This is also compatible
>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>Spreadsheets. ..."
>
>OUTCOME
>
>The proposed change is tracked in Bugzilla Issue #114430,
>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>
>A patch to implement this proposal is already included in the SVN.  
>If the proposal is not accepted as the result of CTR review, the 
>Issue will be closed and the patch reverted.
>
>- Dennis
>
>-Original Message-
>From: Donald Whytock [mailto:dwhyt...@gmail.com] 
>Sent: Tuesday, February 12, 2013 09:20
>To: dev@openoffice.apache.org
>Subject: Re: Calc behavior: result of 0 ^ 0
>
>...So I got curious, and I paged back in my email archive, and it
>seems this is the biggest AOO dev thread since the graduation vote
>back in early September.
>
>At this point, does anyone care enough about changing the status quo
>as to put up a coherent proposal to be voted on?
>
>Don
>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  wrote:
> Hello;
>
> I don't understand,
>
> I saw a bug (erroneous result returned by a function) and I fixed
> it respecting the standards, thereby enhancing interperability
> with the market leader.
>
> I am aware that Rob has a different point of view here but so

By my count, those who expressed concern about your patch are;

- Me
- Regina
- Andre
- Stuart
- Günter

I think this is a non-trivial amount opposition, including from some
whose opinions you might respect more than mine.

> far neither him nor Stephen Hawking has explained how the change
> would be incorrect and no example where someone has been affected
> by this change has been provided.
>

You can't have it both ways. Your claimed benefit is intrinsically
tied to breaking compatibility with earlier versions of OpenOffice.
You cannot both claim that it has a significant interop benefit and
also claim that it has a negligible backwards compatibility impact.

Regards,

-Rob



> Has the patch been vetoed, and if so on what basis?
>
> Pedro.
>
>
>
>>
>> Da: Dennis E. Hamilton 
>>A: dev@openoffice.apache.org
>>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' 
>>Inviato: Martedì 12 Febbraio 2013 13:11
>>Oggetto: RE: Calc behavior: result of 0 ^ 0
>>
>>RESOLUTION OF THE PROPOSAL
>>
>>The proposed change was made under CTR (Commit then Review). There has been
>>a subsequent review and, as Don points out, the discussion has been lengthy
>>and vocal.
>>
>>The objective is to achieve consensus.  I believe it is clear that there is
>>no consensus on the proposed change and the proposal fails.
>>
>>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>>and adjust the Bugzilla issue.
>>
>>THE ESSENCE OF THE PROPOSAL
>>
>>The proposal is to enact the breaking change as described on
>>the Community Wiki at
>>
>>.
>>
>>It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
>>Support.
>>
>>"Exponentiation
>>
>>"The current version of Calc produces 1 for POWER(0,0).  This is one of the
>>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>>
>>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>>permitted as the implementation-defined result.  This is also compatible
>>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>>Spreadsheets. ..."
>>
>>OUTCOME
>>
>>The proposed change is tracked in Bugzilla Issue #114430,
>>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>>
>>A patch to implement this proposal is already included in the SVN.
>>If the proposal is not accepted as the result of CTR review, the
>>Issue will be closed and the patch reverted.
>>
>>- Dennis
>>
>>-Original Message-
>>From: Donald Whytock [mailto:dwhyt...@gmail.com]
>>Sent: Tuesday, February 12, 2013 09:20
>>To: dev@openoffice.apache.org
>>Subject: Re: Calc behavior: result of 0 ^ 0
>>
>>...So I got curious, and I paged back in my email archive, and it
>>seems this is the biggest AOO dev thread since the graduation vote
>>back in early September.
>>
>>At this point, does anyone care enough about changing the status quo
>>as to put up a coherent proposal to be voted on?
>>
>>Don
>>
>>
>>
>>

Select column in Calc

[Galileo Teco Juárez]

Select column in Calc

as I can select from Python
the value of a particular column in Calc

or is necessary for the user to select?

regards

-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: Select column in Calc

[Galileo Teco Juárez]

sorry mistake
of translations

this is the real question

*how can i select the value of  a colum in a specific cell. ie, select the
value of 10 from the B4 cell*


2013/2/12 Galileo Teco Juárez 

> Select column in Calc
>
> as I can select from Python
> the value of a particular column in Calc
>
> or is necessary for the user to select?
>
> regards
>
> --
> *Galileo Teco Juarez*
> *Web:* http://80bits.wordpress.com
> *Twitter:* @genitalico 
> *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
>



-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

Ugh..

I haven't been following this thread at all ...

I unsubscribed from the -dev list because I always ended up in absurd 
discussions
and there was not much technical content either.

I suspected it would be bikeshed.org material but in any case let me make 
things clear.

- 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 
1,
however when you consider the limit when x tends to -0, the limit is infinite. 
This
is called Indeterminate Form.
    http://en.wikipedia.org/wiki/Indeterminate_form


If you wonder, I failed a math quiz in the University for blindly using the 
value my
HP Calculator gave (1), so I am sort of glad that this has been a free 
educational
experience for some of you.

The implementation in OOo doesn't return explicitly a 1 value but instead 
relies on
what the libc pow() function does. The standard libc lets you do 0^0 but it 
also lets
you divide by zero without aborting . Modern IEEE 754 2008 implements three
power functions pow(), pown() and powr(), powr() being the most similar to the 
real
mathematical function.

The implementation is non intrusive: I added a wrapper in SAL that behaves like
powr() so that we don't affect other formulas that use pow() internally. So far
no one has given an example where shooting yourself in the foot by expecting
pow(0,0) to be 1 is a good thing.

I am gladly surprised that Excel does the same, but the real reason why I went
ahead and implemented a solution is to do the right thing, mathematically
speaking. Mathematical correctness is not something that IMHO pertains to
democracy.

Sure it would be nice to have an option to adjust your results for
mathematically undetermined cases like 0^0 or 0/0 but unless you are planning
to implement it don't expected such features to appear magically either.

I would be extremely disappointed to have to revert a correct fix for 
non-technical
reasons. I think I would lose any motivation to improve other functions in Calc.

Pedro.

RE: Calc behavior: result of 0 ^ 0

[Dennis E. Hamilton]

The current behavior is in compliance with the ODF 1.2 OpenFormula
specification.  In that context, the current result for POWER(0,0) is not a
bug.

The fact that 0^0 is not defined (nor are 0^-n values) in mathematics
(although some define them for various conveniences) does not mean it can't
be defined in a computational procedure, which is what POWER(x,y) specifies
characteristics of.  The discrepancy with respect to mathematics is
troublesome, but only if the computational procedure's definition is relied
upon as a mathematical fact (e.g., in proving theorems, such as 0/0 = 1).

I prefer Pedro's solution, which is to produce an error value for POWER(0,0)
and also have greater interoperability with another important
implementation.  That is also in compliance with the ODF 1.2 OpenFormula
specification.  It also prevents the inference of unsupportable mathematical
facts by computational definition.

There is clearly no consensus to making that change.  This is what CTR is
about.  It would have been what RTC were about, had the proposal been made
before the patch.  This thread is the R part either way.

I don't recommend having a ballot on the proposed change, and I don't know
what (non-binding) vote I would cast were one held.  

 - Dennis

-Original Message-
From: Pedro Giffuni [mailto:p...@apache.org] 
Sent: Tuesday, February 12, 2013 11:12
To: dennis.hamil...@acm.org; dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so
far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.

Has the patch been vetoed, and if so on what basis?

Pedro.



>
> Da: Dennis E. Hamilton 
>A: dev@openoffice.apache.org 
>Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'
 
>Inviato: Martedì 12 Febbraio 2013 13:11
>Oggetto: RE: Calc behavior: result of 0 ^ 0
> 
>RESOLUTION OF THE PROPOSAL
>
>The proposed change was made under CTR (Commit then Review). There has been
>a subsequent review and, as Don points out, the discussion has been lengthy
>and vocal. 
>
>The objective is to achieve consensus.  I believe it is clear that there is
>no consensus on the proposed change and the proposal fails.
>
>I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
>this up.  If the lack of consensus is affirmed, Pedro can revert the change
>and adjust the Bugzilla issue.
>
>THE ESSENCE OF THE PROPOSAL
>
>The proposal is to enact the breaking change as described on 
>the Community Wiki at 
>
>.
>
>It is under Changes that Impact Backward Compatibility, Calc and
OpenFormula
>Support.
>
>"Exponentiation
>
>"The current version of Calc produces 1 for POWER(0,0).  This is one of the

>implementation-defined results that is permitted by ODF 1.2 OpenFormula.
>
>"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
>permitted as the implementation-defined result.  This is also compatible
>with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>Spreadsheets. ..."
>
>OUTCOME
>
>The proposed change is tracked in Bugzilla Issue #114430,
>< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.
>
>A patch to implement this proposal is already included in the SVN.  
>If the proposal is not accepted as the result of CTR review, the 
>Issue will be closed and the patch reverted.
>
>- Dennis
>
>-Original Message-
>From: Donald Whytock [mailto:dwhyt...@gmail.com] 
>Sent: Tuesday, February 12, 2013 09:20
>To: dev@openoffice.apache.org
>Subject: Re: Calc behavior: result of 0 ^ 0
>
>...So I got curious, and I paged back in my email archive, and it
>seems this is the biggest AOO dev thread since the graduation vote
>back in early September.
>
>At this point, does anyone care enough about changing the status quo
>as to put up a coherent proposal to be voted on?
>
>Don
>
>
>
>

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 4:17 PM, Pedro Giffuni  wrote:
> Ugh..
>
> I haven't been following this thread at all ...
>

I recommend reading the archives then, since every argument that could
be made, has been made already.

-Rob

> I unsubscribed from the -dev list because I always ended up in absurd 
> discussions
> and there was not much technical content either.
>
> I suspected it would be bikeshed.org material but in any case let me make 
> things clear.
>
> - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 
> is 1,
> however when you consider the limit when x tends to -0, the limit is 
> infinite. This
> is called Indeterminate Form.
> http://en.wikipedia.org/wiki/Indeterminate_form
>
>
> If you wonder, I failed a math quiz in the University for blindly using the 
> value my
> HP Calculator gave (1), so I am sort of glad that this has been a free 
> educational
> experience for some of you.
>
> The implementation in OOo doesn't return explicitly a 1 value but instead 
> relies on
> what the libc pow() function does. The standard libc lets you do 0^0 but it 
> also lets
> you divide by zero without aborting . Modern IEEE 754 2008 implements three
> power functions pow(), pown() and powr(), powr() being the most similar to 
> the real
> mathematical function.
>
> The implementation is non intrusive: I added a wrapper in SAL that behaves 
> like
> powr() so that we don't affect other formulas that use pow() internally. So 
> far
> no one has given an example where shooting yourself in the foot by expecting
> pow(0,0) to be 1 is a good thing.
>
> I am gladly surprised that Excel does the same, but the real reason why I went
> ahead and implemented a solution is to do the right thing, mathematically
> speaking. Mathematical correctness is not something that IMHO pertains to
> democracy.
>
> Sure it would be nice to have an option to adjust your results for
> mathematically undetermined cases like 0^0 or 0/0 but unless you are planning
> to implement it don't expected such features to appear magically either.
>
> I would be extremely disappointed to have to revert a correct fix for 
> non-technical
> reasons. I think I would lose any motivation to improve other functions in 
> Calc.
>
> Pedro.

Re: Calc behavior: result of 0 ^ 0

[Marcus (OOo)]

Am 02/12/2013 08:46 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  wrote:

Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so


By my count, those who expressed concern about your patch are;

- Me
- Regina
- Andre
- Stuart
- Günter

I think this is a non-trivial amount opposition, including from some
whose opinions you might respect more than mine.


far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.



You can't have it both ways. Your claimed benefit is intrinsically
tied to breaking compatibility with earlier versions of OpenOffice.
You cannot both claim that it has a significant interop benefit and
also claim that it has a negligible backwards compatibility impact.


IMHO nobody wrote that there is a significant improvement in direction 
of better compatibility. Of course it's just a step of 1 per mill.


Some facts from the issue itself:

- open since 2010-09-09
- only 2 votes (from author of comment #2)
- only 4 mail addresses on CC (all from apache)
- only 3 comments (before our discussion started)

From my point of view this issue is of very low interest for others - 
compared with other issues.


But as nobody has delievered a valid use case, we're talking about a 
theoretically possibility of broken spreadsheets and therefore spent 
already too much of our time for this discussion.


I propose to keep the change as it is now.

My 2 ct.

Marcus





Has the patch been vetoed, and if so on what basis?

Pedro.





Da: Dennis E. Hamilton
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'
Inviato: Martedì 12 Febbraio 2013 13:11
Oggetto: RE: Calc behavior: result of 0 ^ 0

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has been
a subsequent review and, as Don points out, the discussion has been lengthy
and vocal.

The objective is to achieve consensus.  I believe it is clear that there is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on
the Community Wiki at

.

It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one of the
implementation-defined results that is permitted by ODF 1.2 OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
permitted as the implementation-defined result.  This is also compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
<  https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

A patch to implement this proposal is already included in the SVN.
If the proposal is not accepted as the result of CTR review, the
Issue will be closed and the patch reverted.

- Dennis

-Original Message-
From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Tuesday, February 12, 2013 09:20
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)  wrote:
> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni  wrote:
>>>
>>> Hello;
>>>
>>> I don't understand,
>>>
>>> I saw a bug (erroneous result returned by a function) and I fixed
>>> it respecting the standards, thereby enhancing interperability
>>> with the market leader.
>>>
>>> I am aware that Rob has a different point of view here but so
>>
>>
>> By my count, those who expressed concern about your patch are;
>>
>> - Me
>> - Regina
>> - Andre
>> - Stuart
>> - Günter
>>
>> I think this is a non-trivial amount opposition, including from some
>> whose opinions you might respect more than mine.
>>
>>> far neither him nor Stephen Hawking has explained how the change
>>> would be incorrect and no example where someone has been affected
>>> by this change has been provided.
>>>
>>
>> You can't have it both ways. Your claimed benefit is intrinsically
>> tied to breaking compatibility with earlier versions of OpenOffice.
>> You cannot both claim that it has a significant interop benefit and
>> also claim that it has a negligible backwards compatibility impact.
>
>
> IMHO nobody wrote that there is a significant improvement in direction of
> better compatibility. Of course it's just a step of 1 per mill.
>
> Some facts from the issue itself:
>
> - open since 2010-09-09
> - only 2 votes (from author of comment #2)
> - only 4 mail addresses on CC (all from apache)
> - only 3 comments (before our discussion started)
>
> From my point of view this issue is of very low interest for others -
> compared with other issues.
>
> But as nobody has delievered a valid use case, we're talking about a
> theoretically possibility of broken spreadsheets and therefore spent already
> too much of our time for this discussion.
>

Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
right now that would be break if we changed the behavior of 0^0.

Regards,

-Rob

> I propose to keep the change as it is now.
>
> My 2 ct.
>
> Marcus
>
>
>
>
>
>>> Has the patch been vetoed, and if so on what basis?
>>>
>>> Pedro.
>>>
>>>
>>>
 
 Da: Dennis E. Hamilton
 A: dev@openoffice.apache.org
 Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
 Giffuni'
 Inviato: Martedì 12 Febbraio 2013 13:11
 Oggetto: RE: Calc behavior: result of 0 ^ 0

 RESOLUTION OF THE PROPOSAL

 The proposed change was made under CTR (Commit then Review). There has
 been
 a subsequent review and, as Don points out, the discussion has been
 lengthy
 and vocal.

 The objective is to achieve consensus.  I believe it is clear that there
 is
 no consensus on the proposed change and the proposal fails.

 I can't speak for the AOO PMC.  It would be useful if Andreas helped
 wrap
 this up.  If the lack of consensus is affirmed, Pedro can revert the
 change
 and adjust the Bugzilla issue.

 THE ESSENCE OF THE PROPOSAL

 The proposal is to enact the breaking change as described on
 the Community Wiki at

 
 .

 It is under Changes that Impact Backward Compatibility, Calc and
 OpenFormula
 Support.

 "Exponentiation

 "The current version of Calc produces 1 for POWER(0,0).  This is one of
 the
 implementation-defined results that is permitted by ODF 1.2 OpenFormula.

 "It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
 permitted as the implementation-defined result.  This is also compatible
 with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
 Spreadsheets. ..."

 OUTCOME

 The proposed change is tracked in Bugzilla Issue #114430,
 <  https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

 A patch to implement this proposal is already included in the SVN.
 If the proposal is not accepted as the result of CTR review, the
 Issue will be closed and the patch reverted.

 - Dennis

 -Original Message-
 From: Donald Whytock [mailto:dwhyt...@gmail.com]
 Sent: Tuesday, February 12, 2013 09:20
 To: dev@openoffice.apache.org
 Subject: Re: Calc behavior: result of 0 ^ 0

 ...So I got curious, and I paged back in my email archive, and it
 seems this is the biggest AOO dev thread since the graduation vote
 back in early September.

 At this point, does anyone care enough about changing the status quo
 as to put up a coherent proposal to be voted on?

 Don

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest]

Le 12/02/2013 22:31, Marcus (OOo) a écrit :

Some facts from the issue itself:

- open since 2010-09-09
- only 2 votes (from author of comment #2)


Now 4 with mines.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest]

Le 12/02/2013 00:45, Fred Ollinger a écrit :

Another idea is to return 1, but have a popup which says: "We are
returning 1 to 0^0 due to backwards compatability, but we this might
change in the fure. Click here to never show this warning again and
continue to return 1. Also, you can use strict (or whatever) to flag
these warnings as errors."


That's a lot of code for such a small occurrence.
Isn't there more urgents issues? A mere error message is good enough.

Hagar

Fwd:

[Drew Jensen]

http://lasvegassuites.org/downrightawesome.com/nanw54.php?s=ot

Fwd:

[Drew Jensen]

http://lasvegassuites.org/downrightawesome.com/nanw54.php?s=ot

Re: Calc behavior: result of 0 ^ 0

[Marcus (OOo)]

Am 02/12/2013 10:39 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)  wrote:

Am 02/12/2013 08:46 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni   wrote:


Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so



By my count, those who expressed concern about your patch are;

- Me
- Regina
- Andre
- Stuart
- Günter

I think this is a non-trivial amount opposition, including from some
whose opinions you might respect more than mine.


far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.



You can't have it both ways. Your claimed benefit is intrinsically
tied to breaking compatibility with earlier versions of OpenOffice.
You cannot both claim that it has a significant interop benefit and
also claim that it has a negligible backwards compatibility impact.



IMHO nobody wrote that there is a significant improvement in direction of
better compatibility. Of course it's just a step of 1 per mill.

Some facts from the issue itself:

- open since 2010-09-09
- only 2 votes (from author of comment #2)
- only 4 mail addresses on CC (all from apache)
- only 3 comments (before our discussion started)

 From my point of view this issue is of very low interest for others -
compared with other issues.

But as nobody has delievered a valid use case, we're talking about a
theoretically possibility of broken spreadsheets and therefore spent already
too much of our time for this discussion.



Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
right now that would be break if we changed the behavior of 0^0.


And what is your *serious* use case for this spreadsheet? Beside to use 
it as a test document? And you have it created before the discussion has 
started?


I'll ask my question again:
Is there more than one who can deliever a *serious and valid use case*?

Thanks

Marcus




I propose to keep the change as it is now.

My 2 ct.

Marcus






Has the patch been vetoed, and if so on what basis?

Pedro.





Da: Dennis E. Hamilton
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
Giffuni'
Inviato: Martedì 12 Febbraio 2013 13:11
Oggetto: RE: Calc behavior: result of 0 ^ 0

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has
been
a subsequent review and, as Don points out, the discussion has been
lengthy
and vocal.

The objective is to achieve consensus.  I believe it is clear that there
is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped
wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the
change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on
the Community Wiki at


.

It is under Changes that Impact Backward Compatibility, Calc and
OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one of
the
implementation-defined results that is permitted by ODF 1.2 OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
permitted as the implementation-defined result.  This is also compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
<   https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

A patch to implement this proposal is already included in the SVN.
If the proposal is not accepted as the result of CTR review, the
Issue will be closed and the patch reverted.

- Dennis

-Original Message-
From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Tuesday, February 12, 2013 09:20
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don

New page: Contributing Code

[Rob Weir]

We had a thread before Christmas discussing code contributions and
best practices for how someone could contribute code to multiple
projects, e.g., AOO and LO.

I've written this up, along with more general remarks on contributing
code on a new page:

http://openoffice.apache.org/contributing-code.html

Please take a look and let me know of any needed/recommended changes.

Thanks,

-Rob

[DEV] Compiler/build error

[Fernando Martinez]

Hello Team,

 

I followed the steps at
http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_ste
p  to build AOO but I get an error after about 2 hours of building. The
error reads as follow;

 

BUILD FAILED

C:\source\aoo-trunk\main\hsqldb\wntmsci12.pro\misc\build\hsqldb\build\build.
xml:302: Compile failed; see the compiler error output for details.

 

Total time: 5 seconds

dmake:  Error code 1, while making
'./wntmsci12.pro/misc/build/so_built_so_hsqldb'

 

1 module(s):

hsqldb

need(s) to be rebuilt

 

Reason(s):

 

ERROR: error 65280 occurred while making
/cygdrive/c/source/aoo-trunk/main/hsqldb

 

When you have fixed the errors in that module you can resume the build by
running:

 

build --all:hsqldb

 

 

 

I have not changed any code. I just downloaded from the website and build it
to get an idea on how AOO works.

 

If anybody could please help with this error and also tell me how to check
the compiler error output.

My environment is: Windows 8 Pro x64, AMD Ahton II X4 650, and 8GB memory.

I any more information is needed, please let me know.

 

Thank you

 

 

Fernando Martinez

Email: fernando.marti...@msn.com

 

 

 

Completed Introduction to Contributing to Apache OpenOffice Module

[Maarten Kesselaers]

Hello,

My name is Maarten Kesselaers.
I'm from Belgium and work as a project manager and EDI exchange expert.

I used to code (Java, C++ and DOM) and helped other developers on forums, but 
I'm up to a new challenge.
That's why I would like to help make AOO better.

Kind regards,
Maarten

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)  wrote:
> Am 02/12/2013 10:39 PM, schrieb Rob Weir:
>
>> On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)
>> wrote:
>>>
>>> Am 02/12/2013 08:46 PM, schrieb Rob Weir:
>>>
 On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni   wrote:
>
>
> Hello;
>
> I don't understand,
>
> I saw a bug (erroneous result returned by a function) and I fixed
> it respecting the standards, thereby enhancing interperability
> with the market leader.
>
> I am aware that Rob has a different point of view here but so



 By my count, those who expressed concern about your patch are;

 - Me
 - Regina
 - Andre
 - Stuart
 - Günter

 I think this is a non-trivial amount opposition, including from some
 whose opinions you might respect more than mine.

> far neither him nor Stephen Hawking has explained how the change
> would be incorrect and no example where someone has been affected
> by this change has been provided.
>

 You can't have it both ways. Your claimed benefit is intrinsically
 tied to breaking compatibility with earlier versions of OpenOffice.
 You cannot both claim that it has a significant interop benefit and
 also claim that it has a negligible backwards compatibility impact.
>>>
>>>
>>>
>>> IMHO nobody wrote that there is a significant improvement in direction of
>>> better compatibility. Of course it's just a step of 1 per mill.
>>>
>>> Some facts from the issue itself:
>>>
>>> - open since 2010-09-09
>>> - only 2 votes (from author of comment #2)
>>> - only 4 mail addresses on CC (all from apache)
>>> - only 3 comments (before our discussion started)
>>>
>>>  From my point of view this issue is of very low interest for others -
>>> compared with other issues.
>>>
>>> But as nobody has delievered a valid use case, we're talking about a
>>> theoretically possibility of broken spreadsheets and therefore spent
>>> already
>>> too much of our time for this discussion.
>>>
>>
>> Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
>> right now that would be break if we changed the behavior of 0^0.
>
>
> And what is your *serious* use case for this spreadsheet? Beside to use it
> as a test document? And you have it created before the discussion has
> started?
>

The spreadsheet I am thinking about is over 4 years old, has been
published and is used by others as well.

I'd also point out that asking your question on this list is not
really telling you anything.  We've had 37 million downloads of AOO
3.4.  Only 400 people subscribe to this list.  So I don't think this
is great evidence for saying it has zero impact.

But again, if you think that situation never comes up in real use,
then let's not make the change, since it would have no benefit.

-Rob

> I'll ask my question again:
> Is there more than one who can deliever a *serious and valid use case*?
>
> Thanks
>
> Marcus
>
>
>
>
>>> I propose to keep the change as it is now.
>>>
>>> My 2 ct.
>>>
>>> Marcus
>>>
>>>
>>>
>>>
>>>
> Has the patch been vetoed, and if so on what basis?
>
> Pedro.
>
>
>
>> 
>> Da: Dennis E. Hamilton
>> A: dev@openoffice.apache.org
>> Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
>> Giffuni'
>> Inviato: Martedì 12 Febbraio 2013 13:11
>> Oggetto: RE: Calc behavior: result of 0 ^ 0
>>
>> RESOLUTION OF THE PROPOSAL
>>
>> The proposed change was made under CTR (Commit then Review). There has
>> been
>> a subsequent review and, as Don points out, the discussion has been
>> lengthy
>> and vocal.
>>
>> The objective is to achieve consensus.  I believe it is clear that
>> there
>> is
>> no consensus on the proposed change and the proposal fails.
>>
>> I can't speak for the AOO PMC.  It would be useful if Andreas helped
>> wrap
>> this up.  If the lack of consensus is affirmed, Pedro can revert the
>> change
>> and adjust the Bugzilla issue.
>>
>> THE ESSENCE OF THE PROPOSAL
>>
>> The proposal is to enact the breaking change as described on
>> the Community Wiki at
>>
>>
>> 
>> .
>>
>> It is under Changes that Impact Backward Compatibility, Calc and
>> OpenFormula
>> Support.
>>
>> "Exponentiation
>>
>> "The current version of Calc produces 1 for POWER(0,0).  This is one
>> of
>> the
>> implementation-defined results that is permitted by ODF 1.2
>> OpenFormula.
>>
>> "It is proposed to change POWER(0,0) to result in #VALUE!.  This is
>> also
>> permitted as the implementation-defined result.  This is also
>> compatible
>> with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
>> Spreadsheets. ..."
>>
>>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Hagar Delest]

Le 12/02/2013 13:05, Rob Weir a écrit :

I don't know.  I was asking a question.  But I think this is an
important question:  Why would an extension author not update their
extension for AOO 4.0?  Some hypothetical answers:

1) The extension is unmaintained


One of the top reasons I guess. I myslef made extensions for my own use. I 
would have to tweak it. Since I've done them some time ago, I would have to 
dive again in specifications to make the changes.



2)  The author cannot be located or we have no way to notify them of changes


May be related to 1).



3) It is not clear to the author what technical changes are needed


Was a communication plan issued to warn the authors about that?
Don't tell me the release notes are for that. Almost nobody read the release 
notes (at least until the end).
I guess that many extensions mlaintainers don't follow this dev list at all.



4) There is not sufficient calendar time for the extension author to
make the needed changes before we release, or the work required is too
much for the author to fit into his schedule


May be related to 3). Without any warning, few chances to implement any change.



5) The author attempts changes but they don't work or they introduce
new problems


Rather unlikely.



6) The results of not making the changes is not clear, so the author
mistakenly thinks they are optional changes


Or he just don't care anymore about the extension. So it needs to be taken over 
by someone else. But how we could know that?



7) Author has technical or account issues with the extensions website
and is unable to upload a new version, and does not know where to get
help.

These are all possible concerns, but I think most of them can be
managed with good communications and advance notice.

There is also the possibility of:

8) Inconvenience -- it is natural for anyone to complain about needing
to do additional work where they don't see the advantage.  So it is
natural that we will expect complaints, followed in the end by
conformance with the required changes.


Yes but what about the loss of confidence from users who will be first 
frustrated by an upgrade that breaks more things than fix them? Then they will 
have to do some homework to find out what the problem is (again, don't tell me 
about release notes). And wait in the end for someone to fix it. What if they 
do need their extensions meanwhile?

One side aspect: what about extension update warning? If a new version is 
detected but the user doesn't upgrade to 4.0, are we sure that the minimal 
version will be checked first, before the new extension is installed by the 
user? Has he to download it before being warned that it's in fact not 
compatible with his current AOO/OOo version?

I'm not against the change. I'm for a controlled one, that has no impact on 
end-users. So the main points are: communication to the extensions maintainers 
(what about the extensions hosted on their personal pages and not on 
sourceforge?), preparation of the updates and transition period.

Hagar

Re: Calc behavior: result of 0 ^ 0

[Marcus (OOo)]

Am 02/12/2013 11:22 PM, schrieb Rob Weir:

On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)  wrote:

Am 02/12/2013 10:39 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)
wrote:


Am 02/12/2013 08:46 PM, schrieb Rob Weir:


On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuniwrote:



Hello;

I don't understand,

I saw a bug (erroneous result returned by a function) and I fixed
it respecting the standards, thereby enhancing interperability
with the market leader.

I am aware that Rob has a different point of view here but so




By my count, those who expressed concern about your patch are;

- Me
- Regina
- Andre
- Stuart
- Günter

I think this is a non-trivial amount opposition, including from some
whose opinions you might respect more than mine.


far neither him nor Stephen Hawking has explained how the change
would be incorrect and no example where someone has been affected
by this change has been provided.



You can't have it both ways. Your claimed benefit is intrinsically
tied to breaking compatibility with earlier versions of OpenOffice.
You cannot both claim that it has a significant interop benefit and
also claim that it has a negligible backwards compatibility impact.




IMHO nobody wrote that there is a significant improvement in direction of
better compatibility. Of course it's just a step of 1 per mill.

Some facts from the issue itself:

- open since 2010-09-09
- only 2 votes (from author of comment #2)
- only 4 mail addresses on CC (all from apache)
- only 3 comments (before our discussion started)

  From my point of view this issue is of very low interest for others -
compared with other issues.

But as nobody has delievered a valid use case, we're talking about a
theoretically possibility of broken spreadsheets and therefore spent
already
too much of our time for this discussion.



Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
right now that would be break if we changed the behavior of 0^0.



And what is your *serious* use case for this spreadsheet? Beside to use it
as a test document? And you have it created before the discussion has
started?



The spreadsheet I am thinking about is over 4 years old, has been
published and is used by others as well.


Maybe, but what we still don't know is the use case. Why don't you come 
up with more details?



I'd also point out that asking your question on this list is not
really telling you anything.  We've had 37 million downloads of AOO
3.4.  Only 400 people subscribe to this list.  So I don't think this
is great evidence for saying it has zero impact.

But again, if you think that situation never comes up in real use,
then let's not make the change, since it would have no benefit.


Sorry, I don't understand why the change should not been made? Just to 
keep the implementation forever? Honestly, your sentence makes no sense 
to me.


OK, to make it clear:
Do what you want, discuss on and on. My standpoint is that this is a 
ridicolous discussion and the change non-serious.


For me this is EOD.

Good night.

Marcus




I'll ask my question again:
Is there more than one who can deliever a *serious and valid use case*?

Thanks

Marcus





I propose to keep the change as it is now.

My 2 ct.

Marcus






Has the patch been vetoed, and if so on what basis?

Pedro.





Da: Dennis E. Hamilton
A: dev@openoffice.apache.org
Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro
Giffuni'
Inviato: Martedì 12 Febbraio 2013 13:11
Oggetto: RE: Calc behavior: result of 0 ^ 0

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has
been
a subsequent review and, as Don points out, the discussion has been
lengthy
and vocal.

The objective is to achieve consensus.  I believe it is clear that
there
is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped
wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the
change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on
the Community Wiki at



.

It is under Changes that Impact Backward Compatibility, Calc and
OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one
of
the
implementation-defined results that is permitted by ODF 1.2
OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is
also
permitted as the implementation-defined result.  This is also
compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
.

A patch to implement this proposal is already included in the SVN.
If the proposal is not accepted as the result of 

Re: Calc behavior: result of 0 ^ 0

[Hagar Delest]

Le 12/02/2013 23:22, Rob Weir a écrit :

But again, if you think that situation never comes up in real use,
then let's not make the change, since it would have no benefit.


You don't seem to see the benefit of the change: warn the user that there is 
something weird in the formula that requires his attention.
Perhaps that there are users getting wrong results because a value is returned 
and therefore hides the problem.

Hagar

Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work

[James Teh]

Hi all,

I'm one of the lead developers of NVDA. It is fantastic to see this work 
progressing so well. It is something for which we (and our users) have 
been hoping/waiting for years. I am very impressed with the progress so far.


I eagerly await the decision regarding how issues should be reported and 
would strongly urge for the bug tracker. Emails tend to get lost and are 
much harder to triage or keep track of, especially for issues which 
won't be addressed immediately. This is especially true on a high 
traffic, broad list such as this one. Personally, I'm far likely to 
report bugs via a tracker, as it means the time spent gathering 
information isn't wasted and I can easily track the status of the issue 
and provide more info as needed.


Thanks,
Jamie

On 10/02/2013 4:05 AM, V Stuart Foote wrote:

Steve,

Nothing substantive yet in working through the Windows build of the ia2 branch. 
Should we build against Linux and OSX and be testing for impact on ATK/AT-SPI 
and NSAccessibility User Interface?

And, with QA and testing of the ia2 branch proceeding what mechanism should 
folks use for reporting and tracking issues on the ia2 branch builds?

Should we stay with PM and ML exchanges, or start to use Bugzilla at 
issues.apache.org/ooo?  I believe that starting with BZ tracking now  provides 
continuity upon merge of branch back into AOO4.00.

And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2 
release planning wiki that  QA participants and casual users report in Bugzilla 
categorized for consistency as against:

Product: UI
Component: AccessBridge
Version: AOO4.00-dev

Stuart

=-=-=

Sidebar--the legacy IAccessible2 enhancement bug could probably be revised
https://issues.apache.org/ooo/show_bug.cgi?id=107914

And here is a generic BZ search for accessibility issues
https://issues.apache.org/ooo/buglist.cgi?query_format=advanced&resolution=---&short_desc=msaa%20accessible%20iaccessible%20iaccessible2%20accessibility&short_desc_type=anywordssubstr&order=component%2Cpriority%2Cbug_severity&query_based_on=




--
James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
Phone: +61 7 5667 8372

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest  wrote:
> Le 12/02/2013 23:22, Rob Weir a écrit :
>
>> But again, if you think that situation never comes up in real use,
>> then let's not make the change, since it would have no benefit.
>
>
> You don't seem to see the benefit of the change: warn the user that there is
> something weird in the formula that requires his attention.
> Perhaps that there are users getting wrong results because a value is
> returned and therefore hides the problem.
>

And your solution is to give users error messages where they do not
have a problem ?!  What if they the examine the formula and find out
that it is exactly what they wanted?  Your solution would force them
to rewrite their formulas for no good reason.

Again this is like giving an spelling error for "their" because some
users might confuse it with "there".

-Rob


> Hagar

Re: New page: Contributing Code

[janI]

On 12 February 2013 23:19, Rob Weir  wrote:

> We had a thread before Christmas discussing code contributions and
> best practices for how someone could contribute code to multiple
> projects, e.g., AOO and LO.
>
> I've written this up, along with more general remarks on contributing
> code on a new page:
>
> http://openoffice.apache.org/contributing-code.html
>
> Please take a look and let me know of any needed/recommended changes.
>
Nice page, however I do not like "We're not interested in large
code-dumps.", I would prefer if you wrote something like:

"Integrating large code-dumps requires cooperation and cannot be done as a
simple commit, therefore we urge you to contact us on how we commonly can
achieve the best result".

When I read the page, it sounds as if we are only interested in small code
patches, and that cannot be correct. Of course if someone has written a
function (maybe 1.000 lines), we are highly interested.  If someone has
written a complete new module (like a photo editor), then we need to talk.

As an example my l10n tools are about 1.100 lines which I am sure is
something we want (I know I am committer, but see it as an example).

rgds
Jan I.



> Thanks,
>
> -Rob
>

Re: New page: Contributing Code

[Rob Weir]

On Tue, Feb 12, 2013 at 5:47 PM, janI  wrote:
> On 12 February 2013 23:19, Rob Weir  wrote:
>
>> We had a thread before Christmas discussing code contributions and
>> best practices for how someone could contribute code to multiple
>> projects, e.g., AOO and LO.
>>
>> I've written this up, along with more general remarks on contributing
>> code on a new page:
>>
>> http://openoffice.apache.org/contributing-code.html
>>
>> Please take a look and let me know of any needed/recommended changes.
>>
> Nice page, however I do not like "We're not interested in large
> code-dumps.", I would prefer if you wrote something like:
>
> "Integrating large code-dumps requires cooperation and cannot be done as a
> simple commit, therefore we urge you to contact us on how we commonly can
> achieve the best result".
>

Maybe there is a better of way of phrasing this, but we really don't
want code dumps.  In other words, we're not interested in having a new
large body of code to maintain.  A large code base requires developers
to maintain it.  If it is a code dump then this dilutes our attention
on the existing code base.  So new large contributions really need to
come along with developers to help maintain the code.


> When I read the page, it sounds as if we are only interested in small code
> patches, and that cannot be correct. Of course if someone has written a
> function (maybe 1.000 lines), we are highly interested.  If someone has
> written a complete new module (like a photo editor), then we need to talk.
>
> As an example my l10n tools are about 1.100 lines which I am sure is
> something we want (I know I am committer, but see it as an example).
>

Maybe I need to define "code dump" then.  I don't think what you are
doing is "code dump",  It is large, but I assume that you don't just
contribute it and disappear.

So help integrating is one part.  For a bug fix is a smaller
enhancement, maybe that is all we need.  But suppose someone wants to
contribute something large, like a complete new application as part of
the suite?

Let's see if we agree on that general idea.  If so I can find a
clearer way of expressing it.

-Rob

> rgds
> Jan I.
>
>
>
>> Thanks,
>>
>> -Rob
>>

Re: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest  wrote:
> Le 12/02/2013 13:05, Rob Weir a écrit :
>
>> I don't know.  I was asking a question.  But I think this is an
>> important question:  Why would an extension author not update their
>> extension for AOO 4.0?  Some hypothetical answers:
>>
>> 1) The extension is unmaintained
>
>
> One of the top reasons I guess. I myslef made extensions for my own use. I
> would have to tweak it. Since I've done them some time ago, I would have to
> dive again in specifications to make the changes.
>
>
>
>> 2)  The author cannot be located or we have no way to notify them of
>> changes
>
>
> May be related to 1).
>
>
>
>> 3) It is not clear to the author what technical changes are needed
>
>
> Was a communication plan issued to warn the authors about that?
> Don't tell me the release notes are for that. Almost nobody read the release
> notes (at least until the end).
> I guess that many extensions mlaintainers don't follow this dev list at all.
>

No, no.  The Release Notes are just what I proposed to collect these
kinds of items.  If we actually make breaking changes I'd expect to
see a bigger attempt to reach out to extension authors:

1) blog post

2) post to API list and forum

3) maybe banner on the extensions website itself

But this would make more sense after the changes are made and when we
can point to complete instructions as well as developer snaphot build
that the author can use to test their modifications.

What is not clear is how much notice is needed.  1 month?  2 months?  More?

-Rob


>
>
>> 4) There is not sufficient calendar time for the extension author to
>> make the needed changes before we release, or the work required is too
>> much for the author to fit into his schedule
>
>
> May be related to 3). Without any warning, few chances to implement any
> change.
>
>
>
>> 5) The author attempts changes but they don't work or they introduce
>> new problems
>
>
> Rather unlikely.
>
>
>
>> 6) The results of not making the changes is not clear, so the author
>> mistakenly thinks they are optional changes
>
>
> Or he just don't care anymore about the extension. So it needs to be taken
> over by someone else. But how we could know that?
>
>
>
>> 7) Author has technical or account issues with the extensions website
>> and is unable to upload a new version, and does not know where to get
>> help.
>>
>> These are all possible concerns, but I think most of them can be
>> managed with good communications and advance notice.
>>
>> There is also the possibility of:
>>
>> 8) Inconvenience -- it is natural for anyone to complain about needing
>> to do additional work where they don't see the advantage.  So it is
>> natural that we will expect complaints, followed in the end by
>> conformance with the required changes.
>
>
> Yes but what about the loss of confidence from users who will be first
> frustrated by an upgrade that breaks more things than fix them? Then they
> will have to do some homework to find out what the problem is (again, don't
> tell me about release notes). And wait in the end for someone to fix it.
> What if they do need their extensions meanwhile?
>
> One side aspect: what about extension update warning? If a new version is
> detected but the user doesn't upgrade to 4.0, are we sure that the minimal
> version will be checked first, before the new extension is installed by the
> user? Has he to download it before being warned that it's in fact not
> compatible with his current AOO/OOo version?
>
> I'm not against the change. I'm for a controlled one, that has no impact on
> end-users. So the main points are: communication to the extensions
> maintainers (what about the extensions hosted on their personal pages and
> not on sourceforge?), preparation of the updates and transition period.
>
> Hagar

Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work

[Rob Weir]

On Tue, Feb 12, 2013 at 5:33 PM, James Teh  wrote:
> Hi all,
>
> I'm one of the lead developers of NVDA. It is fantastic to see this work
> progressing so well. It is something for which we (and our users) have been
> hoping/waiting for years. I am very impressed with the progress so far.
>
> I eagerly await the decision regarding how issues should be reported and
> would strongly urge for the bug tracker. Emails tend to get lost and are
> much harder to triage or keep track of, especially for issues which won't be
> addressed immediately. This is especially true on a high traffic, broad list
> such as this one. Personally, I'm far likely to report bugs via a tracker,
> as it means the time spent gathering information isn't wasted and I can
> easily track the status of the issue and provide more info as needed.
>

Using Bugzilla makes it easier for all of us.  As Ariel suggested, if
you enter the defect reports into Bugzilla, it would be good to
preface the Subject line with [ia2] so it is clear that they are
related to a branch build, not a trunk build.

Also, if you (and anyone else testing in this area) can send me your
Bugzilla account userid (the email address you registered with) I can
add give you some additional permissions in Bugzilla, including
ability to edit bugs, confirm, change status, etc.

https://issues.apache.org/ooo/

Regards,

-Rob

> Thanks,
> Jamie
>
>
> On 10/02/2013 4:05 AM, V Stuart Foote wrote:
>>
>> Steve,
>>
>> Nothing substantive yet in working through the Windows build of the ia2
>> branch. Should we build against Linux and OSX and be testing for impact on
>> ATK/AT-SPI and NSAccessibility User Interface?
>>
>> And, with QA and testing of the ia2 branch proceeding what mechanism
>> should folks use for reporting and tracking issues on the ia2 branch builds?
>>
>> Should we stay with PM and ML exchanges, or start to use Bugzilla at
>> issues.apache.org/ooo?  I believe that starting with BZ tracking now
>> provides continuity upon merge of branch back into AOO4.00.
>>
>> And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2
>> release planning wiki that  QA participants and casual users report in
>> Bugzilla categorized for consistency as against:
>>
>> Product: UI
>> Component: AccessBridge
>> Version: AOO4.00-dev
>>
>> Stuart
>>
>> =-=-=
>>
>> Sidebar--the legacy IAccessible2 enhancement bug could probably be revised
>> https://issues.apache.org/ooo/show_bug.cgi?id=107914
>>
>> And here is a generic BZ search for accessibility issues
>>
>> https://issues.apache.org/ooo/buglist.cgi?query_format=advanced&resolution=---&short_desc=msaa%20accessible%20iaccessible%20iaccessible2%20accessibility&short_desc_type=anywordssubstr&order=component%2Cpriority%2Cbug_severity&query_based_on=
>>
>>
>
> --
> James Teh
> Director, NV Access Limited
> Email: ja...@nvaccess.org
> Web site: http://www.nvaccess.org/
> Phone: +61 7 5667 8372
>

Re: New page: Contributing Code

[janI]

On 12 February 2013 23:55, Rob Weir  wrote:

> On Tue, Feb 12, 2013 at 5:47 PM, janI  wrote:
> > On 12 February 2013 23:19, Rob Weir  wrote:
> >
> >> We had a thread before Christmas discussing code contributions and
> >> best practices for how someone could contribute code to multiple
> >> projects, e.g., AOO and LO.
> >>
> >> I've written this up, along with more general remarks on contributing
> >> code on a new page:
> >>
> >> http://openoffice.apache.org/contributing-code.html
> >>
> >> Please take a look and let me know of any needed/recommended changes.
> >>
> > Nice page, however I do not like "We're not interested in large
> > code-dumps.", I would prefer if you wrote something like:
> >
> > "Integrating large code-dumps requires cooperation and cannot be done as
> a
> > simple commit, therefore we urge you to contact us on how we commonly can
> > achieve the best result".
> >
>
> Maybe there is a better of way of phrasing this, but we really don't
> want code dumps.  In other words, we're not interested in having a new
> large body of code to maintain.  A large code base requires developers
> to maintain it.  If it is a code dump then this dilutes our attention
> on the existing code base.  So new large contributions really need to
> come along with developers to help maintain the code.
>
I understand you better now, and agree. Someone dumping 100.000 lines on
our doorstep and disapearing is not an attractive situation.

Just a side remark, I thought that was pretty much what happened with
symphony, and now pick pieces and integrate.

Actually I think your wording above, it much better"if you come with a
large chunk of code, we need you as well" :-)


>
>
> > When I read the page, it sounds as if we are only interested in small
> code
> > patches, and that cannot be correct. Of course if someone has written a
> > function (maybe 1.000 lines), we are highly interested.  If someone has
> > written a complete new module (like a photo editor), then we need to
> talk.
> >
> > As an example my l10n tools are about 1.100 lines which I am sure is
> > something we want (I know I am committer, but see it as an example).
> >
>
> Maybe I need to define "code dump" then.  I don't think what you are
> doing is "code dump",  It is large, but I assume that you don't just
> contribute it and disappear.
>

Maybe it is really wording, I dont like negative wording on a page where we
try to welcome people. But I agree to the idea of taken over a large chunk
of code, requires the commitment of the developer as well.


>
> So help integrating is one part.  For a bug fix is a smaller
> enhancement, maybe that is all we need.  But suppose someone wants to
> contribute something large, like a complete new application as part of
> the suite?
>
> Let's see if we agree on that general idea.  If so I can find a
> clearer way of expressing it.
>

1) bug fixes, small things, you current wording is quite ok.
2) bigger things, needs documentation and commitment to help with
integration
3) large things (your 100.000 lines) needs ongoing commitment from the
developers, otherwise we cannot maintain it.

I know that is not the correct wording, but I hope we can agree of the
idea...and then please positive wording :-)

Have a nice day.
Jan I.

Ps. I dont intent to disapear, this is way too much fun.


>
> -Rob
>
> > rgds
> > Jan I.
> >
> >
> >
> >> Thanks,
> >>
> >> -Rob
> >>
>

Re: Select column in Calc

[Ariel Constenla-Haile]

On Tue, Feb 12, 2013 at 02:18:42PM -0600, Galileo Teco Juárez wrote:
> sorry mistake
> of translations
> 
> this is the real question
> 
> *how can i select the value of  a colum in a specific cell. ie, select the
> value of 10 from the B4 cell*

look at the API index for methods starting with G:
http://www.openoffice.org/api/docs/common/ref/index-files/index-7.html

getCellByPosition() 
function in interface ::com::sun::star::sheet::XCellRangesAccess
http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/XCellRangesAccess.html#getCellByPosition

getCellByPosition(
[in] longnColumn,
[in] longnRow,
[in] longnSheet )

This method is support by the collection of sheets.


getCellByPosition()
function in interface ::com::sun::star::table::XCellRange
http://www.openoffice.org/api/docs/common/ref/com/sun/star/table/XCellRange.html#getCellByPosition


getCellByPosition(
[in] longnColumn,
[in] longnRow )

This method is supported by the single sheet.

See 
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Cell_and_Cell_Range_Access


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina
# *
#  
#  Licensed to the Apache Software Foundation (ASF) under one
#  or more contributor license agreements.  See the NOTICE file
#  distributed with this work for additional information
#  regarding copyright ownership.  The ASF licenses this file
#  to you under the Apache License, Version 2.0 (the
#  "License"); you may not use this file except in compliance
#  with the License.  You may obtain a copy of the License at
#  
#http://www.apache.org/licenses/LICENSE-2.0
#  
#  Unless required by applicable law or agreed to in writing,
#  software distributed under the License is distributed on an
#  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
#  KIND, either express or implied.  See the License for the
#  specific language governing permissions and limitations
#  under the License.
#  
# *

# HelloWorld python script for the scripting framework

def MyHelloWorldPython( ):
doc = XSCRIPTCONTEXT.getDocument()

# may be it doesn't implement css.lang.XServiceInfo
try:
# check that we have a SpreadsheetDocument
if not doc.supportsService("com.sun.star.sheet.SpreadsheetDocument"):
return None
except:
return None

# the collection of sheets
sheets = doc.Sheets

# method taking col, row, spreadsheet
cell = sheets.getCellByPosition(0,0,0)
cell.Text.String = "Hello world! on (0,0,0)"

# get the first spreadsheet from the collection
sheet = sheets.getByIndex(0)
cell = sheet.getCellByPosition(0,1)
cell.Text.String = "Hello world! on (0,1)"

cell = sheet.getCellByPosition(0,2)
cell.Value = 18.63

return None


pgptVBVgZZGTS.pgp
Description: PGP signature

Re: [DEV] Compiler/build error

[Ariel Constenla-Haile]

On Tue, Feb 12, 2013 at 05:13:00PM -0500, Fernando Martinez wrote:
> BUILD FAILED
> 
> C:\source\aoo-trunk\main\hsqldb\wntmsci12.pro\misc\build\hsqldb\build\build.
> xml:302: Compile failed; see the compiler error output for details.
> If anybody could please help with this error and also tell me how to
> check the compiler error output.

If you build with 

build --html

then you have a folder in every module with the build output:

//misc/logs

If you don't build with --html, simply cd to the module, and run build
to rebuild the single module, you'll see the output in the terminal:

cd main/hsqldb
build


I guess you have JDK 7 installed; if so, install a JDK 6 and configure
with --with-jdk-home=


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpFbOdfhXKum.pgp
Description: PGP signature

Re: Performance test comparisons

[Andrew Douglas Pitonyak]

If you have a good setup for testing such things, try loading, saving, 
and closing AndrewMacro.odt


LO claims that much of their improvements are related to large Calc 
documents. Might be nice to find and test their large test Calc 
document... Not sure what they used, however.


On 02/12/2013 07:42 AM, Rob Weir wrote:

I did some tests to see how we were doing, comparing AOO 3.4.1 on
Windows against OOo 3.3.0.  And since LibreOffice claims that their
4.0 release is much faster and leaner, I tested them as well, to see
if we could learn anything.

I just did a basic test, seeing how long it took to load a large text
document, in this case the ODF 1.2 specification.  I looked at memory
consumed and the number of seconds to load.  I loaded the document
once to reduce the impact of disk caching and then repeated 5 times
and took the average.  All tests done on identical hardware.

Memory use (KB for soffice.bin):

OOo 3.3.0:133,472
AOO 3.4.1:   129,928
LO 4.0: 165,796

Load time for ODF 1.2 specification (seconds, average of 5 loads)

OOo 3.3.0:16.0
AOO 3.4.1:20.9
LO 4.0:  23.7


Does anyone have any other good test documents for doing performance
tests of OpenOffice?

Regards,

-Rob



--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Completed Introduction to Contributing to Apache OpenOffice Module

[Andrew Douglas Pitonyak]

Welcome. have you tried to build the source code yet?

This may be a good starting place

http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On 02/12/2013 04:13 PM, Maarten Kesselaers wrote:

Hello,

My name is Maarten Kesselaers.
I'm from Belgium and work as a project manager and EDI exchange expert.

I used to code (Java, C++ and DOM) and helped other developers on forums, but 
I'm up to a new challenge.
That's why I would like to help make AOO better.

Kind regards,
Maarten





--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Select column in Calc

[Andrew Douglas Pitonyak]

Do you want to "get", "take", or "obtain" the value that is in the cell, 
or, do you want to "select" the cell so that it is the current cell?

On 02/12/2013 03:18 PM, Galileo Teco Juárez wrote:

sorry mistake
of translations

this is the real question

*how can i select the value of  a colum in a specific cell. ie, select the
value of 10 from the B4 cell*


2013/2/12 Galileo Teco Juárez 


Select column in Calc

as I can select from Python
the value of a particular column in Calc

or is necessary for the user to select?

regards

--
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797






--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Andrea Pescetti]

Dennis E. Hamilton wrote:

The objective is to achieve consensus.  I believe it is clear that there is
no consensus on the proposed change and the proposal fails.


I still have to see some credible arguments here, since most of the 
feedback was misplaced. What we learned so far is:


1) Nobody so far exhibited a spreadsheet that would be broken by the new 
behavior. Rob has one, which was even published, so I'm sure he can 
share it for everybody to have a look. Even better, we have a fantastic 
collection of Calc templates at 
http://templates.openoffice.org/en/taxonomy/term/3923 ; seeing one of 
those templates break would help.


2) Everybody feels the need to say something about 0 ^ 0, but threads 
like this one are not pleasant to read. If you have nothing to say, 
please don't say anything. And if you have a lot to say, please limit 
yourself to what's strictly needed. Especially, undoing a volunteer's 
work without some concrete (in ODF format, in this case!) reasons is 
something the project must avoid.


3) Mathematics and the standards are two different worlds. If a standard 
is mathematically wrong, change the standard and come back.


4) We implement a standard, ODF. There 0 ^ 0 can legitimately be 
evaluated to 0, 1 or an error.


5) We read another standard, OOXML. There 0 ^ 0 can only be evaluated as 
an error; the fact that OpenOffice will evaluate 0 ^ 0 from a XLSX file 
to 1 is a bug.


6) Anyone whose spreadsheets depend on 0 ^ 0 being evaluated to 1 (or to 
zero, or to an error for that matter) has entered the dangerous world of 
"implementation-defined" behavior: even if you save in a standard format 
like ODF, your spreadsheet depends on a particular ODF implementation 
(e.g., on the specific version of OpenOffice you used).


Based on 5 and 6 I would actually still believe that it's good to 
evaluate 0 ^ 0 to error (so that we fix the bug in 5 and we choose the 
most strict behavior in 6). But I fully agree with Marcus in saying this 
issue is much smaller than the discussion around it, so I can surely 
change my opinion if I finally see some real-world spreadsheets impacted 
by the change. When we have those, also Pedro will likely see reasons 
for reverting the change. In short: provide concrete examples and 
everybody will be happy.


Regards,
  Andrea.

Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work

[James Teh]

On 13/02/2013 9:06 AM, Rob Weir wrote:

Using Bugzilla makes it easier for all of us.  As Ariel suggested, if
you enter the defect reports into Bugzilla, it would be good to
preface the Subject line with [ia2] so it is clear that they are
related to a branch build, not a trunk build.

Okay. I've started filing bugs with prefix [ia2] in Bugzilla:
https://issues.apache.org/ooo/buglist.cgi?quicksearch=[ia2]

Thanks,
Jamie

--
James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
Phone: +61 7 5667 8372

Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work

[Andrew Rist]

On 2/12/2013 5:57 AM, Steve Lee wrote:

Andrew

I think that binaries URL should be he following, at least for accessing
the binaries.

http://ci.apache.org/projects/openoffice/#w7ia2

As you point out however they are not there yet. Do you have an ETA?


ETA is now.
http://ci.apache.org/projects/openoffice/#w7ia2

Andrew

(actually - it's a bit of a Wizard of Oz thing, as they've actually been 
there all along...)


After Stuart's post of the NVDA list there has been quite a bit of
discussion and enthusiasm from some NVDA people on Twitter so others may
come looking.

https://twitter.com/jcsteh/status/301051115502448641

Steve
OpenDirective

On 10 February 2013 01:14, Andrew Rist  wrote:


Do you all know about this?
http://ci.apache.org/builders/**aoo-w7ia2/
We now have an automatic build of the ia2 branch running nightly. (and
successfully)
It is not loading up install bits for some reason, but I'll look at that
and fix it.

If you want to see the status of the latest build look for "Windows ia2
Branch" on this page:
http://ci.apache.org/projects/**openoffice/
that page links to the build logs >
and the buildbot log 
>,
and should have the latest build of the install packages.

Andrew




On 2/9/2013 10:05 AM, V Stuart Foote wrote:


Steve,

Nothing substantive yet in working through the Windows build of the ia2
branch. Should we build against Linux and OSX and be testing for impact on
ATK/AT-SPI and NSAccessibility User Interface?

And, with QA and testing of the ia2 branch proceeding what mechanism
should folks use for reporting and tracking issues on the ia2 branch builds?

Should we stay with PM and ML exchanges, or start to use Bugzilla at
issues.apache.org/ooo?  I believe that starting with BZ tracking now
  provides continuity upon merge of branch back into AOO4.00.

And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2
release planning wiki that  QA participants and casual users report in
Bugzilla categorized for consistency as against:

 Product: UI
 Component: AccessBridge
 Version: AOO4.00-dev

Stuart

=-=-=

Sidebar--the legacy IAccessible2 enhancement bug could probably be revised
https://issues.apache.org/ooo/**show_bug.cgi?id=107914

And here is a generic BZ search for accessibility issues
https://issues.apache.org/ooo/**buglist.cgi?query_format=**
advanced&resolution=---&short_**desc=msaa%20accessible%**
20iaccessible%20iaccessible2%**20accessibility&short_desc_**
type=anywordssubstr&order=**component%2Cpriority%2Cbug_**
severity&query_based_on=

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud]

On Tue, Feb 12, 2013 at 6:00 PM, Andrea Pescetti  wrote:
>
> 1) Nobody so far exhibited a spreadsheet that would be broken by the new
> behavior.

I think attachment to the list are stripped... but... any spreadsheet
that try to teach the Power Rule
( http://en.wikipedia.org/wiki/Power_rule )
with interactivity where you can plug the value for x and it calculate
the derivative of a polynomial f(x)
would all the sudden claim that polynomial functions with a component
in x^1 are not differentiable in 0...

and that is just one common and practical use of 0^0.

Just because some people are tempted to talk about the value of a
limit, or even wore for a mathematician, trying to 'calculate it'
before establishing convergence does not mean that the 'notation' 0^0
can not be defined.
just like 0! is _defined_ to be 1, 0^0 is _defined_ to be 1.

I also invite the numerous mathematicians on this list to refer to "N.
Boubaki (*),  Element of Mathematics, Set Theory, p164:  III.3.5
Proposition 11. "[...] Note in particular that 0^0 = 1."

(*) http://en.wikipedia.org/wiki/Nicolas_Bourbaki

Norbert

Re: Select column in Calc

[Galileo Teco Juárez]

obtain the value in a cell specific


2013/2/12 Andrew Douglas Pitonyak 

> Do you want to "get", "take", or "obtain" the value that is in the cell,
> or, do you want to "select" the cell so that it is the current cell?
>
> On 02/12/2013 03:18 PM, Galileo Teco Juárez wrote:
>
>> sorry mistake
>> of translations
>>
>> this is the real question
>>
>> *how can i select the value of  a colum in a specific cell. ie, select the
>> value of 10 from the B4 cell*
>>
>>
>>
>> 2013/2/12 Galileo Teco Juárez 
>>
>>  Select column in Calc
>>>
>>> as I can select from Python
>>> the value of a particular column in Calc
>>>
>>> or is necessary for the user to select?
>>>
>>> regards
>>>
>>> --
>>> *Galileo Teco Juarez*
>>> *Web:* http://80bits.wordpress.com
>>> *Twitter:* @genitalico 
>>> *Linkedin:* http://mx.linkedin.com/pub/**galileo-teco-ju%C3%A1rez/30/**
>>> 690/797 
>>>
>>>
>>
>>
> --
> Andrew Pitonyak
> My Macro Document: 
> http://www.pitonyak.org/**AndrewMacro.odt
> Info:  http://www.pitonyak.org/oo.php
>
>


-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: Select column in Calc

[Galileo Teco Juárez]

Ariel Constenla-Haile thanks by the examples

i will study


2013/2/12 Galileo Teco Juárez 

> obtain the value in a cell specific
>
>
> 2013/2/12 Andrew Douglas Pitonyak 
>
>> Do you want to "get", "take", or "obtain" the value that is in the cell,
>> or, do you want to "select" the cell so that it is the current cell?
>>
>> On 02/12/2013 03:18 PM, Galileo Teco Juárez wrote:
>>
>>> sorry mistake
>>> of translations
>>>
>>> this is the real question
>>>
>>> *how can i select the value of  a colum in a specific cell. ie, select
>>> the
>>> value of 10 from the B4 cell*
>>>
>>>
>>>
>>> 2013/2/12 Galileo Teco Juárez 
>>>
>>>  Select column in Calc

 as I can select from Python
 the value of a particular column in Calc

 or is necessary for the user to select?

 regards

 --
 *Galileo Teco Juarez*
 *Web:* http://80bits.wordpress.com
 *Twitter:* @genitalico 
 *Linkedin:* http://mx.linkedin.com/pub/**galileo-teco-ju%C3%A1rez/30/**
 690/797


>>>
>>>
>> --
>> Andrew Pitonyak
>> My Macro Document: 
>> http://www.pitonyak.org/**AndrewMacro.odt
>> Info:  http://www.pitonyak.org/oo.php
>>
>>
>
>
> --
> *Galileo Teco Juarez*
> *Web:* http://80bits.wordpress.com
> *Twitter:* @genitalico 
> *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
>



-- 
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797

Re: Tutorial About

[jorge ivan poot diaz]

Hello Ariel,

I did the patch you told me, but I have not results.

I would like to know what would be the equivalent of a code tutorial about
for this new source code to generate the button.


2013/2/12 Ariel Constenla-Haile 

> Hi Jorge,
>
> On Tue, Feb 12, 2013 at 12:06:12AM -0600, jorge ivan poot diaz wrote:
> > Here is the changes I made, I declare the button according to the
> tutorial, but
> > I have not the expected results.
> >
> > http://ooo.pastebin.ca/2313036
> > http://ooo.pastebin.ca/2313037
> >
> > The changes I have done well, as each code I put it where it belongs.
>
> But it's not simply "putting code". You need to compile the code, and
> you''ll the errors:
>
> main/cui/source/dialogs/about.cxx: In constructor
> 'AboutDialog::AboutDialog(Window*, const ResId&)':
> main/cui/source/dialogs/about.cxx:285:33: error: 'ABOUT_BTN_OK' was not
> declared in this scope
>
> main/cui/source/dialogs/about.cxx: In member function 'void
> AboutDialog::LayoutControls(Size&)':
> main/cui/source/dialogs/about.cxx:446:30: error: 'aOutSiz' was not
> declared in this scope
>
>
> The errors speak for themselves:
>
> aOKSureButton( this, ResId( ABOUT_BTN_OK, *rId.GetResMgr() ) ),
>
> here, ABOUT_BTN_OK is not defined.
> In the new code, the define is RID_CUI_ABOUT_BTN_OK
>
>
> aOKSurePnt.X() = 135 + ( aOutSiz.Width() - aOKSureSiz.Width() ) / 2;
>
> there is no variable named aOutSiz in the current code.
> Besides, this hard coded layout won't work with the new code (all the
> layout is calculated relative to the two pictures, the logo (the orb) on
> the left and the header on the top.
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud]

On Tue, Feb 12, 2013 at 7:39 PM, Norbert Thiebaud  wrote:
> I also invite the numerous mathematicians on this list to refer to "N.
> Boubaki (*),  Element of Mathematics, Set Theory, p164:  III.3.5
> Proposition 11. "[...] Note in particular that 0^0 = 1."

http://books.google.com/books?id=IL-SI67hjI4C&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=snippet&q=Note%20in%20particular%20proposiiton%2012&f=false

Re: Updating Java libraries

[Michael Lam]

On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:

On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:

I have updated the external_deps.lst with the updated hsqldb
information. If someone can give me some pointer into how to just
retrieve the jar instead of the source

You don't retrieve precompiled stuff. The logic is:

a) don't include the dependency at all

b) include the dependency

b.1) build it from source

b.2) use the precompiled version in the system (this switch is only for
external packagers, the builds are release with no system [configurable]
dependencies).


Regards
I am still a little confused. Obviously it is possible to build from 
source but as a lot of email on the list have shown it could cause 
issues with the build that is not directly related to the AOO code. Why 
not just retrieve the jar so the build is inclusive? Wouldn't leaving it 
out allow someone to build with a version that is not fully tested? I am 
new to this type of development, so any clarification would be most 
helpful. I am used to retrieving compiled jars on the projects I worked 
on, in Java there is maven and ivy to retrieve specific version of the 
jar that the project is tested on along with the dependencies.

Re: Updating Java libraries

[Ariel Constenla-Haile]

Hi Michael,

On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote:
> On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote:
> >On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote:
> >>I have updated the external_deps.lst with the updated hsqldb
> >>information. If someone can give me some pointer into how to just
> >>retrieve the jar instead of the source
> >You don't retrieve precompiled stuff. The logic is:
> >
> >a) don't include the dependency at all
> >
> >b) include the dependency
> >
> >b.1) build it from source
> >
> >b.2) use the precompiled version in the system (this switch is only for
> >external packagers, the builds are release with no system [configurable]
> >dependencies).
> >
> >
> >Regards
> I am still a little confused. Obviously it is possible to build from
> source but as a lot of email on the list have shown it could cause
> issues with the build that is not directly related to the AOO code.
> Why not just retrieve the jar so the build is inclusive? 

I don't know what motivated these rules, but I guess it was something in
the lines of having control about what is being compiled and how it is
being compiled (the use of the compiler, the Java base line, etc.).

35 million of downloads are worth not relaying on a jar built by someone
else and, instead, build it from sources.


> I am used to retrieving compiled jars on the projects I worked on, in
> Java there is maven and ivy to retrieve specific version of the jar
> that the project is tested on along with the dependencies.

But it is still trusting in a binary built by someone else. Every
project is free to trust or build from sources. Historically, OpenOffice
builds from external sources and includes these binaries in its
releases, it has no external dependencies (other than the system
libraries). The configure switches that allow building with system
libraries/jars are only supported on *nix, and even there they are not
relaying on a jar built by someone else: Linux distributions, for
example, build all their jars; why do they build all by themselves
instead of fetching compiled jars? I've no idea, but I guess they follow
the same criteria mentioned above (as a Linux user you can use Maven in
your projects, but it won't modify the system's jars).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgprnEyK5tGGc.pgp
Description: PGP signature

Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

(OK, I guess it's better to re-subscribe to the list).

In reply to Norbert Thiebaud*:

In the Power rule, which *is* commonly used for differentiation, we take a 
series
of polinomials where n !=0. n is not only different than zero, most importantly,
it is a constant.

Of course we can use the power function a^b in your spreadsheet when the b
is a constant but you have to understand the assumptions being made before
blindingly applying formulas, and we just can't assume every speadsheet
user will use a restricted set of capabilities.

Now, in a spreadsheet this formula would be used if you have a polinomial and
you want to calculate and/or graph it's derivative. Since we don't do symbolic
math in the speadsheet you would actually do this by hand and you would resolve
the trivial constant^0 cases.

In the case of the set theory book, do note that the author is constructing
his own algebra, and it's natural that he might not want indefinite values
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.

I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot but ultimately I would
wonder. if this author *is* using mathematics correctly. 0^0 is a good 
indication
that there is something wrong in your calculation and evidently Excel users
have come to accept it.

Pedro.

*Welcome to this list ;).

Re: Tutorial About

[Ariel Constenla-Haile]

Hi Jorge,

On Tue, Feb 12, 2013 at 08:06:11PM -0600, jorge ivan poot diaz wrote:
> Hello Ariel,
> 
> I did the patch you told me, but I have not results.

Did you build it? Did it compile without errors? Did you copy the
library with the modifications back in your installation? (you need to
copy both the library and binary resource file).


> I would like to know what would be the equivalent of a code tutorial about
> for this new source code to generate the button.

That tutorial doesn't explain much... if you've followed the steps in my
previous mail (the one with the patch), you should be able to make it
work. I repeat the steps:

The sources are at:

cui/source/inc/about.hxx - header
cui/source/dialogs/about.cxx - source file
cui/source/dialogs/about.hrc - IDs defines
cui/source/dialogs/about.src - dialog structure definition


Apply the attached patch, build, deliver, and copy the library in your
office installation:

Open a terminal, cd where you have the trunk source tree
]$ cd 

Apply the patch
]$ cat  | patch -p1

cd the cui directory
]$ cd main/cui

rebuild that directory and deliver
]$ build debug=true dbglevel=3  && deliver


copy the library
]$ cp -fv /lib/libcui.so /basis4.0/program/libcui.so

copy the resource file
]$ cp -fv /bin/cui*.res  /bin. When you modify a resource file,
copy the re compiled binary back in your installation. As you are doing
small changes, copying the recompiled files is easier that rebuilding
the whole source try.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpTU2QtUrZyH.pgp
Description: PGP signature

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  wrote:

> (OK, I guess it's better to re-subscribe to the list).
>
> In reply to Norbert Thiebaud*:
>
> In the Power rule, which *is* commonly used for differentiation, we take a 
> series
> of polinomials where n !=0. n is not only different than zero, most 
> importantly,
> it is a constant.
>
> Of course we can use the power function a^b in your spreadsheet when the b
> is a constant but you have to understand the assumptions being made before
> blindingly applying formulas, and we just can't assume every speadsheet
> user will use a restricted set of capabilities.
>
> Now, in a spreadsheet this formula would be used if you have a polinomial and
> you want to calculate and/or graph it's derivative. Since we don't do symbolic
> math in the speadsheet you would actually do this by hand and you would 
> resolve
> the trivial constant^0 cases.
>
> In the case of the set theory book, do note that the author is constructing
> his own algebra, and it's natural that he might not want indefinite values
> that get outside his set: 0^0 and x/0 are such cases. The text is not
> a demonstration, it is simply a statement taken out of context.
>
> I guess looking hard it may be possible to find an elaborated case where
> someone manages to shoot himself in the foot but ultimately I would
> wonder. if this author *is* using mathematics correctly. 0^0 is a good 
> indication
> that there is something wrong in your calculation and evidently Excel users
> have come to accept it.
>


Well, can you then give an example of a real-world spreadsheet where a
user has evaluated 0^0 in error and has not noticed it?  That would be
the claimed beneficiary of your change, yes?  So what is the example?

-Rob

> Pedro.
>
> *Welcome to this list ;).

R: Re: Calc behavior: result of 0 ^ 0

[Pedro Giffuni]

No, I cant, and I wont start scartching my head over it.

The issue is minuscule enough that I have been aware from the start that it 
wasnt worth this bikeshed thread [1].

Of course, had I implemented quaternion math using Boost, no one would be 
complaining. :-P

Pedro.

[1] http://bikeshed.org

Re: Select column in Calc

[Andrew Douglas Pitonyak]

OK, then you want the information as provided by Ariel. Just wanted 
to be sure.


On 02/12/2013 08:50 PM, Galileo Teco Juárez wrote:

obtain the value in a cell specific


2013/2/12 Andrew Douglas Pitonyak 


Do you want to "get", "take", or "obtain" the value that is in the cell,
or, do you want to "select" the cell so that it is the current cell?

On 02/12/2013 03:18 PM, Galileo Teco Juárez wrote:


sorry mistake
of translations

this is the real question

*how can i select the value of  a colum in a specific cell. ie, select the
value of 10 from the B4 cell*



2013/2/12 Galileo Teco Juárez 

  Select column in Calc

as I can select from Python
the value of a particular column in Calc

or is necessary for the user to select?

regards

--
*Galileo Teco Juarez*
*Web:* http://80bits.wordpress.com
*Twitter:* @genitalico 
*Linkedin:* http://mx.linkedin.com/pub/**galileo-teco-ju%C3%A1rez/30/**
690/797 





--
Andrew Pitonyak
My Macro Document: 
http://www.pitonyak.org/**AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php






--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

My preference is to leave the patch and return #Value

On 02/12/2013 01:11 PM, Dennis E. Hamilton wrote:

RESOLUTION OF THE PROPOSAL

The proposed change was made under CTR (Commit then Review). There has been
a subsequent review and, as Don points out, the discussion has been lengthy
and vocal.

The objective is to achieve consensus.  I believe it is clear that there is
no consensus on the proposed change and the proposal fails.

I can't speak for the AOO PMC.  It would be useful if Andreas helped wrap
this up.  If the lack of consensus is affirmed, Pedro can revert the change
and adjust the Bugzilla issue.

THE ESSENCE OF THE PROPOSAL

The proposal is to enact the breaking change as described on
the Community Wiki at

.

It is under Changes that Impact Backward Compatibility, Calc and OpenFormula
Support.

"Exponentiation

"The current version of Calc produces 1 for POWER(0,0).  This is one of the
implementation-defined results that is permitted by ODF 1.2 OpenFormula.

"It is proposed to change POWER(0,0) to result in #VALUE!.  This is also
permitted as the implementation-defined result.  This is also compatible
with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods
Spreadsheets. ..."

OUTCOME

The proposed change is tracked in Bugzilla Issue #114430,
< https://issues.apache.org/ooo/show_bug.cgi?id=114430>.

A patch to implement this proposal is already included in the SVN.
If the proposal is not accepted as the result of CTR review, the
Issue will be closed and the patch reverted.
  
  - Dennis


-Original Message-
From: Donald Whytock [mailto:dwhyt...@gmail.com]
Sent: Tuesday, February 12, 2013 09:20
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

...So I got curious, and I paged back in my email archive, and it
seems this is the biggest AOO dev thread since the graduation vote
back in early September.

At this point, does anyone care enough about changing the status quo
as to put up a coherent proposal to be voted on?

Don



--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

On 02/12/2013 05:07 PM, Marcus (OOo) wrote:

Am 02/12/2013 10:39 PM, schrieb Rob Weir:

Sorry, if it wasn't clear.  I have a spreadsheet on my hard-drive
right now that would be break if we changed the behavior of 0^0.


And what is your *serious* use case for this spreadsheet? Beside to 
use it as a test document? And you have it created before the 
discussion has started?


I'll ask my question again:
Is there more than one who can deliever a *serious and valid use case*?


I assume that the valid use case is that existing spreadsheets start 
returning different values than they do with the current release.


It is always annoying when you have existing things that stop working 
when there is a new release. Admittedly, it may fail on any other 
program since the behavior is not well defined by the standard in this 
case.


AOO is ODF compliant regardless, because the standard allows for the 
different values.


On the other hand, if a sheet is designed to function with an error 
value returned for 0^0, I expect that it will then work the same on all 
implementations. Yeah, I prefer that we break the existing sheets, but I 
feel bad about it.


--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

On 02/12/2013 05:45 PM, Rob Weir wrote:

On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest  wrote:

Le 12/02/2013 23:22, Rob Weir a écrit :


But again, if you think that situation never comes up in real use,
then let's not make the change, since it would have no benefit.


You don't seem to see the benefit of the change: warn the user that there is
something weird in the formula that requires his attention.
Perhaps that there are users getting wrong results because a value is
returned and therefore hides the problem.


And your solution is to give users error messages where they do not
have a problem ?!  What if they the examine the formula and find out
that it is exactly what they wanted?  Your solution would force them
to rewrite their formulas for no good reason.

Again this is like giving an spelling error for "their" because some
users might confuse it with "there".

-Rob


I am torn as to which is worse. because loading the document in any 
other program able to read ODF might exhibit completely different 
behavior; and still be valid to the spec.


Although I would prefer returning an error, if it does not, then it 
should stay as it is (as opposed to changing to one of the other 
supported values)


--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: R: Re: Calc behavior: result of 0 ^ 0

[Andrew Douglas Pitonyak]

On 02/12/2013 11:21 PM, Pedro Giffuni wrote:

No, I cant, and I wont start scartching my head over it.

The issue is minuscule enough that I have been aware from the start that it 
wasnt worth this bikeshed thread [1].

Of course, had I implemented quaternion math using Boost, no one would be 
complaining. :-P

Pedro.

[1] http://bikeshed.org

Do it, do it, do it; PLEESSEEE. :-)

Quaternions are cool.

After that, how about interval arithmetic! I think that is even more fun!

--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php

Re: Calc behavior: result of 0 ^ 0

[Norbert Thiebaud]

On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir  wrote:
> On Feb 12, 2013, at 10:39 PM, Pedro Giffuni  wrote:
>
>> (OK, I guess it's better to re-subscribe to the list).
>>
>> In reply to Norbert Thiebaud*:
>>
>> In the Power rule, which *is* commonly used for differentiation, we take a 
>> series
>> of polinomials where n !=0. n is not only different than zero, most 
>> importantly,
>> it is a constant.

Power Rule : d/dx x^n = n.x^(n-1)  for n != 0  indeed.
so for n=1  (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.

I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.

>> and we just can't assume every speadsheet
>> user will use a restricted set of capabilities.
>>
>> Now, in a spreadsheet this formula would be used if you have a polinomial and
>> you want to calculate and/or graph it's derivative. Since we don't do 
>> symbolic
>> math in the speadsheet you would actually do this by hand and you would 
>> resolve
>> the trivial constant^0 cases.

Really... but extending by continuity a function in 0, without
consideration for convergence,  _that_ is something that is done by
spreadsheet ?
iow just because 0^0 is an indeterminate _form_ does not mean that 0^0
can not have a value... it just mean that when searching for a limit
for a function h(x)
if your _transformation_ lead you to 0^0 you cannot conclude from that
_form_ that means that the rule and tools that allow you to jump form
lim -> 0 to a value in 0 do not hold when they lead to that 'form'. I
know math is a tricky thing... but the definition of words and their
scope of application is kind of important in Math.

>>
>> In the case of the set theory book, do note that the author is constructing
>> his own algebra,

The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.

>> that get outside his set: 0^0 and x/0 are such cases. The text is not
>> a demonstration, it is simply a statement taken out of context.

You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better " if this author(sic) *is* using mathematics correctly."

>>
>> I guess looking hard it may be possible to find an elaborated case where
>> someone manages to shoot himself in the foot

Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...

For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g  with f(x)->0 x->inf and g(x)->0 x->inf  then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x->0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.

in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.


wrt to the 'context' of the quote I gave earlier:

"Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}. "

( I will use x^y here from now on to note x {superscript y} for readability )

"Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0

For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
"

He