date:20130211

On Mon, Feb 11, 2013 at 12:57:57AM +0100, Andrea Pescetti wrote:
 It is unavoidable that we will open a discussion about the
 extensions compatibility; I started this one about 0 ^ 0 which is
 enjoying unexpected popularity (and I would appreciate, for the sake
 of completeness, to see one example of a spreadsheet that would be
 broken by the new behavior), but when this one has settled I'll open
 one about extensions

There is already a thread on api@, where it belongs. Please don't start
spreading threads everywhere! (It already hard to follow
endless/pointless discussion on these mailing lists, to follow them in
parallel in several lists).


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpnE1s06ZjII.pgp
Description: PGP signature

Re: Calc behavior: result of 0 ^ 0

On Sun, Feb 10, 2013 at 11:39 PM, Andrew Douglas Pitonyak
and...@pitonyak.org wrote:

 On 02/10/2013 10:04 AM, Rory O'Farrell wrote:

 My thinking is the Calc should return the mathematically correct answer.

 ODF standard defines what can be returned. If there is a single
 mathematically correct answer, I would expect the standard to define it. If
 the standard is wrong (like defining 1+1=3), then the standard should be
 changed.

 At the end of the day, it amuses me that the standard allows for three
 different values. I suppose that if the people writing the standard could
 not agree on a single answer, I doubt if you will receive a decent consensus
 here.


The goal when writing the ODF 1.2 OpenFormula specification was to
describe current spreadsheet behavior.  It was not our goal to define
a new spreadsheet formula language that was cleaner, better-designed,
more consistent than what was already out there.  It would have been
legitimate to define an entirely new language and open up all past
design decisions.  But that is not what we aimed to do.

If you recall MS Office 2007 was not interoperable with OpenOffice
spreadsheets.  Every single formula was incompatible.  Even basic
functions like SUM() and AVERAGE() were lost when Office opened an ODF
document.

By having a new ODF 1.2 formula specification that encompasses the
range of behaviors in real-world spreadsheets today, we now have an MS
Office Excel that is compatible with the vast majority of OpenOffice
spreadsheets, even though there may be differences in edge cases like
0^0.  So from the standardization perspective I think this is a
success, both technically and politically.  It vastly improved
interoperability.

-Rob

 I would find it a bit offensive if 0/0 returned 0 or 1 (not that it might
 not be occasionally useful). I can probably claim the same for 0^0.

 The fact that the standard does not take a stand leaves me a bit bewildered,
 but I can guess as to why.

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

Re: Updating Java libraries


On 02/06/2013 03:58 PM, Dave Fisher wrote:

On Feb 5, 2013, at 8:26 PM, Ariel Constenla-Haile wrote:


Is there any recommendation/objection on this? After hsqldb I would
like to move on to lucene.

In this case, it would be nice to investigate if lucence can be replaced
by clucene, this will reduce the need of installing Java for basic
stuff, like the Online Help.


Apache Lucy is a C version of Apache Lucene

http://lucy.apache.org/

Regards,
Dave

That is certainly an option, although it comes down to how it is used, 
if it is only for searching the help, it might not need all the new 
functionality in the latest Lucene. Since Lucy is a loose port of 
Lucene, I am not sure if the updates on Lucene are ported although some 
are Java centric and the same issue might not be applicable in C.


Michael

Re: Calc behavior: result of 0 ^ 0

2013-02-11 Thread Andrea Pescetti


Andre Fischer wrote:

If the spec said that 2 is the only valid return value then we would
have to return 2.


But then, since we also read XLSX and the OOXML standard prescribes that 
0 ^ 0 should return an error, returning an error would be the common 
ground here: of course we don't want to depend on the file format, so 
choosing something where the standards agree makes sense. (As Dennis 
noted, Excel returns an error indeed, but a different one than what the 
OOXML specification prescribes... so this seems a difficult question 
there too!).



We should change the ODF spec first instead. A spec that basically says
whatever you want to return is fine is of no value, as was proven in
this thread.


A specification may need to leave room for implementation-defined 
behavior. Look at the C or C++ standard for example. ODF is indeed not 
too strong (I didn't check all details, but I think it might be possible 
to have Calc evaluate =two+two as five -or four for that matter- 
and not break the ODF specification), but this doesn't necessarily mean 
that the standard is flawed, only that it admits implementations that 
differ on this detail.


Regards,
  Andrea.

Re: Updating Java libraries


On 02/06/2013 12:50 PM, Kay Schenk wrote:



On 02/06/2013 06:15 AM, Michael Lam wrote:

On 02/06/2013 05:57 AM, Herbert Duerr wrote:

I just saw that Ariel had already provided an excellent answer when I
had trouble with my mail connection. Sorry about that.

On 06.02.2013 11:49, Herbert Duerr wrote:

Hi Michael,

On 06.02.2013 04:06, Michael Lam wrote:

I would like to update some of the Java libraries used, starting with
hsqldb. Is there any preference to getting the source and building 
the

jar or just grabbing the jar from the project site?


Some other Apache projects are redistributing unmodified upstream 
JARs,

so I guess we could do this as well and this would simplify the build.


There are four BZ
issues in reference to hsqldb with patches, I am going to test the 
new

version to make sure those issues are resolved but they are very old.
Should I open another issue for this?


Opening just one issue with task about updating hsqldb should suffice.


Is there any recommendation/objection on this? After hsqldb I would
like
to move on to lucene.


Thank you very much for working on this!


Just a general question, there are many old issues on BZ for example
there are 96 for hsqldb but most of them are from 2006 and is 
referring
to an old version of OpenOffice, would it be possible to close 
very old

issues?


Sure, obsolete issues can be closed. Quickly skimping over the list of
hsqldb issues [1] shows that some problems may be generic and could
still be relevant. Having their reports and descriptions on how to
reproduce them could be valuable enough to reconsider closing them.
Maybe they are interesting test cases when you upgraded hsqldb?

[1] http://s.apache.org/aoo_hsqldb_open

Herbert




Thank you Herbert and Ariel. I already have a build with the latest code
from SVN and the latest jar from hsqldb. I was thinking the same as
using the existing issues especially the one with the patches as test
cases to make sure the new jar doesn't introduce regression.


Good going Michael!! Ok, you used latest HSQLDB jar, hsqldb-2.2.9, and 
which version of java on your system?


And yes, looking through old dba dev mail archives did prove 
useful/interesting, as well as information starting in:


http://www.openoffice.org/dba/



I can look into updating the files both ways to build but I would think
it is better to just retrieve the jar and simplify the build process. As
a new volunteer, the current process is quite complex even with the
great documentation. I think simplifying it by concentrating on the core
openoffice code would be helpful.




I have successfully test hsqldb-2.2.9 against the following 4 issues and 
it is functioning correctly:

https://issues.apache.org/ooo/show_bug.cgi?id=96823
https://issues.apache.org/ooo/show_bug.cgi?id=103528
https://issues.apache.org/ooo/show_bug.cgi?id=104901
https://issues.apache.org/ooo/show_bug.cgi?id=97032

