Re: 4.0 and loss of backward compatibility for extensions with toolbar
On 2/12/13 12:03 AM, Andrea Pescetti wrote: On 11/02/2013 Hagar Delest wrote: No real problem with reinstalling extensions after a major upgrade, I've done that too. But there is a difference between the mere inconvenience of reinstalling extensions and losing them completely (waiting that someone dare update them). The real issue is here indeed. Reinstalling won't be perceived as a big problem. But the fact that reinstalling the same extension won't work will be a problem. Most of the extensions hosted on extensions.openoffice.org won't be updated, and extensions.openoffice.org does not support filtering by version (and anyway the information would be missing in current releases). The top five extensions at http://extensions.openoffice.org/en/most_popular total 1 million downloads per year, which could give some backing to the nightmare support scenario Hagar envisions. Ariel posted to the API list saying that the two reasonable options in his opinion are either to keep or revert his entire change (Hagar, please note that Ariel asked not to start a discussion here and now, and mentioned he cannot be responsive at the moment; anyway...). But if there is a way, even using redundant code, to still support the old and new toolbar handling this would be very useful to end-users. From the FOSDEM talks I understood there could the possibility to still support both mechanisms (and of course, warn users when the deprecated one is used). maybe you understand it wrong, no warning. If we support both the underlying code would be more complex, slower and more ugly to maintain. and Ariel pointed already out that he is not willing to support both based on this fact. Either the old or the new mechanism, or somebody else step forward and implement the change. The whole discussion is really based on assumption. We can ask our friends of SourceForge to analyze by a script all extensions and check if they contain an Addon.xcu or not. All developers, maintainers of extensions with Addon.xcu can we contact and can inform them about the proposed change and how to adapt the xcu. Juergen
Re: 4.0 and loss of backward compatibility for extensions with toolbar
On 2/12/13 12:41 AM, Rob Weir wrote: On Mon, Feb 11, 2013 at 5:37 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 11/02/2013 22:46, Rob Weir a écrit : My impression was that even if we made no changes, from the user's perspective, they would lose all extensions. This is due to the change in base directory for the profile. So all extensions would be lost and need to be reinstalled. So there will be no doubt in the user's mind, even if they do not read the release notes, that the extensions are gone. [...] Again, my impression is that users will lose their extensions and need to reinstall them, even if we do not make any API changes. [...] I think a clean break with the past profile helps us avoid the current generation of crash issues. We get to start clean rather than deal with the many upgrade paths: No real problem with reinstalling extensions after a major upgrade, I've done that too. But there is a difference between the mere inconvenience of reinstalling extensions and losing them completely (waiting that someone dare update them). Is that what we're really facing? Are you saying that extension author will not update their extensions if they become incompatible? Is that what we think? I agree that this would be a bad situation. But is it the likely situation we would face? The authors of the top extensions would not update? If that is the case than we can stop to talk about extensions at all. I would not spent any further minute to make the life of extension developers easier. Juergen
Re: Performance test comparisons
On 12 February 2013 12:42, Rob Weir robw...@apache.org wrote: I just did a basic test, seeing how long it took to load a large text document, in this case the ODF 1.2 specification. I looked at memory consumed and the number of seconds to load. I loaded the document once to reduce the impact of disk caching and then repeated 5 times and took the average. All tests done on identical hardware. http://neowiki.neooffice.org/index.php/NeoOffice_Performance_Comparison is old, but may be useful for developing a good list of benchmarks. Note the MS Word column. - d.
Re: Draft blog post: $21 million per day
Good morning. It is posted now. The URL is: http://blogs.apache.org/OOo/entry/21_million_per_day Regards, -Rob On Sat, Feb 9, 2013 at 8:54 AM, Sally Khudairi sallykhuda...@yahoo.com wrote: Thanks so much, Rob. I'd prefer we go out at 8AM ET on Tuesday. I think we'll get the most media attention during the business week, and also give the international press a chance to cover us as well. I'll keep everyone abreast of developments on our end. Kind regards, Sally [From the mobile; kindly excuse spelling/spacing/auto-correct anomalies] - Reply message - From: Rob Weir robw...@apache.org To: Sally Khudairi sallykhuda...@yahoo.com Cc: dev@openoffice.apache.org, Sally Khudairi s...@apache.org Subject: Draft blog post: $21 million per day Date: Sat, Feb 9, 2013 8:28 AM On Sat, Feb 9, 2013 at 6:25 AM, Sally Khudairi 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: 4.0 and loss of backward compatibility for extensions with toolbar
On 2/12/13 1:42 PM, Joost Andrae wrote: Hi, in the moment I have just one question in mind: Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu like presentation-minimizer.oxt ? well the extensions where we have the source code can be changed by volunteers. Maybe directly at Apache or as Google code project when there are license incompatible dependencies. Everything else is unclear and I doubt that Oracle has interest in updating them. And nobody else can do that. The best thing would be to start new projects providing similar functionality but where the code is available and under a proper license. Unmaintained extensions are a general problem and should not have influence on any decision. Juergen 8) Inconvenience -- it is natural for anyone to complain about needing to do additional work where they don't see the advantage. So it is natural that we will expect complaints, followed in the end by conformance with the required changes. What is totally unclear to me is whether we are facing #8 only, or whether we have any of the other concerns. One option for #8 is to add a nice new feature or capability to the API so extension author will *want* to update. Kind regards, Joost
Re: pdf export option for FilterData and ExportFormFields
Hi Andrea, Am 05.02.2013 22:34, schrieb Andrea Pescetti: Do you mean that not only you wish that OpenOffice export fields as enterable fields (which it already does) but that the PDF file produced by OpenOffice should also support the ability to save form content? But is this ability a document property or something that depends on the PDF reader being used? Yes, I mean the ability to save the content of form fields. And as I see now here [1], it doesn't seem to be a legal issue of Adobe®. It's a document property and doesn't depend on the reader. Regards Peter [1] http://www.foxitsoftware.com/company/press.php?action=viewpage=20080508aw3E.html
Re: Draft blog post: $21 million per day
Posted https://twitter.com/TheASF/status/301315097794596867 ...as well as sent to our media/analyst list :-) Cheers, Sally From: Sally Khudairi sallykhuda...@yahoo.com To: Rob Weir robw...@apache.org; dev@openoffice.apache.org Cc: Sally Khudairi s...@apache.org Sent: Thursday, 7 February 2013, 23:21 Subject: Re: Draft blog post: $21 million per day Thank you, Rob. This is great. I'm happy to support this with a tweet from @TheASF as well as send to our dedicated media/analyst list. Keep up the great work! -Sally [From the mobile; kindly excuse spelling/spacing/auto-correct anomalies] - Reply message - From: Rob Weir 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?
Regina Henschel schrieb: I have written to Mathias Stürmer and ask, how to get the patches. I have got a private answers and waiting for the permission to share it. Kind regards Regina
Re: Performance test comparisons
On Tuesday, February 12, 2013 07:42:49 Rob Weir wrote: I did some tests to see how we were doing, comparing AOO 3.4.1 on Windows against OOo 3.3.0. And since LibreOffice claims that their 4.0 release is much faster and leaner, I tested them as well, to see if we could learn anything. I just did a basic test, seeing how long it took to load a large text document, in this case the ODF 1.2 specification. I looked at memory consumed and the number of seconds to load. I loaded the document once to reduce the impact of disk caching and then repeated 5 times and took the average. All tests done on identical hardware. Memory use (KB for soffice.bin): OOo 3.3.0:133,472 AOO 3.4.1: 129,928 LO 4.0: 165,796 Load time for ODF 1.2 specification (seconds, average of 5 loads) OOo 3.3.0:16.0 AOO 3.4.1:20.9 LO 4.0: 23.7 And what were the values for Calligra Words 2.6.0? ;) Does anyone have any other good test documents for doing performance tests of OpenOffice? Regards, -Rob
Re: [Call For QA Volunteers] AOO UI IAccessible2 testing work
Andrew I think that binaries URL should be he following, at least for accessing the binaries. http://ci.apache.org/projects/openoffice/#w7ia2 As you point out however they are not there yet. Do you have an ETA? After Stuart's post of the NVDA list there has been quite a bit of discussion and enthusiasm from some NVDA people on Twitter so others may come looking. https://twitter.com/jcsteh/status/301051115502448641 Steve OpenDirective On 10 February 2013 01:14, Andrew Rist andrew.r...@oracle.com wrote: Do you all know about this? http://ci.apache.org/builders/**aoo-w7ia2/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/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.**htmlhttp://ci.apache.org/projects/openoffice/buildlogs/w7ia2/log/wntmsci12.pro.build.html and the buildbot log http://ci.apache.org/**builders/aoo-w7ia2/builds/6http://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=107914https://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=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: 4.0 and loss of backward compatibility for extensions with toolbar
On 2/12/13 2:15 PM, Rory O'Farrell wrote: On Tue, 12 Feb 2013 14:07:59 +0100 Jürgen Schmidt jogischm...@gmail.com wrote: On 2/12/13 1:42 PM, Joost Andrae wrote: Hi, in the moment I have just one question in mind: Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu like presentation-minimizer.oxt ? well the extensions where we have the source code can be changed by volunteers. Maybe directly at Apache or as Google code project when there are license incompatible dependencies. Everything else is unclear and I doubt that Oracle has interest in updating them. And nobody else can do that. The best thing would be to start new projects providing similar functionality but where the code is available and under a proper license. Unmaintained extensions are a general problem and should not have influence on any decision. There are already reports on incompatabilities with LibO 4.0 and some existing extensions. One thread, for example, at http://forum.openoffice.org/en/forum/viewtopic.php?f=101t=59595 Might there be possibility for a shim to be written to sit between Addons.xcu and AOO 4.0? I don't know, I haven't looked into it but I know that they have changed API's more radical. No surprise for me. Juergen
Re: 4.0 and loss of backward compatibility for extensions with toolbar
On Tue, Feb 12, 2013 at 01:42:42PM +0100, Joost Andrae wrote: Hi, in the moment I have just one question in mind: Who's going to adapt the Sun/Oracle extensions that contain Addons.xcu like presentation-minimizer.oxt ? This extension does not provide a toolbar of its own, it uses only menubar merging. This is the situation of Oracle extensions: * No longer maintained: - Oracle PDF Import Extension (Nr. 1 in popularity) http://extensions.openoffice.org/en/project/pdfimport 2008-Oct-29 No Addons.xcu Only OpenOffice.org-minimal-version value=3.0 Reading the comments on the extension site, it seems quite broken. Link to the old OOo mailing list should be removed Incompatible license in dependencies - MySQL Connector for OpenOffice.org (Nr. 13 in popularity) http://extensions.openoffice.org/en/project/mysql_connector 2011-Jan-05 No Addons.xcu Only OpenOffice.org-minimal-version value=3.1 Incompatible license in dependencies - Oracle Report Builder (Nr. 15 in popularity) http://extensions.openoffice.org/en/project/reportdesign 2010-Dec-14 No Addons.xcu Only OpenOffice.org-minimal-version value=3.2 Incompatible license in dependencies * Still maintained: - Oracle Presenter Console (Nr. 22 in popularity) http://extensions.openoffice.org/en/project/presenter-screen 2010-Nov-25 No Addons.xcu Only OpenOffice.org-minimal-version value=3.3 Compatible license - Oracle Presentation Minimizer (Nr. 35 in popularity) http://extensions.openoffice.org/en/project/PresentationMinimizer 2010-Nov-21 Addons.cxu but *only* with OfficeMenuBarMerging node Only OpenOffice.org-minimal-version value=2.3 Compatible license - Sun Wiki Publisher http://extensions.services.openoffice.org/en/project/wikipublisher 2009-Jun-09 Addons.cxu but *only* with OfficeMenuBarMerging node Only OpenOffice.org-minimal-version value=3.0 Compatible license Regards -- Ariel Constenla-Haile La Plata, Argentina pgpxmpVJMhKE6.pgp Description: PGP signature
Re: Calc behavior: result of 0 ^ 0
On 11/02/2013 Andre Fischer wrote: On 11.02.2013 17:10, Andrea Pescetti wrote: A specification may need to leave room for implementation-defined behavior. Look at the C or C++ standard for example. Do you know of any example where this is actually a good thing? It is good for developers who need to implement the standard, but indeed not for users! Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
OT: Calc behavior: result of 0 ^ 0
I want to circle back and complete the relationship, if any, between the specifications of computations procedures and mathematics. First, there is no prohibition between defining any number of algorithms as computations on computer-representations of numbers. Mathematics allows all sort of functions, including ones that rules can't be written down for. And computational algorithms are some of those that do have written-down rules that can be followed by a computer. The problem that is being seen here is what happens when (1) mathematically-defined functions are appealed to as the ideal that the computed procedure is intended to approach in some agreeable degree of approximation. This shows up in the description that is provided and in the notation and names that are used. When the computational functions are casually identified with mathematical ones and nothing more is said, what's left hanging are two things: (1) anything about *mathematical* edge cases and places where the mathematical function is undefined, and (2) difficulties where limitations of the computer representation of arithmetic prevent a result with some expected degree of reliability. (1) can be finessed by providing computationally-convenient results for edge cases, and a mathematically-precise definition can be provided in definition for the resulting modification. If a standard dictates such a definition, so be it. The POWER(x,y) computational function specified for OpenFormula is not the mathematical one anyhow. It is an approximation (sometimes quite good) for some limited cases of the mathematically-allowed (x,y). It can be defined to be a (limited) variant covering places where mathematics has nothing to offer, so long as there is agreement on what the variant is. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Monday, February 11, 2013 14:24 To: dev@openoffice.apache.org Subject: RE: Calc behavior: result of 0 ^ 0 This is not a vote. There is a statement about what is acceptable mathematically that I cannot leave unchallenged. However, that is different than what might or might not be acceptable computationally for a give case and I continue to refrain from reiterating any argument about that. - Dennis MATHEMATICAL RIGHT/WRONG-NESS I'm sorry, I will not accept that 0^0 = 1 as a definition is not wrong mathematically. It is not right mathematically either. That it is convenient to assume 0^0 = 1 in certain contexts of mathematical *application* is different than making it part of the laws of number theory. The problem with 0^0 = 1 as a rule is that it has as a consequence that 0/0 = 1 as well or else standard mathematics is inconsistent. But 0/0 = 1 (or any fixed value) makes mathematics unavoidably inconsistent anyhow (as the well-known defective proofs used to claim paradoxes like 0 = 1 and 1 = 2 demonstrate). There is no escaping the fact that x/0 needs to be undefined and that includes 0/0, so 0^0 needs to go along. Let us not confuse computational expedient or algorithmic simplicity with mathematical rigor. When a computer arithmetic had no provision for coding errors and indefinable cases, computational concessions were unavoidable (as is the case for integer types in common programming languages). That is not the case with spreadsheets, which do include error values, nor is it the case with modern floating-point arithmetic implementations (and the standards they satisfy). I understand Knuth's argument (and its form in Concrete Mathematics and in Art of Computer Programming). But adding rules to *mathematics* that make the standard model of arithmetic inconsistent is not mathematically justifiable. It is very handy, in certain contexts relying on mathematical definitions, to define the x^0 case to always be 1 regardless of x. In the case of the binomial theorem, it appears to be an appropriate simplification in providing algorithms that are easier to reason about in some respect. That context is specifically (a+b)^n by polynomial expansion and in this context the particular case of n = 0 and b = -a is perhaps not all that interesting in comparison to the serious cases. Unfortunately, the computation, POWER(x,0) has no mathematical context. It is not known what POWER(x,0) is being used for, and what the nature of x is. Although the standards for C and C++ have division by 0 to be undefined, there is not such clarity for pow(x,y). The ANSI/ISO Standards for C thought of as C90 define pow(x,y) to be a domain error if the result cannot be represented when x is zero and y is less than or equal to zero. Even so, Plauger's 1992 The Standard C Library has pow(x,0.0) return 1.0 so long as x is neither NaN nor an Inf. Harbison and Steele's C: A Reference Manual, 4th (1995) edition simply assert that pow(0.0,0.0) is a domain error. The ISO C99 specification says that a domain error
RE: Calc behavior: result of 0 ^ 0
RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Mwiki is moved into maintenance mode.
When I look at the preceding mail in this thread, I see a lot of god suggestionsbut it seems its all still open, or did I miss a point. Regarding streamlining Mwiki, - there are no real proposals to reduce the number of catagories - it seems that everybody agrees on marking old pages (with outdate or needs update marker), however the definition of these pages seems to be a discussion point. Regarding moving cwiki to wiki. - There seemed to be general consensus to move the pages, however there seems to be a discussion whether to keep Cwiki as scratch paper. - It is also remarkable (at least to me), that there seems to be a big difference in saying and doingmeaning that our cwiki still get new pages, even from people who I understood supported a move. - For the actual transfer, there seems to several options, from the most radical (and interesting): Freeze, build a new wiki (and web), to more or less do nothing. I have also noted, that no one have opted to help with this undertaking. So I assume that, due to the fact that its hard to impossible to see what to do and be within consensus, it is simpler to do nothing ? Rgds Jan I. Ps. being a developer I do not see the filter (cwiki - mwiki) as a major challenge, compared with changing the will/habit of people :-) On 9 February 2013 19:16, David Gerard dger...@gmail.com wrote: 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.
Re: Calc behavior: result of 0 ^ 0
Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamilton dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffuni p...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. Regards, -Rob Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamilton dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Select column in Calc
Select column in Calc as I can select from Python the value of a particular column in Calc or is necessary for the user to select? regards -- *Galileo Teco Juarez* *Web:* http://80bits.wordpress.com *Twitter:* @genitalico http://twitter.com/genitalico *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
Re: Select column in Calc
sorry mistake of translations this is the real question *how can i select the value of a colum in a specific cell. ie, select the value of 10 from the B4 cell* 2013/2/12 Galileo Teco Juárez genital...@gmail.com Select column in Calc as I can select from Python the value of a particular column in Calc or is necessary for the user to select? regards -- *Galileo Teco Juarez* *Web:* http://80bits.wordpress.com *Twitter:* @genitalico http://twitter.com/genitalico *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797 -- *Galileo Teco Juarez* *Web:* http://80bits.wordpress.com *Twitter:* @genitalico http://twitter.com/genitalico *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797
Re: Calc behavior: result of 0 ^ 0
Ugh.. I haven't been following this thread at all ... I unsubscribed from the -dev list because I always ended up in absurd discussions and there was not much technical content either. I suspected it would be bikeshed.org material but in any case let me make things clear. - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1, however when you consider the limit when x tends to -0, the limit is infinite. This is called Indeterminate Form. http://en.wikipedia.org/wiki/Indeterminate_form If you wonder, I failed a math quiz in the University for blindly using the value my HP Calculator gave (1), so I am sort of glad that this has been a free educational experience for some of you. The implementation in OOo doesn't return explicitly a 1 value but instead relies on what the libc pow() function does. The standard libc lets you do 0^0 but it also lets you divide by zero without aborting . Modern IEEE 754 2008 implements three power functions pow(), pown() and powr(), powr() being the most similar to the real mathematical function. The implementation is non intrusive: I added a wrapper in SAL that behaves like powr() so that we don't affect other formulas that use pow() internally. So far no one has given an example where shooting yourself in the foot by expecting pow(0,0) to be 1 is a good thing. I am gladly surprised that Excel does the same, but the real reason why I went ahead and implemented a solution is to do the right thing, mathematically speaking. Mathematical correctness is not something that IMHO pertains to democracy. Sure it would be nice to have an option to adjust your results for mathematically undetermined cases like 0^0 or 0/0 but unless you are planning to implement it don't expected such features to appear magically either. I would be extremely disappointed to have to revert a correct fix for non-technical reasons. I think I would lose any motivation to improve other functions in Calc. Pedro.
RE: Calc behavior: result of 0 ^ 0
The current behavior is in compliance with the ODF 1.2 OpenFormula specification. In that context, the current result for POWER(0,0) is not a bug. The fact that 0^0 is not defined (nor are 0^-n values) in mathematics (although some define them for various conveniences) does not mean it can't be defined in a computational procedure, which is what POWER(x,y) specifies characteristics of. The discrepancy with respect to mathematics is troublesome, but only if the computational procedure's definition is relied upon as a mathematical fact (e.g., in proving theorems, such as 0/0 = 1). I prefer Pedro's solution, which is to produce an error value for POWER(0,0) and also have greater interoperability with another important implementation. That is also in compliance with the ODF 1.2 OpenFormula specification. It also prevents the inference of unsupportable mathematical facts by computational definition. There is clearly no consensus to making that change. This is what CTR is about. It would have been what RTC were about, had the proposal been made before the patch. This thread is the R part either way. I don't recommend having a ballot on the proposed change, and I don't know what (non-binding) vote I would cast were one held. - Dennis -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Tuesday, February 12, 2013 11:12 To: dennis.hamil...@acm.org; dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org Subject: Re: Calc behavior: result of 0 ^ 0 Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamilton dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 4:17 PM, Pedro Giffuni p...@apache.org wrote: Ugh.. I haven't been following this thread at all ... I recommend reading the archives then, since every argument that could be made, has been made already. -Rob I unsubscribed from the -dev list because I always ended up in absurd discussions and there was not much technical content either. I suspected it would be bikeshed.org material but in any case let me make things clear. - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1, however when you consider the limit when x tends to -0, the limit is infinite. This is called Indeterminate Form. http://en.wikipedia.org/wiki/Indeterminate_form If you wonder, I failed a math quiz in the University for blindly using the value my HP Calculator gave (1), so I am sort of glad that this has been a free educational experience for some of you. The implementation in OOo doesn't return explicitly a 1 value but instead relies on what the libc pow() function does. The standard libc lets you do 0^0 but it also lets you divide by zero without aborting . Modern IEEE 754 2008 implements three power functions pow(), pown() and powr(), powr() being the most similar to the real mathematical function. The implementation is non intrusive: I added a wrapper in SAL that behaves like powr() so that we don't affect other formulas that use pow() internally. So far no one has given an example where shooting yourself in the foot by expecting pow(0,0) to be 1 is a good thing. I am gladly surprised that Excel does the same, but the real reason why I went ahead and implemented a solution is to do the right thing, mathematically speaking. Mathematical correctness is not something that IMHO pertains to democracy. Sure it would be nice to have an option to adjust your results for mathematically undetermined cases like 0^0 or 0/0 but unless you are planning to implement it don't expected such features to appear magically either. I would be extremely disappointed to have to revert a correct fix for non-technical reasons. I think I would lose any motivation to improve other functions in Calc. Pedro.
Re: Calc behavior: result of 0 ^ 0
Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. Regards, -Rob I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Calc behavior: result of 0 ^ 0
Le 12/02/2013 22:31, Marcus (OOo) a écrit : Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) Now 4 with mines. Hagar
Re: Calc behavior: result of 0 ^ 0
Le 12/02/2013 00:45, Fred Ollinger a écrit : Another idea is to return 1, but have a popup which says: We are returning 1 to 0^0 due to backwards compatability, but we this might change in the fure. Click here to never show this warning again and continue to return 1. Also, you can use strict (or whatever) to flag these warnings as errors. That's a lot of code for such a small occurrence. Isn't there more urgents issues? A mere error message is good enough. Hagar
Fwd:
http://lasvegassuites.org/downrightawesome.com/nanw54.php?s=ot
Fwd:
http://lasvegassuites.org/downrightawesome.com/nanw54.php?s=ot
Re: Calc behavior: result of 0 ^ 0
Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? Thanks Marcus I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
New page: Contributing Code
We had a thread before Christmas discussing code contributions and best practices for how someone could contribute code to multiple projects, e.g., AOO and LO. I've written this up, along with more general remarks on contributing code on a new page: http://openoffice.apache.org/contributing-code.html Please take a look and let me know of any needed/recommended changes. Thanks, -Rob
[DEV] Compiler/build error
Hello Team, I followed the steps at http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_ste p to build AOO but I get an error after about 2 hours of building. The error reads as follow; BUILD FAILED C:\source\aoo-trunk\main\hsqldb\wntmsci12.pro\misc\build\hsqldb\build\build. xml:302: Compile failed; see the compiler error output for details. Total time: 5 seconds dmake: Error code 1, while making './wntmsci12.pro/misc/build/so_built_so_hsqldb' 1 module(s): hsqldb need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /cygdrive/c/source/aoo-trunk/main/hsqldb When you have fixed the errors in that module you can resume the build by running: build --all:hsqldb I have not changed any code. I just downloaded from the website and build it to get an idea on how AOO works. If anybody could please help with this error and also tell me how to check the compiler error output. My environment is: Windows 8 Pro x64, AMD Ahton II X4 650, and 8GB memory. I any more information is needed, please let me know. Thank you Fernando Martinez Email: fernando.marti...@msn.com
Completed Introduction to Contributing to Apache OpenOffice Module
Hello, My name is Maarten Kesselaers. I'm from Belgium and work as a project manager and EDI exchange expert. I used to code (Java, C++ and DOM) and helped other developers on forums, but I'm up to a new challenge. That's why I would like to help make AOO better. Kind regards, Maarten
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.org wrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? The spreadsheet I am thinking about is over 4 years old, has been published and is used by others as well. I'd also point out that asking your question on this list is not really telling you anything. We've had 37 million downloads of AOO 3.4. Only 400 people subscribe to this list. So I don't think this is great evidence for saying it has zero impact. But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. -Rob I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? Thanks Marcus I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my
Re: 4.0 and loss of backward compatibility for extensions with toolbar
Le 12/02/2013 13:05, Rob Weir a écrit : I don't know. I was asking a question. But I think this is an important question: Why would an extension author not update their extension for AOO 4.0? Some hypothetical answers: 1) The extension is unmaintained One of the top reasons I guess. I myslef made extensions for my own use. I would have to tweak it. Since I've done them some time ago, I would have to dive again in specifications to make the changes. 2) The author cannot be located or we have no way to notify them of changes May be related to 1). 3) It is not clear to the author what technical changes are needed Was a communication plan issued to warn the authors about that? Don't tell me the release notes are for that. Almost nobody read the release notes (at least until the end). I guess that many extensions mlaintainers don't follow this dev list at all. 4) There is not sufficient calendar time for the extension author to make the needed changes before we release, or the work required is too much for the author to fit into his schedule May be related to 3). Without any warning, few chances to implement any change. 5) The author attempts changes but they don't work or they introduce new problems Rather unlikely. 6) The results of not making the changes is not clear, so the author mistakenly thinks they are optional changes Or he just don't care anymore about the extension. So it needs to be taken over by someone else. But how we could know that? 7) Author has technical or account issues with the extensions website and is unable to upload a new version, and does not know where to get help. These are all possible concerns, but I think most of them can be managed with good communications and advance notice. There is also the possibility of: 8) Inconvenience -- it is natural for anyone to complain about needing to do additional work where they don't see the advantage. So it is natural that we will expect complaints, followed in the end by conformance with the required changes. Yes but what about the loss of confidence from users who will be first frustrated by an upgrade that breaks more things than fix them? Then they will have to do some homework to find out what the problem is (again, don't tell me about release notes). And wait in the end for someone to fix it. What if they do need their extensions meanwhile? One side aspect: what about extension update warning? If a new version is detected but the user doesn't upgrade to 4.0, are we sure that the minimal version will be checked first, before the new extension is installed by the user? Has he to download it before being warned that it's in fact not compatible with his current AOO/OOo version? I'm not against the change. I'm for a controlled one, that has no impact on end-users. So the main points are: communication to the extensions maintainers (what about the extensions hosted on their personal pages and not on sourceforge?), preparation of the updates and transition period. Hagar
Re: Calc behavior: result of 0 ^ 0
Am 02/12/2013 11:22 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 5:07 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 10:39 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 4:31 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 02/12/2013 08:46 PM, schrieb Rob Weir: On Tue, Feb 12, 2013 at 2:11 PM, Pedro Giffunip...@apache.orgwrote: Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so By my count, those who expressed concern about your patch are; - Me - Regina - Andre - Stuart - Günter I think this is a non-trivial amount opposition, including from some whose opinions you might respect more than mine. far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. You can't have it both ways. Your claimed benefit is intrinsically tied to breaking compatibility with earlier versions of OpenOffice. You cannot both claim that it has a significant interop benefit and also claim that it has a negligible backwards compatibility impact. IMHO nobody wrote that there is a significant improvement in direction of better compatibility. Of course it's just a step of 1 per mill. Some facts from the issue itself: - open since 2010-09-09 - only 2 votes (from author of comment #2) - only 4 mail addresses on CC (all from apache) - only 3 comments (before our discussion started) From my point of view this issue is of very low interest for others - compared with other issues. But as nobody has delievered a valid use case, we're talking about a theoretically possibility of broken spreadsheets and therefore spent already too much of our time for this discussion. Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? The spreadsheet I am thinking about is over 4 years old, has been published and is used by others as well. Maybe, but what we still don't know is the use case. Why don't you come up with more details? I'd also point out that asking your question on this list is not really telling you anything. We've had 37 million downloads of AOO 3.4. Only 400 people subscribe to this list. So I don't think this is great evidence for saying it has zero impact. But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. Sorry, I don't understand why the change should not been made? Just to keep the implementation forever? Honestly, your sentence makes no sense to me. OK, to make it clear: Do what you want, discuss on and on. My standpoint is that this is a ridicolous discussion and the change non-serious. For me this is EOD. Good night. Marcus I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? Thanks Marcus I propose to keep the change as it is now. My 2 ct. Marcus Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamiltondennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni'p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this
Re: Calc behavior: result of 0 ^ 0
Le 12/02/2013 23:22, Rob Weir a écrit : But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. You don't seem to see the benefit of the change: warn the user that there is something weird in the formula that requires his attention. Perhaps that there are users getting wrong results because a value is returned and therefore hides the problem. Hagar
Re: New page: Contributing Code
On 12 February 2013 23:19, Rob Weir robw...@apache.org wrote: We had a thread before Christmas discussing code contributions and best practices for how someone could contribute code to multiple projects, e.g., AOO and LO. I've written this up, along with more general remarks on contributing code on a new page: http://openoffice.apache.org/contributing-code.html Please take a look and let me know of any needed/recommended changes. Nice page, however I do not like We're not interested in large code-dumps., I would prefer if you wrote something like: Integrating large code-dumps requires cooperation and cannot be done as a simple commit, therefore we urge you to contact us on how we commonly can achieve the best result. When I read the page, it sounds as if we are only interested in small code patches, and that cannot be correct. Of course if someone has written a function (maybe 1.000 lines), we are highly interested. If someone has written a complete new module (like a photo editor), then we need to talk. As an example my l10n tools are about 1.100 lines which I am sure is something we want (I know I am committer, but see it as an example). rgds Jan I. Thanks, -Rob
Re: 4.0 and loss of backward compatibility for extensions with toolbar
On Tue, Feb 12, 2013 at 5:31 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 12/02/2013 13:05, Rob Weir a écrit : I don't know. I was asking a question. But I think this is an important question: Why would an extension author not update their extension for AOO 4.0? Some hypothetical answers: 1) The extension is unmaintained One of the top reasons I guess. I myslef made extensions for my own use. I would have to tweak it. Since I've done them some time ago, I would have to dive again in specifications to make the changes. 2) The author cannot be located or we have no way to notify them of changes May be related to 1). 3) It is not clear to the author what technical changes are needed Was a communication plan issued to warn the authors about that? Don't tell me the release notes are for that. Almost nobody read the release notes (at least until the end). I guess that many extensions mlaintainers don't follow this dev list at all. No, no. The Release Notes are just what I proposed to collect these kinds of items. If we actually make breaking changes I'd expect to see a bigger attempt to reach out to extension authors: 1) blog post 2) post to API list and forum 3) maybe banner on the extensions website itself But this would make more sense after the changes are made and when we can point to complete instructions as well as developer snaphot build that the author can use to test their modifications. What is not clear is how much notice is needed. 1 month? 2 months? More? -Rob 4) There is not sufficient calendar time for the extension author to make the needed changes before we release, or the work required is too much for the author to fit into his schedule May be related to 3). Without any warning, few chances to implement any change. 5) The author attempts changes but they don't work or they introduce new problems Rather unlikely. 6) The results of not making the changes is not clear, so the author mistakenly thinks they are optional changes Or he just don't care anymore about the extension. So it needs to be taken over by someone else. But how we could know that? 7) Author has technical or account issues with the extensions website and is unable to upload a new version, and does not know where to get help. These are all possible concerns, but I think most of them can be managed with good communications and advance notice. There is also the possibility of: 8) Inconvenience -- it is natural for anyone to complain about needing to do additional work where they don't see the advantage. So it is natural that we will expect complaints, followed in the end by conformance with the required changes. Yes but what about the loss of confidence from users who will be first frustrated by an upgrade that breaks more things than fix them? Then they will have to do some homework to find out what the problem is (again, don't tell me about release notes). And wait in the end for someone to fix it. What if they do need their extensions meanwhile? One side aspect: what about extension update warning? If a new version is detected but the user doesn't upgrade to 4.0, are we sure that the minimal version will be checked first, before the new extension is installed by the user? Has he to download it before being warned that it's in fact not compatible with his current AOO/OOo version? I'm not against the change. I'm for a controlled one, that has no impact on end-users. So the main points are: communication to the extensions maintainers (what about the extensions hosted on their personal pages and not on sourceforge?), preparation of the updates and transition period. Hagar
Re: New page: Contributing Code
On 12 February 2013 23:55, Rob Weir robw...@apache.org wrote: On Tue, Feb 12, 2013 at 5:47 PM, janI j...@apache.org wrote: On 12 February 2013 23:19, Rob Weir robw...@apache.org wrote: We had a thread before Christmas discussing code contributions and best practices for how someone could contribute code to multiple projects, e.g., AOO and LO. I've written this up, along with more general remarks on contributing code on a new page: http://openoffice.apache.org/contributing-code.html Please take a look and let me know of any needed/recommended changes. Nice page, however I do not like We're not interested in large code-dumps., I would prefer if you wrote something like: Integrating large code-dumps requires cooperation and cannot be done as a simple commit, therefore we urge you to contact us on how we commonly can achieve the best result. Maybe there is a better of way of phrasing this, but we really don't want code dumps. In other words, we're not interested in having a new large body of code to maintain. A large code base requires developers to maintain it. If it is a code dump then this dilutes our attention on the existing code base. So new large contributions really need to come along with developers to help maintain the code. I understand you better now, and agree. Someone dumping 100.000 lines on our doorstep and disapearing is not an attractive situation. Just a side remark, I thought that was pretty much what happened with symphony, and now pick pieces and integrate. Actually I think your wording above, it much betterif you come with a large chunk of code, we need you as well :-) When I read the page, it sounds as if we are only interested in small code patches, and that cannot be correct. Of course if someone has written a function (maybe 1.000 lines), we are highly interested. If someone has written a complete new module (like a photo editor), then we need to talk. As an example my l10n tools are about 1.100 lines which I am sure is something we want (I know I am committer, but see it as an example). Maybe I need to define code dump then. I don't think what you are doing is code dump, It is large, but I assume that you don't just contribute it and disappear. Maybe it is really wording, I dont like negative wording on a page where we try to welcome people. But I agree to the idea of taken over a large chunk of code, requires the commitment of the developer as well. So help integrating is one part. For a bug fix is a smaller enhancement, maybe that is all we need. But suppose someone wants to contribute something large, like a complete new application as part of the suite? Let's see if we agree on that general idea. If so I can find a clearer way of expressing it. 1) bug fixes, small things, you current wording is quite ok. 2) bigger things, needs documentation and commitment to help with integration 3) large things (your 100.000 lines) needs ongoing commitment from the developers, otherwise we cannot maintain it. I know that is not the correct wording, but I hope we can agree of the idea...and then please positive wording :-) Have a nice day. Jan I. Ps. I dont intent to disapear, this is way too much fun. -Rob rgds Jan I. Thanks, -Rob
Re: Select column in Calc
On Tue, Feb 12, 2013 at 02:18:42PM -0600, Galileo Teco Juárez wrote: sorry mistake of translations this is the real question *how can i select the value of a colum in a specific cell. ie, select the value of 10 from the B4 cell* look at the API index for methods starting with G: http://www.openoffice.org/api/docs/common/ref/index-files/index-7.html getCellByPosition() function in interface ::com::sun::star::sheet::XCellRangesAccess http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/XCellRangesAccess.html#getCellByPosition getCellByPosition( [in] longnColumn, [in] longnRow, [in] longnSheet ) This method is support by the collection of sheets. getCellByPosition() function in interface ::com::sun::star::table::XCellRange http://www.openoffice.org/api/docs/common/ref/com/sun/star/table/XCellRange.html#getCellByPosition getCellByPosition( [in] longnColumn, [in] longnRow ) This method is supported by the single sheet. See http://wiki.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Cell_and_Cell_Range_Access Regards -- Ariel Constenla-Haile La Plata, Argentina # * # # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the # License); you may not use this file except in compliance # with the License. You may obtain a copy of the License at # #http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, # software distributed under the License is distributed on an # AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either express or implied. See the License for the # specific language governing permissions and limitations # under the License. # # * # HelloWorld python script for the scripting framework def MyHelloWorldPython( ): doc = XSCRIPTCONTEXT.getDocument() # may be it doesn't implement css.lang.XServiceInfo try: # check that we have a SpreadsheetDocument if not doc.supportsService(com.sun.star.sheet.SpreadsheetDocument): return None except: return None # the collection of sheets sheets = doc.Sheets # method taking col, row, spreadsheet cell = sheets.getCellByPosition(0,0,0) cell.Text.String = Hello world! on (0,0,0) # get the first spreadsheet from the collection sheet = sheets.getByIndex(0) cell = sheet.getCellByPosition(0,1) cell.Text.String = Hello world! on (0,1) cell = sheet.getCellByPosition(0,2) cell.Value = 18.63 return None pgptVBVgZZGTS.pgp Description: PGP signature
Re: [DEV] Compiler/build error
On Tue, Feb 12, 2013 at 05:13:00PM -0500, Fernando Martinez wrote: BUILD FAILED C:\source\aoo-trunk\main\hsqldb\wntmsci12.pro\misc\build\hsqldb\build\build. xml:302: Compile failed; see the compiler error output for details. If anybody could please help with this error and also tell me how to check the compiler error output. If you build with build --html then you have a folder in every module with the build output: module/buildout/misc/logs If you don't build with --html, simply cd to the module, and run build to rebuild the single module, you'll see the output in the terminal: cd main/hsqldb build I guess you have JDK 7 installed; if so, install a JDK 6 and configure with --with-jdk-home=absolute path to JDK home Regards -- Ariel Constenla-Haile La Plata, Argentina pgpFbOdfhXKum.pgp Description: PGP signature
Re: Completed Introduction to Contributing to Apache OpenOffice Module
Welcome. have you tried to build the source code yet? This may be a good starting place http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO On 02/12/2013 04:13 PM, Maarten Kesselaers wrote: Hello, My name is Maarten Kesselaers. I'm from Belgium and work as a project manager and EDI exchange expert. I used to code (Java, C++ and DOM) and helped other developers on forums, but I'm up to a new challenge. That's why I would like to help make AOO better. Kind regards, Maarten -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Select column in Calc
Do you want to get, take, or obtain the value that is in the cell, or, do you want to select the cell so that it is the current cell? On 02/12/2013 03:18 PM, Galileo Teco Juárez wrote: sorry mistake of translations this is the real question *how can i select the value of a colum in a specific cell. ie, select the value of 10 from the B4 cell* 2013/2/12 Galileo Teco Juárez genital...@gmail.com Select column in Calc as I can select from Python the value of a particular column in Calc or is necessary for the user to select? regards -- *Galileo Teco Juarez* *Web:* http://80bits.wordpress.com *Twitter:* @genitalico http://twitter.com/genitalico *Linkedin:* http://mx.linkedin.com/pub/galileo-teco-ju%C3%A1rez/30/690/797 -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Tutorial About
Hello Ariel, I did the patch you told me, but I have not results. I would like to know what would be the equivalent of a code tutorial about for this new source code to generate the button. 2013/2/12 Ariel Constenla-Haile arie...@apache.org Hi Jorge, On Tue, Feb 12, 2013 at 12:06:12AM -0600, jorge ivan poot diaz wrote: Here is the changes I made, I declare the button according to the tutorial, but I have not the expected results. http://ooo.pastebin.ca/2313036 http://ooo.pastebin.ca/2313037 The changes I have done well, as each code I put it where it belongs. But it's not simply putting code. You need to compile the code, and you''ll the errors: main/cui/source/dialogs/about.cxx: In constructor 'AboutDialog::AboutDialog(Window*, const ResId)': main/cui/source/dialogs/about.cxx:285:33: error: 'ABOUT_BTN_OK' was not declared in this scope main/cui/source/dialogs/about.cxx: In member function 'void AboutDialog::LayoutControls(Size)': main/cui/source/dialogs/about.cxx:446:30: error: 'aOutSiz' was not declared in this scope The errors speak for themselves: aOKSureButton( this, ResId( ABOUT_BTN_OK, *rId.GetResMgr() ) ), here, ABOUT_BTN_OK is not defined. In the new code, the define is RID_CUI_ABOUT_BTN_OK aOKSurePnt.X() = 135 + ( aOutSiz.Width() - aOKSureSiz.Width() ) / 2; there is no variable named aOutSiz in the current code. Besides, this hard coded layout won't work with the new code (all the layout is calculated relative to the two pictures, the logo (the orb) on the left and the header on the top. Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Updating Java libraries
On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote: On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote: I have updated the external_deps.lst with the updated hsqldb information. If someone can give me some pointer into how to just retrieve the jar instead of the source You don't retrieve precompiled stuff. The logic is: a) don't include the dependency at all b) include the dependency b.1) build it from source b.2) use the precompiled version in the system (this switch is only for external packagers, the builds are release with no system [configurable] dependencies). Regards I am still a little confused. Obviously it is possible to build from source but as a lot of email on the list have shown it could cause issues with the build that is not directly related to the AOO code. Why not just retrieve the jar so the build is inclusive? Wouldn't leaving it out allow someone to build with a version that is not fully tested? I am new to this type of development, so any clarification would be most helpful. I am used to retrieving compiled jars on the projects I worked on, in Java there is maven and ivy to retrieve specific version of the jar that the project is tested on along with the dependencies.
Re: Updating Java libraries
Hi Michael, On Tue, Feb 12, 2013 at 09:59:02PM -0500, Michael Lam wrote: On 02/12/2013 12:01 AM, Ariel Constenla-Haile wrote: On Mon, Feb 11, 2013 at 11:37:35PM -0500, Michael Lam wrote: I have updated the external_deps.lst with the updated hsqldb information. If someone can give me some pointer into how to just retrieve the jar instead of the source You don't retrieve precompiled stuff. The logic is: a) don't include the dependency at all b) include the dependency b.1) build it from source b.2) use the precompiled version in the system (this switch is only for external packagers, the builds are release with no system [configurable] dependencies). Regards I am still a little confused. Obviously it is possible to build from source but as a lot of email on the list have shown it could cause issues with the build that is not directly related to the AOO code. Why not just retrieve the jar so the build is inclusive? I don't know what motivated these rules, but I guess it was something in the lines of having control about what is being compiled and how it is being compiled (the use of the compiler, the Java base line, etc.). 35 million of downloads are worth not relaying on a jar built by someone else and, instead, build it from sources. I am used to retrieving compiled jars on the projects I worked on, in Java there is maven and ivy to retrieve specific version of the jar that the project is tested on along with the dependencies. But it is still trusting in a binary built by someone else. Every project is free to trust or build from sources. Historically, OpenOffice builds from external sources and includes these binaries in its releases, it has no external dependencies (other than the system libraries). The configure switches that allow building with system libraries/jars are only supported on *nix, and even there they are not relaying on a jar built by someone else: Linux distributions, for example, build all their jars; why do they build all by themselves instead of fetching compiled jars? I've no idea, but I guess they follow the same criteria mentioned above (as a Linux user you can use Maven in your projects, but it won't modify the system's jars). Regards -- Ariel Constenla-Haile La Plata, Argentina pgprnEyK5tGGc.pgp Description: PGP signature
Re: Calc behavior: result of 0 ^ 0
(OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Of course we can use the power function a^b in your spreadsheet when the b is a constant but you have to understand the assumptions being made before blindingly applying formulas, and we just can't assume every speadsheet user will use a restricted set of capabilities. Now, in a spreadsheet this formula would be used if you have a polinomial and you want to calculate and/or graph it's derivative. Since we don't do symbolic math in the speadsheet you would actually do this by hand and you would resolve the trivial constant^0 cases. In the case of the set theory book, do note that the author is constructing his own algebra, and it's natural that he might not want indefinite values that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. I guess looking hard it may be possible to find an elaborated case where someone manages to shoot himself in the foot but ultimately I would wonder. if this author *is* using mathematics correctly. 0^0 is a good indication that there is something wrong in your calculation and evidently Excel users have come to accept it. Pedro. *Welcome to this list ;).
Re: Tutorial About
Hi Jorge, On Tue, Feb 12, 2013 at 08:06:11PM -0600, jorge ivan poot diaz wrote: Hello Ariel, I did the patch you told me, but I have not results. Did you build it? Did it compile without errors? Did you copy the library with the modifications back in your installation? (you need to copy both the library and binary resource file). I would like to know what would be the equivalent of a code tutorial about for this new source code to generate the button. That tutorial doesn't explain much... if you've followed the steps in my previous mail (the one with the patch), you should be able to make it work. I repeat the steps: The sources are at: cui/source/inc/about.hxx - header cui/source/dialogs/about.cxx - source file cui/source/dialogs/about.hrc - IDs defines cui/source/dialogs/about.src - dialog structure definition Apply the attached patch, build, deliver, and copy the library in your office installation: Open a terminal, cd where you have the trunk source tree ]$ cd SRC_ROOT Apply the patch ]$ cat PATH_TO_PATH | patch -p1 cd the cui directory ]$ cd main/cui rebuild that directory and deliver ]$ build debug=true dbglevel=3 deliver copy the library ]$ cp -fv unxlngx6/lib/libcui.so BASIS_DIR/basis4.0/program/libcui.so copy the resource file ]$ cp -fv unxlngx6/bin/cui*.res BASIS_DIR/basis4.0/program/resource/ It seems I didn't give the last step in my previous mail. The resource files, the ones with the *.src extension, are compiled into a binary file that usually has the module name+language.res, for example cuien-US.res cuies.res cuide.res The languages dependen on the --with-lang=lang1 lang2 switch. They are located in unxlngx6/bin. When you modify a resource file, copy the re compiled binary back in your installation. As you are doing small changes, copying the recompiled files is easier that rebuilding the whole source try. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpTU2QtUrZyH.pgp Description: PGP signature
Re: Calc behavior: result of 0 ^ 0
My preference is to leave the patch and return #Value On 02/12/2013 01:11 PM, Dennis E. Hamilton wrote: RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
On 02/12/2013 05:07 PM, Marcus (OOo) wrote: Am 02/12/2013 10:39 PM, schrieb Rob Weir: Sorry, if it wasn't clear. I have a spreadsheet on my hard-drive right now that would be break if we changed the behavior of 0^0. And what is your *serious* use case for this spreadsheet? Beside to use it as a test document? And you have it created before the discussion has started? I'll ask my question again: Is there more than one who can deliever a *serious and valid use case*? I assume that the valid use case is that existing spreadsheets start returning different values than they do with the current release. It is always annoying when you have existing things that stop working when there is a new release. Admittedly, it may fail on any other program since the behavior is not well defined by the standard in this case. AOO is ODF compliant regardless, because the standard allows for the different values. On the other hand, if a sheet is designed to function with an error value returned for 0^0, I expect that it will then work the same on all implementations. Yeah, I prefer that we break the existing sheets, but I feel bad about it. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
On 02/12/2013 05:45 PM, Rob Weir wrote: On Tue, Feb 12, 2013 at 5:35 PM, Hagar Delest hagar.del...@laposte.net wrote: Le 12/02/2013 23:22, Rob Weir a écrit : But again, if you think that situation never comes up in real use, then let's not make the change, since it would have no benefit. You don't seem to see the benefit of the change: warn the user that there is something weird in the formula that requires his attention. Perhaps that there are users getting wrong results because a value is returned and therefore hides the problem. And your solution is to give users error messages where they do not have a problem ?! What if they the examine the formula and find out that it is exactly what they wanted? Your solution would force them to rewrite their formulas for no good reason. Again this is like giving an spelling error for their because some users might confuse it with there. -Rob I am torn as to which is worse. because loading the document in any other program able to read ODF might exhibit completely different behavior; and still be valid to the spec. Although I would prefer returning an error, if it does not, then it should stay as it is (as opposed to changing to one of the other supported values) -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Calc behavior: result of 0 ^ 0
On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote:
On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote:
(OK, I guess it's better to re-subscribe to the list).
In reply to Norbert Thiebaud*:
In the Power rule, which *is* commonly used for differentiation, we take a
series
of polinomials where n !=0. n is not only different than zero, most
importantly,
it is a constant.
Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed.
so for n=1 (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.
and we just can't assume every speadsheet
user will use a restricted set of capabilities.
Now, in a spreadsheet this formula would be used if you have a polinomial and
you want to calculate and/or graph it's derivative. Since we don't do
symbolic
math in the speadsheet you would actually do this by hand and you would
resolve
the trivial constant^0 cases.
Really... but extending by continuity a function in 0, without
consideration for convergence, _that_ is something that is done by
spreadsheet ?
iow just because 0^0 is an indeterminate _form_ does not mean that 0^0
can not have a value... it just mean that when searching for a limit
for a function h(x)
if your _transformation_ lead you to 0^0 you cannot conclude from that
_form_ that means that the rule and tools that allow you to jump form
lim - 0 to a value in 0 do not hold when they lead to that 'form'. I
know math is a tricky thing... but the definition of words and their
scope of application is kind of important in Math.
In the case of the set theory book, do note that the author is constructing
his own algebra,
The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.
You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better if this author(sic) *is* using mathematics correctly.
I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot
Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...
For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.
in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.
wrt to the 'context' of the quote I gave earlier:
Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}.
( I will use x^y here from now on to note x {superscript y} for readability )
Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0
For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
Here is the full context of the
