Join OpenOffice at ApacheCon North America!
Forwarding a message from the ApacheCon NA organizers. See http://na.apachecon.com/ for details. To those going to attend: you may also consider to join some informal activities, see http://wiki.apache.org/apachecon/HackathonNA13 and http://wiki.apache.org/apachecon/BarCampApachePortland --- Hi All It's now about 3 weeks until ApacheCon North America, which is taking place Sunday 24th Feb - Thursday 28th in Portland. Quite a few people will be there, and we'd love to see you all! If you haven't already registered for the conference, then we've some good news - we've managed to snag a 20% discount for you! To register with the 20% off, use code PMC or the link http://acna13.eventbrite.com/?discount=PMC [ Note: this code can by used by anyone on the dev list ] To see what the talks are, including the ones relating to our project, please see the schedule - http://na.apachecon.com/schedule/ Would you like to get more involved in the project? Maybe learn more about contributing, get some mentoring on a patch, or help collaborate on some fixes? People from the project may be at the (Free!) Hackathon on the Monday. If you'd like to come, whether you can make it to the main conference or not, the details are on the ApacheCon wiki: http://wiki.apache.org/apachecon/HackathonNA13 Also talking of free, a few of us will be at the BarCamp on the Sunday. This is open to everyone, Portland natives and conference-goers alike, and should be a great chance to share new ideas and learn about existing + upcoming projects. To sign up to come to that, or learn more, it's http://wiki.apache.org/apachecon/BarCampApachePortland Hopefully see some of you in Portland in a few weeks!
Re: Case Study on Open Office
On 03/02/2013 Ryan, Benjamin wrote: 1. Identify the software development approaches used in the development of the Software? e.g Open office What software development approaches were used eg Structured(top-down) prototyping,RAD or Agile I have little to add to what Rob already answered. OpenOffice is a community effort, so we don't enforce any particular methodologies. The project has coding standards, see for example http://wiki.openoffice.org/wiki/Cpp_Coding_Standards and http://wiki.openoffice.org/wiki/Writer/Code_Conventions ; and it has a number of development branches where new features are developed before being merged to the main trunk. So nothing unusual in this respect. We may use a review then commit or commit then review approach depending on the impact of a change, but we ensure that all new code is reviewed by peer developers. 6. Evaluate how effectively the new system met the needs of the user or the target market? How the software has met the needs of the user and target audience At the current statistics Open office has taken 14% of Microsoft offices sale which is quiet significant Market-Share etc We invite feedback from the users and ask them how OpenOffice can better meet their needs. For example, months ago we ran a Google Moderator initiative https://www.google.com/moderator/#16/e=2011d5 asking users for their priorities in the OpenOffice development, and getting about 1000 new ideas from them. Regards, Andrea.
Re: which version to use
Galileo, 3.4.1 is the most recent version. You can download it from here: http://www.openoffice.org/download/ - Shenfeng (Simon) 2013/2/3 Galileo Teco Juárez genital...@gmail.com hi I volunter I volunteer I begin to understand the development of extensions I have a question. which is the most stable version to start always downloaded the latest version -- *Galileo Teco Juarez* *Web:* http://80bits.wordpress.com *Twitter:* @genitalico http://twitter.com/genitalico *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
Re: Draft blog post: $21 million per day
On Sat, Feb 9, 2013 at 6:25 AM, Sally Khudairi sallykhuda...@yahoo.com wrote: Rob, et.al. --is there a preferred day/time you'd like to go live with this? Given that you, Don, and I all live in the snow-socked East Coast, should we give ourselves some blizzard recovery time or just go ahead (say, on Tuesday)? Snow should end for us my mid-afternoon today. State has a ban on driving so roads are empty. USPS has suspended mail delivery. But we didn't lose electricity. So I can publish this anytime. But if Tuesday 8am EST works well, I can aim for that. -Rob Thanks in advance, Sally [From the mobile; kindly excuse spelling/spacing/auto-correct anomalies] - Reply message - From: Rob Weir robw...@apache.org To: dev@openoffice.apache.org Cc: Sally Khudairi s...@apache.org Subject: Draft blog post: $21 million per day Date: Thu, Feb 7, 2013 7:39 PM https://blogs.apache.org/preview/OOo/?previewEntry=21_million_per_day Hoping to publish early next week. Regards, -Rob
Re: Will AOO write .docx?
Hi, Jürgen Schmidt schrieb: 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. I have written to Mathias Stürmer and ask, how to get the patches. Kind regards Regina
Bugzilla legacy login instructions
We currently have this message in Bugzilla: Please Note: All users with accounts with the legacy OpenOffice.org issue tracker must reset their passwords to gain access to their old accounts. To reset your password, click on the Forgot Password link in the header or footer and enter your user name. Note: If your user name when the service was hosted at Oracle was myuser, then your login for the migrated Bugzilla instance will be the email address associated with myu...@openoffice.org. So not the openoffice.org address, but the address that the openoffice.org address was previously forwarded to. Is this still relevant? How does a password reset work today if the legacy openoffice.org email forwarder is gone? -Rob
Re: Bugzilla legacy login instructions
On 9 February 2013 16:19, Rob Weir robw...@apache.org wrote: We currently have this message in Bugzilla: Please Note: All users with accounts with the legacy OpenOffice.org issue tracker must reset their passwords to gain access to their old accounts. To reset your password, click on the Forgot Password link in the header or footer and enter your user name. Note: If your user name when the service was hosted at Oracle was myuser, then your login for the migrated Bugzilla instance will be the email address associated with myu...@openoffice.org. So not the openoffice.org address, but the address that the openoffice.org address was previously forwarded to. Is this still relevant? How does a password reset work today if the legacy openoffice.org email forwarder is gone? At least I can say, that I have no problem accessing my account (but this might be a new account compared to oracle accounts). I did look at the notice an wondered. I think we could remove the message, after this al this time, I am sure the old users have accessed (or tried to) access their accounts. Meaning at this point of time, it is either new users, or legacy user that have a new password. rgds Jan I. -Rob
Re: Bugzilla legacy login instructions
Rob Weir wrote: We currently have this message in Bugzilla: ... Is this still relevant? How does a password reset work today if the legacy openoffice.org email forwarder is gone? It is still relevant, but it doesn't need to stay in evidence. Anyway, it works like this: if j...@openoffice.org used to be an alias for j...@example.org, the user can regain access by asking a new password for j...@example.org. This adjustment was done by Infra when the @openoffice.org aliases were retired and should still work. But I honestly doubt that this is still useful to someone: I agree this should be removed or moved to a less prominent position, like on the password reset page only. Regards, Andrea.
Changes that Impact Backwards Compatibility
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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
RE: [Call For QA Volunteers] AOO UI IAccessible2 testing work
Steve, Nothing substantive yet in working through the Windows build of the ia2 branch. Should we build against Linux and OSX and be testing for impact on ATK/AT-SPI and NSAccessibility User Interface? And, with QA and testing of the ia2 branch proceeding what mechanism should folks use for reporting and tracking issues on the ia2 branch builds? Should we stay with PM and ML exchanges, or start to use Bugzilla at issues.apache.org/ooo? I believe that starting with BZ tracking now provides continuity upon merge of branch back into AOO4.00. And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2 release planning wiki that QA participants and casual users report in Bugzilla categorized for consistency as against: Product: UI Component: AccessBridge Version: AOO4.00-dev Stuart =-=-= Sidebar--the legacy IAccessible2 enhancement bug could probably be revised https://issues.apache.org/ooo/show_bug.cgi?id=107914 And here is a generic BZ search for accessibility issues https://issues.apache.org/ooo/buglist.cgi?query_format=advancedresolution=---short_desc=msaa%20accessible%20iaccessible%20iaccessible2%20accessibilityshort_desc_type=anywordssubstrorder=component%2Cpriority%2Cbug_severityquery_based_on=
Re: Changes that Impact Backwards Compatibility
Hi. When do you expect a feature to enter the list. 1) Before development 2) Before committing to trunk (e.g. committed in a branch) 3) after QA. The reason for my question, is that I work on l10n tools, which I hope will make it to 4.0, The tools have a high effect on the translation process: a) the sdf files will no longer exist b) t On 9 February 2013 18:40, Rob Weir robw...@apache.org wrote: 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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
Re: Mwiki is moved into maintenance mode.
On 8 February 2013 21:52, Andrea Pescetti pesce...@apache.org wrote: - Move cwiki to mwiki. this has been discussed/decided earlier, but might need a positive decision. I agree, we can progressively move stuff by turning pages into redirects to the MWiki. This may take time but could be the less problematic way (for example, I had created the FOSDEM pages on the cwiki but they should be moved to the mwiki since other FOSDEM pages are archived there). A drastic redirect could confuse people who are actively working on some pages, like the logo discussions. Is there some filter to allow smooth translation of cwiki syntax? There appear to be no commonly-available filters to move pages in bulk from Confluence to MediaWiki, preserving links and formatting. The general problem is that anyone who moves a wiki from one engine to another does the job precisely once, so there's no-one who really maintains a good converter script, and the knowledge doesn't accumulate (as it does in an ongoing open-source project). That said, there are people who do want to move from Confluence to MediaWiki and end up doing it by a quick hack without the knowledge accumulating. So if you do go for an automated method and come up with a script, please do put the details and script up on http://mediawiki.org , and others with the same problem in the future will be grateful. - d.
Changes that Impact Backwards Compatibility
-- Forwarded message -- From: janI j...@apache.org Date: 9 February 2013 19:17 Subject: Re: Changes that Impact Backwards Compatibility To: janI j...@apache.org Stupid browser sorry for that. On 9 February 2013 19:15, janI j...@apache.org wrote: Hi. When do you expect a feature to enter the list. 1) Before development 2) Before committing to trunk (e.g. committed in a branch) 3) after QA. The reason for my question, is that I work on l10n tools, which I hope will make it to 4.0, The tools have a high effect on the translation process: a) the sdf files will no longer exist b) there will only be 2x45 files c) help and ui will not be seperate projects. The first part is available in branch l10n but not integrated in build, or tested yet. Rgds Jan I. On 9 February 2013 18:40, Rob Weir robw...@apache.org wrote: 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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
RE: [Call For QA Volunteers] AOO UI IAccessible2 testing work
From: V Stuart Foote Sent: Saturday, February 09, 2013 12:05 PM And here is a generic BZ search for accessibility issues https://issues.apache.org/ooo/buglist.cgi?query_format=advancedresolution=---short_desc=msaa%20accessible%20iaccessible%20iaccessible2%20accessibilityshort_desc_type=anywordssubstrorder=component%2Cpriority%2Cbug_severityquery_based_on= Sorry, here is a slightly more complete retrieval adding the old ACC: keyword https://issues.apache.org/ooo/buglist.cgi?query_format=advancedlist_id=45172short_desc=ACC%3A%20msaa%20accessible%20iaccessible%20iaccessible2%20accessibilityshort_desc_type=anywordssubstrresolution=---
Re: Changes that Impact Backwards Compatibility
On Sat, Feb 9, 2013 at 1:17 PM, janI j...@apache.org wrote: -- Forwarded message -- From: janI j...@apache.org Date: 9 February 2013 19:17 Subject: Re: Changes that Impact Backwards Compatibility To: janI j...@apache.org Stupid browser sorry for that. On 9 February 2013 19:15, janI j...@apache.org wrote: Hi. When do you expect a feature to enter the list. 1) Before development 2) Before committing to trunk (e.g. committed in a branch) 3) after QA. It is not to track AOO 4.0 stuff that might happen. So I wouldn't put items in their before development happens. But I'd put items in there after the code is checked in. -- this can be a guide for QA to know what areas to concentrate on -- It tells doc what new items to document -- We could have a blog post drawing attention to changes in API's that extension authors and others should be aware of, so they have time to update their apps. Note: we can easily produce a report before AOO 4.0 is released, looking at Bugzilla and Subversion logs, to get a list of bugs fixed, etc. But it is better IMHO to get the important items written down as soon as they happen, so we can better coordinate. -Rob The reason for my question, is that I work on l10n tools, which I hope will make it to 4.0, The tools have a high effect on the translation process: a) the sdf files will no longer exist b) there will only be 2x45 files c) help and ui will not be seperate projects. The first part is available in branch l10n but not integrated in build, or tested yet. Rgds Jan I. On 9 February 2013 18:40, Rob Weir robw...@apache.org wrote: 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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
Re: Bugzilla -- Any interest in enabling categories?
On 08/02/2013 Rob Weir wrote: So with a new top-level category, I can easily get to 3 or 4 top level items, and then under applications reduce it to the core set of 5 products. Can we get anywhere close by combining products? I had a look again. If the aim is to avoid presenting lists of more than 10 items, there is no way to do it by moving products. With categories, we should have a category for application-specific bugs (with the 6 components only but let's please improve their description so that it includes the application name!), a category for cross-application bugs (framework, chart, formula, scripting, vba, bibliographic, gsl, ui...) and other categories for websites and so on. If you manage to find a proposal for a taxonomy that is clear for new bug reporters and efficient for experienced QA people too it would surely be nice. But I think we'll have to see the proposed taxonomy tree on this list, since I cannot find something really clear (for example, my proposal above would have the problem that a bug with charts in Calc should be reported in generic-chart rather than application-calc, but people would use the latter; and ultimately this is probably not going to hurt QA or development too much!). Regards, Andrea.
Re: FOSDEM: Thank you all!
On 04/02/2013 Kay Schenk wrote: It would be great to get a blog on the outcome of this event...even a short one! I don't think this is worth a new post, but I've now added a Post-conference update paragraph to https://blogs.apache.org/OOo/entry/apache_openoffice_at_fosdem_2013 with links to slides and pictures. Regards, Andrea.
RE: Changes that Impact Backwards Compatibility
Thanks for adding this. I have added a Calc and OpenFormat Support subsection there, with description of the proposed change to have POWER(0,0) produce an error value (#VALUE!) instead of 1, the current result. That is explained on the Release Notes and at the Bugzilla Issue #114430 at https://issues.apache.org/ooo/show_bug.cgi?id=114430. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 09:40 To: dev@openoffice.apache.org Subject: Changes that Impact Backwards Compatibility 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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
Re: FOSDEM: Thank you all!
Hi all, Andrea Pescetti schrieb: On 04/02/2013 Kay Schenk wrote: It would be great to get a blog on the outcome of this event...even a short one! I don't think this is worth a new post, but I've now added a Post-conference update paragraph to https://blogs.apache.org/OOo/entry/apache_openoffice_at_fosdem_2013 with links to slides and pictures. I have added a small page on the Wiki. http://wiki.openoffice.org/wiki/Conferences/FOSDEM/2013 But I'm not sure about the stand staff. Can someone please add the other names? Kind regards Regina
Re: Changes that Impact Backwards Compatibility
On Sat, Feb 9, 2013 at 4:35 PM, Dennis E. Hamilton orc...@apache.org wrote: Thanks for adding this. I have added a Calc and OpenFormat Support subsection there, with description of the proposed change to have POWER(0,0) produce an error value (#VALUE!) instead of 1, the current result. That is explained on the Release Notes and at the Bugzilla Issue #114430 at https://issues.apache.org/ooo/show_bug.cgi?id=114430. Thanks. I'll plan on editing this down when we get closer to the release, and before we translate them. IMHO Release Notes should be succinct and to the point. For example, instead of 5 paragraphs on the topic, I would simply say: POWER(0,0) returns the #VALUE! error. Previous versions returned 1. See Bugzilla Issue #114430. If the reader wants more details they can find them in the linked BZ issue. But out of sympathy for the eventual translators, let's keep the Release Notes succinct. -Rob - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 09:40 To: dev@openoffice.apache.org Subject: Changes that Impact Backwards Compatibility 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. I think we all acknowledge that a major release like 4.0 is an opportunity to make incompatible changes, but I hope we also agree that this is not a free-for-all where we can indiscriminately break compatibility. We need to think carefully about where we break compatibility, have good reasons for it, and have a plan for how we communicate such changes to users and application developers. The later, especially, need advance notice. Personally, I consider any changes that break compatibility to be controversial and think that lazy consensus should be sought on this list before committing it. Regards, -Rob
Re: java 7 patch
Fred --
Thanks. We'll see if we can get some testing/build with this this coming
week.
On 02/07/2013 11:32 AM, Fred Ollinger wrote:
To whom it may concern,
Below is a patch to fix some java7 compilation bugs. Also, this is attached.
Index: hsqldb/jdbcDriver.java
===
--- hsqldb.orig/jdbcDriver.java 2013-02-07 09:17:01.0 -0800
+++ hsqldb/jdbcDriver.java 2013-02-07 09:17:32.0 -0800
@@ -31,6 +31,11 @@
package org.hsqldb;
+//#ifdef JAVA7
+import java.sql.SQLFeatureNotSupportedException;
+import java.util.logging.Logger;
+//#enddif JAVA7
+
import java.sql.Connection;
import java.sql.Driver;
import java.sql.DriverManager;
@@ -121,6 +126,12 @@
*/
public class jdbcDriver implements Driver {
+//#ifdef JAVA7
+public Logger getParentLogger() throws SQLFeatureNotSupportedException {
+ throw new SQLFeatureNotSupportedException();
+}
+//#endif JAVA7
+
/**
* Attempts to make a database connection to the given URL. The driver
* returns null if it realizes it is the wrong kind of driver to
@@ -321,4 +332,8 @@
DriverManager.registerDriver(new jdbcDriver());
} catch (Exception e) {}
}
+
+public boolean isCloseOnCompletion() { return false; }
+
}
+
Index: hsqldb/jdbc/jdbcCallableStatement.java
===
--- hsqldb.orig/jdbc/jdbcCallableStatement.java 2013-02-07
09:55:57.0 -0800
+++ hsqldb/jdbc/jdbcCallableStatement.java 2013-02-07 09:57:17.0
-0800
@@ -302,6 +302,14 @@
public class jdbcCallableStatement extends jdbcPreparedStatement
implements CallableStatement {
+//#if JAVA7
+public T T getObject(String s, ClassT T) throws SQLException
{ throw new SQLException(); }
+public T T getObject(int i, ClassT T) throws SQLException {
throw new SQLException(); }
+public boolean isCloseOnCompletion() {
+ throw new UnsupportedOperationException(Not supported yet.);
+}
+//#endif JAVA7
+
/** parameter name = parameter index */
private IntValueHashMap parameterNameMap;
@@ -3373,11 +3381,6 @@
{
throw new UnsupportedOperationException(Not supported yet.);
}
-//#endif JAVA6
-
-//#if JAVA7
-[javac]
/mnt/lfs/sources/ubuntu/old/local_dev300/hsqldb/unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/jdbc/jdbcCallableStatement.java
:302: error: jdbcCallableStatement is not abstract and does not
override abstract method TgetObject(String,ClassT) in
CallableStatement
-
-//#endif JAVA7
+//#endif JAVA6
}
Index: hsqldb/jdbc/jdbcConnection.java
===
--- hsqldb.orig/jdbc/jdbcConnection.java2013-02-07 11:22:20.0
-0800
+++ hsqldb/jdbc/jdbcConnection.java 2013-02-07 11:22:43.0 -0800
@@ -31,6 +31,10 @@
package org.hsqldb.jdbc;
+//#ifdef JAVA7
+import java.util.concurrent.Executor;
+//#endif JAVA7
+
//#ifdef JAVA2
import java.sql.Array;
import java.sql.Blob;
@@ -416,6 +420,21 @@
* @see jdbcDatabaseMetaData
*/
public class jdbcConnection implements Connection {
+//#ifdef JAVA7
+public void abort(Executor e){}
+public int getNetworkTimeout(){
+ throw new UnsupportedOperationException(Not supported yet.);
+}
+public void setNetworkTimeout(Executor e, int i ){
+ throw new UnsupportedOperationException(Not supported yet.);
+}
+public String getSchema() {
+ throw new UnsupportedOperationException(Not supported yet.);
+}
+public void setSchema(String s) {
+ throw new UnsupportedOperationException(Not supported yet.);
+}
+//#endif JAVA7
// Common Attributes --
Index: hsqldb/jdbc/jdbcDatabaseMetaData.java
===
--- hsqldb.orig/jdbc/jdbcDatabaseMetaData.java 2013-02-07
11:27:01.0 -0800
+++ hsqldb/jdbc/jdbcDatabaseMetaData.java 2013-02-07 11:27:03.0
-0800
@@ -99,7 +99,7 @@
* P
* A method that gets information about a feature that the driver does not
* support will throw an codeSQLException/code.
- * In the case of methods that return a codeResultSet/code
+ * In the case of methods that eeturn a codeResultSet/code
* object, either a codeResultSet/code object (which may be empty) is
* returned or an codeSQLException/code is thrown.p
*
@@ -282,6 +282,13 @@
*/
public class jdbcDatabaseMetaData implements DatabaseMetaData {
+//#ifdef JAVA7
+public ResultSet getPseudoColumns(String catalog, String
schemaPattern, String tableNamePattern, String columnNamePattern)
throws SQLException {throw new SQLException(); }
+
+public boolean generatedKeyAlwaysReturned(){ return false; }
+//#endif JAVA7
+
+
/** Used by getBestRowIdentifier to avoid extra object construction */
static final
Calc behavior: result of 0 ^ 0
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? Regards, Andrea.
Re: Changes that Impact Backwards Compatibility
Rob Weir wrote: On Sat, Feb 9, 2013 at 4:35 PM, Dennis E. Hamilton wrote: I have added a Calc and OpenFormat Support subsection there, with description of the proposed change to have POWER(0,0) produce an error value (#VALUE!) instead of 1, the current result. https://issues.apache.org/ooo/show_bug.cgi?id=114430 I've just opened a separate discussion about this proposed change, so that we are all aware of it. For example, instead of 5 paragraphs on the topic, I would simply say: POWER(0,0) returns the #VALUE! error. Previous versions returned 1. See Bugzilla Issue #114430. I agree. Let's keep the release notes short and give pointers instead. Regards, Andrea.
Some ideas for the Basic macro editor, including the dialog editor
Please reconsider the present macro language and the way it links to the OOo API. Originally macro languages were added to office software to enable non-programmers to automate repetitive jobs, but in the OOo paradigm macros should apparently only be developed by programming geeks. For instance, the code to initialise a custom-made dialog box is DialogLibraries.LoadLibrary(Standard) oDialog1 = CreateUnoDialog(DialogLibraries.Standard.TranslateDialog) I don't object to such constructs in Java or Python scripts, both languages require some learning, and both use this kind of constructs extensively, but Basic is supposed to be fit for use by rooks, and this kind of code will discourage rooks right away. Please also remember that if the time spent on developing the macro exceeds the time gained by executing it, it's time wasted. This software is a productivity tool, it should be aimed at improving the productivity of its users. In the forum we often advice people who are new to programming but want to write a macro to achieve something to avoid macros as much as they possibly can, simply because macros are so hard in OOo. That's a shame. And quite apart from the productivity aspect, writing code and seeing it work as you wanted is great fun. So far, I never felt that fun when trying to get an OOo macro to work. Talking about dialog boxes, I toyed around with them and only after spending some hours on that I found, /quite by accident/, that you can select the dialog object itself by clicking on its border, and that the same holds for the frame object. Before that the only way to adjust the dimensions of a frame control was to edit the xcd file. I have worked with Delphi, where you can click anywhere in a form or control to select it (with the single exception of the bevel object), and if you have controls that you can't select in the designer, you can still select them from a list of controls at the top of the properties panel. Apart from that I found that some of the default settings for the controls differ from those in the average dialog box - for instance the background of a label control is white by default, and when I tried to change it to the background colour of the entire dialog box, I found that it was impossible - that particular colour was missing in the colour drop down list. Last of all, could you add an interface for Pascal/Delphi/ Lazarus code? That would enable people who can do great things in pascal but can't get along with C or C++. Thank you for bearing with me. floris v
Re: Calc behavior: result of 0 ^ 0
On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti pesce...@apache.org 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 Spreadsheets are used by businessmen and not only mathematicians. Stability is important to them. Getting different results in different versions of OpenOffice would be a very scary thing. - 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 In other words, the results we were giving before were entirely valid. - We gain interoperability since Excel returns an error too Microsoft has gone decades with treating the year 1900 as a leap year. Should we? - We lose backwards compatibility if someone was relying on the fact that OpenOffice returns 1 as the result of =0 ^ 0 Correct. The fact is we have returned 1 for this calculation for over a decade. Whether mathematicians think it is right or wrong (and they do not all agree), that is what we did. So changing it now has the potential to break real user spreadsheets. So this is a serious change. 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 For what advantage? Better Microsoft interop? OK. That is reasonable. But I would not support a similar change merely because it amuses the mathematically curious. 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). We need to take our responsibility as stewards of OpenOffice seriously. And that means dealing with the fact that we have millions of users and many millions of documents out there created with past versions of OpenOffice. We can't just change something because one person feels like it. Otherwise someone else can just change this function back at a later date because they feel like it. (ODF says 0 is also a permitted value. Maybe someone wants to change to that?) We need to discuss these kinds of changes. Changing the behavior of a Calc function, without prior discussion on the list, is entirely unacceptable. Maybe this was not clear before, but as I stated in my other note, I consider all changes that break backwards compatibility of public API's and interfaces, including spreadsheet formulas, to be controversial. They should require Review-then-Commit. Of course, having this discussion now, even after the code was checked in, and starting to add info the Release Notes, is good progress. But I want to make sure we're all on the same page as to why such changes are critical to have reviewed. Is there consensus that this is a reasonable backwards-incompatible change, or compelling reasons to revert it? I already gave my concerns for accepting such changes: 1) We need Release notes. 2) We need Test cases Dennis contributed the first. It would be great to have a test document attached to the issue so we can verify that other aspects of the POWER() and associated ^ operator were not modified as well. I can come up with something and attach it to the BZ issue. Regards, -Rob Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
Am 02/10/2013 12:11 AM, schrieb Andrea Pescetti: 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). Right, the change has a *very* narrow and limited group of users. I mean not the power function itself but the result of 0 ^ 0. Is there consensus that this is a reasonable backwards-incompatible change, or compelling reasons to revert it? I don't see any problem to change the behavior for *this special* case. Before it was behaving within the ODF standard and after the commit it's still the same. And when we can improve the interoperability with MS Office - even if it's just 0.5% - then even better. So, +1 to keep Pedro's change. Marcus
RE: Calc behavior: result of 0 ^ 0
It is not clear that OpenOffice-lineage software has returned the same value for POWER(0,0) over the years. It seems that a third-party library has been relied upon for the implementation and there was apparently not much attention to edge cases. If that library changes or is different on different platforms, there is the prospect of unexpected differences. It is good that this is being nailed down. In any case, in order to produce *any* reliable result for POWER(0,0), it is necessary to declare what that is as an implementation-defined (not -dependent) commitment. So Sayeth ODF 1.2 OpenFormula. The same goes for another implementation-defined case of POWER(a,b) although it seems that one is consistently implemented. (Java has a different idea, though. It appears capable of computing POWER(-27,1/3) = -3. Let's not do that.) - Dennis PS: I appreciate that the Release note should be succinct. For now, having an explanation for what is involved seemed useful for folks who wonder whether this is the right thing to do. A link to the BZ issue is helpful, once it is closed one way or the other. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 15:43 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti pesce...@apache.org 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 Spreadsheets are used by businessmen and not only mathematicians. Stability is important to them. Getting different results in different versions of OpenOffice would be a very scary thing. - 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 In other words, the results we were giving before were entirely valid. - We gain interoperability since Excel returns an error too Microsoft has gone decades with treating the year 1900 as a leap year. Should we? - We lose backwards compatibility if someone was relying on the fact that OpenOffice returns 1 as the result of =0 ^ 0 Correct. The fact is we have returned 1 for this calculation for over a decade. Whether mathematicians think it is right or wrong (and they do not all agree), that is what we did. So changing it now has the potential to break real user spreadsheets. So this is a serious change. 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 For what advantage? Better Microsoft interop? OK. That is reasonable. But I would not support a similar change merely because it amuses the mathematically curious. 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). We need to take our responsibility as stewards of OpenOffice seriously. And that means dealing with the fact that we have millions of users and many millions of documents out there created with past versions of OpenOffice. We can't just change something because one person feels like it. Otherwise someone else can just change this function back at a later date because they feel like it. (ODF says 0 is also a permitted value. Maybe someone wants to change to that?) We need to discuss these kinds of changes. Changing the behavior of a Calc function, without prior discussion on the list, is entirely unacceptable. Maybe this was not clear before, but as I stated in my other note, I consider all changes that break backwards compatibility of public API's and interfaces, including spreadsheet formulas, to be controversial. They should require Review-then-Commit. Of course, having this discussion now, even after the code was checked in, and starting to add info the Release Notes, is good progress. But I want to make sure we're all on the same page as to why such changes are critical to have reviewed. Is there consensus that this is a reasonable backwards-incompatible change, or compelling reasons to revert it? I already gave my concerns for accepting such changes: 1) We need Release notes. 2) We need Test cases Dennis contributed the first. It would be great to have a test document attached to the issue so we can verify that other aspects of the POWER() and
Re: Calc behavior: result of 0 ^ 0
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 Am 10.02.2013 00:43, schrieb Rob Weir: On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti pesce...@apache.org 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 Spreadsheets are used by businessmen and not only mathematicians. Stability is important to them. Getting different results in different versions of OpenOffice would be a very scary thing. - 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 In other words, the results we were giving before were entirely valid. - We gain interoperability since Excel returns an error too Microsoft has gone decades with treating the year 1900 as a leap year. Should we? - We lose backwards compatibility if someone was relying on the fact that OpenOffice returns 1 as the result of =0 ^ 0 Correct. The fact is we have returned 1 for this calculation for over a decade. Whether mathematicians think it is right or wrong (and they do not all agree), that is what we did. So changing it now has the potential to break real user spreadsheets. So this is a serious change. 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 For what advantage? Better Microsoft interop? OK. That is reasonable. But I would not support a similar change merely because it amuses the mathematically curious. 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). We need to take our responsibility as stewards of OpenOffice seriously. And that means dealing with the fact that we have millions of users and many millions of documents out there created with past versions of OpenOffice. We can't just change something because one person feels like it. Otherwise someone else can just change this function back at a later date because they feel like it. (ODF says 0 is also a permitted value. Maybe someone wants to change to that?) We need to discuss these kinds of changes. Changing the behavior of a Calc function, without prior discussion on the list, is entirely unacceptable. Maybe this was not clear before, but as I stated in my other note, I consider all changes that break backwards compatibility of public API's and interfaces, including spreadsheet formulas, to be controversial. They should require Review-then-Commit. Of course, having this discussion now, even after the code was checked in, and starting to add info the Release Notes, is good progress. But I want to make sure we're all on the same page as to why such changes are critical to have reviewed. Is there consensus that this is a reasonable backwards-incompatible change, or compelling reasons to revert it? I already gave my concerns for accepting such changes: 1) We need Release notes. 2) We need Test cases Dennis contributed the first. It would be great to have a test document attached to the issue so we can verify that other aspects of the POWER() and associated ^ operator were not modified as well. I can come up with something and attach it to the BZ issue. Regards, -Rob Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
On 2/9/2013 18: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? Regards, Andrea. If we keep the change (+1 from me), someone more adept than I should write something like a POWER0(a,b) function. This can be substituted easily for POWER, or a ^ b, and returns 0^0=0. If we're sure to break some spreadsheets, let's make a quick fix easy. (I'd bet that in half of the broken cases, someone will say, Aha! That value should never be 0! We've finally found that old bug! In short, we'll be helping some folks.) /tj/
Re: Calc behavior: result of 0 ^ 0
On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton orc...@apache.org wrote: It is not clear that OpenOffice-lineage software has returned the same value for POWER(0,0) over the years. It seems that a third-party library has been relied upon for the implementation and there was apparently not much attention to edge cases. If that library changes or is different on different platforms, there is the prospect of unexpected differences. It is good that this is being nailed down. In any case, in order to produce *any* reliable result for POWER(0,0), it is necessary to declare what that is as an implementation-defined (not -dependent) commitment. So Sayeth ODF 1.2 OpenFormula. There is big difference between documenting the behavior (nailing it down) and changing the behavior. Imagine the following scenario: Someone has implemented a custom application based on an OpenOffice spreadsheet document. It is a mixture of macros and spreadsheet formulas. The user enters data into some cells, presses a button, and a new results table and a nice chart pop up on another sheet in the file. The developer extensively tested this application, exercised the full range of input values for his calculations, and verified that the results were correct. For sake of argument, imagine that in some user inputs, he does a calculation of 0^0, and it returns 1, and his model is entirely happy to use that result. It works for him. It is correct for his use. The developer then distributes his app to end-users, who are now happily using the application. They don't know that it uses POWER() behind the scenes. In fact, the calculations might all be in hidden sheets, with password protection enabled. There are no user-serviceable parts here. The person who suffers because of the change is not necessarily the person who can fix it. This is the kind of thing we risk break by changing the behavior of spreadsheet functions to introduce a new error where once the a function returned a reasonable value. We need to avoid the belief that the only thing to worry about is someone who sat down and typed 0^0 into a cell. That is not the point. The point is spreadsheets that work correct today, and may break tomorrow because of this change. The same goes for another implementation-defined case of POWER(a,b) although it seems that one is consistently implemented. (Java has a different idea, though. It appears capable of computing POWER(-27,1/3) = -3. Let's not do that.) - Dennis PS: I appreciate that the Release note should be succinct. For now, having an explanation for what is involved seemed useful for folks who wonder whether this is the right thing to do. A link to the BZ issue is helpful, once it is closed one way or the other. -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 15:43 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Sat, Feb 9, 2013 at 6:11 PM, Andrea Pescetti pesce...@apache.org 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 Spreadsheets are used by businessmen and not only mathematicians. Stability is important to them. Getting different results in different versions of OpenOffice would be a very scary thing. - 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 In other words, the results we were giving before were entirely valid. - We gain interoperability since Excel returns an error too Microsoft has gone decades with treating the year 1900 as a leap year. Should we? - We lose backwards compatibility if someone was relying on the fact that OpenOffice returns 1 as the result of =0 ^ 0 Correct. The fact is we have returned 1 for this calculation for over a decade. Whether mathematicians think it is right or wrong (and they do not all agree), that is what we did. So changing it now has the potential to break real user spreadsheets. So this is a serious change. 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 For what advantage? Better Microsoft interop? OK. That is reasonable. But I would not support a similar change merely because it amuses the mathematically curious. that school students quickly wanting to find out what is the result of 0 ^ 0 would be told the truth (it's an
Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work
Do you all know about this? http://ci.apache.org/builders/aoo-w7ia2/ We now have an automatic build of the ia2 branch running nightly. (and successfully) It is not loading up install bits for some reason, but I'll look at that and fix it. If you want to see the status of the latest build look for Windows ia2 Branch on this page: http://ci.apache.org/projects/openoffice/ that page links to the build logs http://ci.apache.org/projects/openoffice/buildlogs/w7ia2/log/wntmsci12.pro.build.html and the buildbot log http://ci.apache.org/builders/aoo-w7ia2/builds/6, and should have the latest build of the install packages. Andrew On 2/9/2013 10:05 AM, V Stuart Foote wrote: Steve, Nothing substantive yet in working through the Windows build of the ia2 branch. Should we build against Linux and OSX and be testing for impact on ATK/AT-SPI and NSAccessibility User Interface? And, with QA and testing of the ia2 branch proceeding what mechanism should folks use for reporting and tracking issues on the ia2 branch builds? Should we stay with PM and ML exchanges, or start to use Bugzilla at issues.apache.org/ooo? I believe that starting with BZ tracking now provides continuity upon merge of branch back into AOO4.00. And, if into Bugzilla, would suggest a note in your AOO 4.0 IAccessible2 release planning wiki that QA participants and casual users report in Bugzilla categorized for consistency as against: Product: UI Component: AccessBridge Version: AOO4.00-dev Stuart =-=-= Sidebar--the legacy IAccessible2 enhancement bug could probably be revised https://issues.apache.org/ooo/show_bug.cgi?id=107914 And here is a generic BZ search for accessibility issues https://issues.apache.org/ooo/buglist.cgi?query_format=advancedresolution=---short_desc=msaa%20accessible%20iaccessible%20iaccessible2%20accessibilityshort_desc_type=anywordssubstrorder=component%2Cpriority%2Cbug_severityquery_based_on=
RE: Calc behavior: result of 0 ^ 0
Please, I think I made it very clear that whatever the agreed direction, the documentation needs to be explicit. I also looked in the AOO embedded help for POWER and it is not helpful. (By the way, it would be great if it remained possible to access the on-line help even if the embedded help is installed.) That is the only point of the note being replied to below. Knuth and I will continue to disagree about what is an appropriate result for 0^0 (maybe even 0/0). Either way, I rest my case. 0 is already an exception in the laws of arithmetic. One must always make exceptions to avoid reasoning through a division by 0 (a common trick for proving that 0 = 1). And as far as the February 1900 calendar bug goes, please recall that it was to remain downward compatible with Lotus 1-2-3. At the international standard level that was not tolerated, as you know. Think of this as delayed karma for Apache OpenOffice. In this case, allowing any of 0, 1, or error to be implementation-defined is not helpful and the compelling case for me is alignment with Excel on error. I see no point in reiterating on this. I am not going to change my recommendation. All of the considerations have been presented. Now it remains to determine how to go forward. I have no idea what the consensus will be. I await what others have to say. I have no need to say any more. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 16:57 To: dev@openoffice.apache.org; orc...@apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton orc...@apache.org wrote: It is not clear that OpenOffice-lineage software has returned the same value for POWER(0,0) over the years. It seems that a third-party library has been relied upon for the implementation and there was apparently not much attention to edge cases. If that library changes or is different on different platforms, there is the prospect of unexpected differences. It is good that this is being nailed down. In any case, in order to produce *any* reliable result for POWER(0,0), it is necessary to declare what that is as an implementation-defined (not -dependent) commitment. So Sayeth ODF 1.2 OpenFormula. There is big difference between documenting the behavior (nailing it down) and changing the behavior. [ ... ]
RE: Calc behavior: result of 0 ^ 0
Please, I think I made it very clear that whatever the direction, the documentation needs to be explicit. I also looked in the embedded help for POWER and it is not helpful. That is the only point of the note being replied to below. Knuth and I will continue to disagree about that. Either way, I rest my case. And as far as the February 1900 calendar bug goes, please recall that it was to remain downward compatible with Lotus 1-2-3. At the international standard level, that was not tolerated, as you know. Think of this as delayed karma for Apache OpenOffice. In this case, allowing any of 0, 1, or error to be implementation-defined is not helpful and the compelling case for me is alignment with Excel on error. I see no point in reiterating on this. I am not going to change my recommendation. All of the considerations have been presented. Now it remains to determine how to go forward. I have no idea what the consensus will be. I await what others have to say. I have no need to say any more. - Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Saturday, February 09, 2013 16:57 To: dev@openoffice.apache.org; orc...@apache.org Subject: Re: Calc behavior: result of 0 ^ 0 On Sat, Feb 9, 2013 at 7:39 PM, Dennis E. Hamilton orc...@apache.org wrote: It is not clear that OpenOffice-lineage software has returned the same value for POWER(0,0) over the years. It seems that a third-party library has been relied upon for the implementation and there was apparently not much attention to edge cases. If that library changes or is different on different platforms, there is the prospect of unexpected differences. It is good that this is being nailed down. In any case, in order to produce *any* reliable result for POWER(0,0), it is necessary to declare what that is as an implementation-defined (not -dependent) commitment. So Sayeth ODF 1.2 OpenFormula. There is big difference between documenting the behavior (nailing it down) and changing the behavior. [ ... ]