and I have looked at

http://hg.services.openoffice.org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related to 
hsqldb19 and it is already in the latest revision. As for the hsqldb specific, 
the patches does not apply to 2.2.9. As far as patches, wouldn't it be better 
to report upstream and provide the patch instead of just patching within the 
build? There are also checks within the code to specifically check for version 
1.8.x, not sure  wouldn't it be better to enforce on configure/bootstrap? The 
current way seem to require a lot more work to update dependencies and the 
with-system-hsqldb for configure provides no warning.

I will take a look at the open issues and see if it is resolved with the new 
version.

I am guessing my next steps would be looking into updating the build to pull 
the jar?

Michael

Re: Updating Java libraries

2013-02-11 Thread Herbert Duerr


Hi Michael,

On 11.02.2013 17:21, Michael Lam wrote:

I have successfully test hsqldb-2.2.9 against the following 4 issues and
it is functioning correctly:
https://issues.apache.org/ooo/show_bug.cgi?id=96823
https://issues.apache.org/ooo/show_bug.cgi?id=103528
https://issues.apache.org/ooo/show_bug.cgi?id=104901
https://issues.apache.org/ooo/show_bug.cgi?id=97032


Thanks a lot for investigating this!


and I have looked at

http://hg.services.openoffice.org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related
to hsqldb19 and it is already in the latest revision. As for the hsqldb
specific, the patches does not apply to 2.2.9. As far as patches,
wouldn't it be better to report upstream and provide the patch instead
of just patching within the build?


Definitely.

In a linux distribution or a project such as ours with so many external 
dependencies there are good reasons not to always use the latest version 
of each component: That could easily result in endless churn and prevent 
releases. So backporting fixes is an alternative that should is often 
preferable. I don't know the background of the issues mentioned above 
that were fixed for HSQLDB but maybe they were such backports of fixes?



There are also checks within the code
to specifically check for version 1.8.x, not sure  wouldn't it be better
to enforce on configure/bootstrap? The current way seem to require a lot
more work to update dependencies and the with-system-hsqldb for
configure provides no warning.


Using configure for checking this and cleaning up checks for obsoleted 
versions is a good plan. Please go ahead.



I will take a look at the open issues and see if it is resolved with the
new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?


Better use the mechanism provided by main/external_deps.lst

Herbert

Re: java 7 patch

On Thu, Feb 7, 2013 at 2:32 PM, Fred Ollinger folli...@gmail.com wrote:
 To whom it may concern,

 Below is a patch to fix some java7 compilation bugs. Also, this is attached.


Thanks for the patch, Fred!

I've created a Bugzilla issue for this, so we don't lose track of it.
 I also added you to the cc list for the report, so you will be
notified when its status changes.

https://issues.apache.org/ooo/show_bug.cgi?id=121754


Regards,

