Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt]

On 2/11/13 5:39 AM, Andrew Douglas Pitonyak 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. 

that is indeed the most interesting thing of this whole thread.

Juergen


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

Re: Calc behavior: result of 0 ^ 0

[Andre Fischer]

On 10.02.2013 00:11, Andrea Pescetti wrote:
A good practical example of backwards-incompatible changes in version 
4.0 is the behavior of Calc while computing 0 ^ 0.


You can find a long issue, with different points of view, about this at:
https://issues.apache.org/ooo/show_bug.cgi?id=114430
but in short:
- Obviously, 0 ^ 0 is an illegal operation in mathematics and the 
result is undefined/invalid

- In 3.4.1, "=0 ^ 0" returns 1
- In 4.0, as patched by Pedro (see issue), "=0 ^ 0" would return an error
- According to ODF, valid results are 0, 1, error
- We gain interoperability since Excel returns an error too
- We lose backwards compatibility if someone was relying on the fact 
that OpenOffice returns 1 as the result of "=0 ^ 0"


I'm OK with the proposed change, provided we advertise it in the 
release notes. I'm not aware of any cases where someone is actively 
using the fact that in Calc 0 ^ 0 evaluates to 1, and even if someone 
did, I would say that his spreadsheets should not compute 0 ^ 0 at 
all. A side benefit would be that school students quickly wanting to 
find out what is the result of 0 ^ 0 would be told the truth (it's an 
error) instead of being presented with a numeric result and no 
warnings. (Then the student would go on and write "= - 2 ^ 2" and have 
a lot of fun, but this is out of scope here).


Is there consensus that this is a reasonable backwards-incompatible 
change, or compelling reasons to revert it?


I would like to propose to revert the change because, as Rob said 
elsewhere in this thread, this is not a mathematical question.  If the 
the ODF spec says that 0,1, and error are valid return values and we 
return 1 then there is no error (despite the three exclamation marks in 
the title of the bug).


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


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.


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


Regards,
Andre

Re: Calc behavior: result of 0 ^ 0

[Jürgen Schmidt]

On 2/10/13 9:51 PM, Hagar Delest wrote:
> Le 10/02/2013 21:21, Rob Weir a écrit :
>> Did you not notice the title of this thread? Has it entirely escaped
>> you that we're talking about 0^0 here?  If you want to start another
>> threat about extensions, then go ahead and I will comment there.  But
>> anyone of the intelligence of a grapefruit would not find it strange
>> that I am discussing only 0^0 in this thread.
> 
> And have you read my previous message?
> I don't understand why there is almost nothing aired when there are
> talks about breaking the compatibility of ALL the extensions because of
> a minor issue. And here you're challenging a change that will affect
> very few users.

"ALL the extensions" is of course completely nonsense. The change we
talked about is only for extensions that define an own toolbar.

And we can of course start a new discussion about the missing
cooperation of extension developers to work with core developers. It can
be relatively easy fixed by any extension developer. And of course with
a little extra work in a way that breaks nothing. Minor effort in the
extensions, much more and more complex code in the core.

The question is always how we want to move forward. Changes are good if
they help to attract more developers and if they help to improve the
product over time.

If developers can't change things and can't improve code etc. over time
we will have a problem to find enough developers who are willing to
maintain old incomprehensible code that we have in many areas.

That don't mean that I support any kind of incompatible change but when
we have a simple migration path in place and when we talk about a major
version I will probably support most of them.

Juergen

> 
> You told in your first message that you were concerned that the change
> would break the backward compatibility.
> But are you not concerned by all the users having their extensions
> deactivated by a minor API change???
> 
> There is your other message:
> Le 09/02/2013 18:40, Rob Weir a écrit :
>> I've added a new section to the 4.0 Release Notes for tracking changes
>> that impact backwards compatibility:
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes
>>
>>
>> This would include changes to the public interfaces of AOO, including
>> incompatible changes to API's (including spreadsheet functions), file
>> formats, etc.
> 
> But I don't see any reference to the extensions issue.
> 
> If there is a real problem to be talked about, it's more the API change
> that would break extensions compatibility.
> Honestly, I don't care about the 0^0 issue. Not enough users will be
> impacted.
> 
> Hagar

Re: Calc behavior: result of 0 ^ 0

[Ariel Constenla-Haile]

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

[Ariel Constenla-Haile]

On Sun, Feb 10, 2013 at 09:51:25PM +0100, Hagar Delest wrote:
> And have you read my previous message?  I don't understand why there
> is almost nothing aired when there are talks about breaking the
> compatibility of ALL the extensions because of a minor issue. And here
> you're challenging a change that will affect very few users.
> 
> You told in your first message that you were concerned that the change
> would break the backward compatibility.  But are you not concerned by
> all the users having their extensions deactivated by a minor API
> change???

That change is in the configuration schema, not in the API; so, this
isn't an API change.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpAdwSIyiW7l.pgp
Description: PGP signature

Re: Calc behavior: result of 0 ^ 0

[Rob Weir]

