Re: Building with --without-system-serf
On 2/13/13 10:11 PM, Andrea Pescetti wrote: I've been busy with building lately, especially with building on Fedora 18 with the --with-system-libs switch, which should be used for packaging in Fedora. This is preparation work for the Fedora 19 packaging. To isolate the problematic dependencies, I configure with something like ./configure --with-system-libs --without-system-NAME1 --without-system-NAME2 [...] The effect in general is that the without switch overrides the generic --with-system-libs. So for example ./configure --with-system-libs --without-system-libxslt won't use the system library. Now, some libraries use a different convention: ./configure --with-system-libs --without-system-serf will still use the system library and not override the generic choice. You can see the different patterns in http://svn.apache.org/viewvc/openoffice/trunk/main/configure.in?view=markup (4002-4003 for the former pattern, 4579 for the latter) Any technical reasons for that? Otherwise I'll assume lazy consensus and modify configure.in to use the former pattern consistently, at least in the cases where I need it. The patch would be a variant of: -if test x$with_system_serf = xyes -o -n $with_system_libs; then +if test -n $with_system_serf -o -n $with_system_libs \ + test $with_system_serf != no; then I believe you don't have to wait, just fix it. Cleaning up and document configure would be a nice job for somebody who is familiar with autoconf, configure etc. Juergen
Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280
On 2/13/13 10:27 PM, Maarten Kesselaers wrote: My build just crashed on the build.xml under ./main/l10ntools/java/jpropex/ at line 122 : 122classpathref=classpath So I guess I need to set a CLASSPATH, right? To which directory should it be set? do you have configured a working build env with Java? If no please try to do that first. You don't have to tweak classpath settings manually, everything should be fine with working and well configured build env. On which platform are you building? Juergen
Re: crashes due to corrupted user profile [was: Re: [IMPORTANT, DISCUSS]: no migration/use of former user profile with AOO 4.0]
Hi Hagar, On 10.02.2013 21:32, Hagar Delest wrote: Le 06/02/2013 21:21, Hagar Delest a écrit : Le 06/02/2013 09:03, Oliver-Rainer Wittmann a écrit : BTW, does the above given workarounds work on your side? Sadly, it's the profile of the machine that got its Windows XP partition unusable anymore. So can't say. But I keep the information in mind and will check next time I see a corner case like that on the forum. Or will try to dig to find a still open topic about the crashes. It seems there is a positive one: http://forum.openoffice.org/en/forum/viewtopic.php?f=6t=59477 Your trick did work after the profile reset had no effect. Thanks for the positive feedback. Best regards, Oliver. P.S.: Sorry for the long silence, again. I had got another viral flue which knocked me out the last days.
Re: Calc behavior: result of 0 ^ 0
On 2/14/13 2:29 AM, Andrew Douglas Pitonyak wrote: On 02/13/2013 02:46 PM, Pedro Giffuni wrote: Independently of the vote result I will be effectively stopping the development work I intended to do on Calc as I have lost all interest on improving it given the current situation. I totally understand. I don't understand it. You are doing great work and the project appreciate what you are doing. Now a fix you have made is controversial which is understandable when taking the discussion into account. We have an old behaviour which is ok from the spec and we have a new one which is also ok from the spec perspective. You prefer the new one which reflect your fix, which is fine. Others see a potential risk to break backward compatibility which is fine as well. By the way I have personally no preference here ;-) Now it is our responsibility to find consensus for the solution we want support in the future. Many opinions and less who are doing the work, not really surprising and a general problem of such a big project. But we need to find consensus. I am sure you would accept the result of vote (if necessary when no consensus can be found) but at the same time you say that you will stop all your intended work in this area. And that is something that I don't understand. Well it's your decision and you can do what you want but is this the right approach? I believe not. I believe we should listen to each other and should at least try to understand and accept other opinions. And fixes which have a direct influence to our users are always special. I learned it as well in the last weeks when discussion about incompatible API/config changes came up that were long discussed and planned and where people starting now to understand what it really means. I still believe we need such changes but the way how we introduce them is important. In this special case I believe we still have time to inform extension developers and show the easy migration path. We all have to learn that changes can result in controversial discussion where at the end a decision have to be made (by vote if necessary but not preferred). I know for sure that I will hate it if something that I drive and where I do the work will be blocked mainly by people who prefer talking. But I have to learn to accept it and will do my best. Otherwise we will fail to move this project forward. So please continue your work and discuss the changes on the dev list as you did of course. And we all should try to give feedback early to any kind of proposed change from anybody to find consensus early before the work is done. Sorry, a little bit off topic from the thread. Juergen
Integration of the patches from OSB-Alliance, Office Interoperability
Hi all, some parts were developed by Lanedo and then integrated into LibreOffice. I have got the permission to forward the list of commit IDs. The OSB-Alliance can relicense them under Apache License 2.0. I think before we go to ask for relicensing, we should look whether this patches are useful for AOO. But it is beyond my code knowledge and available time to do this myself. You can get the patches from git://anongit.freedesktop.org/libreoffice/core using the commit IDs or look at them at http://cgit.freedesktop.org/libreoffice/core/log/ The lists are attached. Kind regards Regina 5923e540d4eab0dc331ea439377ec1eb407400b9 f88c296212ac39055d2179ecf6e19f9f3848a032 40411d73bb00f5bc1e65dc1d13727e55d0335fd6 6819f9b834581acd5507cd2301bda8b5395b937d 57ca766ab44e0d55ce21ee734aa0aafbff94eb45 1f2c079dd2bc9a2f5aa3597a8222bde3073a04da 8c178a50334109b34ef456ca6aa51cd3d98699ae ee9f23bb94b4c2c8c4db6466ecca272a092e9492 b1859c3a6d32dff66550c33831df241035d91aa9 18be0ce63bbff4132c198e29a34cf3e5a27369d5 194ba3a2cacbb5438dfcb8fb35167055e01ca251 1874df3041789729478ef99ff156ccee489c6a7a 87c66e9e3d7ab1351fac8db9aad80ed01e7634b6 40e0a5d73a5b7a0f23015ee481a94639400f581d 58aeb8e6aadd8511a700ec1c289bdc229f7592c9 73731b01cd65defdf9b42a9754bede3ba84221d7 75c05bd7d2e0e2fb41d4218eb0bb8f5631ca46fe 0dce7eae55bf90d2a7171a1fb8663d66ba4ac6d3 7d632ff29e601c2e680c4a689997fbf552592a4b 67f42de08bb5d075d554cf5aa1a4c106fe9e4f5c acef2d6cd075705eab015a4125badeca39078ef1 7705a50ba330cd3fa08f5edfe6617d9acde8e8a5 ec06049af9c40646772a8c8f7c3cf42d776b172d 78a5ce35db4cc762bbbc68e39dba1f73367ec520 69299e517b8f87089339c2b674be174a3f8b69be 64dc5a0c6d7ef1169fe09a0377106e98f71ce6f7 b0176f6245b996cdfabdce7ca299b95e4b64bb88 559a1a5d28d94e915150f94d5267a4f720d175b0 9a5eb5f51d29b3af4e2d23653508196cc68c0b87 9751056ba806ba9614392f3c70ada3cbd1251814 2cf0f5fe6244e1a98f82a1aca77b32c029c73e27 3cb619bd15a6017f253891f4c377fc790d8aae82 e33a9181c76309d31f2ace01b924e404906da28c 57633e42ffba2f495fd685233695acad6b9dde94 63a7550931c88ce06e4ab6f258121061c1f2dcf2 e1a509f4a362d21248b439c99e3b55f4fa9ba1bd f0efecfb69b336e064e7c8dd2597655eff07944f 53b7f7df0617bcbd7bbef9a34ef53e5097eb16dc commit 5923e540d4eab0dc331ea439377ec1eb407400b9 Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Wed Jan 23 14:26:02 2013 +0100 docx export: use 'nil' instead of 'none' to express no border Word2007 writes nil too, and doesn't properly import none. Change-Id: I32147bbf8c94f8dcf079bcecad48ffaaf3aa1968 commit f88c296212ac39055d2179ecf6e19f9f3848a032 Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Tue Jan 22 17:20:02 2013 +0100 docx export: fix table 'tblInd' attribute computation Change-Id: I3980ad8e372290973ed89488eb540267136af491 commit 40411d73bb00f5bc1e65dc1d13727e55d0335fd6 Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Wed Jan 16 11:11:52 2013 +0100 sw unit test: force layout compute after loading document Change-Id: I35173bbc2a4e33dfee555aa71f053e219ef01d1e commit 6819f9b834581acd5507cd2301bda8b5395b937d Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Wed Jan 16 00:48:28 2013 +0100 docx export: fix regression on table borders export The removed code was supposed to allow LO to write cell borders only if they were different from default cell border. Bug #59275 show that this is incorrect. Change-Id: If31914c412480fdadb775ca6675999ecde3e6bba commit 57ca766ab44e0d55ce21ee734aa0aafbff94eb45 Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Fri Jan 11 14:39:13 2013 +0100 docx export: add test case for paragraph mark export Change-Id: I2701ee12221460f8ff19397ea215cc1484648d18 Reviewed-on: https://gerrit.libreoffice.org/1650 Reviewed-by: Noel Power noel.po...@suse.com Tested-by: Noel Power noel.po...@suse.com commit 1f2c079dd2bc9a2f5aa3597a8222bde3073a04da Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Fri Jan 11 14:34:04 2013 +0100 sax: add methods to duplicate current top marker and reapply it later The need for this is ooxml: we need to have a duplicate entry (rPr) like this: p pPr rPr.../rPr /pPr r rPr.../rPR /r /p This patch allows to do that by setting aside a copy of the rPr line, and then merging the copy when needed. Change-Id: I3868a822aa9e5210f3d814c68398a38f95072cd5 Reviewed-on: https://gerrit.libreoffice.org/1648 Reviewed-by: Noel Power noel.po...@suse.com Tested-by: Noel Power noel.po...@suse.com commit 8c178a50334109b34ef456ca6aa51cd3d98699ae Author: Pierre-Eric Pelloux-Prayer pierre-e...@lanedo.com Date: Fri Jan 11 14:38:12 2013 +0100 docx export: also export rPr in pPr (paragraph mark styling) Change-Id: I179363e7d0acc3d6a1f95dcfe975275a9243e863 Reviewed-on: https://gerrit.libreoffice.org/1649 Reviewed-by: Noel Power noel.po...@suse.com
Re: [improvement idea] in-place editing of Input Fields in Writer
Hi, On 06.02.2013 17:39, Regina Henschel wrote: Oliver-Rainer Wittmann schrieb: Hi, recently I got notice about our (from my point of view) very user-unfriendly way for editing Input Fields in Writer. Currently, you can not place the cursor into an Input Field which in general is shown with a grey background when Menu View - Field Shading is on. If you click on the Input Field, a modal dialog pops up. In this dialog you can edit the Input Field's content. On confirmation of the dialog the Input Field's content is changed in the text document. To edit the next Input Field you need to click on it. There is also a special key shortcut - namely Shift-Ctrl-F9. This key shortcut opens the Input Field content editing dialog for the first field. This time the dialog has a Next button by which you can confirm your change and switch directly to the next Input Field. A Previous button is not available. By Murphys law the dialog hides most of the time the Input Field in the text document. I have got the opinion that such an editing experience is bad, especially, if the document is a form which makes use of a lot of Input Fields to be filled by the user. See issue https://issues.apache.org/ooo/show_bug.cgi?id=33737. Thank you Regina for the link to the issue. I am remembering this work as I was partly involved, but I did not had the issue number at hand. I my local environment, I tried this work and experienced the one or the other issue. This work relies on an ODF enhancement which was proposed to the OASIS ODF TC - the technical committee at OASIS which works on the OpenDocument file format standard -, but was not driven to bring it into the standard. The proposed ODF enhancement is also much more than just changing the editing capabilities of Input Fields. There is also an UI missing to insert such new fields. Thus, currently my preference is not to follow this approach for this proposed improvement. Best regards, Oliver. P.S.: Sorry for the long silence, again. I had got another viral flue which knocked me out the last days.
Re: [improvement idea] in-place editing of Input Fields in Writer
Hi Dennis, On 06.02.2013 19:35, Dennis E. Hamilton wrote: For real input fields, (that is, form:text elements), direct entry works. I am not sure what you mean by 'real input fields'. I am talking about the fields which are inserted into a text document in AOO Writer by Menu Insert - Fields - Other - Functions - Input field. These Input Fields are represented in ODF by the text:text-input. For these Input Fields we have no in-place editing in AOO Writer - as I have described. I assume that the case being discussed is for conventional field values that someone wants to edit. (Like a page number or a date field in a footer.) In those cases, I suppose direct entry might be useful. But there is probably something needed to avoid accidental type-overs and to also warn that other actions might later over-write the change. Allowing for that, allowing type-over seems like a reasonable improvement. No, I am not talking about these kind of fields. Best regards, Oliver. P.S.: Sorry for the long silence, again. I had got another viral flue which knocked me out the last days. - Dennis -Original Message- From: Oliver-Rainer Wittmann [mailto:orwittm...@googlemail.com] Sent: Wednesday, February 06, 2013 08:23 To: dev@openoffice.apache.org; us...@openoffice.apache.org Subject: [improvement idea] in-place editing of Input Fields in Writer Hi, recently I got notice about our (from my point of view) very user-unfriendly way for editing Input Fields in Writer. Currently, you can not place the cursor into an Input Field which in general is shown with a grey background when Menu View - Field Shading is on. If you click on the Input Field, a modal dialog pops up. In this dialog you can edit the Input Field's content. On confirmation of the dialog the Input Field's content is changed in the text document. To edit the next Input Field you need to click on it. There is also a special key shortcut - namely Shift-Ctrl-F9. This key shortcut opens the Input Field content editing dialog for the first field. This time the dialog has a Next button by which you can confirm your change and switch directly to the next Input Field. A Previous button is not available. By Murphys law the dialog hides most of the time the Input Field in the text document. I have got the opinion that such an editing experience is bad, especially, if the document is a form which makes use of a lot of Input Fields to be filled by the user. [ ... ]
I love Free Software
Hello, Thank you very much to all of you, men and women, developers, QA-persons, authors of documentation and all others, who support this great Free office-suite. Tanks to all, who remain true to our MissionStatement: To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. http://www.openoffice.org/about/ Kind regards Michael signature.asc Description: OpenPGP digital signature
[sidebar] warning in module svx during build
Hi, I am currently building branch sidebar, revision 1444704. I observed the following warning during the build in module svx: warning Text [ en-US ] = Color Light Preview; ^ f4099: c:/AOO/sources/sidebar/main/svx/source/engine3d/float3d.src, line 1440: Warning in the object (Type: String, 162): Global resources should have an identifier = 256. /warning Is this a critical warning? Thanks in advance, Oliver.
Re: Tutorial About
On 2013/02/14 2:27 AM, jorge ivan poot diaz wrote: How I can do a debug mode? Where I can find more information about the debug mode? http://wiki.openoffice.org/wiki/Non_Product_Build is a good start for the debug mode of AOO. Also http://wiki.openoffice.org/wiki/Debugging is a good start for debugging AOO using gdb. Herbert
Re: Integration of the patches from OSB-Alliance, Office Interoperability
Hi Regina, * On Thu, Feb 14, 2013 at 10:31:53AM +0100, Regina Henschel wrote: Hi all, some parts were developed by Lanedo and then integrated into LibreOffice. I have got the permission to forward the list of commit IDs. The OSB-Alliance can relicense them under Apache License 2.0. I think before we go to ask for relicensing, we should look whether this patches are useful for AOO. But it is beyond my code knowledge and available time to do this myself. a quick look at some patches reveals that we have some docx export code, but its not built: Adding these three files in sw/Library_msword.mk sw/source/filter/ww8/docxattributeoutput \ sw/source/filter/ww8/docxexport \ sw/source/filter/ww8/docxexportfilter \ shows that they don't build, there are some headers not delivered from oox/export oox/ole etc. but at least there are some sources. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpkoP4SpawXk.pgp Description: PGP signature
Re: Integration of the patches from OSB-Alliance, Office Interoperability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2/14/13 12:32 PM, Ariel Constenla-Haile wrote: Hi Regina, * On Thu, Feb 14, 2013 at 10:31:53AM +0100, Regina Henschel wrote: Hi all, some parts were developed by Lanedo and then integrated into LibreOffice. I have got the permission to forward the list of commit IDs. The OSB-Alliance can relicense them under Apache License 2.0. I think before we go to ask for relicensing, we should look whether this patches are useful for AOO. But it is beyond my code knowledge and available time to do this myself. a quick look at some patches reveals that we have some docx export code, but its not built: Adding these three files in sw/Library_msword.mk sw/source/filter/ww8/docxattributeoutput \ sw/source/filter/ww8/docxexport \ sw/source/filter/ww8/docxexportfilter \ shows that they don't build, there are some headers not delivered from oox/export oox/ole etc. but at least there are some sources. exactly some code is already there and I believe it is the foundation for any further work in LO, but I am not 100% sure. It would be worth to start a project working on this code. After 4.0 we can think of a motto for the next release or so. Andre had such an idea last week during a coffee break and mentioned we could call out a year of OOXML support. Means that we all concentrate on improved OOXML import and a working export. This could be really a challenging thing where hopefully many would work together. Collecting test documents, typical use case scenarios of real life documents, defining and implementing tests, implementing of course the necessary core changes in the filter and more ... Juergen -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRHNEEAAoJEM/u8xZRtf3ol68P/jNSJ8xwrnqLus0YSCkK3rLc STASPC4uP3+HhA67cP4bIH6gLHG4KAIaSOC+BSFoXXWhS2gI3ySVhWby3PMb2H+g JmEQVtLZHCOXeGL8h/Cj7KQau6Co1ksoeHZmOLHjYIe+oVC6j7MlBTt2Mr3voLdj tbGgA6lHetlRqBeAeylVdr7SwYkZn2OMkKTxIDsKT1iH9IDK0PRWQBWnfm7N9UiN pHDlGPw++QpKwh7/dDLqDJuK/F1aK+GSwWcyFbgg5J7SntaBGfrBj602Q+E9mnvR XWkqFc596sQrrkS5eFEaP9bOUorYU01vj2kLiLo1/EJ39se/vxLBuB5uUDZb2h2X GGGVgrDmJFcVmJ9Vc3R/lBFDyv3FdmwYBr4owEbKWKJgHDn/3NZtYASU9G+tZLRP p6G5WGRg0GCetFZcFuqk6Ai6V7zEWtzLbPQ/2aNxJox2fcnf2sPKS9BJ5QsG2vFW o7ttdqiAE3KbA5l9zDdTOQ9K+BqMKLPu6GT70sC9vMnJM8EUjWhdVyp4MEVFeVTU 6DkS+0QCdHU4Iy3P0SKMkzudqab2QCHpLb3QMYvdMhB1aHMA27mCkan3KlBH3rvi ldAebxiUOEDbvNOyJTpfxPmX9z2cVLTPGqUWdZcRwalFCxWVqkW4aM0waoei7ZRN HuR5Q4G4+wDekgfx8iph =OI67 -END PGP SIGNATURE-
Re: Calc behavior: result of 0 ^ 0
On 13/02/2013 Pedro Giffuni wrote: I will ask everyone to take a break for two weeks before starting the voting procedure for this. Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to write!) about the impact of this change, which can perfectly stay in daily builds at the moment... maybe someone will find more significant examples of spreadsheets relying on the result of 0 ^ 0. I won't reply to recent discussions on this thread since the point is not to explain to people what implementation-defined means or investigate what the several branches of mathematics use. Independently of the vote result I will be effectively stopping the development work I intended to do on Calc as I have lost all interest on improving it given the current situation. This is sad, but understandable. Anyway, as Juergen clarified, contributions are always welcome; it is really rare that code (assuming that people who posted to this thread did read the code...) gets this level of public discussion and most of the proposed improvements should be uncontroversial, so when you feel like to hack on Calc again just do it (sending a note here before any backwards-incompatible changes) and everybody will be happy, hopefully! Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Rob Weir .-- We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. The patch needs to be reverted, now. We actually have two *invalid* vetos I recall you aduced the change is not backwards compatible. Backwards compatibility is not a requirement for 4.0 release, especially in this case since we are trying to comply with a stricter standard. (Plus you added a section for backwards incompatible changes in the Release notes, so I guess you know it is OK). http://www.apache.org/foundation/voting.html To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, etc. ). A veto without a justification is invalid and has no weight. So you have two weeks to look for a valid technical justification: Pedro.
Wiki Accessibility
I have noticed that when signing up for the wiki sites you use the cat images captcha. I'm not blind myself, and i don't know much about how blind people use a computer, but I do wonder how a blind person would manage to solve this. Perhaps there is a way, but I thought I'd mention this in case it has been overlooked. I have seen other alternatives where it is possible to play back the captcha as audio, but I assume that won't work with cat images. Regards, Robin
Re: Calc behavior: result of 0 ^ 0
Rob Weir wrote: On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote: Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. Vetos must be based on technical grounds and can be withdrawn, see http://www.apache.org/foundation/voting.html#Veto (no, I haven't seen a clearly stated technical ground in Kay's mail). Due to the exceptional amount of posts in this thread, a proper vote is now the clearest way out, and in case of opposition it will allow to record clearly what the technical reason was. The patch needs to be reverted, now. Please do not go on and revert it now, and please do not escalate the problem again (this friendly advice applies to Pedro too). It is a trivial issue, with no side effects on the rest of the code, and it will be quickly solved by voting (where a -1 from a committer with a clearly stated technical ground counts as veto) well before a release, or even a beta version, containing it is distributed. Overstating the problem or insisting on this, no longer fruitful, discussion would only drain resources from more important topics. I recommend that we put community over code, suspend this discussion, take a final vote when Pedro calls it and respect its outcome, whatever it is. Regards, Andrea.
Re: Calc behavior: result of 0 ^ 0
Hi Andrea; - Messaggio originale - Da: Andrea Pescetti Rob Weir wrote: On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote: Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. Vetos must be based on technical grounds and can be withdrawn, see http://www.apache.org/foundation/voting.html#Veto (no, I haven't seen a clearly stated technical ground in Kay's mail). Due to the exceptional amount of posts in this thread, a proper vote is now the clearest way out, and in case of opposition it will allow to record clearly what the technical reason was. The reason why I am asking for a two weeks break from the issue is that the list is in bikeshed mode. As far as I can tell: - No one involved in thread has a spreadsheet depending on POWER(0, 0) and are only now aware that the value is somehow dubious. - With the notable exception of Regina, no one in this thread is doing Calc development and this change doesn't interfere with anyone else's work. - No one has complained about the technical merits of the patch. Was there a cleaer way to do it .. patches welcome!! AFAICT, just because this issue is easy to understand and somewhat controversial everyone think they should take a part of it. This called bikeshedding. I will not be bringing again this patch everytime there is a major release: if it doesn't make it in 4.0 it will be a sign that the fundamental Calc functionality is untouchable. I would prefer if people have time to evaluate the pros and cons of the patch before taking a vote. I honestly think the change is innocuous. The patch needs to be reverted, now. Please do not go on and revert it now, and please do not escalate the problem again (this friendly advice applies to Pedro too). It is a trivial issue, with no side effects on the rest of the code, and it will be quickly solved by voting (where a -1 from a committer with a clearly stated technical ground counts as veto) well before a release, or even a beta version, containing it is distributed. So far Regina's response has been the best structured opposition to the patch and without bikeshedding. I do have the patch ready to revert if if required but TBH I don't see valid reasons as of yet. Pedro.
Re: Calc behavior: result of 0 ^ 0
Hello Juergen; - Messaggio originale - Da: Jürgen Schmidt On 2/14/13 2:29 AM, Andrew Douglas Pitonyak wrote: On 02/13/2013 02:46 PM, Pedro Giffuni wrote: Independently of the vote result I will be effectively stopping the development work I intended to do on Calc as I have lost all interest on improving it given the current situation. I totally understand. I don't understand it. You are doing great work and the project appreciate what you are doing. Now a fix you have made is controversial which is understandable when taking the discussion into account. We have an old behaviour which is ok from the spec and we have a new one which is also ok from the spec perspective. You prefer the new one which reflect your fix, which is fine. Others see a potential risk to break backward compatibility which is fine as well. By the way I have personally no preference here ;-) First of all, I am not stopping from doing other changes in less controversial areas ... updating python to the final 2.7.4 version of fixing the java7 build seem to be reasonable uncontroversial and necessary tasks. The work I was planning to do on Calc involved a much deeper revision on how math is done. The idea was only sketched in some of the patches I left in Bugzilla and meant: - Replacing the native implementations of most functionality with the Boost counterparts. - Implementation of new functionality: including more complex functions, better statistics support and several random functions in line with what gnumeric does. Now, this meant quite an investment of my time to ensure that we move from something that works acceptably well to something that works better. This small change that caused the bikeshed is in those same lines: the POWER function we have works, but it can be better. As it is now POWER (x, 0) is a no-op (always 1), in my enhancement it regains it's mathematical value. This particular change had to be done only before a major release or not done at all. Now it is our responsibility to find consensus for the solution we want support in the future. Many opinions and less who are doing the work, not really surprising and a general problem of such a big project. But we need to find consensus. The thing is, and it is, I suppose, normal in any project, that I was willing to the work, I am not willing to spend time on the bikeshed part of it: mathematics is not something that should be left for democracy. I am sure you would accept the result of vote (if necessary when no consensus can be found) but at the same time you say that you will stop all your intended work in this area. And that is something that I don't understand. Well it's your decision and you can do what you want but is this the right approach? I believe not. I am OK with losing the vote: for all purposes people won't even notice the effect of the change. The lack of consensus is worrying though. It is a clear signal that work on Calc is not really welcome without an incredibly expensive discussion process and my time for such things is really limited nowadays. Pedro.
Re: Calc behavior: result of 0 ^ 0
Hi Juergen; - Messaggio originale - Da: Jürgen Schmidt ... And to be honest the technical ground for the veto is in this thread, especially Norbert's mail. As I replied to Norbert's email: the quote was taken out of context: the definition applies to some special purpose algebra in an invented set that has no connection to the regular math in a spreadsheet. In all honesty, the discussion about the correct value that should be assigned to 0 ^ 0 is in discussion since at least 1834 and is apparently not going to be solved in this list :). Pedro.
Re: Releasing incompatible changes
On Wed, Feb 13, 2013 at 10:32 PM, tj t...@apache.org wrote: Prior to working with AOO, I thought that there was a widely-known and generally accepted methodology for releasing incompatible changes. However, the problem has surfaced here three times: once last spring (encryption default), and twice currently (0⁰, and extensions with toolbars). I want to try to separate the how we release it from the should we do it and the technical details. The two key points of the method I'm used to are (1) long lead time, and (2) parallel operation. Introducing a new way and deprecating an old one are not really disruptive. The disruption comes when support for the old way is dropped, and something doesn't work any more. Hence, new ways and deprecations can be issued at any minor release, and the sooner the better. However, for an organization with so large a following as ours, we need to allow a lead time of an entire major release (though circumstances may vary) before dropping support. As an example, for the extensions change, we should say something like, A new method of handling toolbars [link] is provided in AOO 4.0. The old method is deprecated, and support may be dropped as soon as AOO 5.0. Extension developers should provide two versions, using MAX_VER and MIN_VER ... [Please excuse my ignorance, here.] Ariel is quite correct to point out that this parallelism doesn't come for free: it can involve a messy piece of code to be maintained. However, two points: (a) maintenance in the area should be near zero for the life of the lead time (unless the area is a target for new features), and (b) shouldn't we (developers) be doing the hard work, so our downstream folks have it easier? Providing parallelism for the Calc 0⁰ problem should be easy enough, while deferring our proposed change to 5.0. (I favor the change, but not so suddenly!) But note the differing expectations between developers and end-users. Developers know that code does not last forever. They know that any non-trivial piece of code needs to to be maintained and adapted due to changes in dependencies. This could be OS updates, 3rd party library updates or changes in OpenOffice API's. For extension authors, the OpenOffice API's are a large part of this dependency chain and they rely on us to practice good change management techniques to minimize the disruption when such changes occur. So I think everything you wrote above applies to the extension authors: they expect that changes will occur from time to time, and they rely on us to communicate these changes clearly and with sufficient advance notice that they can adapt their code in time. But end-users, the expectations are different. End users expect that with a new release the UI might change, that features might be enhanced. They expect that it will require some small amount of time to adjust to a new upgrade, especially a major one. But when it comes to THEIR documents (and I emphasize their to show that they consider this their property, not ours) they have a very low tolerance to having changes introduced in an upgrade. If the formatting changes during an upgrade, it is a FAIL. If pages renumber because of an upgrade, then it is a FAIL. If objects on a slide move after an upgrade, then it is a FAIL. And if a spreadsheet returns a result even a penny different, or introduces an error where once a calculation succeeded, then it is also a big FAIL. Where spreadsheets have evolved, they have done so very carefully, in a way that does not break backwards compatibility. For example, Excel 2013 has a legacy CEILING() function, but also a new CEILING.ISO() and a CEILING.MATH() function. They knew that it would be trouble if they changed the behavior of the existing function, so they created new versions to express the new behavior. In any case, I don't support the idea that end-users should be taught to expect breaking changes in their documents from release to release and that they will need to modify their documents to account for the changes we make. We need the engineering discipline and skill to avoid such breaking changes. IMHO. Regards, -Rob HTH, /tj/
Re: missing commit log
On Wed, Feb 13, 2013 at 11:38 PM, Carl Marcum cmar...@apache.org wrote: can I append a missing commit log? I committed r1446039 on command line okay, but r1446040and r1446041 using netbeans I missed the message: Added IT localization files Patch by: Fabrizio Marchesano fmarches...@gmail.com Review by: GianAngelo Cencio gacen...@gmail.com And thanks for giving attention to the patch by and review by comments. -Rob Thanks, Carl
Re: Wiki Accessibility
On Feb 14, 2013 2:33 PM, Robin Fowler robin.fow...@outlook.com wrote: I have noticed that when signing up for the wiki sites you use the cat images captcha. I'm not blind myself, and i don't know much about how blind people use a computer, but I do wonder how a blind person would manage to solve this. Perhaps there is a way, but I thought I'd mention this in case it has been overlooked. I have seen other alternatives where it is possible to play back the captcha as audio, but I assume that won't work with cat images. Hi you are quite right, our create account is not friendly towards blind people, having said that we need something like that in order to fight spam, and anybody who has a problem creating an account can mail this help and will get help. You might also have noticed that neither our wiki nor our www is especially friendly for blind people. A lot of pages uses pictures, and our menu tree is rather dynamic (makring it harder to remember). We are currently discussing updating/renewing both content and look/feel of the wikie, where I will keep your posting in memory. have a nice day Jan I Regards, Robin
Re: Wiki Accessibility
On 14 February 2013 16:05, janI j...@apache.org wrote: Hi you are quite right, our create account is not friendly towards blind people, having said that we need something like that in order to fight spam, and anybody who has a problem creating an account can mail this help and will get help. rationalwiki.org, which I'm a volunteer sysadmin on, uses MediaWiki with QuestyCaptcha with some success: https://www.mediawiki.org/wiki/Extension:QuestyCaptcha It asks a question in text form. This utterly confuses the spambots in our experience. Downside: it's really annoying to configure. - d.
Re: Wiki Accessibility
On Feb 14, 2013 5:13 PM, David Gerard dger...@gmail.com wrote: On 14 February 2013 16:05, janI j...@apache.org wrote: Hi you are quite right, our create account is not friendly towards blind people, having said that we need something like that in order to fight spam, and anybody who has a problem creating an account can mail this help and will get help. rationalwiki.org, which I'm a volunteer sysadmin on, uses MediaWiki with QuestyCaptcha with some success: https://www.mediawiki.org/wiki/Extension:QuestyCaptcha It asks a question in text form. This utterly confuses the spambots in our experience. Downside: it's really annoying to configure. I looked at that, but you really need somebody to maintain the questions (at least as I saw it), and that is a resource which we dont have today. There are many different captcha's available, and we tried some different ones. At least to me (as a maintainer) it is important to use one that does not require running maintenance, or takes a long time to configure. I do the maintenance of the mwiki (at OS level, others do a great job at sysop level), and cannot devote my full time to it. rgds Jan I. - d.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 1:58 PM, Kay Schenk kay.sch...@gmail.com wrote: On Thu, Feb 14, 2013 at 5:49 AM, Andrea Pescetti pesce...@apache.orgwrote: Rob Weir wrote: On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote: Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. Vetos must be based on technical grounds and can be withdrawn, see http://www.apache.org/**foundation/voting.html#Vetohttp://www.apache.org/foundation/voting.html#Veto (no, I haven't seen a clearly stated technical ground in Kay's mail). Due to the exceptional amount of posts in this thread, a proper vote is now the clearest way out, and in case of opposition it will allow to record clearly what the technical reason was. I readily admit this is true. I would like my veto to stand and here I will elaborate and hopefully provide my technical justification. In my mind, current mathematical information aside, we have implemented an acceptable solution based on the ODF specification. If, at some point, some universal mathematical body says without doubt that 0^0 should never ever be considered 1, then I am assuming the ODF standards body would change the standard for that function, and we would then change the current calculation. I have seen many references to this issue on the web, some which support the current implementation, some of which do not. In my mind, this needs to go back to OASIS. So for what it's worth, this is my technical justification. We are not a mathematical body, we are implementing code that complies to the ODF standard. If we have a problem with that standard, we need to discuss it with the standards body, not change existing code because of a personal viewpoint. And so it is clear, my technical objection is: Backwards compatibility of spreadsheet documents, and calculations specifically, is critical. If AOO 4.0 returns results that are even a penny different than earlier versions than this would be a severe defect. If we found such a defect even the day before a major release we would probably treat it as a stop ship blocking issue. Any change that breaks backwards compatibility is a technical issue. Fact: Pedro's patch changes the results of spreadsheet calculations in OpenOffice, introducing an error where there was not one before. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. Regards, -Rob The patch needs to be reverted, now. Please do not go on and revert it now, and please do not escalate the problem again (this friendly advice applies to Pedro too). It is a trivial issue, with no side effects on the rest of the code, and it will be quickly solved by voting (where a -1 from a committer with a clearly stated technical ground counts as veto) well before a release, or even a beta version, containing it is distributed. Overstating the problem or insisting on this, no longer fruitful, discussion would only drain resources from more important topics. I recommend that we put community over code, suspend this discussion, take a final vote when Pedro calls it and respect its outcome, whatever it is. Regards, Andrea. -- MzK A great deal of talent is lost to the world for want of a little courage. -- Sydney Smith
Re: Calc behavior: result of 0 ^ 0
Man.. do I have to repeat everything again? - Messaggio originale - Da: Rob Weir And so it is clear, my technical objection is: Backwards compatibility of spreadsheet documents, and calculations specifically, is critical. If AOO 4.0 returns results that are even a penny different than earlier versions than this would be a severe defect. If we found such a defect even the day before a major release we would probably treat it as a stop ship blocking issue. Any change that breaks backwards compatibility is a technical issue. Breaking backwards compatibility is acceptable for 4.0 Release given that we are attempting to comply with a stricter standard. If it were prohibited to do such changes then other Apache Projects would be in big trouble: look at Apache Lucene: http://lucene.apache.org/core/4_1_0/changes/Changes.html The same number of compatibility-related changes than optimizations! Fact: Pedro's patch changes the results of spreadsheet calculations in OpenOffice, introducing an error where there was not one before. OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. Oh, and Microsoft Excel, which holds a bigger market share than all the above mentioned alternatives is evidently buried within such mountain. :). Is this really the best you got? Why not take my offer and give it a two weeks thought? You may come up with something more elaborate. Pedro.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 2:58 PM, Pedro Giffuni p...@apache.org wrote: Man.. do I have to repeat everything again? - Messaggio originale - Da: Rob Weir And so it is clear, my technical objection is: Backwards compatibility of spreadsheet documents, and calculations specifically, is critical. If AOO 4.0 returns results that are even a penny different than earlier versions than this would be a severe defect. If we found such a defect even the day before a major release we would probably treat it as a stop ship blocking issue. Any change that breaks backwards compatibility is a technical issue. Breaking backwards compatibility is acceptable for 4.0 Release given that we are attempting to comply with a stricter standard. If it were prohibited to do such changes then other Apache Projects would be in big trouble: look at Apache Lucene: I am not talking about backwards compatibility in general. I am talking specifically about spreadsheet formulas. We have never had a discussion, and certainly not consensus, about breaking spreadsheet formula backwards compatibility for AOO 4.0. If I am in error in this, please point me to the thread. http://lucene.apache.org/core/4_1_0/changes/Changes.html We are talking about spreadsheet formula evaluation in AOO 4,0. I'm not talking about Lucerne. The same number of compatibility-related changes than optimizations! Fact: Pedro's patch changes the results of spreadsheet calculations in OpenOffice, introducing an error where there was not one before. OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. -Rob Oh, and Microsoft Excel, which holds a bigger market share than all the above mentioned alternatives is evidently buried within such mountain. :). Is this really the best you got? Why not take my offer and give it a two weeks thought? You may come up with something more elaborate. Pedro.
Two ideas for supporting images as well as text links in announcement area of website
I'd like to run this by as an idea.
Today, the announcement at the top of our website is controlled by this file:
https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/brand.mdtext
The announce and announceurl values then enter into the
templating process via:
https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/templates/brand.html
Specifically:
{% block announce %}{% if headers.announce %}div id=announcea
href={{ headers.announceurl }} title={{ headers.announcetip }}{{
headers.announce }}/a/div{% endif %}{% endblock %}
So what if we want to support images there as well?
Two approaches:
1) Add additional possible value for brand.mdtext, announceimage.
Change logic in brand.html so it follows some precedence order, say
look for announceimage first, if that exists, put an img there,
otherwise look for announce and display that as a a hyperlink.
2) Or, we could just change announce so it is the contents of a div.
So brand.html is actually simplified, and brand.mdtext would contain
the actual markup. For example, it could be: announce=a
href=foo.htmlimg src=foo.jpg alt=foo//a
#2 has the advantage of flexibility, that it allows other kinds of
markup to be inserted there, including lists, tables, etc.. Of
course, UI-wise, there is not a lot of space to play with, but it
would have that flexibility.
Any thoughts?
-Rob
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Rob Weir ... OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Please note that we don't return an error: this is not something that will cause core dumps or affect stability: we return Not a Number (NaN), which is more in line with the mathematical behavior of the real function and signals the end user that he likely made has to revisit his formulation (all very good IMHO). The distinction is important. I surely didn't introduce a bug. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. And I don't see a valid technical objection, just different criteria. Now, it is probably not fair for me to judge if your technical objection is valid or not. It surely doesn't fall within the common examples ( does not open a security exposure, negatively affects performance, etc) There should probably be an objective judge for these things (the PMC?) but it is not defined within the Apache procedures. Pedro.
Re: [BZ] Change strings with OOo on the BZ startpage
Am 02/13/2013 10:34 PM, schrieb Rob Weir: On Wed, Feb 13, 2013 at 4:24 PM, Marcus (OOo)marcus.m...@wtnet.de wrote: Hi BZ admins, https://issues.apache.org/ooo/ May I suggest some little string changes on the BZ startpage: HTML title -- Currently: Apache OOo Bugzilla Main Page New: Apache OpenOffice (AOO) Bugzilla Main Page Headline Currently: Welcome to Apache OOo Bugzilla New: Welcome to Apache OpenOffice (AOO) Bugzilla Link somewhat below the hreadline - Currently: Apache OOo Bugzilla User's Guide New: Apache OpenOffice (AOO) Bugzilla User's Guide On the top and bottom of every page (are these the header and footer?) there are other strings with OOo that should be changed, too. These all look like reasonable changes, but I don't see them as configuration items in the BZ admin tools available to us. The only text from the homepage that I can change from the admin tool is the message in the box: Please Note: All users with accounts with the legacy OpenOffice.org issue tracker... So we'll probably need to open an JIRA issue with Infra to get this updated. OK, I've done it with: https://issues.apache.org/jira/browse/INFRA-5865 Thanks Marcus
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir ... OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Please note that we don't return an error: this is not something that will cause core dumps or affect stability: we return Not a Number (NaN), which is more in line with the mathematical behavior of the real function and signals the end user that he likely made has to revisit his formulation (all very good IMHO). The distinction is important. I surely didn't introduce a bug. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. And I don't see a valid technical objection, just different criteria. Now, it is probably not fair for me to judge if your technical objection is valid or not. It surely doesn't fall within the common examples ( does not open a security exposure, negatively affects performance, etc) You have two vetos. Are you going to revert or shall I do it for you? You are welcome to continue the discussion all you want, but that should be done with the change reverted first. -Rob There should probably be an objective judge for these things (the PMC?) but it is not defined within the Apache procedures. Pedro.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 3:42 PM, Rob Weir robw...@apache.org wrote: On Thu, Feb 14, 2013 at 3:31 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir ... OOo already has plenty of functions that give backwards incompatible results with previous versions of OOo and Symphony (which is rather crappy). atanh, asinh, erf, everything in SAL has needed continued revisions. I have not seen anything that took a legitimate formula and changed it to an error. I'm not ab absolutist. I'm willing to consider changes at the 8th decimal points. But not gross level breaks in compatibility. Please note that we don't return an error: this is not something that will cause core dumps or affect stability: we return Not a Number (NaN), which is more in line with the mathematical behavior of the real function and signals the end user that he likely made has to revisit his formulation (all very good IMHO). The distinction is important. I surely didn't introduce a bug. Finally, treating 0^0 == 1 is very common in programming languages and spreadsheets, being the value returned by OpenOffice since 1.0, as well as by Calligra Sheets, Google Docs, Symphony, LibreOffice, Java, C, and .NET. Anyone arguing that the value is incorrect faces a mountain of contrary opinion and practice. So far you have failed to produce an example of reasonable use where such incompatibility is evident. For purposes of a veto I only need to show that I have a technical objection. And I don't see a valid technical objection, just different criteria. Now, it is probably not fair for me to judge if your technical objection is valid or not. It surely doesn't fall within the common examples ( does not open a security exposure, negatively affects performance, etc) You have two vetos. Are you going to revert or shall I do it for you? You are welcome to continue the discussion all you want, but that should be done with the change reverted first. And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. -Rob -Rob There should probably be an objective judge for these things (the PMC?) but it is not defined within the Apache procedures. Pedro.
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Presentation templates for ApacheCon NA 2013
Any updates on the discussion below? (I leave it for context since it was sent to multiple lists). ApacheCon NA 2013 is coming soon and speakers would really appreciate to have an updated presentation template within a few days! Regards, Andrea. On 08/02/2013 Shenfeng Liu wrote: Saransh, Thanks very much for your help! As I mentioned below, you can refer to the Apache OpenOffice template websitehttp://templates.openoffice.org and ApacheCon EU 2012 templatehttp://templates.openoffice.org/en/node/8865. We need to design 1 cover slide and 1 content slide. Last time we made the visual design in 2000*1500 jpeg files firstly. If people like the design, then we can take the picture as background and build the template (which I'm good at and can help ^_^ ). - Shenfeng (Simon) 2013/2/8 Saransh Sharmasara...@theupscale.in Count me in I love designing ...so tell me where to start ...bytheway i am an designer On Fri, Feb 8, 2013 at 8:53 AM, Steve Holdenst...@holdenweb.com wrote: Shenfeng: Thank you very much. I think given the season the Chinese contingent can be said to have fulfilled its obligations. I trust you will all have a very joyous Spring Festival. If any volunteer reading this wishes to approach the task, please get in touch. regards Steve On Feb 7, 2013, at 7:05 PM, Shenfeng Liu wrote: I talked to Xin Li, who was the template designer of 2012 ApacheCon EU. She kindly agreed to think about the template. But the problem is that next week is Chinese Spring Festival Holidays, and Xin may not able to work on it till Feb 16. Considering that we don't have much time left, I'd like to call for more UX volunteers to work together on the template design. If any one have interest in the template design, you can refer to the Apach OpenOffice template site here . And you can find the template used for 2012 ApacheCon EU here . I think the key is the background theme, which, IMHO, should have: (1) Apache logo + conference name; (2) some character of the host (e.g. for 2012 ApacheCon EU, we designed the ribbons of black+red+yellow to indicate that it was hosted in Germany). Just my 0.02$. And I also copied to openoffice dev list, hoping to have more volunteers. - Shenfeng (Simon) 2013/2/7 Steve Holdenst...@holdenweb.com I believe Daniel Gruno was kind enough to do some graphics for us for ACEU, and I believe ShenFeng Liu of the Open Office Group prepared the templates. I have copied them both in case they would like to, and have time to, help. regards Steve On Feb 6, 2013, at 10:21 AM, Mark Grover wrote: Hi, I was looking to see if there are any presentation templates available for ApacheCon NA 2013. I found some graphics at http://holdenweb.com/acna13gfx/ but no presentation templates. I also found a similar thread for ApacheCon Europe with some templates ( http://mail-archives.apache.org/mod_mbox/www-apachecon-discuss/201210.mbox/%3c506bcc23.6070...@nanthrax.net%3E ) but nothing for ApacheCon NA 2013. Any pointers or templates would be much appreciated! Thanks! Mark Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 -- Best Regards Saransh Sharma Upscale Consultancy PVT LTD. Disclaimer: -- This email was sent from within the Upscale Consultancy Services Pvt Ltd. The contents of this email, including the attachments, are LEGALLY PRIVILEGED AND CONFIDENTIAL to the intended recipient at the email address to which it has been addressed. If you receive it in error, please notify the sender immediately by return email and then permanently delete it from your system.The unauthorized use, distribution, copying or alteration of this email, including the attachments, is strictly forbidden. Thank you.Please note that neither Upscale Group nor the sender accepts any responsibility for viruses and it is your responsibility to scan the email and attachments (if any). --
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Calc behavior: result of 0 ^ 0
Hi all, please have a break. Keep in mind, that our community members from China have their Chinese New Year holidays and might not be back yet. Give them a change to notice the discussion. Kind regards Regina Andrea Pescetti schrieb: Rob Weir wrote: On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote: Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. Vetos must be based on technical grounds and can be withdrawn, see http://www.apache.org/foundation/voting.html#Veto (no, I haven't seen a clearly stated technical ground in Kay's mail). Due to the exceptional amount of posts in this thread, a proper vote is now the clearest way out, and in case of opposition it will allow to record clearly what the technical reason was. The patch needs to be reverted, now. Please do not go on and revert it now, and please do not escalate the problem again (this friendly advice applies to Pedro too). It is a trivial issue, with no side effects on the rest of the code, and it will be quickly solved by voting (where a -1 from a committer with a clearly stated technical ground counts as veto) well before a release, or even a beta version, containing it is distributed. Overstating the problem or insisting on this, no longer fruitful, discussion would only drain resources from more important topics. I recommend that we put community over code, suspend this discussion, take a final vote when Pedro calls it and respect its outcome, whatever it is.
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 4:47 PM, Rob Weir robw...@apache.org wrote: On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. And I should mention that this would come up quite frequently, due to the way Calc treats empty cells. So if a user had a spreadsheet for users to fill out and did: =a1^a2 and used that return in a calculation, and initially had A1 and A2 blank for the user to fill in, then before there was no error before the user entered data, but now there is. So it is essentially changing the UI of template spreadsheets. -Rob 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Rob Weir On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: Now that I recall, I did indeed test that and had noticed some strange errors but I thought it may be related with my systems' libc (I am also an OS developer in my spare time). 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. The last 4 values would've been sufficiently technical to cause the revert but I should be given the chance to revert it my self. in particular since the change in main/sc/source/core/inc/interpre.hxx were correct cleanups. Pedro.
Re: Two ideas for supporting images as well as text links in announcement area of website
On Thu, Feb 14, 2013 at 12:24 PM, Rob Weir robw...@apache.org wrote:
I'd like to run this by as an idea.
Today, the announcement at the top of our website is controlled by this
file:
https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/content/brand.mdtext
The announce and announceurl values then enter into the
templating process via:
https://svn.apache.org/repos/asf/incubator/ooo/ooo-site/trunk/templates/brand.html
Specifically:
{% block announce %}{% if headers.announce %}div id=announcea
href={{ headers.announceurl }} title={{ headers.announcetip }}{{
headers.announce }}/a/div{% endif %}{% endblock %}
So what if we want to support images there as well?
Two approaches:
1) Add additional possible value for brand.mdtext, announceimage.
Change logic in brand.html so it follows some precedence order, say
look for announceimage first, if that exists, put an img there,
otherwise look for announce and display that as a a hyperlink.
2) Or, we could just change announce so it is the contents of a div.
So brand.html is actually simplified, and brand.mdtext would contain
the actual markup. For example, it could be: announce=a
href=foo.htmlimg src=foo.jpg alt=foo//a
The Announcements line already has a div generated for it ---
see generated source:
div id=announcea
href=http://openoffice.apache.org/get-involved.html
view-source:http://openoffice.apache.org/get-involved.html
title=Read the announcementVolunteers needed in all areas — Help us
make 4.0 the best OpenOffice ever!/a/div
If this helps. Style is in:
http://www.openoffice.org/css/ooo.css
But you are correct, the WAY this is generated would need some changes.
#2 has the advantage of flexibility, that it allows other kinds of
markup to be inserted there, including lists, tables, etc.. Of
course, UI-wise, there is not a lot of space to play with, but it
would have that flexibility.
Any thoughts?
I would need to see some examples before any more thoughts on this. Right
now I think the format of the Announcements really needs some improvement
-- via margins especially.
Any images etc well might not work real well with current design.
If you have something particular in mind, some mockups would help.
-Rob
--
MzK
Achieving happiness requires the right combination of Zen and Zin.
Proposal: How we should handle committer vetos and reverts in the future
Obviously the changes to Calc's POWER() function did not go well. IMHO, we need to better respect the rare but powerful veto option that committers have: http://www.apache.org/foundation/glossary.html#Veto When a committ is vetoed, it should be reverted quickly. Remember, a veto is likely to come only after sufficient discussion on the list for one or more committers to think a veto is justified. So if there was a just a simple misunderstanding then it would have already been taken care of. So when a veto comes we need to treat it seriously and revert the change. (Think of it this way: If we treat a veto merely as Let's discuss this some more on the list but not take any actions right now then we don't really have a veto option. ) If the original coder is willing and able to revert quickly, then great. But anyone, including the veto'er can do this. It is not rocket science and does not require special knowledge: svn merge -c -XX (where XX is the revision number of the revision that introduced the change you want to revert) svn ci That's it. It is very likely that the person whose changes were vetoed will not like the veto or the revert. That is quite natural. We all have egos. None of us like having our changes rejected. We all have our egos wrapped up in our code. That is why we cannot rely on the original coder being the one to revert. We don't want to turn this into a battle of wills between the person who made the change and the person(s) who vetoed it.Put egos aside. A veto is not the opportunity to escalate the argument. A veto is an opportunity to isolate the controversial code where both sides can calmly discuss it, knowing that there is no longer immediate concern in the main code. And reversion is SVN is a simple mechanical act. It does not require anyone special to do it. Any committer can do it. Then, if needed, continue the discussion, including alternative approaches and solutions to satisfying the concerns of outstanding vetos. If the vetos are withdrawn, then the patch can go back in. Again, this is a simple mechanical task. The point of a veto and a quick reversion is to return the code base quick to a state where it does not contain controversial changes in it. And remember, a veto does not mean you are wrong. It just means that another committer, like yourself, has expressed serious concerns about your change. You should respect that concern and be willing to remove the code until these concerns are addressed. -Rob
Re: Calc behavior: result of 0 ^ 0
On Thu, Feb 14, 2013 at 5:18 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: Now that I recall, I did indeed test that and had noticed some strange errors but I thought it may be related with my systems' libc (I am also an OS developer in my spare time). 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. The last 4 values would've been sufficiently technical to cause the revert but I should be given the chance to revert it my self. in particular since the change in Sorry, but I believed you when you stated emphatically that you would not revert this patch: https://issues.apache.org/ooo/show_bug.cgi?id=114430#c28 In any case, I don't think anyone should care who reverts. Once a veto has been stated, the code needs to be reverted. Who does it is a matter of convenience. Please don't be offended if someone else does it. -Rob main/sc/source/core/inc/interpre.hxx were correct cleanups. Pedro.
New member's introduction - Tomas Zahradnik
Hi, I am a high school (gymnasial) student in 12th grade from Czech Republic, Prague. Since programming belongs to my biggest interests, I have a great motivation to extend my knowledge and gain valuable experiences. So far I have been learning through books, contests (codeforces, topcoder) and mostly through writting projects with bus factor 1. I dare to change it. Therefore I want to join Apache OpenOffice. I am slightly advanced in C++ and Java. I have just finished an engine for a card game called Raining (variety of mau-mau) and going to post it as open source with hope of finding someone who would help with UI (plus I created four different strategies how to play the game, run simulation and did statistics). As beginner with open sources I am still a little bit confused and not sure where it would be the best to start. I would be glad for some advice. Thank you. Tomas Zahradnik
Re: Proposal: How we should handle committer vetos and reverts in the future
Rob Weir wrote: When a committ is vetoed, it should be reverted quickly. Yes, when we have a proper veto, with valid technical grounds. A good side of the 0 ^ 0 discussion is that contributors are now better educated on this. If the original coder is willing and able to revert quickly, then great. But anyone, including the veto'er can do this. Of course anyone can. But it's appropriate to try and have the committer, and nobody else, undo his work, unless there are exceptional reasons (trademark concerns, build breakers that forbid others from getting this done...). It is very likely that the person whose changes were vetoed will not like the veto or the revert. That is quite natural. A committer is expected to be mature enough to understand rules: if a veto is issued, a committer will comply with policy and revert his patch, with no need that you step in and do it for him. It has already been discussed on this list: it may only be a matter of politeness, but someone sees it as unrespectful to have a commit reverted by someone else. Give him the opportunity to fix things himself, if not else as a way to acknowledge that the veto had the required technical grounds. Enforce the revert only if needed. The results on the code are identical, but the results on the community are different. And we all care about (and benefit from) having a healthy community, where everybody feels respected. Then, if needed, continue the discussion, including alternative approaches and solutions to satisfying the concerns of outstanding vetos. I agree that there should be no delay from the moment a veto is acknowledged to the moment the commit is reverted, and that discussions can be held after the revert. But, whenever possible, give the committer the opportunity to revert the commit himself. Regards, Andrea.
Become a Volunteer
Hi I want to become a volunteer for the development or another tasks of the project but i don't understand if i need firs introduce myself in the dev and next sign up on the wikis. What is the correct process for that. I apreciate the help. Thanks a lot.
Re: Proposal: How we should handle committer vetos and reverts in the future
On Thu, Feb 14, 2013 at 6:41 PM, Andrea Pescetti pesce...@apache.org wrote: Rob Weir wrote: When a committ is vetoed, it should be reverted quickly. Yes, when we have a proper veto, with valid technical grounds. A good side of the 0 ^ 0 discussion is that contributors are now better educated on this. If the original coder is willing and able to revert quickly, then great. But anyone, including the veto'er can do this. Of course anyone can. But it's appropriate to try and have the committer, and nobody else, undo his work, unless there are exceptional reasons (trademark concerns, build breakers that forbid others from getting this done...). It is very likely that the person whose changes were vetoed will not like the veto or the revert. That is quite natural. A committer is expected to be mature enough to understand rules: if a veto is issued, a committer will comply with policy and revert his patch, with no need that you step in and do it for him. It has already been discussed on this list: it may only be a matter of politeness, but someone sees it as unrespectful to have a commit reverted by someone else. Give him the opportunity to fix things himself, if not else as a way to acknowledge that the veto had the required technical grounds. Enforce the revert only if needed. The results on the code are identical, but the results on the community are different. And we all care about (and benefit from) having a healthy community, where everybody feels respected. Then, if needed, continue the discussion, including alternative approaches and solutions to satisfying the concerns of outstanding vetos. I agree that there should be no delay from the moment a veto is acknowledged to the moment the commit is reverted, and that discussions can be held after the revert. But, whenever possible, give the committer the opportunity to revert the commit himself. I agree with you that this is a good description of how a mainstream veto should work. I'm not sure we need to document how to handle the odd cases were there is explicit or implied refusal to revert from the original coder. But obviously every committer has it within their power to deal with such exceptional cases. That in itself should make it clear that it is ineffective to refuse or delay reverting a patch after a veto. -Rob Regards, Andrea.
Re: Become a Volunteer
On Thu, Feb 14, 2013 at 7:16 PM, Luis Ortiz 3ckb4...@gmail.com wrote: Hi I want to become a volunteer for the development or another tasks of the project but i don't understand if i need firs introduce myself in the dev and next sign up on the wikis. What is the correct process for that. Hello Luis, Welcome to the Apache OpenOffice project! We have quite a few mailing lists for the project, including this list (main dev list) as well as lists for documentation, QA, marketing, translation, etc. We also have several native-language lists. These mailing lists are described here: http://openoffice.apache.org/mailing-lists.html and http://openoffice.apache.org/native-lang.html So one approach is to simply sign up for the mailing list(s) that interest you and introduce yourself on each one. Another approach, more methodical, is to review our New Volunteer Orientation modules: http://openoffice.apache.org/orientation/index.html Those pages will teach you more about the project, how we work, what the various project areas are, how to get started, etc. For example, if you are interested in the coding side, this page has the information to help you get started: http://openoffice.apache.org/orientation/intro-development.html Regards, -Rob I apreciate the help. Thanks a lot.
Re: New member's introduction - Tomas Zahradnik
On Thu, Feb 14, 2013 at 5:06 PM, Tomáš Zahradník tzahr...@gmail.com wrote: Hi, I am a high school (gymnasial) student in 12th grade from Czech Republic, Prague. Since programming belongs to my biggest interests, I have a great motivation to extend my knowledge and gain valuable experiences. So far I have been learning through books, contests (codeforces, topcoder) and mostly through writting projects with bus factor 1. I dare to change it. Hello Tomáš, Welcome to the Apache OpenOffice project! We have many university students volunteering with the project, but I think you are our first high school student. Therefore I want to join Apache OpenOffice. I am slightly advanced in C++ and Java. I have just finished an engine for a card game called Raining (variety of mau-mau) and going to post it as open source with hope of finding someone who would help with UI (plus I created four different strategies how to play the game, run simulation and did statistics). Cool. As beginner with open sources I am still a little bit confused and not sure where it would be the best to start. I would be glad for some advice. Well, you start with what you already know. What operating system do you want to develop on? We build on Windows, Linux and MacOS. Most developers will tell you that it is easier to get started on Linux or MacOS. We have some New Volunteer Orientation pages to help new volunteers learn more about the project and how it works. If you are working on an open source project for the first time it is good to review these pages: http://openoffice.apache.org/orientation/ Then, when you get to the Introduction to Development page, it will try to help you get started with your first build of OpenOffice. But I can almost guarantee that your build will not work at first. So if/when you get an error, and can't solve it, post a question to the list and one of the other developers will try to help. Once you have a working build, then let us know. We have a list of easy tasks that you might want to try. Regards, -Rob Thank you. Tomas Zahradnik
Re: Proposal: How we should handle committer vetos and reverts in the future
- Messaggio originale - Da: Rob Weir Inviato: Giovedì 14 Febbraio 2013 17:31 Oggetto: Proposal: How we should handle committer vetos and reverts in the future Obviously the changes to Calc's POWER() function did not go well. IMHO, we need to better respect the rare but powerful veto option that committers have: http://www.apache.org/foundation/glossary.html#Veto Rare is the correct term. It seems to me like a last resort and that is likely to require some discussion. If I change is obviously broken you don't issue a veto, you simply discuss it. a veto is nowhere near being resolved within minutes. When a committ is vetoed, it should be reverted quickly. Remember, a veto is likely to come only after sufficient discussion on the list for one or more committers to think a veto is justified. So if there was a just a simple misunderstanding then it would have already been taken care of. So when a veto comes we need to treat it seriously and revert the change. The thing about the veto, and this happened today, is that there must be a clear technical issue with it. We were far from that point early today. (Think of it this way: If we treat a veto merely as Let's discuss this some more on the list but not take any actions right now then we don't really have a veto option. ) If the original coder is willing and able to revert quickly, then great. But anyone, including the veto'er can do this. It is not rocket science and does not require special knowledge: I disagree, this is extremely rude. Just like you don't put your fingers into your neighbours dish, you have to give space to other committers. Reverting someone elses commit is an insult, you are saying: you completely screwed up your change is worthless you shouldn't be a committer Under no circumstance should a committer be intimidated or made unconfortable about committing, furthermore, committing early is good as it let's your code be tested. Of course if you are being asked to revert all your changes you know you have to be careful. svn merge -c -XX (where XX is the revision number of the revision that introduced the change you want to revert) svn ci That's it. Oh, and I would certainly expect more care when reverting if you are not regularly working with the code: imagine trying to type a letter in a bus while a strager is erasing what you write. It is very likely that the person whose changes were vetoed will not like the veto or the revert. That is quite natural. What we have to avoid specifically are reverts to reverts: SVN is not the place to resolve issues: the mailing list is. In the case of todays revert you should have waited as I could've tried a quick fix. This is/was not an urgent issue and 99% of AOO was fully operational without affecting anyone elses work.. It doesn't really matter anymore (specially if the bug is where I think it is) but it is an experience to learn from. Pedro.
Re: Calc behavior: result of 0 ^ 0
Rob; Can you confirm the platform where you got those results? Thanks, Pedro. - Messaggio originale - Da: Rob Weir robw...@apache.org A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Cc: Inviato: Giovedì 14 Febbraio 2013 16:47 Oggetto: Re: Calc behavior: result of 0 ^ 0 On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote: - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Proposal: How we should handle committer vetos and reverts in the future
- Messaggio originale - Da: Dave Fisher ... I agree that there should be no delay from the moment a veto is acknowledged to the moment the commit is reverted, and that discussions can be held after the revert. But, whenever possible, give the committer the opportunity to revert the commit himself. As long as no delay allows for the person being some reasonable number of hours away from the their technology including that daily activity that some call sleep. Or work, we are all volunteers and can't necessarily spend time in the week to follow the list right? I would think no delay == within 24 hours. Pedro.
Re: Proposal: How we should handle committer vetos and reverts in the future
3 days I'd say is fine. There is no need to rush out and fix a broken trunk, no matter what the rationale may be. From: Pedro Giffuni p...@apache.org To: dev@openoffice.apache.org dev@openoffice.apache.org Sent: Thursday, February 14, 2013 9:32 PM Subject: Re: Proposal: How we should handle committer vetos and reverts in the future - Messaggio originale - Da: Dave Fisher ... I agree that there should be no delay from the moment a veto is acknowledged to the moment the commit is reverted, and that discussions can be held after the revert. But, whenever possible, give the committer the opportunity to revert the commit himself. As long as no delay allows for the person being some reasonable number of hours away from the their technology including that daily activity that some call sleep. Or work, we are all volunteers and can't necessarily spend time in the week to follow the list right? I would think no delay == within 24 hours. Pedro.
Re: Tutorial About
Hello Ariel, How I can update 3.5 to 4.0? I would like to know step by step how to do this. Help me. 2013/2/14 Herbert Dürr h...@apache.org On 2013/02/14 2:27 AM, jorge ivan poot diaz wrote: How I can do a debug mode? Where I can find more information about the debug mode? http://wiki.openoffice.org/**wiki/Non_Product_Buildhttp://wiki.openoffice.org/wiki/Non_Product_Build is a good start for the debug mode of AOO. Also http://wiki.openoffice.org/**wiki/Debugginghttp://wiki.openoffice.org/wiki/Debugging is a good start for debugging AOO using gdb. Herbert
Re: Proposal: How we should handle committer vetos and reverts in the future
On Feb 14, 2013, at 9:35 PM, Joe Schaefer joe_schae...@yahoo.com wrote: 3 days I'd say is fine. There is no need to rush out and fix a broken trunk, no matter what the rationale may be. In this case Pedro had already written that he *would not* revert the patch. I take that as permission for anyone else to do so, given that we had two vetoes.This doesn't mean there is a rush to revert. It just means that there is no reason to wait for Pedro to revert once he has already said he would not revert. -Rob From: Pedro Giffuni p...@apache.org To: dev@openoffice.apache.org dev@openoffice.apache.org Sent: Thursday, February 14, 2013 9:32 PM Subject: Re: Proposal: How we should handle committer vetos and reverts in the future - Messaggio originale - Da: Dave Fisher ... I agree that there should be no delay from the moment a veto is acknowledged to the moment the commit is reverted, and that discussions can be held after the revert. But, whenever possible, give the committer the opportunity to revert the commit himself. As long as no delay allows for the person being some reasonable number of hours away from the their technology including that daily activity that some call sleep. Or work, we are all volunteers and can't necessarily spend time in the week to follow the list right? I would think no delay == within 24 hours. Pedro.
Re: Calc behavior: result of 0 ^ 0
On Feb 14, 2013, at 8:51 PM, Pedro Giffuni p...@apache.org wrote: Rob; Can you confirm the platform where you got those results? I believe this was WinXP SP3 (32-bit), but I can confirm in the morning. -Rob Thanks, Pedro. - Messaggio originale - Da: Rob Weir robw...@apache.org A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Cc: Inviato: Giovedì 14 Febbraio 2013 16:47 Oggetto: Re: Calc behavior: result of 0 ^ 0 On Thu, Feb 14, 2013 at 4:19 PM, Pedro Giffuni p...@apache.org wrote - Messaggio originale - Da: Rob Weir And I should say that I'm happy to help if you or anyone else wishes to introduce a warning mode or formula lint or similar feature that can be optionally enabled to check for possible inadvertent user errors. As the guys from the poisonous people video[1] said: Patches Welcome Pedro, I reverted your patch. It was broken in many ways. It is sad that with the length of this thread that no one, apparently even you, tried to test it. But I did and found: 0^0 now returns a #VALUE! error in Calc, breaking compatibility. 2^(1/3) which should be the cube root of 2 now returns 1. This is mathematically incorrect and breaks compatibility. 2^(-1/3) which should be the reciprocal of the cube root of 3 returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -2^(-1/3) which should be an error (returns #VALUE! in AOO 3.4.1) now returns 1 with Pedro's changes. This is mathematically incorrect and breaks compatibility. -Rob Pedro. [1] http://www.youtube.com/watch?v=Q52kFL8zVoM
Re: Tutorial About
On Thu, Feb 14, 2013 at 09:05:55PM -0600, jorge ivan poot diaz wrote: Hello Ariel, How I can update 3.5 to 4.0? are you using subversion? What's the output of cd SRC_ROOT svn info Regards -- Ariel Constenla-Haile La Plata, Argentina pgp19b4POJgLl.pgp Description: PGP signature
:Re: Calc behavior: result of 0 ^ 0
Thats alright I just needed to know it was not linux. In the bugzilla issue Dennis had reported those were OK in some platform. Ah well, given the monster thread this caused excuse me if I dont hurry to fix it ;). Pedro.
R: Re: Proposal: How we should handle committer vetos and reverts in the future
Ugh... I think this is beating the dead horse now, but you cannot say I was unresponsive during this thread. The main question to rescue here is: How decides if a veto is valid or not? Kay#39;s veto really needed clarification and I still think that your original veto was not technical. Pedro.
Re: R: Re: Proposal: How we should handle committer vetos and reverts in the future
The PMC decides whether or not an expressed veto is valid or not. But generally speaking, vetos should not be either thrown around willy- nilly nor should they be challenged every time they are issued. It's all part of how we work, this recent episode should be considered a learning experience not a model for future work together. From: Pedro Giffuni p...@apache.org To: dev@openoffice.apache.org Sent: Thursday, February 14, 2013 10:46 PM Subject: R: Re: Proposal: How we should handle committer vetos and reverts in the future Ugh... I think this is beating the dead horse now, but you cannot say I was unresponsive during this thread. The main question to rescue here is: How decides if a veto is valid or not? Kay's veto really needed clarification and I still think that your original veto was not technical. Pedro.
Re: Calc behavior: result of 0 ^ 0
On 02/14/2013 09:29 AM, Jürgen Schmidt wrote: On 2/14/13 2:49 PM, Andrea Pescetti wrote: Rob Weir wrote: On Thu, Feb 14, 2013 at 7:34 AM, Andrea Pescetti wrote: Fine. I would have started the vote earlier, but it's your code so I'll respect your choice. And it's good to give people more time to think (not to We had a committer veto. Why are having a vote? A -1 from a commmitter is not something we vote on. Vetos must be based on technical grounds and can be withdrawn, see http://www.apache.org/foundation/voting.html#Veto (no, I haven't seen a clearly stated technical ground in Kay's mail). Due to the exceptional amount of posts in this thread, a proper vote is now the clearest way out, and in case of opposition it will allow to record clearly what the technical reason was. The patch needs to be reverted, now. Please do not go on and revert it now, and please do not escalate the problem again (this friendly advice applies to Pedro too). It is a trivial issue, with no side effects on the rest of the code, and it will be quickly solved by voting (where a -1 from a committer with a clearly stated technical ground counts as veto) well before a release, or even a beta version, containing it is distributed. Overstating the problem or insisting on this, no longer fruitful, discussion would only drain resources from more important topics. I recommend that we put community over code, suspend this discussion, take a final vote when Pedro calls it and respect its outcome, whatever it is. independent of this thread and just for completeness see http://www.apache.org/foundation/glossary.html#Veto According to the Apache methodology, a change which has been made or proposed may be made moot through the exercise of a veto by a committer to the codebase in question. If the R-T-C commit policy is in effect, a veto prevents the change from being made. In either the R-T-C or C-T-R environments, a veto applied to a change that has already been made forces it to be reverted. Vetos may not be overridden nor voted down, and only cease to apply when the committer who issued the veto withdraws it. All vetos must be accompanied by a valid technical justification; a veto without such a justification is invalid. Vetos only apply to code changes; they do not apply to procedural issues such as software releases. And to be honest the technical ground for the veto is in this thread, especially Norbert's mail. Juergen Thanks, this is very instructive for me! -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php
Re: Tutorial About
I have this subversion: svn co https://svn.apache.org/repos/asf/openoffice/trunk My question again, is how I can update basis3.4. to basis4? Explain me step by step please. 2013/2/14 Ariel Constenla-Haile arie...@apache.org On Thu, Feb 14, 2013 at 09:05:55PM -0600, jorge ivan poot diaz wrote: Hello Ariel, How I can update 3.5 to 4.0? are you using subversion? What's the output of cd SRC_ROOT svn info Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Tutorial About
Hi Jorge, On Thu, Feb 14, 2013 at 11:43:34PM -0600, jorge ivan poot diaz wrote: I have this subversion: svn co https://svn.apache.org/repos/asf/openoffice/trunk then you need to update the source tree: svn up There are several subversion tutorial on the web. Regards -- Ariel Constenla-Haile La Plata, Argentina pgpen7MBfCwKk.pgp Description: PGP signature
Re: [BUILD PROBLEM] Fail on JPropex build.xml line 122 \\ Error 65280
I have full working eclipse env and try to build on Mac OS X 10.6. All prerequisits are installed as described in the guide. Thanks, Maarten Op 14-feb.-2013 09:33 schreef Jürgen Schmidt jogischm...@gmail.com het volgende: On 2/13/13 10:27 PM, Maarten Kesselaers wrote: My build just crashed on the build.xml under ./main/l10ntools/java/jpropex/ at line 122 : 122classpathref=classpath So I guess I need to set a CLASSPATH, right? To which directory should it be set? do you have configured a working build env with Java? If no please try to do that first. You don't have to tweak classpath settings manually, everything should be fine with working and well configured build env. On which platform are you building? Juergen
Re: Presentation templates for ApacheCon NA 2013
Do you want me to design something!! On Fri, Feb 15, 2013 at 3:08 AM, Andrea Pescetti pesce...@apache.orgwrote: Any updates on the discussion below? (I leave it for context since it was sent to multiple lists). ApacheCon NA 2013 is coming soon and speakers would really appreciate to have an updated presentation template within a few days! Regards, Andrea. On 08/02/2013 Shenfeng Liu wrote: Saransh, Thanks very much for your help! As I mentioned below, you can refer to the Apache OpenOffice template websitehttp://templates.**openoffice.orghttp://templates.openoffice.org and ApacheCon EU 2012 templatehttp://templates.**openoffice.org/en/node/8865http://templates.openoffice.org/en/node/8865 . We need to design 1 cover slide and 1 content slide. Last time we made the visual design in 2000*1500 jpeg files firstly. If people like the design, then we can take the picture as background and build the template (which I'm good at and can help ^_^ ). - Shenfeng (Simon) 2013/2/8 Saransh Sharmasara...@theupscale.in Count me in I love designing ...so tell me where to start ...bytheway i am an designer On Fri, Feb 8, 2013 at 8:53 AM, Steve Holdenst...@holdenweb.com wrote: Shenfeng: Thank you very much. I think given the season the Chinese contingent can be said to have fulfilled its obligations. I trust you will all have a very joyous Spring Festival. If any volunteer reading this wishes to approach the task, please get in touch. regards Steve On Feb 7, 2013, at 7:05 PM, Shenfeng Liu wrote: I talked to Xin Li, who was the template designer of 2012 ApacheCon EU. She kindly agreed to think about the template. But the problem is that next week is Chinese Spring Festival Holidays, and Xin may not able to work on it till Feb 16. Considering that we don't have much time left, I'd like to call for more UX volunteers to work together on the template design. If any one have interest in the template design, you can refer to the Apach OpenOffice template site here . And you can find the template used for 2012 ApacheCon EU here . I think the key is the background theme, which, IMHO, should have: (1) Apache logo + conference name; (2) some character of the host (e.g. for 2012 ApacheCon EU, we designed the ribbons of black+red+yellow to indicate that it was hosted in Germany). Just my 0.02$. And I also copied to openoffice dev list, hoping to have more volunteers. - Shenfeng (Simon) 2013/2/7 Steve Holdenst...@holdenweb.com I believe Daniel Gruno was kind enough to do some graphics for us for ACEU, and I believe ShenFeng Liu of the Open Office Group prepared the templates. I have copied them both in case they would like to, and have time to, help. regards Steve On Feb 6, 2013, at 10:21 AM, Mark Grover wrote: Hi, I was looking to see if there are any presentation templates available for ApacheCon NA 2013. I found some graphics at http://holdenweb.com/**acna13gfx/http://holdenweb.com/acna13gfx/but no presentation templates. I also found a similar thread for ApacheCon Europe with some templates ( http://mail-archives.apache.**org/mod_mbox/www-apachecon-** discuss/201210.mbox/%**3C506BCC23.6070009@nanthrax.**net%3Ehttp://mail-archives.apache.org/mod_mbox/www-apachecon-discuss/201210.mbox/%3c506bcc23.6070...@nanthrax.net%3E ) but nothing for ApacheCon NA 2013. Any pointers or templates would be much appreciated! Thanks! Mark Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 -- Best Regards Saransh Sharma Upscale Consultancy PVT LTD. Disclaimer: --**--** --** This email was sent from within the Upscale Consultancy Services Pvt Ltd. The contents of this email, including the attachments, are LEGALLY PRIVILEGED AND CONFIDENTIAL to the intended recipient at the email address to which it has been addressed. If you receive it in error, please notify the sender immediately by return email and then permanently delete it from your system.The unauthorized use, distribution, copying or alteration of this email, including the attachments, is strictly forbidden. Thank you.Please note that neither Upscale
Re: Tutorial About
Hello Ariel, output of cd SRC_ROOT svn info Path:. URL: https://svn.apache.org/repos/asf/openoffice/trunk Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 1440197 Node type: directory Scheduled: normal Author of last change: alg Review of last change: 1439888 Date of last change: 01/29/2013 7:32:36 -0600 (Tue 29 Jan 2013) 2013/2/14 jorge ivan poot diaz ivan.pootd...@gmail.com I have this subversion: svn co https://svn.apache.org/repos/asf/openoffice/trunk My question again, is how I can update basis3.4. to basis4? Explain me step by step please. 2013/2/14 Ariel Constenla-Haile arie...@apache.org On Thu, Feb 14, 2013 at 09:05:55PM -0600, jorge ivan poot diaz wrote: Hello Ariel, How I can update 3.5 to 4.0? are you using subversion? What's the output of cd SRC_ROOT svn info Regards -- Ariel Constenla-Haile La Plata, Argentina
Re: Presentation templates for ApacheCon NA 2013
Ok Great let me work on it how much time do we have to complete this ...if we have short time i can ask my fellow designers to contribute and to help me if we have ample time then great!!! On Fri, Feb 15, 2013 at 10:19 AM, Saransh Sharma saransh-...@projktr.inwrote: Do you want me to design something!! On Fri, Feb 15, 2013 at 3:08 AM, Andrea Pescetti pesce...@apache.org wrote: Any updates on the discussion below? (I leave it for context since it was sent to multiple lists). ApacheCon NA 2013 is coming soon and speakers would really appreciate to have an updated presentation template within a few days! Regards, Andrea. On 08/02/2013 Shenfeng Liu wrote: Saransh, Thanks very much for your help! As I mentioned below, you can refer to the Apache OpenOffice template websitehttp://templates.**openoffice.org http://templates.openoffice.org and ApacheCon EU 2012 templatehttp://templates.**openoffice.org/en/node/8865 http://templates.openoffice.org/en/node/8865 . We need to design 1 cover slide and 1 content slide. Last time we made the visual design in 2000*1500 jpeg files firstly. If people like the design, then we can take the picture as background and build the template (which I'm good at and can help ^_^ ). - Shenfeng (Simon) 2013/2/8 Saransh Sharmasara...@theupscale.in Count me in I love designing ...so tell me where to start ...bytheway i am an designer On Fri, Feb 8, 2013 at 8:53 AM, Steve Holdenst...@holdenweb.com wrote: Shenfeng: Thank you very much. I think given the season the Chinese contingent can be said to have fulfilled its obligations. I trust you will all have a very joyous Spring Festival. If any volunteer reading this wishes to approach the task, please get in touch. regards Steve On Feb 7, 2013, at 7:05 PM, Shenfeng Liu wrote: I talked to Xin Li, who was the template designer of 2012 ApacheCon EU. She kindly agreed to think about the template. But the problem is that next week is Chinese Spring Festival Holidays, and Xin may not able to work on it till Feb 16. Considering that we don't have much time left, I'd like to call for more UX volunteers to work together on the template design. If any one have interest in the template design, you can refer to the Apach OpenOffice template site here . And you can find the template used for 2012 ApacheCon EU here . I think the key is the background theme, which, IMHO, should have: (1) Apache logo + conference name; (2) some character of the host (e.g. for 2012 ApacheCon EU, we designed the ribbons of black+red+yellow to indicate that it was hosted in Germany). Just my 0.02$. And I also copied to openoffice dev list, hoping to have more volunteers. - Shenfeng (Simon) 2013/2/7 Steve Holdenst...@holdenweb.com I believe Daniel Gruno was kind enough to do some graphics for us for ACEU, and I believe ShenFeng Liu of the Open Office Group prepared the templates. I have copied them both in case they would like to, and have time to, help. regards Steve On Feb 6, 2013, at 10:21 AM, Mark Grover wrote: Hi, I was looking to see if there are any presentation templates available for ApacheCon NA 2013. I found some graphics at http://holdenweb.com/**acna13gfx/ http://holdenweb.com/acna13gfx/but no presentation templates. I also found a similar thread for ApacheCon Europe with some templates ( http://mail-archives.apache.**org/mod_mbox/www-apachecon-** discuss/201210.mbox/%**3C506BCC23.6070009@nanthrax.**net%3E http://mail-archives.apache.org/mod_mbox/www-apachecon-discuss/201210.mbox/%3c506bcc23.6070...@nanthrax.net%3E ) but nothing for ApacheCon NA 2013. Any pointers or templates would be much appreciated! Thanks! Mark Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 Steve Holden st...@holdenweb.com +1 571 484 6266 @holdenweb -- Python classes (and much more) through the web http://oreillyschool.com/ Conferences and technical event management at http://theopenbastion.com/ Next event:ApacheCon NA 2013: Feb 26-28 http://na.apachecon.com/ Community events: Barcamp Feb 24 Hackathon Feb 25 Development Mar 1/2 -- Best Regards Saransh Sharma Upscale Consultancy PVT LTD. Disclaimer: --**--** --** This email was sent from within the Upscale Consultancy Services Pvt
RE: :Re: Calc behavior: result of 0 ^ 0
I did not test with your patch. I reported on behavior of available releases. - Dennis -Original Message- From: Pedro Giffuni [mailto:p...@apache.org] Sent: Thursday, February 14, 2013 19:42 To: rabas...@gmail.com; dev@openoffice.apache.org Subject: :Re: Calc behavior: result of 0 ^ 0 Thats alright I just needed to know it was not linux. In the bugzilla issue Dennis had reported those were OK in some platform. Ah well, given the monster thread this caused excuse me if I dont hurry to fix it ;). Pedro.
Re: Implementation-defined behaviors in ODF spreadsheets
On 13/02/2013 Rob Weir wrote: This lead to a series of behaviors which were specified to be implementation-defined, or in some case locale-defined or unspecified. These are subtly different, and express nuances common in standards, what we refer to as dimensions of variability. And where does OpenOffice document its choices? In OpenDocument-v1.2-cd05-part2 2.3 I read: Applications should document all implementation-defined and variances from this standard in a manner that the application users can obtain the information (e.g., in the application help for the relevant function). If we have nothing, starting a wiki page seems a better option than integrating the application help right now. If we ever do go to a warning mode in Calc, where users are warned about potential calculation issues, these would probably be ones that we would check for. This is not going to happen soon, but by 4.0, especially if we want to advertise the better ODF compliance we'll have by then, our implementation-defined behavior should be documented. Regards, Andrea.