-Rob


 Index: hsqldb/jdbcDriver.java
 ===
 --- hsqldb.orig/jdbcDriver.java 2013-02-07 09:17:01.0 -0800
 +++ hsqldb/jdbcDriver.java  2013-02-07 09:17:32.0 -0800
 @@ -31,6 +31,11 @@

  package org.hsqldb;

 +//#ifdef JAVA7
 +import java.sql.SQLFeatureNotSupportedException;
 +import java.util.logging.Logger;
 +//#enddif JAVA7
 +
  import java.sql.Connection;
  import java.sql.Driver;
  import java.sql.DriverManager;
 @@ -121,6 +126,12 @@
   */
  public class jdbcDriver implements Driver {

 +//#ifdef JAVA7
 +public Logger getParentLogger() throws SQLFeatureNotSupportedException {
 +  throw new SQLFeatureNotSupportedException();
 +}
 +//#endif JAVA7
 +
  /**
   *  Attempts to make a database connection to the given URL. The driver
   *  returns null if it realizes it is the wrong kind of driver to
 @@ -321,4 +332,8 @@
  DriverManager.registerDriver(new jdbcDriver());
  } catch (Exception e) {}
  }
 +
 +public boolean isCloseOnCompletion() { return false; }
 +
  }
 +
 Index: hsqldb/jdbc/jdbcCallableStatement.java
 ===
 --- hsqldb.orig/jdbc/jdbcCallableStatement.java 2013-02-07
 09:55:57.0 -0800
 +++ hsqldb/jdbc/jdbcCallableStatement.java  2013-02-07 09:57:17.0 
 -0800
 @@ -302,6 +302,14 @@
  public class jdbcCallableStatement extends jdbcPreparedStatement
  implements CallableStatement {

 +//#if JAVA7
 +public T T getObject(String s, ClassT T) throws SQLException
 { throw new SQLException(); }
 +public T T getObject(int i, ClassT T) throws SQLException {
 throw new SQLException(); }
 +public boolean isCloseOnCompletion() {
 + throw new UnsupportedOperationException(Not supported yet.);
 +}
 +//#endif JAVA7
 +
  /** parameter name = parameter index */
  private IntValueHashMap parameterNameMap;

 @@ -3373,11 +3381,6 @@
  {
  throw new UnsupportedOperationException(Not supported yet.);
  }
 -//#endif JAVA6
 -
 -//#if JAVA7
 -[javac] 
 /mnt/lfs/sources/ubuntu/old/local_dev300/hsqldb/unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/jdbc/jdbcCallableStatement.java
 :302: error: jdbcCallableStatement is not abstract and does not
 override abstract method TgetObject(String,ClassT) in
 CallableStatement
 -
 -//#endif JAVA7

 +//#endif JAVA6
  }
 Index: hsqldb/jdbc/jdbcConnection.java
 ===
 --- hsqldb.orig/jdbc/jdbcConnection.java2013-02-07 11:22:20.0 
 -0800
 +++ hsqldb/jdbc/jdbcConnection.java 2013-02-07 11:22:43.0 -0800
 @@ -31,6 +31,10 @@

  package org.hsqldb.jdbc;

 +//#ifdef JAVA7
 +import java.util.concurrent.Executor;
 +//#endif JAVA7
 +
  //#ifdef JAVA2
  import java.sql.Array;
  import java.sql.Blob;
 @@ -416,6 +420,21 @@
   * @see jdbcDatabaseMetaData
   */
  public class jdbcConnection implements Connection {
 +//#ifdef JAVA7
 +public void abort(Executor e){}
 +public int getNetworkTimeout(){
 +  throw new UnsupportedOperationException(Not supported yet.);
 +}
 +public void setNetworkTimeout(Executor e, int i ){
 +  throw new UnsupportedOperationException(Not supported yet.);
 +}
 +public String getSchema() {
 +   throw new UnsupportedOperationException(Not supported yet.);
 +}
 +public void setSchema(String s) {
 +   throw new UnsupportedOperationException(Not supported yet.);
 +}
 +//#endif JAVA7

  //  Common Attributes --

 Index: hsqldb/jdbc/jdbcDatabaseMetaData.java
 ===
 --- hsqldb.orig/jdbc/jdbcDatabaseMetaData.java  2013-02-07
 11:27:01.0 -0800
 +++ hsqldb/jdbc/jdbcDatabaseMetaData.java   2013-02-07 11:27:03.0 
 -0800
 @@ -99,7 +99,7 @@
   * P
   * A method that gets information about a feature that the driver does not
   * support will throw an codeSQLException/code.
 - * In the case of methods that return a codeResultSet/code
 + * In the case of methods that eeturn a codeResultSet/code
   * object, either a codeResultSet/code object (which may be empty) is
   * returned or an codeSQLException/code is thrown.p
   *
 @@ -282,6 +282,13 @@
   */
  public class jdbcDatabaseMetaData implements DatabaseMetaData {

 +//#ifdef JAVA7
 +public ResultSet getPseudoColumns(String catalog, String

Re: Updating Java libraries

2013-02-11 Thread Kay Schenk

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org wrote:

Hi Michael,

On 11.02.2013 17:21, Michael Lam wrote:

I have successfully test hsqldb-2.2.9 against the following 4 issues and
it is functioning correctly:
https://issues.apache.org/ooo/**show_bug.cgi?id=96823https://issues.apache.org/ooo/show_bug.cgi?id=96823
https://issues.apache.org/ooo/**show_bug.cgi?id=103528https://issues.apache.org/ooo/show_bug.cgi?id=103528
https://issues.apache.org/ooo/**show_bug.cgi?id=104901https://issues.apache.org/ooo/show_bug.cgi?id=104901
https://issues.apache.org/ooo/**show_bug.cgi?id=97032https://issues.apache.org/ooo/show_bug.cgi?id=97032

Thanks a lot for investigating this!

yes, great news!

and I have looked at

http://hg.services.openoffice.**org/cws/hsqldb19/http://hg.services.openoffice.org/cws/hsqldb19/

Unless I am looking at this wrong, many of the changes are not related
to hsqldb19 and it is already in the latest revision. As for the hsqldb
specific, the patches does not apply to 2.2.9. As far as patches,
wouldn't it be better to report upstream and provide the patch instead
of just patching within the build?

Definitely.

In a linux distribution or a project such as ours with so many external
dependencies there are good reasons not to always use the latest version of
each component: That could easily result in endless churn and prevent
releases. So backporting fixes is an alternative that should is often
preferable. I don't know the background of the issues mentioned above that
were fixed for HSQLDB but maybe they were such backports of fixes?

I thought the main reason for investigating the HSQLDB upgrade/change was
due to issues between java 6 and 7? we have some other patches submitted to
help with that also. I could be wrong about this though.

There are also checks within the code
to specifically check for version 1.8.x, not sure wouldn't it be better
to enforce on configure/bootstrap? The current way seem to require a lot
more work to update dependencies and the with-system-hsqldb for
configure provides no warning.

Using configure for checking this and cleaning up checks for obsoleted
versions is a good plan. Please go ahead.

I will take a look at the open issues and see if it is resolved with the
new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?

Better use the mechanism provided by main/external_deps.lst

Herbert

MzK

A great deal of talent is lost to the world
for want of a little courage.
-- Sydney Smith

RE: Will AOO write .docx?

2013-02-11 Thread Dennis E. Hamilton

For some reason, I failed to consider this question until some restless sleep 
this past weekend.

My understanding is that the improvements in OOXML handling are to be made 
available under the ALv2 license.  However, if those are in the form of 
patches, their usefulness to AOO will depend on whether or not the AOO *has* an 
available implementation for OOXML export already.  There needs to be something 
that the patches could be re-engineered against.

I know OOXML export is not enabled in the current release builds.  Is there any 
unreleased code that is part of the AOO code base and, if so, shouldn't work on 
that being released go ahead regardless, even if it shows up as an experimental 
feature while shaking it out?

 - Dennis

-Original Message-
From: Jürgen Schmidt [mailto:jogischm...@gmail.com] 
Sent: Friday, February 08, 2013 04:08
To: dev@openoffice.apache.org
Subject: Re: Will AOO write .docx?

On 2/7/13 9:44 PM, Regina Henschel wrote:
 Hi Andrea,
 
 Andrea Pescetti schrieb:
 On 01/02/2013 David Gerard wrote:
 Is .docx writing scheduled for AOO any given time, 4.0 or later?

 I expect that sooner or later we will implement it. But, in order to
 avoid unnecessary duplication of work, we will want to take a look at
 what comes out of the OSB Alliance effort
 http://s.apache.org/openoffice-aceu2012-day-3
 before tackling it. In short, I see it reasonable to expect this for
 some 4.x version, but not for 4.0.

 
 LibreOffice has already integrated parts of it. Shouldn't we ask
 Matthias Stürmer to sent us the source code?
 

the work was done on the LibreOffice code base which is no surprise
because Suse and Lanedo were contracted to do the work. It is also no
surprise that there is no patch available today. The information I have
is that the patches will be provided at the end of the project. And if
we can then use the patches is open and depends on the code itself and
the dependencies to other work not directly part of the OSBA project. We
tried to emphasize this problem with Mathias Stuermer during the
ApacheCon EU last year.

We should simply wait until we have seen and reviewed the first patches.

But to make it clear for everybody we are willing to collaborate on this
topic with other projects and especially LO to provide the best and most
complete solution for the users of OO and the eco system around free
open source based office productivity suites.

When I read in the morning that a user was introduced to uninstall
OpenOffice and install LibreOffice 4.0 and after that he had problems
with an OpenOffice doc file (whatever doc means in detail) where
formatting was lost or where things looked different. These are the
issues which are more serious and they damage the whole eco-system and
another company will be quite happy to read such things :-(

Juergen

Re: Updating Java libraries

On 02/11/2013 01:16 PM, Kay Schenk wrote:

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org wrote:

Hi Michael,

On 11.02.2013 17:21, Michael Lam wrote:

Thanks a lot for investigating this!

yes, great news!

and I have looked at

http://hg.services.openoffice.**org/cws/hsqldb19/http://hg.services.openoffice.org/cws/hsqldb19/

Definitely.

There are also checks within the code

to specifically check for version 1.8.x, not sure wouldn't it be better
to enforce on configure/bootstrap? The current way seem to require a lot
more work to update dependencies and the with-system-hsqldb for
configure provides no warning.

Using configure for checking this and cleaning up checks for obsoleted
versions is a good plan. Please go ahead.

I will take a look at the open issues and see if it is resolved with the

new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?

Better use the mechanism provided by main/external_deps.lst

Herbert

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. 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.

Re: Updating Java libraries

I'll help with testing java 6 and java 7 from Oracle.

I vote for keeping up with latest and greatest, but we should also
respect that many distros are probably going to ship java 6 for a
while.

Thus, we should probably work with both then officially deprecated
java6 when it's time.

Fred

On Mon, Feb 11, 2013 at 11:06 AM, Michael Lam mnsyl4...@verizon.net wrote:
On 02/11/2013 01:16 PM, Kay Schenk wrote:

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr h...@apache.org wrote:

Hi Michael,

On 11.02.2013 17:21, Michael Lam wrote:

I have successfully test hsqldb-2.2.9 against the following 4 issues and
it is functioning correctly:

https://issues.apache.org/ooo/**show_bug.cgi?id=96823https://issues.apache.org/ooo/show_bug.cgi?id=96823

https://issues.apache.org/ooo/**show_bug.cgi?id=103528https://issues.apache.org/ooo/show_bug.cgi?id=103528

https://issues.apache.org/ooo/**show_bug.cgi?id=104901https://issues.apache.org/ooo/show_bug.cgi?id=104901

https://issues.apache.org/ooo/**show_bug.cgi?id=97032https://issues.apache.org/ooo/show_bug.cgi?id=97032

Thanks a lot for investigating this!

yes, great news!

and I have looked at

http://hg.services.openoffice.**org/cws/hsqldb19/http://hg.services.openoffice.org/cws/hsqldb19/

Definitely.

In a linux distribution or a project such as ours with so many external
dependencies there are good reasons not to always use the latest version
of
each component: That could easily result in endless churn and prevent
releases. So backporting fixes is an alternative that should is often
preferable. I don't know the background of the issues mentioned above
that
were fixed for HSQLDB but maybe they were such backports of fixes?

I thought the main reason for investigating the HSQLDB upgrade/change was
due to issues between java 6 and 7? we have some other patches submitted
to
help with that also. I could be wrong about this though.

There are also checks within the code

Using configure for checking this and cleaning up checks for obsoleted
versions is a good plan. Please go ahead.

I will take a look at the open issues and see if it is resolved with
the

new version.

I am guessing my next steps would be looking into updating the build to
pull the jar?

Better use the mechanism provided by main/external_deps.lst

Herbert

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. 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.

Google Summer of Code 2013: Coming sooner than you think

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.

Regards,

-Rob

Re: Updating Java libraries

On Mon, Feb 11, 2013 at 2:06 PM, Michael Lam mnsyl4...@verizon.net 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


+1
fwiw
FC

Re: Updating Java libraries

On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger folli...@gmail.com wrote:

 but we should also
 respect that many distros are probably going to ship java 6 for a
 while.


for example?

FC

Re: Updating Java libraries

Haha, I don't know. I could be wrong.

I'm not trying to start a debate, but I'm just trying help to get
things working on as many current distros as possible.

Best Wishes,

Fred

On Mon, Feb 11, 2013 at 12:08 PM, Fernando Cassia fcas...@gmail.com wrote:
 On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger folli...@gmail.com wrote:

 but we should also
 respect that many distros are probably going to ship java 6 for a
 while.


 for example?

 FC

Re: Calc behavior: result of 0 ^ 0


Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit :

I usually want things to just work. If an arbitrary value is used, and it is 
not brought to my attention, I may not be producing the answer that I really 
want. Not returning an error gives me a false sense of security.


That's precisely my point. As long as the software gives an answer, you can't 
suspect a problem somewhere.

Do we want Calc to give an answer even if it's wrong and make users angry 
because Calc gave a wrong value? Or prevent him to spot a corner case (like 
#DIV/0! does)?
Of course, it's much easier to say that it could break compatibility and 
continue to give a nice politically correct value (1).

Rob, you talked about the 1900 leap year, it's exactly the same: should we 
continue providing a questionable value for the sake of compatibility with old 
files (even if there are very few of them with this situation) and 
compatibility with MS Office?

Hagar

Re: Updating Java libraries

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com wrote:

 Haha, I don't know. I could be wrong.


OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
developers'  perspective it' s as unattractive as some .Net developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: we should also respect that many distros are probably going to
ship java 6 for a while. = SciFi ?

FC



-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

Re: Calc behavior: result of 0 ^ 0


Le 11/02/2013 09:13, Andre Fischer a écrit :

We should change the ODF spec first instead.  A spec that basically says whatever you want to 
return is fine is of no value, as was proven in this thread.  This is something that I would 
only accept from a random() function.


+1. That's also what has been said by other posters (with some between the 
lines reading).



Besides, my emacs calc says that 0^0 is 1, so that can be the only correct 
answer, right?


:-)
But is there anyone with some real maths application that could check (R or 
Mathlab, ...)?

Hagar

Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 3:26 PM, Hagar Delest hagar.del...@laposte.net wrote:
 Le 11/02/2013 05:57, Andrew Douglas Pitonyak a écrit :

 I usually want things to just work. If an arbitrary value is used, and it
 is not brought to my attention, I may not be producing the answer that I
 really want. Not returning an error gives me a false sense of security.


 That's precisely my point. As long as the software gives an answer, you
 can't suspect a problem somewhere.

 Do we want Calc to give an answer even if it's wrong and make users angry
 because Calc gave a wrong value? Or prevent him to spot a corner case (like
 #DIV/0! does)?
 Of course, it's much easier to say that it could break compatibility and
 continue to give a nice politically correct value (1).

 Rob, you talked about the 1900 leap year, it's exactly the same: should we
 continue providing a questionable value for the sake of compatibility with
 old files (even if there are very few of them with this situation) and
 compatibility with MS Office?


But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
 It is not wrong per the ODF 1.2 standard.

-Rob

 Hagar

Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net wrote:
 Le 11/02/2013 09:13, Andre Fischer a écrit :

 We should change the ODF spec first instead.  A spec that basically says
 whatever you want to return is fine is of no value, as was proven in this
 thread.  This is something that I would only accept from a random()
 function.


 +1. That's also what has been said by other posters (with some between the
 lines reading).



 Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
 answer, right?


 :-)
 But is there anyone with some real maths application that could check (R or
 Mathlab, ...)?


Again, you are looking for the one true answer and declaring that
other answers are wrong.  That is not the case here.  Please review
this survey of the question from the sci.math FAQ on this point:

Consensus has recently been built around setting the value of 0^0 = 1

http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/

Regards,

-Rob


 Hagar

Re: Calc behavior: result of 0 ^ 0

2013-02-11 Thread RGB ES

2013/2/11 Hagar Delest hagar.del...@laposte.net

 Le 11/02/2013 09:13, Andre Fischer a écrit :

  We should change the ODF spec first instead.  A spec that basically says
 whatever you want to return is fine is of no value, as was proven in this
 thread.  This is something that I would only accept from a random()
 function.


 +1. That's also what has been said by other posters (with some between the
 lines reading).



  Besides, my emacs calc says that 0^0 is 1, so that can be the only
 correct answer, right?


 :-)
 But is there anyone with some real maths application that could check (R
 or Mathlab, ...)?