On Sun, Feb 10, 2013 at 11:39 PM, Andrew Douglas Pitonyak
 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

[Michael Lam]

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

[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

[Michael Lam]

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: Calc behavior: result of 0 ^ 0

[Andre Fischer]

On 11.02.2013 17:10, Andrea Pescetti wrote:

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


Fair point.




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. 


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

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.


It probably depends on who uses a spec.  A user to find out what the 
result of a certain operation should be.  Or a developer implementing 
the spec.  For the later it might be good to have some freedom.  A user 
might prefer a spec that clearly states what the expected result for a 
given set of arguments is.  Especially when that result is not canonical 
like 1+1=2.


-Andre

Re: Updating Java libraries

[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

[Rob Weir]

On Thu, Feb 7, 2013 at 2:32 PM, Fred Ollinger  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 getObject(String s, Class T) throws SQLException
> { throw new SQLException(); }
> +public  T getObject(int i, Class 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 getObject(String,Class) 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 @@
>   * 
>   * A method that gets information about a feature that the driver does not
>   * support will throw an SQLException.
> - * In the case of methods that return a ResultSet
> + * In the case of methods that eeturn a ResultSet
>   * object, either a ResultSet object (which may be empty) is
>   * returned or an SQLException is thrown.
>   *
> @@ -282,6 +282,13 @@
>   */
>  public class jdbcDatabaseMetaData implements DatabaseMetaData {
>
> +//#i

Re: Updating Java libraries

[Kay Schenk]

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  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=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!


yes, great news!


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


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?

[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

[Michael Lam]

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

On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  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=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!


yes, great news!




  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?


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




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

[Fred Ollinger]

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  wrote:
> On 02/11/2013 01:16 PM, Kay Schenk wrote:
>>
>> On Mon, Feb 11, 2013 at 9:24 AM, Herbert Duerr  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=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!
>>
>>
>> yes, great news!
>>
>>
>>>
>>>   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?
>>
>>
>> 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
>>>
>>
>>
> 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

[Rob Weir]

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

[Fernando Cassia]

On Mon, Feb 11, 2013 at 2: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


+1
fwiw
FC

Re: Updating Java libraries

[Fernando Cassia]

On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger  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

[Fred Ollinger]

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  wrote:
> On Mon, Feb 11, 2013 at 2:16 PM, Fred Ollinger  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

[Hagar Delest]

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

[Fernando Cassia]

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  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

[Hagar Delest]

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

[Rob Weir]

On Mon, Feb 11, 2013 at 3:26 PM, Hagar Delest  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

[Rob Weir]

On Mon, Feb 11, 2013 at 3:32 PM, Hagar Delest  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

[RGB ES]

2013/2/11 Hagar Delest 

> 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

[Donald Whytock]

Google docs spreadsheet gives 1.

On Mon, Feb 11, 2013 at 3:41 PM, RGB ES  wrote:
> 2013/2/11 Hagar Delest 
>
>> 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

[Торохов Сергей]

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

[Hagar Delest]

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

[Hagar Delest]

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

[Торохов Сергей]

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

[Rob Weir]

On Mon, Feb 11, 2013 at 4:10 PM, Hagar Delest  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

[Fred Ollinger]

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

Fred

On Mon, Feb 11, 2013 at 12:30 PM, Fernando Cassia  wrote:
> On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  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

[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 , 
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  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

[Fernando Cassia]

On Mon, Feb 11, 2013 at 5:19 PM, Fred Ollinger  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

[Rob Weir]

On Mon, Feb 11, 2013 at 4:25 PM, Hagar Delest  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

[Rob Weir]

On Mon, Feb 11, 2013 at 5:24 PM, Dennis E. Hamilton
 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 , 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  
> 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

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

[Hagar Delest]

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

[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  wrote:

On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  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: 4.0 and loss of backward compatibility for extensions with toolbar

[Andrea Pescetti]

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


Regards,
  Andrea.

RE: Calc behavior: result of 0 ^ 0

[Dennis E. Hamilton]

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

[Rob Weir]

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?

-Rob

> Hagar

Re: Calc behavior: result of 0 ^ 0

[Fred Ollinger]

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

[Rob Weir]

On Mon, Feb 11, 2013 at 6:03 PM, 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.
>

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: 4.0 and loss of backward compatibility for extensions with toolbar

[Rob Weir]

On Mon, Feb 11, 2013 at 6:46 PM, Rob Weir  wrote:
> On Mon, Feb 11, 2013 at 6:03 PM, 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.
>>
>
> 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?
>

Answering my own question:  the top downloaded extension is the PDF
Importer, and that has Oracle listed as the owner.  If this extension
is actually unmaintained, then it would be broken, yes.  Of course, if
it is unmaintained, then it is in a very fragile position now, and
almost anything can break it, from AOO changes, to platform changes to
changes in dependent libraries.  I'd say:  if we don't have a plan for
getting such extensions maintained then we should already write them
off as broken.  They will fall over when the wind blows.  It is only a
matter of time.

So my question then is:  are there any top maintained extensions where
the author would not adapt it to the proposed AOO 4.0 changes?  If
this is the case, what is their concern?  They don't like the change
from a technical perspective?  They don't have time to make the
change?  Something else?

-Rob

> 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

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

[Ariel Constenla-Haile]

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 /main/cui
]$ cat  | patch -p1
]$ build debug=true dbglevel=3  && deliver
]$ cp -fv /lib/libcui.so  /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

[Ariel Constenla-Haile]

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

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

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



-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpES5hhKzyTH.pgp
Description: PGP signature

Re: Tutorial About

[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 

> On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
> > ]$ cd /main/cui
> > ]$ cat  | patch -p1
>
> if you are in main/cui it should be -p3 instead of -p1
>
> > ]$ build debug=true dbglevel=3  && deliver
> > ]$ cp -fv /lib/libcui.so
>  /basis4.0/program/libcui.so
>
>
>
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>

Re: Tutorial About

[Ariel Constenla-Haile]

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

[Michael Lam]

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  
wrote:
On Mon, Feb 11, 2013 at 3:13 PM, Fred Ollinger  
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

[Michael Lam]

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: Updating Java libraries

[Ariel Constenla-Haile]

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
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpGTvDryoQ0D.pgp
Description: PGP signature

Re: Tutorial About

[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 

> 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 
>
>> On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
>> > ]$ cd /main/cui
>> > ]$ cat  | patch -p1
>>
>> if you are in main/cui it should be -p3 instead of -p1
>>
>> > ]$ build debug=true dbglevel=3  && deliver
>> > ]$ cp -fv /lib/libcui.so
>>  /basis4.0/program/libcui.so
>>
>>
>>
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
>>
>
>