Maxima (a computer algebra system) gives an error. FreeMat (a Matlab clone)
gives 1. SciDAVis (an originLab clone) gives an error. Calligra Sheets
gives 1 (but you need to insert a = before, otherwise it takes it as text)

Also, remember that any change will break someone's workflow:

http://xkcd.com/1172/

Regards
Ricardo





 Hagar

Re: Calc behavior: result of 0 ^ 0

2013-02-11 Thread Торохов Сергей


02/10/13 04:43, Guenter Marxen пишет:

Hi,

I've looked in Wikipedia
http://en.wikipedia.org/wiki/Zero_power_zero#Zero_to_the_power_of_zero
and for me it seems very reasonable to keep the old behaviour, as 
according to this article many math and other software treats 0^0 = 1 
(see the paragraphs under Treatment on computers).


According to the German wikipedia Donald Knuth refuses to define 
0^0=undefined but claims = 1 because otherwise many mathematical 
theorema would need special case treatments.


So also mathematicians define 0^0=1. So let 0^0=1 in AOO.

Günter Marxen





In this case the expression 0^0 could be represents like f(x)^g(x) and 
the limit of this expression will depends of how rapidly each of f(x) 
and g(x) functions tends to NULL. So evaluation of indeterminate must be 
made individually in every case. To resolve it needs to take logarithm 
of initial expression and then try to find it's limit.


For example the  limit of x^x while x tends to 0 will be equal 1
(if I don't make a mistake)

---
Sergey Torokhov

4.0 and loss of backward compatibility for extensions with toolbar


You certainly have seen from the 0^0 discussion that I have raised the problem 
of the backward compatibility with 4.0 and extensions. In fact, it affects only 
the extensions with a custom toolbar. But except the dictionaries, I guess that 
it makes a good deal of them still.

The problem has been raised by Bernard Marcelly here: 
http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
But as said by Ariel, this is not an API change (so shouldn't the discussion on 
the API list be dropped and discussed here instead?): 
http://www.mail-archive.com/dev@openoffice.apache.org/msg04042.html

Rob has opened a wiki page related but without this topic (as for now): 
http://www.mail-archive.com/dev@openoffice.apache.org/msg03976.html

Basically (my understanding, don't hesitate to correct me):
- For a [minor] issue in the file structure, all the current extensions with a 
toolbar MUST be updated
- Updated and new extensions won't be compatible with former versions of AOO/OOo
For all the details, refer to the link given above.

Consequences:
- Users upgrading to 4.x will lose such extensions (certainly with no warning 
since very few users read the release notes)
- Both versions of each extension will have to be maintained as long as pre-4.0 
versions are still in use

So, are all the committers aware of this change and do they all agree about 
such a major change?

I know that there is a topic on the API list (link given above) but I'm not 
sure it has the same audience as the dev list (number of subscribers I mean). 
Since this is a major change, I think it deserves a discussion on the dev 
mailing list.
I know that if this change is implemented, the forums will be quickly flooded 
with users disappointed to have lost their extensions. So this is the topic I 
will point to in order to explain the dev community rationale about that.

I know that code change is sometimes required. But can we take into account the 
end-user impact here? There may be some transition solution with a deprecated 
method that would be still valid for some time (let's say until version 5.x for 
example) with a massive communication to all the accounts having uploaded an 
extension?

Hagar

Re: Calc behavior: result of 0 ^ 0


Le 11/02/2013 21:40, Rob Weir a écrit :

Again, you are looking for the one true answer and declaring that
other answers are wrong.


No. Even if my personal inclination is for the undefined result, I can 
understand the value 1.
But let the user decide and just warn him that he's facing a corner case that 
requests his attention.
That's all.

Hagar

Re: Calc behavior: result of 0 ^ 0

2013-02-11 Thread Торохов Сергей


P.S.

The over example:

[1-exp(x)]/x

 tends to -1 while x - 0

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

On Mon, Feb 11, 2013 at 4:10 PM, Hagar Delest hagar.del...@laposte.net wrote:
 You certainly have seen from the 0^0 discussion that I have raised the
 problem of the backward compatibility with 4.0 and extensions. In fact, it
 affects only the extensions with a custom toolbar. But except the
 dictionaries, I guess that it makes a good deal of them still.

 The problem has been raised by Bernard Marcelly here:
 http://www.mail-archive.com/api@openoffice.apache.org/msg00107.html
 But as said by Ariel, this is not an API change (so shouldn't the discussion
 on the API list be dropped and discussed here instead?):
 http://www.mail-archive.com/dev@openoffice.apache.org/msg04042.html

 Rob has opened a wiki page related but without this topic (as for now):
 http://www.mail-archive.com/dev@openoffice.apache.org/msg03976.html


I added a section to the existing AOO 4.0 release notes page on the wiki:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes

I didn't add any content to that section.

 Basically (my understanding, don't hesitate to correct me):
 - For a [minor] issue in the file structure, all the current extensions with
 a toolbar MUST be updated
 - Updated and new extensions won't be compatible with former versions of
 AOO/OOo
 For all the details, refer to the link given above.

 Consequences:
 - Users upgrading to 4.x will lose such extensions (certainly with no
 warning since very few users read the release notes)
 - Both versions of each extension will have to be maintained as long as
 pre-4.0 versions are still in use

 So, are all the committers aware of this change and do they all agree about
 such a major change?


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.

Then, when extensions are installed in the fresh AOO 4.0 system, users
will need to install extensions that are compatible with AOO 4.0.

 I know that there is a topic on the API list (link given above) but I'm not
 sure it has the same audience as the dev list (number of subscribers I
 mean). Since this is a major change, I think it deserves a discussion on the
 dev mailing list.
 I know that if this change is implemented, the forums will be quickly
 flooded with users disappointed to have lost their extensions. So this is
 the topic I will point to in order to explain the dev community rationale
 about that.


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 know that code change is sometimes required. But can we take into account
 the end-user impact here? There may be some transition solution with a
 deprecated method that would be still valid for some time (let's say until
 version 5.x for example) with a massive communication to all the accounts
 having uploaded an extension?


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:

AOO 3.4.1 - AOO 4.0
AOO 3.4.9 - AOO 4.0
OOo 3.3.0 - AOO 4.0
OOo 3.2.1 - AOO 4.0
OOo 3.2.0 - AOO 4.0

etc.

So the reduction in complexity should improve the user experience,
once they reinstall their extensions.

The other impact, as you noted, is on the extension author.  I think
for that we need clear communications, with plenty of time for them to
adapt, plus early availability of AOO 4.0 code for them to test with.

Unlike end users, developers know that API's change, and even if they
did not change they should know that they need to retest with major
new versions.  So we should have their attention with the 4.0 release.

I don't have an opinion on changing this for 4.x versus 5.x.

-Rob

 Hagar

Re: Updating Java libraries

OK, I won't build with java6 anymore then.

Fred

On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia fcas...@gmail.com wrote:
 On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com wrote:

 Haha, I don't know. I could be wrong.


 OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

 OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
 they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
 developers'  perspective it' s as unattractive as some .Net developer still
 using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
 matter.

 Ubuntu: OpenJDK 7
 http://packages.ubuntu.com/oneiric/openjdk-7-jdk

 Fedora 18: OpenJDK 7
 http://pkgs.org/download/java-1.7.0-openjdk

 SUSE: OpenJDK 7
 http://software.opensuse.org/package/java-1_7_0-openjdk

 Debian: OpenJDK 7
 http://packages.debian.org/sid/openjdk-7-jre

 ArchLinux: OpenJDK 7
 https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

 So, again: we should also respect that many distros are probably going to
 ship java 6 for a while. = SciFi ?

 FC



 --
 During times of Universal Deceit, telling the truth becomes a revolutionary
 act
 Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
 Revolucionario
 - George Orwell

RE: Calc behavior: result of 0 ^ 0

2013-02-11 Thread Dennis E. Hamilton

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 domain error *may* occur if x is xero and y is less than or equal 
to zero [emphasis mine].  The C++ library, for non-complex x or y, has 
pow(x,y) be as defined for C (without reference to any details) and math.h, 
at least in the 1999 book on The C++ Standard Library.  By ISO C++ 2003, 
pow(0,0) is implementation defined.  Of course none of this is about 
mathematics.  It is about constraints on the definitions of computer software 
libraries and the compromises that are made in order to find agreement on 
standards.  People vote on those.  Mathematics is not defined at the ballot box 
(and legislation of the value of pi is not mathematics [QED]).

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, February 11, 2013 12:40
To: dev@openoffice.apache.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net wrote:
 Le 11/02/2013 09:13, Andre Fischer a écrit :

 We should change the ODF spec first instead.  A spec that basically says
 whatever you want to return is fine is of no value, as was proven in this
 thread.  This is something that I would only accept from a random()
 function.


 +1. That's also what has been said by other posters (with some between the
 lines reading).



 Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
 answer, right?


 :-)
 But is there anyone with some real maths application that could check (R or
 Mathlab, ...)?


Again, you are looking for the one true answer and declaring that
other answers are wrong.  That is not the case here.  Please review
this survey of the question from the sci.math FAQ on this point:

Consensus has recently been built around setting the value of 0^0 = 1

http://www.faqs.org/faqs/sci-math-faq/specialnumbers/0to0/

Regards,

-Rob


 Hagar

Re: Updating Java libraries

On Mon, Feb 11, 2013 at 5:19 PM, Fred Ollinger folli...@gmail.com wrote:

 OK, I won't build with java6 anymore then.


don' t get me wrong, I don' t want to influence your decissions one way or
the other.
For sure there's a lot of openjdk 6 installed out there.

My point was that, going forward, most distros will have openjdk7.

FC


-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 4:25 PM, Hagar Delest hagar.del...@laposte.net wrote:
 Le 11/02/2013 21:40, Rob Weir a écrit :

 Again, you are looking for the one true answer and declaring that
 other answers are wrong.


 No. Even if my personal inclination is for the undefined result, I can
 understand the value 1.
 But let the user decide and just warn him that he's facing a corner case
 that requests his attention.
 That's all.


Maybe we should have spellchecker give a error for their because it
is often confused with there ?

Another example:  When entering a number, a percentage sign multiplies
the number by 0.01.

This usually works fine, e.g., 5% is automatically translated into
0.05.  But if you enter =5% % it will enter the value 0.0005.  My
guess is this feature is more often the result of a mistake than an
intentional user input.

There are dozens of such weird things in spreadsheets.

I could imagine a special mode for giving warnings about things like
this, but in normal operations I don't think we should distract the
user about things that are not errors.  And I certainly don't think we
should treat all of these items as errors, at least not by default.

Now back to the spell checking mode.  In some spell checkers they are
smart enough to give an error for their.  That is because they are
*sensitive to the context*.  They look at the context and can detect
whether the word is misused in that context.  I think we've all seen
tools that do this.  Personally, I find the, annoying since they given
many false-positive error message.  But treating their as an error
in all cases?  That is to give false-positives in almost all cases.
That doesn't make sense to me.

-Rob

 Hagar

Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 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.


If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
an axiom, then you might have a point there.   But it isn't.  The only
entity making logical conclusions and extrapolating to other
mathematical problems from the behavior of POWER() is the user.  So
your concern is not really valid in this context.

-Rob

 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 domain error *may* occur if x is xero and 
 y is less than or equal to zero [emphasis mine].  The C++ library, for 
 non-complex x or y, has pow(x,y) be as defined for C (without reference to 
 any details) and math.h, at least in the 1999 book on The C++ Standard 
 Library.  By ISO C++ 2003, pow(0,0) is implementation defined.  Of course 
 none of this is about mathematics.  It is about constraints on the 
 definitions of computer software libraries and the compromises that are made 
 in order to find agreement on standards.  People vote on those.  Mathematics 
 is not defined at the ballot box (and legislation of the value of pi is not 
 mathematics [QED]).

 -Original Message-
 From: Rob Weir [mailto:robw...@apache.org]
 Sent: Monday, February 11, 2013 12:40
 To: dev@openoffice.apache.org
 Subject: Re: Calc behavior: result of 0 ^ 0

 On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest hagar.del...@laposte.net 
 wrote:
 Le 11/02/2013 09:13, Andre Fischer a écrit :

 We should change the ODF spec first instead.  A spec that basically says
 whatever you want to return is fine is of no value, as was proven in this
 thread.  This is something that I would only accept from a random()
 function.


 +1. That's also what has been said by other posters (with some between the
 lines reading).



 Besides, my emacs calc says that 0^0 is 1, so that can be the only correct
 answer, right?


 :-)
 But is there anyone with some real maths application that could check (R or
 Mathlab, ...)?


 Again, you are looking for the one true answer and declaring that
 other

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


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).