Re: Tutorial About

[jorge ivan poot diaz]

Here are the patch.


2013/2/12 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 
>
>> 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 
>>
>>> On Mon, Feb 11, 2013 at 11:26:22PM -0300, Ariel Constenla-Haile wrote:
>>> > ]$ cd /main/cui
>>> > ]$ cat  | patch -p1
>>>
>>> if you are in main/cui it should be -p3 instead of -p1
>>>
>>> > ]$ build debug=true dbglevel=3  && deliver
>>> > ]$ cp -fv /lib/libcui.so
>>>  /basis4.0/program/libcui.so
>>>
>>>
>>>
>>> --
>>> Ariel Constenla-Haile
>>> La Plata, Argentina
>>>
>>
>>
>

Re: Tutorial About

[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


pgp8RH8eudWBc.pgp
Description: PGP signature

Re: Apache Open Office IAccessible2 QA ia2 branch builds

[V Stuart Foote]

Jamie,


Date: Tue, 12 Feb 2013 05:21:02 +1000

From: James Teh mailto:ja...@nvaccess.org>>

To: NVDA screen reader development

Subject: Re: [NVDA-dev] Apache Open Office IAccessible2 QA ia2 branch

  builds



>Hi Stuart,

>Thanks for letting us know. Initial testing is very promising. I'm

>working on a few tweaks to get NVDA to use some of its custom code for

>symphony to allow for reporting of formatting, etc. (Unfortunately,

>Symphony's IA2 implementation doesn't follow the IA2 standard in some

>areas, though we've already worked around this.)



Yes I've spent a bit more time with it, and Steve Yin's folks have done a 
superb job so far. I am concerned though that you see "non-standard" IA2, 
because while the ia2 Branch builds thus far have been for Windows testing, 
assume that other accessibility components of the Symphony contributed code 
will also be merged in some fashion.



Assume you'd like things to be IAccessible2 1.2.1 and better draft 1.3 
compliant. But that will mean some work under the hood to move the Symphony ia2 
code base onto the emerging standards for IAccessible2. Obviously lots of work, 
and at this point Steve Yin characterizes the work on IAccessible2 at only 5% 
complete-so for getting collaboration on standards compliance in place--now is 
the best time.



Also, for the other bridges--ATK/AT-SPI and NSAccessible--and their mappings of 
the existing UNO Accessibility API, this ongoing work on a native Windows 
bridge offers an opportunity to clean up and redefine incomplete or inadequate 
roles and mappings to bring all the APIs equivalent correcting any omissions. 
And I'd hope that once started, the whole UNO Accessibility API could 
ultimately be systematically extended to support needs of all the ISO/IEC 
13066-1 parts for improving AT.



>I found and read the mailing list thread about this support and saw your

>question about bug tracking, but there hasn't been a response yet. I'll

>check the thread from time to time, but it'd be great if you could let

>us know once a decision has been made about bug tracking. I'm hoping for

>Bugzilla, as this makes for better tracking and I'd rather not be

>swamped by the general ooo-dev list. :)



Will keep an eye out for response. Will post back to the nvda-dev forum any 
guidance.

Stuart

Quick refs:
AOO 4.0 IAccessible2 - 
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+IAccessible2
Why IAccessible2 - http://wiki.openoffice.org/wiki/Why_IAccessibile2