Hagar

Re: Updating Java libraries

2013-02-11 Thread Kay Schenk




On 02/11/2013 02:19 PM, Fred Ollinger wrote:

OK, I won't build with java6 anymore then.

Fred


More than likely no need unless certain sites/people refuse to update to 
java 1.7. I really can't imagine who that would be at this point.




On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia fcas...@gmail.com wrote:

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com wrote:


Haha, I don't know. I could be wrong.



OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but from a
developers'  perspective it' s as unattractive as some .Net developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 for that
matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: we should also respect that many distros are probably going to
ship java 6 for a while. = SciFi ?

FC



--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell


--

MzK

A great deal of talent is lost to the world
  for want of a little courage.
 -- Sydney Smith

Re: Calc behavior: result of 0 ^ 0

I love it. I'd prefer a warning rather than silently giving me 1 even
if I had that in the past.

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.

Fred

On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton orc...@apache.org wrote:
 My apologies.  I replied to the wrong message, so the context was lost.  I 
 was responding to a statement that 0^0 = 1 is not wrong mathematically.  I 
 wanted to point out that is misleading, because it is also not right 
 mathematically.  POWER(x,y) implements an arithmetic function, and I agree 
 that is not a mathematical usage.

 I rose to object based on this statement:

 But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
  It is not wrong per the ODF 1.2 standard.

 (I think there are strings attached to the ODF 1.2 case and those strings 
 need to be tied, as has already been discussed.)

 To make amends for the diversion, I also want to offer my +1 for the 
 following which I did not see the first time:

 An interesting option would be to enable a strict or audit mode of
 calculation where all error-prone expressions are reported to the
 user.  This mode would be slower than a normal calculation, but would
 allow us to point out things like:

 1) Use of implementation-defined formulas that might impact
 interoperability (0^0 is one example, but there are several others)

 2) Dependency on automatic string to number conversion operations that
 might be interpreted differently in different locales.

 3) Operations that involve exact comparisons of results to constant
 floating numbers, something that is very risky due to round-off errors
 and precision limitations.

 4) String operations that silently returned reasonable values despite
 parameters that exceeded the bounds of the string.

 -Original Message-
 From: Rob Weir [mailto:robw...@apache.org]
 Sent: Monday, February 11, 2013 14:30
 To: dev@openoffice.apache.org; dennis.hamil...@acm.org
 Subject: Re: Calc behavior: result of 0 ^ 0

 On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 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.

 [ ... ]


 If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
 an axiom, then you might have a point there.   But it isn't.  The only
 entity making logical conclusions and extrapolating to other
 mathematical problems from the behavior of POWER() is the user.  So
 your concern is not really valid in this context.

 -Rob

 [ ... ]

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

On Mon, Feb 11, 2013 at 6:03 PM, Andrea Pescetti pesce...@apache.org 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.


So you are assuming that the authors of the top extensions will not
update their extensions?  Is that a reasonable assumption?  Why
wouldn't they update?

I agree that if we accepted that assumption then this looks like a bad
change.  But I do wonder about the validity of that assumption.

-Rob

 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).

 Regards,
   Andrea.

Re: Calc behavior: result of 0 ^ 0

2013-02-11 Thread Andrew Douglas Pitonyak


Oh no, please no popup

when I paste that formula into 1000 cells, I don't want 1000 popups. 
Sadly, I sometimes do stupid things like that when I have a warning in 
functions that I write myself and a debug message pops up during 
testing. Yeah, scary! Now, a single warning that is only ever shown 
once, yeah, ok, maybe.



On 02/11/2013 06:45 PM, Fred Ollinger wrote:

I love it. I'd prefer a warning rather than silently giving me 1 even
if I had that in the past.

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.

Fred

On Mon, Feb 11, 2013 at 3:04 PM, Dennis E. Hamilton orc...@apache.org wrote:

My apologies.  I replied to the wrong message, so the context was lost.  I was responding 
to a statement that 0^0 = 1 is not wrong mathematically.  I wanted to point 
out that is misleading, because it is also not right mathematically.  POWER(x,y) 
implements an arithmetic function, and I agree that is not a mathematical usage.

I rose to object based on this statement:

But returning 1 for 0^0 is not wrong.  It is not wrong mathematically.
  It is not wrong per the ODF 1.2 standard.

(I think there are strings attached to the ODF 1.2 case and those strings need 
to be tied, as has already been discussed.)

To make amends for the diversion, I also want to offer my +1 for the following 
which I did not see the first time:

An interesting option would be to enable a strict or audit mode of
calculation where all error-prone expressions are reported to the
user.  This mode would be slower than a normal calculation, but would
allow us to point out things like:

1) Use of implementation-defined formulas that might impact
interoperability (0^0 is one example, but there are several others)

2) Dependency on automatic string to number conversion operations that
might be interpreted differently in different locales.

3) Operations that involve exact comparisons of results to constant
floating numbers, something that is very risky due to round-off errors
and precision limitations.

4) String operations that silently returned reasonable values despite
parameters that exceeded the bounds of the string.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Monday, February 11, 2013 14:30
To: dev@openoffice.apache.org; dennis.hamil...@acm.org
Subject: Re: Calc behavior: result of 0 ^ 0

On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:

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.


[ ... ]
If OpenOffice were a theorem proving system and we put in 0^0 ==1 as
an axiom, then you might have a point there.   But it isn't.  The only
entity making logical conclusions and extrapolating to other
mathematical problems from the behavior of POWER() is the user.  So
your concern is not really valid in this context.

-Rob

[ ... ]



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

Re: Tutorial About

Hello Jorge,

On Mon, Feb 11, 2013 at 07:31:15PM -0600, jorge ivan poot diaz wrote:
 Hello,
 I've done the tutorial about but the expected result was not successful,
 here is the link:
 
 http://wiki.openoffice.org/wiki/Tutorial_About

Those tutorials are rather old, the code has changes in between.


 I've noticed that the source code has changed for example:
 
 cui/source/inc/about.hxx
 
 +   OKButtonaOKSureButton; (tutorial)
 +   OKButtonmaOKButton;  (source code)
 
 I understand that the source code has been modified but I want to know why I
 have added the code does not work, does not generate the button. If the
 button OKButton if successfully generated.
 
 Please I want to know the reason why I can not generate the button.

I have no idea what you have done. Can you generate a patch with your
changes?


 Another important point of the code cui / source / dialogs / about.cxx gives
 me the impression that has changed because the code shown before the
 structure is completely different this is

It has obviously changed since 2007,
http://svn.apache.org/viewvc/openoffice/trunk/main/cui/source/dialogs/about.cxx?view=log


  // OK-Button-Position (at the bottom and centered)

ups, it's not centered, but positioned on the left!

 Size aOKSiz = maOKButton.GetSizePixel();
 Point aOKPnt( ( aDlgSize.Width() - aOKSiz.Width() ) - a6Size.Width(),
 nY );
 maOKButton.SetPosPixel( aOKPnt );
 
 
 How I can implement the tutorial about in the source code to generate the
 button?
 
 What would be the changes I should make to the source code?
 
 Help me.

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:

]$ cd SRC_ROOT/main/cui
]$ cat PATH_TO_PATH | patch -p1
]$ build debug=true dbglevel=3   deliver
]$ cp -fv unxlngx6/lib/libcui.so  BASIS_DIR/basis4.0/program/libcui.so


Once you get a general idea of how it works, try changing something
else: modify the button type, make it a simple push button, and add
a call back so that when it is pressed you show a Hello world! message
box.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina
diff --git a/main/cui/source/dialogs/about.cxx 
b/main/cui/source/dialogs/about.cxx
index b753a3f..4ef4e81 100644
--- a/main/cui/source/dialogs/about.cxx
+++ b/main/cui/source/dialogs/about.cxx
@@ -282,6 +282,7 @@ namespace
 AboutDialog::AboutDialog( Window* pParent, const ResId rId ) :
 SfxModalDialog( pParent, rId ),
 maOKButton( this, ResId( RID_CUI_ABOUT_BTN_OK, *rId.GetResMgr() ) ),
+maOKButtonCenter( this, ResId( RID_CUI_ABOUT_BTN_OK, *rId.GetResMgr() ) ),
 maReadmeButton( this, ResId( RID_CUI_ABOUT_BTN_README, *rId.GetResMgr() ) 
),
 maVersionText( this, ResId( RID_CUI_ABOUT_FTXT_VERSION, *rId.GetResMgr() ) 
),
 maBuildInfoEdit( this, ResId( RID_CUI_ABOUT_FTXT_BUILDDATA, 
*rId.GetResMgr() ) ),
@@ -434,11 +435,14 @@ void AboutDialog::LayoutControls( Size aDlgSize )
 maMainLogoPos = Point( 0, nY / 2 - aMainLogoSz.Height() / 2 );
 maAppLogoPos = Point( nCol1 + a6Size.Width(), 0 );
 
-// OK-Button-Position (at the bottom and centered)
+// OK-Button-Position (at the bottom and right)
 Size aOKSiz = maOKButton.GetSizePixel();
 Point aOKPnt( ( aDlgSize.Width() - aOKSiz.Width() ) - a6Size.Width(), nY );
 maOKButton.SetPosPixel( aOKPnt );
 
+// center the button in the middle
+maOKButtonCenter.SetPosPixel( Point( aDlgSize.Width() / 2 - 
maOKButtonCenter.GetSizePixel().Width() / 2, nY ) );
+
 maReadmeButton.SetPosPixel( Point(a6Size.Width(), nY) );
 
 aDlgSize.Height() = aOKPnt.Y() + aOKSiz.Height() + a6Size.Width();
diff --git a/main/cui/source/inc/about.hxx b/main/cui/source/inc/about.hxx
index 552086d..0fbb63b 100644
--- a/main/cui/source/inc/about.hxx
+++ b/main/cui/source/inc/about.hxx
@@ -38,6 +38,7 @@ class AboutDialog : public SfxModalDialog
 {
 private:
 OKButtonmaOKButton;
+OKButtonmaOKButtonCenter;
 PushButton  maReadmeButton;
 FixedInfo   maVersionText;
 MultiLineEdit   maBuildInfoEdit;


pgpH2wSOqyMKt.pgp
Description: PGP signature

Re: Tutorial About

2013-02-11 Thread jorge ivan poot diaz

I understand the changes but that should not impede the buttons may not work as
I applied the instructions in the required classes. So why not work?


2013/2/11 Ariel Constenla-Haile arie...@apache.org

 On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
  ]$ cd SRC_ROOT/main/cui
  ]$ cat PATH_TO_PATH | patch -p1

 if you are in main/cui it should be -p3 instead of -p1

  ]$ build debug=true dbglevel=3   deliver
  ]$ cp -fv unxlngx6/lib/libcui.so
  BASIS_DIR/basis4.0/program/libcui.so



 --
 Ariel Constenla-Haile
 La Plata, Argentina

Re: Tutorial About

On Mon, Feb 11, 2013 at 09:00:55PM -0600, jorge ivan poot diaz wrote:
 I understand the changes but that should not impede the buttons may not work 
 as
 I applied the instructions in the required classes. So why not work?

I can't guess without seeing what you've done. Please attach a patch
with your changes (the changes as they are in the Wiki won't even
compile).

-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpw4tDBUl5qz.pgp
Description: PGP signature

Re: Updating Java libraries


On 02/11/2013 05:43 PM, Kay Schenk wrote:



On 02/11/2013 02:19 PM, Fred Ollinger wrote:

OK, I won't build with java6 anymore then.

Fred


More than likely no need unless certain sites/people refuse to update 
to java 1.7. I really can't imagine who that would be at this point.




On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia fcas...@gmail.com 
wrote:
On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger folli...@gmail.com 
wrote:



Haha, I don't know. I could be wrong.



OpenJDK 7 is the current version, OpenJDK 8 is coming along nicely.

OpenJDK 6 is the past. Yes, there' s been some RedHat volunteers saying
they' ll keep releasing OpenJDK 6 updates and security fixes, but 
from a
developers'  perspective it' s as unattractive as some .Net 
developer still
using the Net 1.0 APIs... or a Java developer still using JDK 1.4 
for that

matter.

Ubuntu: OpenJDK 7
http://packages.ubuntu.com/oneiric/openjdk-7-jdk

Fedora 18: OpenJDK 7
http://pkgs.org/download/java-1.7.0-openjdk

SUSE: OpenJDK 7
http://software.opensuse.org/package/java-1_7_0-openjdk

Debian: OpenJDK 7
http://packages.debian.org/sid/openjdk-7-jre

ArchLinux: OpenJDK 7
https://www.archlinux.org/packages/extra/x86_64/jre7-openjdk/

So, again: we should also respect that many distros are probably 
going to

ship java 6 for a while. = SciFi ?

FC



--
During times of Universal Deceit, telling the truth becomes a 
revolutionary

act
Durante épocas de Engaño Universal, decir la verdad se convierte en 
un Acto

Revolucionario
- George Orwell


Using a newer JDK is fine, just need to make sure the target version is 
correct. I am not sure what version is the minimum, I would guess 1.5. 
Need to be careful not to use features that is not supported by the 
minimum version. Let's not limit to just Linux distros. There is 
probably a good portion of users on Windows and not everybody is on top 
of their updates.


Michael

Re: Updating Java libraries

I am guessing my next steps would be looking into updating the build to 
pull the jar?

Better use the mechanism provided by main/external_deps.lst

Herbert




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, I can look into simplifying the 
build a little bit. I am thinking I just need to emulate 
--with-hsqldb-jar and the rest of the build does not need to be touch, 
any pointer along that line would also be helpful.


Michael

Re: Tutorial About

2013-02-11 Thread jorge ivan poot diaz

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.


2013/2/11 jorge ivan poot diaz ivan.pootd...@gmail.com

 I understand the changes but that should not impede the buttons may not
 work as I applied the instructions in the required classes. So why not
 work?


 2013/2/11 Ariel Constenla-Haile arie...@apache.org

 On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
  ]$ cd SRC_ROOT/main/cui
  ]$ cat PATH_TO_PATH | patch -p1

 if you are in main/cui it should be -p3 instead of -p1

  ]$ build debug=true dbglevel=3   deliver
  ]$ cp -fv unxlngx6/lib/libcui.so
  BASIS_DIR/basis4.0/program/libcui.so



 --
 Ariel Constenla-Haile
 La Plata, Argentina

Re: Tutorial About

2013-02-11 Thread jorge ivan poot diaz

Here are the patch.


2013/2/12 jorge ivan poot diaz ivan.pootd...@gmail.com

 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.


 2013/2/11 jorge ivan poot diaz ivan.pootd...@gmail.com

 I understand the changes but that should not impede the buttons may not
 work as I applied the instructions in the required classes. So why not
 work?


 2013/2/11 Ariel Constenla-Haile arie...@apache.org

 On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
  ]$ cd SRC_ROOT/main/cui
  ]$ cat PATH_TO_PATH | patch -p1

 if you are in main/cui it should be -p3 instead of -p1

  ]$ build debug=true dbglevel=3   deliver
  ]$ cp -fv unxlngx6/lib/libcui.so
  BASIS_DIR/basis4.0/program/libcui.so



 --
 Ariel Constenla-Haile
 La Plata, Argentina

Re: Tutorial About