Re: Symphony IP Cleanup
Taking a little break from my vacations ... - Is there anything in particular that you want to see cleaned up? Extracting code without the history is not exactly easy so we basically have to check wth the IBM guys anyways. There is also the issue that we only release code through the project releases and it was decided we wont do Symphony-based releases. Just like the code in experimental branches, changing the license headers doesnt imply the code has been or will be released and shouldnt be used as a base in other projects. FWIW, the code as is, has already been of use for bringing new stuff into AOO 3.5. Pedro.
RE: Symphony IP Cleanup
Hi Dennis; I am afraid that what we are doing is exactly cherry picking code and creating patches. AFAICT there is no one actively working on the symphony code. If I notice something I like, I open a bugzilla issue and try to get someone from IBM to look at it. The code still has unacceptable components (at least lcc cpp) and I am not sure it builds. I guess if you find it too bothersome we could move the code to Apache Extras, but it is still useful to be able to look at it somewhere. Pedro. Ps. ApacheCon was fun indeed!
RE: Symphony IP Cleanup
--- Gio 15/11/12, Dennis E. Hamilton dennis.hamil...@acm.org ha scritto: ... So there is flexibility so long as no code appears in releases, but as you point out, code is leaking from the Symphony base into releases under the table. That is not healthy. I wouldnt put it like that. We are slowly taking what we need, and that actually saves us time as we are not spending resources on things that will never be released. This approach depends on having IBM developers available but that is luckily the case. All just IMHO though. Pedro.
Re: [QA] Python version late for MacOS
Thank you Tsutomu-san! I am currently busy with other stuff but I am aware of what's needed in our pyuno layer so I will examine your code soon. Pedro. - Original Message - From: Tsutomu Uchino Hi, 2012/12/2, Pedro Giffuni : FWIW; After updating Python to 2.7.3 I started working on updating pyuno so that it works with Python3 and Python2. I didn't finish and I don't really have much time for that lately but I will be glad to point someone else in the right direction. I modified pyuno to support Python 3.3 with new functions added on 3.3. But it does not support Python from 3.0 to 3.2. If someone interested in it: https://github.com/hanya/pyuno3 I will make a patch and attach to issue if required. -Tsutomu Adding support for Python3 in pyuno is important and people that make their own packages will need it but in general I would advice against doing the update to 3.x by default now. Let others deal with the migration issues first ;). Pedro. - Original Message - On Fri, Nov 30, 2012 at 8:33 AM, Rob Weir wrote: On Fri, Nov 30, 2012 at 7:11 AM, Andre Fischer wrote: On 30.11.2012 12:02, FR web forum wrote: In trunk we currently have version 2.7.3. Would that be OK? Python 2.7.3 is in end of life. It will be better to directly include Python 3.3. Compatibility for extensions will be more easy with future LibO 4 that use already this version. I thought that 2.x is incompatible from 3.x. Would existing extensions still work with 3.3? Moving to 3.x would be an incompatible change. But 2.7.x is on extended maintenance but no new features are being done there. So the future is certainly with 3.x. But we would need to communicate very carefully with extension authors if we want to make this move. We want to avoid this: 1) AOO 4.0 comes out with broken extensions and unhappy users 2) Extension authors have insufficient time to test with Python 3.x support, leading to 1 3) Extension authors are not aware that we are switching to Python 3.x, leading to 1 So if we want to do this we would need to notify extension authors ASAP and give them a way to test their extensions with Python 3.x. So maybe integrate the new Python early and have a developer preview version that they can test with? -Rob -Andre
Re: Unprocessed solaris bugs
Hi; I went ahead and reviewed some of them... not all. Pedro. - Original Message - From: Jürgen Schmidt jogischm...@gmail.com To: dev@openoffice.apache.org Cc: Sent: Monday, December 3, 2012 10:42 AM Subject: Re: Unprocessed solaris bugs On 12/3/12 3:55 PM, Jean-Louis 'Hans' Fuchs wrote: Hello I have reported the following bugs in april: https://issues.apache.org/ooo/show_bug.cgi?id=120751 https://issues.apache.org/ooo/show_bug.cgi?id=119253 https://issues.apache.org/ooo/show_bug.cgi?id=119252 https://issues.apache.org/ooo/show_bug.cgi?id=119250 https://issues.apache.org/ooo/show_bug.cgi?id=119249 https://issues.apache.org/ooo/show_bug.cgi?id=119251 None of these have been processed, we still have to patch most of these. How can we proceed to complete these issues? I assume the reason is simply because they felt out of scope ;-) I will take a look on it asap and when they are all for Solaris only and don#t conflict on other platforms I see not problem to include them. Juergen Best, Jean-Louis
Re: Official Solaris
Hello Jean-Louis; From: Jean-Louis 'Hans' Fuchs Hello We are working on building AOO for Solaris on Sparc and x86. There are people out there who would like to see official builds for these platforms. For us (and our customers), this would also be a great step forward, and we're eager to do what we can to work on this. This is great news! So, here's a few questions / discussion points. * What are the steps required to promote those builds to be official AOO builds? Is there an official process? * What is the process to make solaris a officially supported platform, other than providing official installers/binaries? There is no actual process, we just want to make sure that there is someone that makes sure it builds and works fine with the code in trunk and that provides the official builds. I understand you might be helping set up a buildbot which is a great start. We are currently checking with our customers if we could move to the GNU Toolchain instead of the Solaris-compiler. (One uses a plug-in that is available in binary only.) This would resolve many build-problems and reduce our effort. * Is something to be said against moving to GCC on solaris? Nothing against it. The main issue is probably the C bridge and then the linux/bsd ports may be of help. There is a few documentation on how it's done: http://wiki.openoffice.org/wiki/Porting_Introduction Pedro.
Easy task for a first time committer
Hello; There is a small patch recently applied on LibreOffice and I confirmed the issue it fixes also happens in AOO. I don't think the patch is copyrightable but in any case I thought I would share here how to clean room it, as an example for similar patches we would like to adopt. In similar cases we could just open a bugzilla issue with enough information to reproduce the bug AND the fix, without including the specific patch. The issue is: when setting up your printer you can define the Postscript level. OO will give you the option to set it to Postcript level 3 but after choosing level 3 it will only set it to level 2. To solve this go to file main/padmin/source/rtsetup.src Search for the string PostScript Level 3 (line 167) As you see after the semicolon there is a 3 which is also the value assigned for Level 2. Change the 3 value to a 4. compile, test and commit :). cheers, Pedro.
Re: Easy task for a first time committer
From: Lucas Burson
...
To solve this go to file
main/padmin/source/rtsetup.src
How are files like these parsed?
For this printer ListBox ('RID_RTS_DEVICE_PRINTLANG_BOX') I found
where it is initialized [1]. Then I found resource managers, and [2]
which is some class dedicated to resources. But I don't see where that
file is actually parsed. Any help?
Thanks,
Lucas
[1]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/padmin/source/prtsetup.cxx#364
[2]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/tools/inc/tools/resid.hxx#41
I think what matters is RID_RTS_DEVICE_LEVEL_BOX
I looked at it yesterday and I didn't find it either: my understanding is that
the value is set and sent to the printer driver (cups?). Curiously the value
appears in
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/test/testgui/ids/obsolete_hid#6906
So it might be doing nothing as well!
The only thing that matters is that 4 is a valid value. And of course there was
a reason to
mention compile and test phases before committing. :)
Pedro.
Re: AOO trunk build fails with HSQLDB
- Original Message -
From: Ariel Constenla-Haile
Hi Lucas,
On Sun, Dec 16, 2012 at 01:52:49PM -0600, Lucas Burson wrote:
Hi,
...
It fails. I get a bunch of compiler errors about abstract methods not
being overridden:
[javac]
/home/ljdelight/aoo/trunk/main/hsqldb/unxlngx6.pro/misc/build/hsqldb/src/org/hsqldb/jdbc/jdbcStatement.java:127:
error: jdbcStatement is not abstract and does not override abstract
method isCloseOnCompletion() in Statement
[javac] public class jdbcStatement implements Statement {
[javac] ^
This method was added on Java 7, see
http://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#isCloseOnCompletion%28%29
There is a patch in debian that adds some stubs for this. The real solution is
updating hsqldb
though.
On the subject of Java 7, someone should look at
https://issues.apache.org/ooo/show_bug.cgi?id=121098
The fix is rather trivial.
Pedro.
Re: AOO trunk build fails with HSQLDB
Hello Kay; Yes, I can confirm after solving those two issues,we got OpenOffice building with JDK 7 on FreeBSD: http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/files/ Pedro.
Chinese list (was Re: [Blog Draft] Update about Apache Asia Road Show Beijing 2012 @Dec 13)
Hello; FWIW, one idea that I left floating during ApacheConEU was the creation of a chinese list. Imacat was working on it, no idea if it the idea is still alive or waiting for volunteers to help moderate, etc. Pedro. - Messaggio originale - Da: Yue Helen I missed the great event...Thanks for the update! Looking forward to more users and contributors from China. Helen 2012/12/17 Shenfeng Liu liush...@gmail.com Hi, all, I just want to give you an update that we had a successful Apache OpenOffice session last Thursday (Dec 13) on Apache Asia Road Show 2012 Beijing. Thanks to Peter, Tao and Da Li for the speech! The topics covered AOO general introduction, contributions from local volunteers, how to join community and make contribution, and building social/cloud solutions by integrating with AOO. We also distributed AOO promotion materials that prepared by Da Li. We got more than 100 audience participated in the OpenOffice session 14:00-15:00. Most of them are technical people from different companies and universities. Per my check during my speech, only 20 had used OpenOffice before. So it is really a good promotion of our product and community. We are refining the presentations and will publish them later. Thanks! - Shenfeng (Simon) 2012/12/5 Peter Junge peter.ju...@gmx.org OK. On 12/5/2012 4:55 PM, Shenfeng Liu wrote: Peter, Thanks for your comments! I added the speaker names per the presenting sequence. Apache OpenOffice in Apache Asia Road Show Beijing 2012 at December 13 Apache Asia Road Show Beijing 2012 will be held at December 13, and Apache OpenOffice will deliver a session in the conference. In the Apache OpenOffice session, Peter Junge, Apache OpenOffice PMC member, will give a speech to introduce Apache OpenOffice, its history and way in Apache. And other contributors in Beijing, Shenfeng Liu, Hongyun An, Tao Liu and Dali Liu, will also give their speech to share the best practice of contributing to the open source community, as well as building enterprise business and Cloud/Social solution on top of Apache OpenOffice. Please visit the Apache Asia Road Show Beijing 2012 website and register: http://apacheasiaroadshow04.eventbrite.com . We are looking forward to seeing you there! Apache OpenOffice将在12月13日Apache Asia Road Show Beijing 2012大会上介绍其发展及解决方案 Apache Asia Road Show Beijing 2012将于12月13日在北京中关村软件园举行。届时Apache OpenOffice将在大会上介绍其发展及相关解决方案。 在论坛上，Apache OpenOffice项目管理委员会成员Peter Junge将首先介绍Apache OpenOffice及其历史和发展方向。其他在北京的Apache OpenOffice志愿者，刘慎锋，安红云，刘涛，刘大力等，也会分享在Apache OpenOffice开源社区做贡献的经验，以及如何基于Apache OpenOffice开发企业应用和云计算及社交解决方案。 欢迎大家到Apache Asia Road Show Beijing 2012网站注册： http://apacheasiaroadshow04.eventbrite.com！让我们共同关注Apache OpenOffice，共同推动开源社区的发展！ - Shenfeng (Simon) 2012/12/5 Peter Junge peter.ju...@gmx.org I would also mention the names of the other speakers. Apart from that it's OK. Peter On 12/4/2012 11:15 PM, Rob Weir wrote: On Mon, Dec 3, 2012 at 11:21 PM, Shenfeng Liu liush...@gmail.com wrote: Don, Thanks for your suggestion! Here is my draft of the blog, in English Chinese. Please review and give your comments! I found myself not able to edit the blog directly, so I wonder if you or any one else can help to post? Thanks very much! Here is the post, in draft form on the blog: https://blogs.apache.org/**preview/OOo/?previewEntry=** apache_asia_road_show_beijing https://blogs.apache.org/preview/OOo/?previewEntry=apache_asia_road_show_beijing Let me know if it is OK and I will publish it. -Rob --**-- Apache OpenOffice in Apache Asia Road Show Beijing 2012 at December 13 Apache Asia Road Show Beijing 2012 will be held at December 13, and Apache OpenOffice will deliver a session in the conference. In the Apache OpenOffice session, Peter Junge, Apache OpenOffice PMC member, will give a speech to introduce Apache OpenOffice, its history and way in Apache. And other contributors in Beijing will also give their speech to share the best practice of contributing to the open source community, as well as building enterprise business and Cloud/Social solution on top of Apache OpenOffice. Please visit the Apache Asia Road Show Beijing 2012 website and register: http://apacheasiaroadshow04.**eventbrite.com
Re: AOO trunk build fails with HSQLDB
- Messaggio originale - Da: Ariel Constenla-Haile On Mon, Dec 17, 2012 at 09:10:09AM -0800, Kay Schenk wrote: On Sun, Dec 16, 2012 at 2:50 PM, Pedro Giffuni wrote: Hello Kay; Yes, I can confirm after solving those two issues,we got OpenOffice building with JDK 7 on FreeBSD: http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/files/ Pedro. Hey -- thanks for this notice. Well, IMO, we should fix these supposedly *trivial* issues and get on with java 7. Java 6 is out of support for *some* time now. We can't expect users to keep an older version like 6 around. AFAIK the Java base is 1.5 (both source and target). Moving this to 1.7 is a bad idea. My understanding is that Java 1.5 is EOL. I agree that moving to 1.7 is a bad idea, so I would say 1.6 is what should be expected. Of course we will have to clean the build for 1.7 anyways and the sooner the better. Pedro.
Re: Blog post
Hi Rob; - Messaggio originale - Da: Rob Weir ... On Dec 18, 2012, at 10:12 AM, Pedro Giffuni wrote: Hello; Just to get the general public to know some of the things there are going on in the AOO code, Andrea and I have been preparing a blog post about the new random number generator: https://blogs.apache.org/preview/OOo/?previewEntry=random_numbers_in_calc_small Nice. Is it worth describing the testing? In particular, do we have any tests that show clear improvements? Anything that can be shown in a chart? The test I did were pretty simple: I only generated a graph with 1000 values and then regenerated several times a complete row (more that 1 million values) to see no values were negative or overflowed. The problem is that in the platforms I use the period of libc's rand() is already long enough that a graphic plot of just 500-1000 values wont show any periodicity. The algorithm is known to pass some very strict statistical tests though. Pedro.
Re: Blog post
Tthank you Andrea! - Messaggio originale - Da: Andrea Pescetti ... On 18/12/2012 Pedro Giffuni wrote: Da: Rob Weir So it might be worth encouraging some more rigorous testing here. In fact, maybe your blog post can help recruit some volunteers? ... That is certainly welcome. I hope Andrea is taking notes. I am! But first: please note that the blog post was entirely written by Pedro, I merely helped in posting it to Roller (our blogging application). And anyone wishing to access Roller must simply request it on this list. The following changes have now been done on https://blogs.apache.org/preview/OOo/?previewEntry=random_numbers_in_calc_small 1) Minor fixes suggested by Donald 2) Removed the reference to this being the first implementation from the last paragraph. 3) Clarification that we don't aim at crypto-grade quality 4) Call for testing volunteers For the record, I am perfectly OK with all the changes and turning this into a community post or whatever the collective feedbacks turns it into ;). Pedro.
Re: [QA] Python version late for MacOS
Hi Alexandro; - Messaggio originale - Da: Alexandro Colorado ... Just as a note, OOo allows the user to select their own JVM and other things such as classpath, and such on the Tools - Options - Java. Could something like this be enabled for Python3 or 2 or would it be as hard as porting the bridge? pyuno needs to know the python version during compile time. This is different in Java because bytecode is made to be portable. I guess you could build pyuno2 and pyuno3 but you would need to have both python versions available. I think hanya may be thinking of something like that in his pyuno3 project: https://github.com/hanya/pyuno3/ cheers, Pedro.
Re: [PROPOSAL] Licenses and Oracle texts.
Hi Andrew; - Messaggio originale - Da: Andrew Rist Jan, Other than the 'Oracle Report Builder' these all look like they should be changed. As for the 'Oracle Report Builder' ones, does that require more detailed surgery? What is the equivalent product now? Asking a larger audience... Abandonware. Not sure if Ariel had something in the works to rescue it as an extension. Pedro.
Re: [PROPOSAL] New Apache OpenOffice 4 logo proposals...
I like it! cheers, Pedro. Da: Michael Acevedo vea1...@gmail.com A: Apache OpenOffice dev@openoffice.apache.org; Apache OpenOffice Marketing market...@openoffice.apache.org Inviato: Mercoledì 19 Dicembre 2012 20:33 Oggetto: [PROPOSAL] New Apache OpenOffice 4 logo proposals... Greetings to the AOO Team! Hello, after a few months of inactivity I've decided to get back in touch with the AOO community. First, congratulations to the AOO team on a successful graduation into a top-level Apache project from the Apache Incubator. Now the reason on why I am writing this email is to formally submit a logo proposal for the next version of the Apache OpenOffice 4.X logo. Previously, I submitted an initial logo on the Apache OpenOffice Google+ community but I went back to the drawing board and created a second version of the logo that both pays respect to the previous Apache OpenOffice orb, but modernizes the look of the overall logo by adding 4 colored squares that represent the four corners of our office suite (Writer, Calc, Impress, and Base) and utilizing a streamlined font. Without further introductions, below I present my official submission for the Apache OpenOffice 4.X logo. This first logo, is the proposed official logo for the project that would be used for our webpage and some other materials. https://lh3.googleusercontent.com/-lETVSrwcgJc/UNJpH6G1sxI/ABg/JnpNrXdRgUo/s653/AOO%25204%2520LOGO%2520v2-5%2520Small%2520copy.jpg There's a secondary logo, which is basically the same logo but changes the proportion of the OpenOffice orb making it better suited for the splash screen that appears at the launch of the application. https://lh4.googleusercontent.com/-uy8gU24uBZw/UNJpH8UiKiI/ABk/xfXTQjO8iQg/s912/AOO%25204%2520LOGO%2520v2-2.png Hope you guys like it and Happy holidays! -- Best, Michael
Re: [proposal] Adopt palette to Symphony palette partially
Hello; Despite being so subjective, this is an extremely interesting subject. I went googling around the subject and it is quite important, I mean, there are experts that work on this stuff. For example, these guys will let you obtain a palette from a picture: http://www.degraeve.com/color-palette/index.php The first list of colors used as a basis for WWW standards were actually taken from the X11 palette: http://en.wikipedia.org/wiki/X11_color_names If we were to adhere to some standard I guess that would be the starting point. Nevertheless, this is a matter that is far from being standardized. Looking at Symphony: I like the color palette but it still can be improved. If you slide over the colors you can see names and while some are descriptive, most are not (cyan1, cyan 2) There are certainly color professionals out there that have considered this and some colors are popular enough to have a name: http://en.wikipedia.org/wiki/List_of_colors_(compact) I would suggest that we do take initially the Symphony palette but attempt to replace most unnamed colors with something that can be identified by name in either of the lists above. It's a lot of work and I am not volunteering though :(. regards, Pedro. Da: Armin Le Grand armin.le.gr...@me.com A: dev@openoffice.apache.org Inviato: Giovedì 20 Dicembre 2012 5:45 Oggetto: [proposal] Adopt palette to Symphony palette partially Hi List, Talking about palettes is always difficult - at the end, it's a question of taste. Nonetheless, we need a palette which is by default installed with the office. You all know the current one (for years ;-)) which I think is far from optimal. Thus, I analyzed the current one and want to share my findings. From that, I want to propose a change for our next release. Also probably not optimal, but optimal in this field depends on the user's eye and cannot be met by a single palette anyways. Talking about palettes is also difficult since you need to 'see' something - pictures say more than words. To make that easier, I have prepared some data. Please look at A Impress document containing two slides (http://people.apache.org/~alg/Palette/palette.odp) The two slides as png's for convenience (http://people.apache.org/~alg/Palette/palette.png, http://people.apache.org/~alg/Palette/palette2.png) The following thext refers to figures there, so please take a look to see what the text is about (...if you want to continue reading ;-)) The current (old?) AOO Palette, It's made up of five groups (from my perspective): (a) The 16 VGA colors: These come originally from the times where only 16 colors were possible and are in hex color notation exactly all eight combinations of red/green/blue on or off, plus these in half intensity. It *had* technical reasons, but these colors do not have any special meaning for the user today (well, for the programmer). Anyways, they are a result of old technical limitations. I think they are ugly and lead to ugly results when using them directly (but that's my impression). (b) The 'Main' Colors: 56 colors which try to build up to eight gradient-stepped ranges, e.g. orange. These ranges are *not* equidistantly spread, but somewhat wild/random (see e.g. the reds). I do not know where they historically come from, but I guess they were done by a deveoper at these days. There are some nice colors among them, but not too many. I always search for useful colors there (c) The Pale colors: These seem to be younger than the others, may have to do historically with the StarOffice 5.2 color theme, but I'm not sure. Not too bad, not too good a selection. A group of seven colors which form a nice kind of 'schema' and make your presentation look 'acceptable' when using them together. (d) The Chart colors: 12 colors used in the new chart module written some years ago. AFAIK these were added at that time especially to support the user having colors at hand corresponding to the default chart colors. Nice. Useful. (e) 'Nice' Colors: A sub-group from (b). One is fix, it's the mentioned 'Blue 9' which is currently the default color for objects and has to be in the palette. I personally like (and often use) 'Blue Gray'. These are a question of taste, I would reccomend the named ones, but we need to collect 'your' favorites here. Keep in mind to keep this number low (probably 4-5) and do not forget that the color you like were not choosen freely, but *because* you were limited to the offered ones, so it might be a compromize you are just used to. Quite a mix. I compared it with Syphony's palette and there completely new colors are used. One interesting aspect are the white/gray/black ones: In our current palette these are divided between (a) (black, white and two grays) and (b) (the rest, gray 80% .. gray 20%). This is of course because the first four grays are technically in the old VGA palette. I more than once were
Re: [proposal] Adopt palette to Symphony palette partially
Da: Pedro Giffuni Hello; Despite being so subjective, this is an extremely interesting subject. I went googling around the subject and it is quite important, I mean, there are experts that work on this stuff. For example, these guys will let you obtain a palette from a picture: http://www.degraeve.com/color-palette/index.php The first list of colors used as a basis for WWW standards were actually taken from the X11 palette: http://en.wikipedia.org/wiki/X11_color_names If we were to adhere to some standard I guess that would be the starting point. Nevertheless, this is a matter that is far from being standardized. Looking at Symphony: I like the color palette but it still can be improved. If you slide over the colors you can see names and while some are descriptive, most are not (cyan1, cyan 2) There are certainly color professionals out there that have considered this and some colors are popular enough to have a name: http://en.wikipedia.org/wiki/List_of_colors_(compact) I would suggest that we do take initially the Symphony palette but attempt to replace most unnamed colors with something that can be identified by name in either of the lists above. It's a lot of work and I am not volunteering though :(. Just following the last link Perhaps just sorting this list by hex value would provide a complete palette for any use: http://en.wikipedia.org/wiki/List_of_colors regards, Pedro.
Re: [proposal] Adopt palette to Symphony palette partially
- Messaggio originale - Da: Armin Le Grand Hi Pedro, On 20.12.2012 16:21, Pedro Giffuni wrote: Hello; ... Looking at Symphony: I like the color palette but it still can be improved. If you slide over the colors you can see names and while some are descriptive, most are not (cyan1, cyan 2) There are certainly color professionals out there that have considered this and some colors are popular enough to have a name: http://en.wikipedia.org/wiki/List_of_colors_(compact) Good idea. I already thought about having a central place in the office with all known named colors (e.g. the Colors in the SVG standard, already in svgio module for example). The problem is that there are 24 million colors (0xff^3). Despite that, there may be serveral names per color. Despite that, the names are not translated. Are color names translatable...? Hmm.. there are indeed a lot of named colors: I thought I was looking at the complete list but it was only A-M. Yes, color names are translatable but even online translation services should give acceptable results. Good thing there are international volunteers that can help :). I would suggest that we do take initially the Symphony palette but attempt to replace most unnamed colors with something that can be identified by name in either of the lists above. It's a lot of work and I am not volunteering though :(. I follow that suggestion: For now, let's use the (extended, see proposal) Symphony palette, but make a follow-up to find better color names. Great! In the long run supporting multiple palettes (as Rony suggested, too) will be unavoidable I think; there are sooo many interesting colors, alone following your links and all the slightly different tones of white. And all that is only in RGB color space... Maybe we should start taking color seriously some day and play with something like CMS ;). http://www.littlecms.com/ cheers, Pedro.
I broke the windows build :(
Hmm.. It looks like my recent update of libxml2 broke the build in Windows. Before reverting, anyone has details of the breakage? The buildbot is not especific at all. Thanks and sorry, Pedro.
Re: I broke the windows build :(
I found it.. it's an upstream bug. I will fix it in half an hour or so. cheers, Pedro. Da: Pedro Giffuni p...@apache.org A: dev@openoffice.apache.org Inviato: Venerdì 21 Dicembre 2012 0:29 Oggetto: I broke the windows build :( Hmm.. It looks like my recent update of libxml2 broke the build in Windows. Before reverting, anyone has details of the breakage? The buildbot is not especific at all. Thanks and sorry, Pedro.
User initiative for improving OOXML (was Re: AOO questions on Google)
Hello; The ASF is a non-profit organization, we don't pay for coding but concerning docx support there was a talk from Matthias Stürmer in ApacheConEU: http://www.apachecon.eu/schedule/presentation/46/ This effort, of course, predates the establishment of AOO as a TLP so we were not consulted. It is a well intended initiative but despite the funding it appears to have produced no results for OpenOffice so far. We had a chance to talk with Matthias and while I won't make any comments, I would think the organizers will make their own evaluation and will likely consider the results before engaging in future investments of this kind. Pedro. Da: Andrew Pitonyak and...@pitonyak.org A: dev@openoffice.apache.org Inviato: Domenica 23 Dicembre 2012 14:46 Oggetto: Re: AOO questions on Google No save as for docx is why libre is installed on a few machines i sometimes deal with. Sent from my Samsung Epic™ 4G F C. Costero fjcc.apa...@gmail.com wrote: Since there is some interest in this particular topic, here are the 9 questions I categorized as MS Interoperability with the number of positive votes appended to each in parentheses. 1. I tryed to save my word processor file as a MS Word file only extensions listed in the drop down were for text or Open Office, no Word option. Help function said I should have had that option in the drop down under save as. version 3.4.1. Could you add a converter for format MS .docx as the actual converter for .doc does not work proper. It mix up text and drawings and make the whole page a mess. (1) 2. hello, How can i open openoffice file with microsoft office? Gr Sam Esman (5) 3. What kind of OOXML support is intended in AOO? Transitional (MS Word) version or ISO (does someone really implement it?). (3) 4. If save filter is implemented, don't you fear a weakening of the ODF then? (6) 5. allow open office to use ms office defaults (5) 6. can i install openoffice when i have microsoft office on my computer (4) 7. OpenOffice, should be able to open properly all 'Word office' files. (9) 8. Is open office compatible with Office 2010? (8) 9. Open Office doesn't handle tables in Word well - for example re-sizing of columns, keeping table rows together, inserting page breaks within tables. Could OO development include a goal of fully matching MS Office functionality for tables? (13) On Sun, Dec 23, 2012 at 9:28 AM, Drew Jensen drewjensen.in...@gmail.comwrote: Hi, Long time since I said anything and so how about, Happy Holidays, to start. Just to say that the #2 doesn't surprise me at all and yes I would strongly suspect it has lots to do with OOXML. Don't forget that this does not necessarily mean interoperability with MSO it also means interchangeability with GDocs as best as I can tell. Thanks On Sun, Dec 23, 2012 at 11:22 AM, Dennis E. Hamilton orc...@apache.org wrote: Concerning Microsoft Office interoperability, I suspect the absence of a way to save documents in OOXML formats is a detractor from Apache OpenOffice 3.4. There are the usual interchange fidelity issues as well, depending on which interchangeable formats are used. - Dennis -Original Message- From: janI [mailto:j...@apache.org] Sent: Sunday, December 23, 2012 02:37 To: dev@openoffice.apache.org Subject: Re: AOO questions on Google Thanks for the summary ! Personally I asumed that LO would be #1, but I am amazed about #2 (MS Office interoperability and Other formats) I thought that was one of our very strong sides. I might be worthwhile to look a bit deeper into that, and see if the cause for the questions is in lack of features, lack of documentation or someelse, to give a clue of what to do ? Maybe we can do something with 4.0. Jan I. On 23 December 2012 04:00, F C. Costero fjcc.apa...@gmail.com wrote: [ ... ] MS Office interoperability 54 Non-English 15 Other formats 54 [ ... ]
Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours !!!!
FWIW; One of the suggestions from Terry E was moving from MySQL to PostgreSQL, which offered advantages for doing proper backups. My memory is sketchy so you may want to dig up the details in the archives. Pedro. Da: janI j...@apache.org A: dev@openoffice.apache.org Inviato: Lunedì 24 Dicembre 2012 6:50 Oggetto: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours Hi. I have taken wiki.openoffice.org, down for a db maintenance. Jan I.
Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours !!!!
FWIW; It also came to my memory that there was the idea to attempt merging at least some of the documentation from MWiki to CWiki by using this plugin: https://studio.plugins.atlassian.com/wiki/display/UWC/Universal+Wiki+Converter Ultimately no one gave it a try due to lack of resources (access to the db, running CWiki, I recall) cheers, Pedro. Da: Pedro Giffuni p...@apache.org A: dev@openoffice.apache.org dev@openoffice.apache.org Cc: janI j...@apache.org Inviato: Lunedì 24 Dicembre 2012 14:45 Oggetto: Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours FWIW; One of the suggestions from Terry E was moving from MySQL to PostgreSQL, which offered advantages for doing proper backups. My memory is sketchy so you may want to dig up the details in the archives. Pedro. Da: janI j...@apache.org A: dev@openoffice.apache.org Inviato: Lunedì 24 Dicembre 2012 6:50 Oggetto: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours Hi. I have taken wiki.openoffice.org, down for a db maintenance. Jan I.
Moving content between CWiki and MWiki (was Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours !!!!)
Da: janI ... Oggetto: Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours @pedro: thx, that can save quite some time if it works. @dave: nice to know that you are admin, so you can help provide e.g. a list of pages. Two things here: The conversor is one way only: to CWiki. Conversion is known to be imperfect and a lot of content would be lost. OTOH, it is also understood that a lot of MWiki content is obsolete and needs to be cleaned out anyway. For conversion of the math stuff the documentation of the plugin states that CWiki could be helped by the use of a latex plugin. We had a discussion a while ago about moving the cwiki content, once the mwiki was upgraded, so I guess now is about the right time to take a decision. I will initiate that shortly. From a licensing perspective the MWiki content is a can of worms. This may or may not be important as this is not included in releases but the general consensus was to keep the MWiki content contained and only accept ALv2 content from now on. There is also a huge -1 in the current MWiki for me: if MWiki is here to stay ldap access must be enabled so that committers have access to it without opening a new account. Just thought I'd point those things out :) Pedro.
Re: Moving content between CWiki and MWiki (was Re: [mwiki] IS DOWN FOR DB MAINTENANCE for the next couple of hours !!!!)
Da: janI On 26 December 2012 16:47, Pedro Giffuni p...@apache.org wrote: ... We do have licensing issues with the content of both the wiki and the website. If you check the lengthy discussion we had about it you will find that the documentation is mostly licensed under PDL. As I said it's a can of worms, but it doesn't mean we won't have to open it. Now I get it, I thought you meant the mediawiki general license. There are for sure bigger issues with the general content, also according to our ICLA we cannot simply copy it. The issue is the SUN contribution agreement for that content was that was under Public Documentation License by default, or alternatively under PD or some CC- copyleft. We can probably get some of that stuff relicensed but this is not usually covered by a SGA. It's a can of worms :(. It limits my ability to contribute to the MediaWiki content as it seems the wiki is unconnected to the rest of Apache. I think it's something that can be solved: my understanding is that accepting LDAP doesn't exclude volunteers from using the existing authentication accounts. well I am right now doing my best to connect it better to apache, LDAP is one small step, which I am actually sitting right now and reading about. Other things are the monitoring and other infra stuff, where I help out a bit. Let me clarify this: you are doing a GREAT job. Updating the MediaWiki software was indeed a requirement for infra@ if MWiki is going to stay. I personally don't want to spend holiday time thinking about documentation or MWikis :). Keep up the good work! Pedro.
Re: Incompatible changes in AOO 4.0 ?
Hi Regina; - Messaggio originale - Da: Regina Henschel A Implementation of FDIST as defined in ODF1.2 The function FDIST (part 2, 6.18.22) calculates the left tail (integral from 0 to x). The function LEGACY.FDIST (part 2, 6.18.23) calculates the right tail (integral from x to infinity). The current implemention of FDIST in AOO is actually “LEGACY.FDIST”. The function FDIST in documents written with OOo2.x are different from the function FDIST, which has to be implemented. I do not speak of the UI names, but of the names in the file. This sounds like FDIST = 1 - LEGACY.FDIST It should be easy to fix and I think it should be done before 4.x. BTW, I am considering doing something drastic there, like replacing all the probablilty distributions with with boost implementations. Would there be any good reason to avoid such approach? Pedro.
Re: Incompatible changes in AOO 4.0 ?
- Messaggio originale - Da: Rob Weir ... BTW, I am considering doing something drastic there, like replacing all the probability distributions with with boost implementations. Would there be any good reason to avoid such approach? What is the advantage of changing? Quality: the precision and performance in the boost implementations is notable. Most of our older implementations are also unmaintained. If you look at the Gamma implementation, for example, you will notice a comment that says it is based on the boost implementation. We surely haven't kept up with the bug fixes or improvements they may have made since then. The boost implementations also have the option of specifying math policy, which is something our current implementations lack. Quite honestly, I was hesitant to introduce boost stuff in Calc but we already depend on it for other things so it comes for free and the code is admittedly very good (with only some small issues in their PRNG). Risk of any change is introducing a bug. From a user's perspective any difference in calculation, even if correct is something that may cause them to halt their work until they understand why their complex calculation gives an answer that is 0.1% different than AOO 3.4.1. 0.1% is a huge number: If the new functions produce 0.1 % more correct results then I would say it's a bugfix and bug fixes are GREAT. I have to say that some of the current math functions are in poor shape, hopefully not 0.1% wrong but still pretty shameful. We have to verify each and every function we replace but I don't think the idea is to produce a crappy Spreadsheet that lies, and producing inaccuracies in cases where we can do much better is pretty much lying. So we need both accuracy and release-to-release consistency. Me may improve accuracy and in the process yield results that differ from earlier versions, but this needs to be tracked and communicated to users carefully, so they understand what happened to their spreadsheets. I don't think we want improvements to be a surprise for the user, especially since at that point bugs and improvements are indistinguishable to casual examination. Of course, there are Release notes for that: there are no surprises here. Major release numbers bumps are useful precisely to indicate such changes. I would also think we will want to keep the legacy implementations available in a scaddin. The beauty of opensource is that anyone is free to lend a hand and do just that. If we don't have a solid test suite to determine whether our calculations are correct or even detect if our calculations differ from release to release then I'm not really in favor of changing the code. But if we wanted to do a rigorous test of OpenOffice, per the standard, and fix any bugs or inaccuracies that the test suite reveals, then I think we end up with a stronger product, and one where we can safely optimize the routines, knowing that the test cases have our back. Please feel free to contribute a spreadsheet that calculates the edge cases. Any contribution of that kind is welcome, and that's why this list exists. We do have a serious problem in the current Calc: we are depending on system libraries for some calculations. This has the disadvantage that the results will differ if you do your calculation on Windows or in UNIX with none of them being too good in accuracy. Under it's current shape I wouldn't recommend a tool like calc for use in serious scientific use. For the record, some of the math libraries used in some libc implementations are derived from Netlib's Cephes and even though modern standards require them, they have been rejected for inclusion in FreeBSD due to their low quality. I am pretty sure I know what I am doing here. I have a patch in my box to fix some of the lower hanging fruit in Calc. You will probably not see any of it this year, but it will be coming through bugzilla so that you have time to help review the changes with real code :).. Pedro.
Re: Incompatible changes in AOO 4.0 ?
Hello Regina; I looked into the AOO code and the situation is actually a less critical than I thought: we don't use the system libraries for the hyperbolic functions but instead we have our own implementations in the SAL layer. - Messaggio originale - Da: Regina Henschel Hi Pedro, hi Andrew, Pedro Giffuni schrieb: ... I did just a very small set of changes for asinh, acosh, atanh and a some internal power functions .. just for testing. Since there is interest in this I opened a Bugzilla issue with the patch: https://issues.apache.org/ooo/show_bug.cgi?id=121561 There's also a spreadsheet with some basic tests. I haven't been able to look at the boost implementation. They do have some tests but from the implementation description we could improve our testing.. I will probably look at that next year :). Would want to compare expected group actual and old to new. Would want to devise test cases against both common and edge cases. Also curios about time impact, does it take more time or less. Yes, the needed calculation time is critical. There are some places in the code, where I had stopped a loop at a fixed count, so that the calculation time is not too long. To be honest, computers are so fast these days that I think most people may sacrifice some performance in exchange for accuracy. The differences are insignificant comparing FreeBSD amd64 (with boost) vs a VM running Windows XP with Symphony, but I am sure someone can come up with more creative tests :). For accuracy you need a comparison to a value which is calculated without the restriction to data type double. For single values Wolfram Alpha might work, for a larger set of test cases a computer algebra system might be appropriate. That's a good idea, thanks! While in Germany I actually met someone from REDUCE, I 'll have to get back to that. cheers, Pedro.
Re: Incompatible changes in AOO 4.0 ?
- Messaggio originale - Da: Rob Weir On Sun, Dec 30, 2012 at 3:49 PM, Pedro Giffuni wrote: - Messaggio originale - Da: Rob Weir ... Please feel free to contribute a spreadsheet that calculates the edge cases. Any contribution of that kind is welcome, and that's why this list exists. Well, what does boost use for its own testing? They must do some sort of testing? Is there something we can easily convert into a spreadsheet? That would help in two ways. since we could test the existing implementation against the same test cases, to see if there actually are any issues. I assume that would be good to know. This is not something one checks by grabbing someone else's testsuite, it depends on the specific function you want to test. Please check the excellent boost documentation: http://www.boost.org/doc/libs/1_52_0/libs/math/doc/sf_and_dist/html/index.html I don't think we have equivalent studies over our native versions :(. More bugs come from overconfidence than from a respectful humility and realization that the work we do is critical for millions of users and that we should do everything possible to ensure that our code is tested by more than just our own personal feelings of satisfaction. IMHO. Rather than overconfidence we are having respectful humility and realization that our homebrew implementations don't really compare against the boost versions. So there are two things here: 1) All the junk out to the 12th decimal place that might matter to a few people and which might be improved by moving to boost 2) The edge stuff where we can very well break real world spreadsheets if we're not careful. This is not entirely about the 12th decimal place. I was one of the co-authors of the OpenFormula specification used in ODF. There is more there than just mathematical fact. There are a lot of conventions, purely pragmatic conventions, involved in spreadsheet formulas, and we need to get those right as well. For example, take the POWER() function. POWER(x;y) == x^y. So what is POWER(0;0) ? I'm sure boost returns something there. But is it the same as AOO 3.4.1 returns? And does it conform to OpenFormula? Another example. We have ISERR() and ISNA() functions. We make a distinction between Not a number (the result of 0/0) and other errors. A spreadsheet user may have error handling logic that is sensitive to this. So we need to make sure that changing in implementation don't introduce changes in what errors are returned. Again, this is a convention, not a mathematical fact that we can just assume boost gets right. So we need to be very careful about how things interact at the level of range and domain errors. NaN, etc. It is possible that AOO 3.4.1 works correctly in some cases purely by accident, because the system routines do the right thing. Then we switch to a different library and it breaks, even though the library is justifiably correct. Please check the boost documentation regarding Policy. Pedro.
Re: Incompatible changes in AOO 4.0 ?
Hi again; - Messaggio originale - Da: Rob Weir So there are two things here: 1) All the junk out to the 12th decimal place that might matter to a few people and which might be improved by moving to boost I think this will indeed be improved by boost. Boost is really cool in that it can promote automatically the number types if there is an advantage when doing calculations 2) The edge stuff where we can very well break real world spreadsheets if we're not careful. This is not entirely about the 12th decimal place. I was one of the co-authors of the OpenFormula specification used in ODF. There is more there than just mathematical fact. There are a lot of conventions, purely pragmatic conventions, involved in spreadsheet formulas, and we need to get those right as well. Thanks to Regina's test spreadsheet I found that I had to change the default boost policy for a simple reason: a scientist wants to know if there is an overflow and is likely to want to stop all the calculations, a Calc user doesn't really care too much and finds absolutely unacceptable to have the application close when such thing happens. Boost actually let's us control the math behavior very well. For example, take the POWER() function. POWER(x;y) == x^y. So what is POWER(0;0) ? I'm sure boost returns something there. But is it the same as AOO 3.4.1 returns? And does it conform to OpenFormula? I happen to have some memories of this specific case. Calc, like my college HP calculator, erroneously sets the value to 1. Calculating the limit, as we did in Calculus I, it can be proved the correct result is infinite. This should be fixed in Calc. OpenFormula is rather ambivalent: it says it is implementation dependent and it can be 0, 1, or Infinite. Boost has no opinion about it: Boost doesn't provide a replacement for this. It is a perfectly valid point though, ee have to check those things function by function. ... So before we attempt a brain transplant with the spreadsheet formulas, let's make sure we're all comfortable with the real-world risk this introduces and have a plan to find (and fix) the bugs this will inevitably introduce. Of course, this is not a demand on you personally, but a challenge for the project overall. Sure, we have to be careful. For good or for bad, boost doesn't provide replacements for everything we do: I think basically the hyperbolic and some power functions that are in my patch and the statistics functions. Pedro.
Re: Boost, LAPACK and fortran
Hi Maho; - Messaggio originale - Da: Maho NAKATA Hi all and Pedro, In 2012/12/30 I recieved an e-mail from Pedro (sorry if you want to keep this activity secret) that he want to use uBLAS http://www.boost.org/doc/libs/1_48_0/libs/numeric/ublas/doc/index.htm for matrix-matrxi, matrix-vector manipulations. For the first step, it is a very very good idea. It wasn't meant to be a secret but I was taking some time to digest the idea of using Boost in general. Here, I'm wondering whether we can include FORTRAN in a build requirement. The idea of using Fortran is rather inconvenient due to the Windows port. We currently use MSVC 2008: Microsoft stopped distributing Fortran compilers ages ago and using gfortran as an extra dependency makes things too complex. I think we could use Boost's ublas for the Matrix operations and that should be sufficient for the very basic matrix support Calc provides. I am not very good with how Matrices work on C++ though, so I don't have plans to work on it. So - depending on BLAS, LAPACK and OpenBLAS in the future are very good idea, and provides far better functionality and performance without license issues. One problem is that we will require build dependency as FORTRAN! We can use FORTRAN for extensions and maybe optional scaddins though. There are some really cool scientific packages in FORTRAN like MUMPS: http://graal.ens-lyon.fr/MUMPS/ Cheers, Pedro.
Re: MWIKI down?
- Messaggio originale - Da: TJ Frazier ... On 1/2/2013 21:07, Andrew Douglas Pitonyak wrote: Trying to create an account for Alexander (as requested) using the user name he sent to me, but mwiki appears to be down... Hi, Andrew, According to http://monitoring.apache.org/status/, the wiki has been down for an hour. (This is a /very/ useful link.) The devices are listed in alphabetical order, by the name at the left; ours is ooo-wiki. According to the Infra page, if something shows red here (as ooo-wiki does), then Infra has already been notified and should be working on the problem, so no further user action is necessary. According to Jan, the system is suffering from kernel panic bouts (???). He plans to upgrade the VM, which may cure the problem. Or they could move to a FreeBSD jail, but when I offered to help last year I was turned down :-P. Pedro.
Re: User initiative for improving OOXML (was Re: AOO questions on Google)
Well, it is easier to get funding for such things if both projects get benefits. Depending on the organizers, if things only go to one side now it is likely that such funding will not be available in the future or that it will be reduced considerably and then everyone loses. Pedro. Da: Drew Jensen LOl - well, I wouldn't make too much of the paid development part, Jurgen, it is what you do also, paid developement work for this project. On Thu, Jan 3, 2013 at 4:49 AM, Joost Andrae joost.and...@gmx.de wrote: Hi, if you're interested into including the changes into AOO then all parties involved are listed here (incl. email addresses): http://www.digitale-**nachhaltigkeit.ch/2012/07/** suse-und-lanedo-setzen-ooxml-**verbesserungen-in-** libreofficeopenoffice-org-fur-**behorden-um/http://www.digitale-nachhaltigkeit.ch/2012/07/suse-und-lanedo-setzen-ooxml-verbesserungen-in-libreofficeopenoffice-org-fur-behorden-um/ Am 03.01.2013 10:22, schrieb Jürgen Schmidt: On 1/2/13 9:05 PM, Drew Jensen wrote: Howdy Jürgen, Hmm - well, I had understood it was ALv2 specifically so that it would be available to the project here. Hopefully when the developers make a drop of the code it will be something that the devs here will want to utilize it, wasn't really fair to ask anyone to comment on something they haven't seen yet. I hope so too, on the other hand it is paid development work and the question is what does it mean to make it available in both projects ;-) Kind regards, Joost
Calc vs. acaddins : where to put stuff.
Hi; While digging around Calc I see some things that could be ordered better. One change that I am considering is moving RAND() to the Analysis scaddin and bringing the error erf() function in base Calc. This has reasons of course: in the case of RAND() I want it in the same file as RANDBETWEEN() so I can use them cleanly.. erf() is something I would consider doing with Boost, and I don't want to have to link boost into the scaddin for just one function. There are probably other changes that can be done too. Just wanted to make sure if there is some criteria to keep some function in or out of the base Calc or in a scaddin. Pedro.
Re: Calc vs. acaddins : where to put stuff.
Hi Regina; Thank you for the explanations. Da: Regina Henschel Hi Pedro, Pedro Giffuni schrieb: Hi; While digging around Calc I see some things that could be ordered better. One change that I am considering is moving RAND() to the Analysis scaddin and bringing the error erf() function in base Calc. This has reasons of course: in the case of RAND() I want it in the same file as RANDBETWEEN() so I can use them cleanly.. erf() is something I would consider doing with Boost, and I don't want to have to link boost into the scaddin for just one function. There are probably other changes that can be done too. Just wanted to make sure if there is some criteria to keep some function in or out of the base Calc or in a scaddin. Long time ago Addin was used for those functions which are not available in a standard Excel installation, but need an addin installed in Excel. Another reason for Addin has been, to show, how own functions can be defined without integrating them directly into the interpreter (example ROT13). I have never done such thing and do not know whether it still works. But there are two issues about it, https://issues.apache.org/ooo/show_bug.cgi?id=101386 and https://issues.apache.org/ooo/show_bug.cgi?id=98149 In the meantime Excel has moved the functions to the standard installation and most of these functions are specified in ODF. Besides the task to give a way to define own functions, there is no need for scaddin at all. So considering that all, I think, that at least all functions, which are defined in ODF, should go to the normal sc. OK, I don't really want to move things around very much, plus these things have to be done in careful order. I think I found a way to do what I need without moving things around so we will see. I do prefer to ask around before doing real changes so bear with me ;-). I do not know, whether a move has any influence on opening old documents, which do not use the ODF namespace oc. I do not understand your comment on erf. The function erf and erfc are moved to rtl::math with https://issues.apache.org/ooo/show_bug.cgi?id=97091 What I see is that we are keeping in rtl::math a lot of things that the system usually provides. It's good to have them there if they are going to be used in Addins but I am not sure the implementations are actually too good. In the case of erf, I think anything related to the Normal Distribution is absolutely critical and essential and I would have expected the implementation to be along with the other stats functions. TBH, I haven't even started to look at the stats stuff. I am very busy with other projects. You are considering far-reaching changes. Therefore I suggest to speak with Eike before doing it. I am actually going very slow, I am surprised that no one had done these things already but then I only looked at this after the pain of updating the ancient boost we were carrying. Of course discussion with people that know this better is welcome and that's why I bring the subject to the public lists. I suspect Eike is reading and that he will chime in if he notices my sharp axe dangerously near his baby ;-). Pedro.
Re: Yes, the Windows build is broken due to boost
Hmm .. I found it, MSVC is picky/dumb and we have to specify the type, like in this case: http://stackoverflow.com/questions/708555/compile-error-c-could-not-deduce-template-argument-for-t If someone with Windows just goes ahead and fixes that, we can continue enjoying great precision in our math support, otherwise I will try to fix it tomorrow and will wait for the buildbot to restart ;). Cheers, Pedro.
Re: Yes, the Windows build is broken due to boost
- Messaggio originale - Da: Herbert Duerr h...@apache.org ... Hi, On 04.01.2013 06:19, Pedro Giffuni wrote: As title says the windows build got broken by my attempt to use boost::math in Calc. The linux buildbots are fine so it seems some interaction between MSVC and boost. hdu@ kindly provided a log: https://issues.apache.org/ooo/attachment.cgi?id=80094action=edit I am completely clueless and some expert help is welcome. I guess I will never get used to this: it is sad that the code was actually working great on UNIX but the Windows port is important so I will revert tomorrow (unless someone gets ahead of me). I think I found the reason and an explanation of what has gone wrong: - the stl/complex.h header gets included somehow - it defines a function abs(complexT) - on windows abs() usually comes from math.h - so stlport=4 on windows doesn't declare stl::abs(double) and the like = there is a problem if stl::abs(double) is needed - the atanh(double) which depends on stl::abs() is thus considered a failure from C++'s SFINAE (Substitution Failure is not an Error) perspective and thus the needed template is not propagated to In short: adding a #define _STLP_HAS_NATIVE_FLOAT_ABS before the #includeboost/math/special_functions/* lines in interpr1.cxx and interpr3.cxx solves the problem, but it is of course too unclean, it just proves the point. To get things going again adding the define conditionally on the WNT target isn't too unreasonable. Interestingly stlport 5.2 adds the define itself unconditionally also for Windows. So in summary the problem was caused by our code base having quite an old stlport interacting with a quite new boost library and the resulting trouble being hidden by the SFINAE mechanism. Yay! Experiences like this or like issue 72248 are interesting reality checks, especially when discussing fancy template libraries with their enthusiasts. Nice find! Thank you Herbert, these type of issues are extremely difficult to hunt without the platform in question! And I guess we have another reason to kill stlport! Pedro. Herbert
Re: Replacing things with solutions from Boost
Hi Regina; I fear that if we create a branch for it, it will be completely untested: - I suspect that I would be the only one using such branch, and things like the building issue with STLport would've been unnoticed.[1] - The changes are really, really small and localized and just don't justify a branch. FWIW, in my local box I replaced Gamma (which was based on boost code anyways). The only other thing that I would plan to replace before 4.0 is the statistics distributions and Boost makes that really REALLY easy. The new FDIST as defined in ODF is just two lines (and one of them is the #include line) I do plan to make patches and spreadsheets available for early testers, but I won't start a branch for two patches (OK, actually three if you count what I will do to the PRNG). Maho-san, may have bigger changes in mind, i that case we may consider a branch, Pedro. [1] Also note that the fix was applied with sufficient scope for all our math stuff so that won't bother againl. Da: Regina Henschel rb.hensc...@t-online.de A: AOO dev dev@openoffice.apache.org Inviato: Domenica 6 Gennaio 2013 10:19 Oggetto: Replacing things with solutions from Boost Hi all, there are attempts to replace things with better solutions provided by Boost. Although I'm not against this aim, I have concerns doing this directly on trunk. Wouldn't it be better, to first make it on a branch and have time enough to test it for all platforms, before it get integrated? There are already ia2 and sidebar to go into AOO4.0. I fear that changing to Boost will be to much to test till AOO4.0. Kind regards Regina
Re: Mac OS X WaE build and boost (Was: Re: Yes, the Windows build is broken due to boost)
Hi Pavel; I think we are walking on a thin ice with this Boost integration. Boost seems to push some C++ compilers to the limits (specially the older ones). Boost does have it's share of bugs, but a share of the problems when using boost is actually caused by STLport. I think I will be partially reverting the sc changes in Boost and the major integration that I was planning will not happen soon. I am currently testing an alternative approach that still brings us the main advantages of using Boost math functions. In any case, for the time being consider those warning messages as merely informational. Pedro. - Messaggio originale - Da: Pavel Janík Hi, On Jan 4, 2013, at 6:42 AM, Pedro Giffuni wrote: MSVC is picky/dumb and we have to specify the type, like in this case: http://stackoverflow.com/questions/708555/compile-error-c-could-not-deduce-template-argument-for-t I have another issue connected with boost update. Mac OS X, WaE build: /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/mpl/aux_/preprocessed/gcc/less_equal.hpp:90: warning: comparison between ‘enum mpl_::int_64::anonymous’ and ‘enum mpl_::int_113::anonymous’ This warning break the build because of WaE tuerned on. Complete build log message: Entering /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sc/source/core/tool Compiling: sc/source/core/tool/interpr1.cxx cc1plus: warnings being treated as errors /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/mpl/aux_/preprocessed/gcc/less_equal.hpp: In instantiation of ‘boost::mpl::less_equal_implmpl_::integral_c_tag, mpl_::integral_c_tag::applyboost::math::policies::digits264, mpl_::int_53 ’: /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/mpl/aux_/preprocessed/gcc/less_equal.hpp:73: instantiated from ‘boost::mpl::less_equalboost::math::policies::digits264, mpl_::int_53 ’ /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/math/special_functions/expm1.hpp:253: instantiated from ‘typename boost::math::tools::promote_argsRT, float, float, float, float, float::type boost::math::expm1(T, const Policy) [with T = long double, Policy = boost::math::policies::policyboost::math::policies::detail::forwarding_arg1, boost::math::policies::detail::forwarding_arg2, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy]’ /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/math/special_functions/sqrt1pm1.hpp:31: instantiated from ‘typename boost::math::tools::promote_argsRT, float, float, float, float, float::type boost::math::sqrt1pm1(const T, const Policy) [with T = long double, Policy = boost::math::policies::policyboost::math::policies::detail::forwarding_arg1, boost::math::policies::detail::forwarding_arg2, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy]’ /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/math/special_functions/asinh.hpp:60: instantiated from ‘T boost::math::detail::asinh_imp(T, const Policy) [with T = long double, Policy = boost::math::policies::policyboost::math::policies::detail::forwarding_arg1, boost::math::policies::detail::forwarding_arg2, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy]’ /Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/inc/boost/math/special_functions/asinh.hpp:109: instantiated from ‘typename boost::math::tools::promote_argsRT, float, float, float, float, float::type boost::math::asinh(T, const Policy) [with T = double, Policy = boost::math::policies::policyboost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math
Re: GNU Environment (New Build on Solaris)
Hello; - Messaggio originale - Da: Jean-Louis 'Hans' Fuchs Hello Everybody Abstract --- Solaris has differtent system-tools, all the GNU tools are prefixed g- (ie. gtar). Some tools and dependencies of the build-system have to be installed from OpenCSW on older solaris. In this mail I discuss how to integrate these tools in the build-system and a policy to integrate latest AOO changes (toward GNU) into solaris. Both topics are too connected to make two mails, but feel free to anwer only on one topic. Tools Integration -- I start a build on a new solaris version. This time I like to ONLY do mergable changes. The main problem lies in the tools. Many tools (grep, sed, tar…) are detected in configure. On solaris it will typically detect (ggrep, gset, gtar…), but most scripts just use the stanard names anyway. I don't have a problem with scripts not using the detected tool. I think we should define GNU-Tools as standard. Otherwise the already complicated build system gets unnecessary error sources. I think there are two approaches: A. Detect all the tools needed in the build system and have every script use the detected tool. B. On systems that have prefixes for the GNU tools a pre-step in the build process creates a GNU Environment. This is how my build system currently works and it should IMO be integrated into the AOO build-system-bootstrap. Detecting gpatch first than patch would be interesting for FreeBSD too, however, please don't play too much with configure.in (it's already ugly in there). We have some configure options for that: --with-gnu-patch= --with-gnu-perf= We have been able to get rid fo gnucp in FreeBSD too, no idea if that is enough for Solaris. B Virtual GNU Env (All problems in computer science can be solved by another level of indirection) 1. If /path/to/build is the build directory, a directory /path/to/build/bin should be created 2. The directory should be added to PATH=/path/to/build/bin:$PATH 3. Find the g-prefixed tools and symbol link them into bin without prefix On a current build system: oobuild@sunt1000sparc ~/slave/aoo-trunk-solaris-11-sparc/build/bin [8 files, 7.5K] (master) $ ls -l total 9 lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 find - /opt/csw/bin/gfind lrwxrwxrwx 1 oobuild staff 18 Oct 10 12:34 grep - /opt/csw/bin/ggrep lrwxrwxrwx 1 oobuild staff 19 Oct 10 12:34 patch - /opt/csw/bin/gpatch lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 perl - /opt/csw/bin/perl * -rwxr-xr-x 1 oobuild staff 107 Oct 10 12:34 pkg-config * lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 sed - /opt/csw/bin/gsed lrwxrwxrwx 1 oobuild staff 17 Oct 10 12:34 tar - /opt/csw/bin/gtar n general avoiding the use of GNU tools with more generic utilities is ideal. In FreeBSD we were able to get rid of GNU coreutils (gcp and GNU mktemp I think). BSD tar and BSD sed (included in illumos) work fine for us. * Special Cases: 1. On some old solaris I can't easily install all the perl-modules needed for the build-system. So I installed perl using the thrid-party package manager OpenCSW. 2. As you see, since I had OpenCSW anyway I used all the OpenCSW tools to be consistant, many tools would be in standard solaris too. 3. pkg-config: $ cat pkg-config #!/bin/bash Please note that this shebang would be totally unacceptable for AOO. http://lwn.net/Articles/343924/ If you *have* to use bash try #/usr/bin/env bash Policy - I need to find out what direction we should go, in order to make a decent proposal. Can we make OpenCSW manatory? (All our clients had no problem with that, and it seems pretty standard) Not a problem. A matter of documentation, I guess. Can we make the virtual GNU Env (build/bin) as part of build-system-bootstrap? Then some policy definition: 1. I think it is quite possible that we have to link against a library from OpenCSW in future. Will that be ok?* * libpoppler is an example. On customer uses the pdf plugin that has libpoppler from OpenCSW linked. 2. I'd vote for the following policy: - Use everything possible from Standard Solaris - Use tools when needed from OpenCSW - Use these OpenCSW tools through the virtual GNU env (no adding of /opt/csw/bin to path) - Use libraries from OpenCSW only if there is NO other solution - Only add library in a per module fashion: export POPPLER_CFLAGS=-I/opt/csw/include -I/opt/csw/include/poppler export POPPLER_LIBS=-L/opt/csw/lib -lpoppler - Never generally add /opt/csw/lib In general there is a lot of flexibility. It is ideal to use configure properly to avoid doing work manually but as long as you don't interfere negatively with other platforms it is OK. Finally, since I like to switch to GNU-Compiler-Toolchain on solaris too, building
Re: Symphony code in AOO 4.0
Hello Marcus; - Messaggio originale - Da: Marcus (OOo) I learned about these claims via email, but not from the TDF mailing list. But I would not be surprised if it originated there. In any case, when a TDF Director and Marketing Lead makes such claims, it carries some weight, and if utterly false the claims should be rebutted. IMHO. The TDF director and Marketing Lead does no development and doesn't really have any idea what is going on here. Why is that surprising or why should we blog about it? It looks to me like he just wants to bring some attention to his project. Pedro. Because it's not a relatively small part but the Symphony code will (IMHO) play a bigger role in coming AOO releases, e.g., improvements in the UI and accessibility. The code is in the tree, we have Wikis describing the changes and we have people working on them. I don't think we gain anything by getting drawn into a communication war about this. Let's wait until 4.0 takes shape. So, I think in this case an exception from the usual way would be appropriate. Me wonders what is the usual way ;-). Pedro.
Re: Mwiki possible name change.
Hello Jan; I would think that as long as the old wiki.openoffice.org redirects to the new site there should be no problem. We are certainly proud to be under the Apache domain. Pedro. Da: janI j...@apache.org A: dev@openoffice.apache.org Inviato: Lunedì 14 Gennaio 2013 15:09 Oggetto: Mwiki possible name change. Hi. I want to inform the community about an ongoing discussion in Infra regarding the use of wiki.openoffice.org or wiki.openoffice.apache.org Background: We decided sometime ago to let me upgrade mwiki, which I did, with great help from many in here. After that there has been a relatively high load on the VM (very positive) and bi-daily kernel panics due to lack of resources. It was then decided to make a new VM with a new ubuntu, instead of an upgrade in place (to get rid of the kernel panic) which I deemed risky due to the state (and documentation) of the installation. I have completed the work with the new VM, and we were ready to transfer the live site. At that point I learned about plans of using https instead of http. Infra-root has a policy that all logins (not only for committers) should be done through https. Using https, requires a certificate, and the ongoing discussion is whether *.openoffice.org is really needed or if *.openoffice.apache.org would be ok. If I have understood the details correctly (sorry for being vague, but I have not been able to get a clear answer), the users would address https: wiki.openoffice.org or http:wiki.openoffice.org and get a response as https: ooo-wiki.openoffice.org or https:ooo-wiki.openoffice.apache.org. I have written/mailed several times that openoffice.org is a legacy, very important to AOO, and hope it has been understood. The latest discussion seems to go in the direction of getting a certificate for openoffice.org, but there are no guarantees. I have informed infra, that I cannot participate in works that causes a url name change, without having a green light from the AOO community. Meaning that I am now just monitoring what happens and not participating. I am sorry to have partly caused the current situation, I wanted to make a clean installation to make the VM easier to maintain, had I not done that, the https discussion would problaly never have surfaced. I have no deadline for the change, mainly because it is done by others, but I am convinced that Infra will end with a solution that the community can accept. Please take this as information, I cannot go into a discussion on behalf of Infra (I am not infra, but we do have other committers that are infra). Rgds jan I.
Re: Build broken in canvas
Hmm... I think I have a dirty build for running svn update in the middle of a build. Nevermind :(. Pedro. - Messaggio originale - Da: Pedro Giffuni ... gmake: Nothing to be done for `allandcheck'. /usr/ports/editors/openoffice-3-devel/work/ooo/main/canvas/source/cairo/cairo_devicehelper.cxx: In member function 'void cairocanvas::DeviceHelper::dumpScreenContent() const': /usr/ports/editors/openoffice-3-devel/work/ooo/main/canvas/source/cairo/cairo_devicehelper.cxx:271: error: no match for 'operator' in 'aStream OutputDevice::GetBitmap(const Point, const Size) const(((const Point)( aEmptyPoint)), ((const Size)((const Size*)(((OutputDevice*)((const cairocanvas::DeviceHelper*)this)-cairocanvas::DeviceHelper::mpRefDevice)-OutputDevice::GetOutputSizePixel()' /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:370: note: candidates are: SvStream SvStream::operator(sal_uInt16) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:371: note: SvStream SvStream::operator(sal_uInt32) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:372: note: SvStream SvStream::operator(long int) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:373: note: SvStream SvStream::operator(short int) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:374: note: SvStream SvStream::operator(int) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:375: note: SvStream SvStream::operator(signed char) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:376: note: SvStream SvStream::operator(char) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:377: note: SvStream SvStream::operator(unsigned char) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:378: note: SvStream SvStream::operator(float) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:379: note: SvStream SvStream::operator(const double) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:380: note: SvStream SvStream::operator(const char*) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:381: note: SvStream SvStream::operator(const unsigned char*) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:388: note: SvStream SvStream::operator(SvStream) /usr/ports/editors/openoffice-3-devel/work/ooo/main/solver/350/unxfbsdx.pro/inc/tools/stream.hxx:625: note: SvStream operator(SvStream, SvStream (*)(SvStream)) dmake: Error code 1, while making '../../unxfbsdx.pro/slo/cairo_devicehelper.obj' ... _ Thanks for fixing ;), Pedro.
FreeBSD port status
Just a small update; The main set of patches for building on FreeBSD were committed before 3.4 Release. I have been slowly committing the remaining FreeBSD patches trying to avoid interfering with other platforms. All this work has been done by Maho. If someone notices breakage after Revision 1433680 (a one line removal), let me know so that it can be reverted. The only remaining issue to have a direct build from the sources is reported in Bugzilla i118574 and doesn't seem easy to solve cleanly. I have been updating some components to match what we use in FreeBSD, but the port is still fragile for two reasons: - internal icu. - stlport. The first needs to be updated and the second needs to die. Both issues are also key to get a working clang port and would help greatly MacOS X. In any case the status is ... the port works and has been shipping for a while! cheers, Pedro.
Re: Build broken in canvas
Thank you Armin; It will take me some time to check but I think that you hit the issue. I guess it's time to have a BSD buildbot (hi Andrew ;) ). The difference with the linux buildbot is that we try to use all the system libraries available. Pedro. Da: Armin Le Grand armin.le.gr...@me.com A: dev@openoffice.apache.org Inviato: Mercoledì 16 Gennaio 2013 5:03 Oggetto: Re: Build broken in canvas Hi Pedro, should be done with rev 1433875 in source/cairo/cairo_devicehelper.cxx, please check. On 16.01.2013 10:41, Armin Le Grand wrote: Hi Pedro, looks as if I had cairo disabled when building linux version of that change, sorry. I'm on it... -- ALG
Re: Build broken in canvas
Hi Maho; Money is never a problem in the ASF ;) We talked about the buildbot in ApacheConEU. infra@ was providing a VM with FreeBSD 9 (9.1 now?). The setup should not be difficult if we start from the current FreeBSD port (which maho@ wrote and maintains). Pedro. Da: Nakata Maho maho.nak...@gmail.com A: dev@openoffice.apache.org dev@openoffice.apache.org Cc: dev@openoffice.apache.org dev@openoffice.apache.org Inviato: Mercoledì 16 Gennaio 2013 19:47 Oggetto: Re: Build broken in canvas Yes!! We should have a build bot. Is any financial support for a new machine for that purpose? Then I can (if no still I can do). iPhoneから送信 2013/01/17 8:53、Andrew Rist andrew.r...@oracle.com のメッセージ: On 1/16/2013 6:48 AM, Pedro Giffuni wrote: Thank you Armin; It will take me some time to check but I think that you hit the issue. I guess it's time to have a BSD buildbot (hi Andrew ;) ). YES! The difference with the linux buildbot is that we try to use all the system libraries available. Pedro. Da: Armin Le Grand armin.le.gr...@me.com A: dev@openoffice.apache.org Inviato: Mercoledì 16 Gennaio 2013 5:03 Oggetto: Re: Build broken in canvas Hi Pedro, should be done with rev 1433875 in source/cairo/cairo_devicehelper.cxx, please check. On 16.01.2013 10:41, Armin Le Grand wrote: Hi Pedro, looks as if I had cairo disabled when building linux version of that change, sorry. I'm on it... -- ALG
Re: Dictionaries?
Hi Gianluca; The older italian version is here: http://code.google.com/a/apache-extras.org/p/ooo-myspell/ The Croatian dictionary was also relicensed but was dropped with all the dictionaries. Ultimately we really don't do dictionaries here in AOO so grabbing them from other places, as long as their license permits, is the right thing to do. Pedro. Da: Gianluca Turconi pub...@letturefantastiche.com A: dev@openoffice.apache.org Inviato: Venerdì 18 Gennaio 2013 6:54 Oggetto: Re: Dictionaries? Il 18/01/2013 1.01, Andrea Pescetti ha scritto: We did have at least one license change (Russian?) but the bundling mechanism is actually designed to retrieve external OXT files at build time. An old Italian dictionary version was changed to Apache license too. Ask Pedro Giffuni for details. Regards, -- Gianluca Turconi Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy, horror, noir, narrativa fantastica e tradizionale: http://www.letturefantastiche.com/
Re: Root README file in SVN
Hi Rob; Perhaps we should add a legal DISCLAIMER to the branches directory? I am aware of other projects taking code from there that we may not be releasing after all (oops). Pedro. - Messaggio originale - Da: Rob Weir I've checked in a README file to the root of our SVN tree: https://svn.apache.org/repos/asf/openoffice/README This should be useful to help orient someone who is browsing our tree. I could use your help identifying the purpose of the branches. I described the ones I know about, but there are several there that I am not familiar with. Thanks! -Rob
Re: Root README file in SVN
I would label it DISCLAIMER to make it pristine clear. Something in the lines of: Development branches represent Work in Progress for internal use only. This code may be present in a future release but no claim is made concerning their content including licensing status or code quality. Use at your own risk. You may want to check with legal if we should include something else. Pedro.
Some development ideas
Hi; I am having fun with other areas of AOO so I don't have time to try this but here are some ideas in case someone wants to do further work there: 1) Update libxslt: xslt is really important in OpenOffice and libxslt 1.1.28 works just fine. 2) Enable building the boost component in python. We carry both boost and Python so it would be natural to make use of them. I think some configure option has to be added to boost for that and then deliver the result. 3) Enable openssl in APR. Again, we carry both, not sure if we are using all the potential there. 4) Replace rtl::math::random with the random nuber generator in APR. We have a random number generator in SAL that we use for bookmarks in documents and to seed the PRNG. APR has a crypto grade number generator that could be used instead. This would add a SAL dependency on APR, but it's likely that APR has functionality that would be interesting for the SAL module. 5) We use hypot a lot (look it up in opengrok), perhaps we should add an implementation in SAL. Pedro. ps. If someone wants to open bugzilla issues for any of these, please don't include me, I specifically don't have time for any of it.
Re: Some development ideas
Hi; - Messaggio originale - Da: Rob Weir 4) Replace rtl::math::random with the random nuber generator in APR. We have a random number generator in SAL that we use for bookmarks in documents and to seed the PRNG. APR has a crypto grade number generator that could be used instead. This would add a SAL dependency on APR, but it's likely that APR has functionality that would be interesting for the SAL module. Is there an opportunity to also get functions for distributions other than uniform? A randomnormal(mean, stdev) function would be quite useful. You can do that with the boost PRNG but it's somewhat broken and I won't recommend it. The is more like a random device .. it's a real random number generator that attempts to be naturally unpredictable. 5) We use hypot a lot (look it up in opengrok), perhaps we should add an implementation in SAL. Pedro. ps. If someone wants to open bugzilla issues for any of these, please don't include me, I specifically don't have time for any of it. I'd still recommend entering these ideas into Bugzilla, classified as a task and setting an appropriate difficulty level. Feel free to do that but I don't want to have to remove myself from any notifications because I don't want them at all. Please do NOT include me. If the tasks get forgotten, so be it, maybe they are not that useful at all. Pedro.
RAT scans: Re: What rights are given in an SGA
Somewhat off-topic, ma non troppo ... It would be good to tun a RAT scan over the website. We have not done anything to clean the content licensewise and we probably carry copyleft content, including code, there! Pedro.
Re: OpenOffice on Wikipedia (was: In case you missed it: The OpenOffice Wikipedia page was FUD'ed over the holidays)
- Messaggio originale - Da: Rob Weir ... https://plus.google.com/111502940353406919728/posts/3CUDTZoTsAp You wrote: OO is dead, LO is alive, switch immediately. The article sorta gets that across - read the history and LibreOffice sections. Apache OpenOffice is a moribund shell, which will live precisely as long as IBM is interested in keeping it alive. And they've shown not all that much interest of late, either. and It was dead from neglect; Oracle donated the corpse to Apache as part of their (details unrevealed) 2008 deal with IBM, with a side order of f*ck-you to LO thrown in for free. and The talk page discussion on naming of the article is interesting. Basically, once AOO 4.0 is out (if it ever comes out - IBM doesn't seem to have merged their Symphony code as yet, and it was supposed to be released next month) there'll be a serious proposal to make AOO a separate article and keep this one as being about the OpenOffice.org that existed from 2000 to 2011. If/when AOO 4.0 comes out with the horrible Symphony interface, expect millions of previously-happy OOo users to absolutely sh*t. It'll be the Windows 8 of office suites. So this does not suggest good faith. In fact, it suggests a profound ignorance of the project and what we've been doing, as well as having an axe to grind. These comments, plus your mendacious editing in the article suggests you are using Wikipedia to push a point of view. http://en.wikipedia.org/wiki/Hanlon's_razor cheers, Pedro.
Re: RAT scans: Re: What rights are given in an SGA
- Messaggio originale - Da: Andrea Pescetti Pedro Giffuni wrote: It would be good to tun a RAT scan over the website. We have not done anything to clean the content licensewise and we probably carry copyleft content, including code, there! The website contains gigabytes of materials for which we are probably unable to trace detailed history and licensing, since they come from multiple CVS repositories, then lost and migrated to multiple SVN repositories, then lost and migrated to the current tree. So a RAT scan wouldn't probably yield anything actionable. The only thing we know for sure is that all those materials were contributed to be put on the openoffice.org website and that we are continuing to keep them online. Even if there is copyleft content or code I believe it will be fine so long as we don't put it in a release (and it won't happen that some site contents go into a release without a thorough check). If we are distributing code there it is our responsibility. I am afraid there are also tarballs that deserve special consideration. I recall we were carrying a GPL'd slovenian dictionary (not sure if I finally got rid of it). Some content like the SDK should be verified for licensing content and updated. The fact that information was transfered through CVS and SVN or whatever is irrelevant we should know what we have and ultimately after any cleanup SVN will remember what we had in there. I understand we are underpowered to fix all that but the biggest problem is that we don't have any accounting over the content there, so it's a can of worms waiting to be opened. Pedro.
Re: [CODE][CLEANUP]: getting rid of the 3 layer office directory structure
- Messaggio originale - Da: Jürgen Schmidt Hi, we currently still have a complex but not necessary 3 layer directory structure in the office that makes many things more complicate and is completely unnecessary. The reason why we have this is historical and not longer relevant and the question is if we want to get rid of this for our next release? It sounds like a good idea. The one thing I wonder about is if it shall cause trouble to the code being merged but you know the answer to that better that me. ;). While here I noticed we started moving some dependent modules from main/ to ext_libraries/ but things like boost and stlport were never moved. Is there some special consideration or adjustment to be done to the build, or is it just a matter of doing some svn move around the base? Any opinions or volunteers who have interest to help with such a project? If we decide to work on it, we have to start immediately to have enough time for testing. Not volunteering sorry, my plate is full. Pedro.
Re: Hi
Hello Michael; There are many interesting things to do with Java: we could use a general update to the code to use generics (I think Eclipse has tools for that) and we have stuff like Lucene that I am pretty sure needs a review to see where we can use the new features. hsqldb could also use some tender care: we even have code for review that no one has looked at. You could make a walkthrough SVN to see how the code is distributed and have a try to build it in your platform. I am not going to lie: the code is big and some parts are scary (hey it's C++ !) , but with patience you get to understand enough to make a huge difference. Pedro. Da: Michael Lam mnsyl4...@verizon.net A: dev@openoffice.apache.org Inviato: Giovedì 24 Gennaio 2013 20:26 Oggetto: Hi My name is Michael Lam, I am a software engineer and I would like to volunteer. I mostly program in Java but also know python and would like to brush up on my C/C++. I have been on this mailing list for awhile and also have an account on bugzilla. I don't have a particular module in mind and would like to know where is the best place to start. Do I just pick something bugzilla? I am up for suggestion and guidance.
Re: Error while trying to build from svn checkout
Hi Michael; That's pretty weird because I just built everything fine. Try svn update and if you get errors report the revision number, Pedro. Da: Michael Lam mnsyl4...@verizon.net A: dev@openoffice.apache.org Inviato: Giovedì 24 Gennaio 2013 23:56 Oggetto: Error while trying to build from svn checkout I got the following when I tried to build from the latest SVN checkout. I am building on Linux. dmake: Error: -- `sg25.sdv' not found, and can't be made 1 module(s): extras need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /project/ooo/main/extras/source/gallery/gallery_system where would I get that file? Thanks Michael
Re: [VOTE]: Release Apache OpenOffice 3.4.1 respin to support 8 new languages
+1 (binding) Da: Jürgen Schmidt jogischm...@gmail.com A: dev@openoffice.apache.org Inviato: Mercoledì 23 Gennaio 2013 4:13 Oggetto: [VOTE]: Release Apache OpenOffice 3.4.1 respin to support 8 new languages Hi all, this is a call for vote on releasing a minor respin of Apache OpenOffice 3.4.1 to support 8 new languages (Danish, Swedish, Norwegian Bokmal, Polish, Korean, Basque, Asturian, Scottish Gaelic). The Hungarian version is repackaged and a Hungarian dictionary is now included. This release is a minor update to support further languages but no bug fixes. We decided to keep the effort minimal and updated only the new languages and no further minor bug fixes. It is the last minor update including incubating in the name and we do that to integrate smoothly in the naming scheme of the current release and to keep the download simple. The source release for AOO 3.4.1 will be renewed and is based now on revision 1435053 from branch AOO34. For our broad user base we built and provide convenience binary packages on the same revision for all new languages. The source release candidate can be found under https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO341srcrelease The convenience binary full install sets for the new languages can be found under https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO341fullsets The convenience binary language packs for the new languages can be found under https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO341languagepacks Please vote on releasing this respin package as a complement to our already released Apache OpenOffice 3.4.1 (incubating). The vote starts now and will be open for 72 hours until: Saturday, 26 January: 2013-01-26 10:00am UTC+1. The vote of PMC members is binding but we invite all people to vote (non binding) on this RC. We would like to provide a release that is supported by the majority of our project members. [ ] +1 Release this respin package as complement Apache OpenOffice 3.4.1 (incubating) [ ] 0 Don't care [ ] -1 Do not release this package because...
Re: SVN
- Messaggio originale - Da: jorge ivan poot diaz ... Oggetto: SVN I have read about SVN, is a very useful tool for the development of projects. On this page http://lihuen.linti.unlp.edu.ar/index.php?title=C%C3% B3mo_usar_SVN there is information. I have installed the subversion but my question is: After the checkout what I have to do? I need more information to start working. Help me. Then the fun starts: http://wiki.openoffice.org/wiki/Documentation/Building_Guide After you learn to configure it and have the dependencies set up, it may take up to a day to build it. Pedro.
Re: Error Building module hsqldb - Installation Source Code in AOO
Hello Alan; My guess is that you are using a localized (non-english) environment, but JDK7 is also a know source of problems ih hsqldb. Hope that helps, Pedro.
Re: Error Building module hsqldb - Installation Source Code in AOO
Hi Kay; - Messaggio originale - Da: Kay Schenk On Sat, Jan 26, 2013 at 5:17 PM, Pedro Giffuni p...@apache.org wrote: Hello Alan; My guess is that you are using a localized (non-english) environment, but JDK7 is also a know source of problems ih hsqldb. Hope that helps, Pedro. A quick weird question on this...Is this partially due to the rather old version of HSQLD we package -- 1.8? (in ext_sources)-- as opposed to newer 2.2? Among other things...I am actually trying to investigate more of the java issues, so this is why I ask. This particular issue is rather easy to fix by patching the weird caracters. I think I will do that soon. The java7 issues are due to the old version of hsqldb and we actually have two options here: 1) Bring the hsqldb19 branch and update to hswldb 2.2.x. 2) Wait for a new version of hsqldb that will be released towards the end of month that will include backward compatibility. OTOH, if you want to work on Java.. I have a bunch of patches that need reviewing. Let me know :). Pedro.
Re: Error Building module hsqldb - Installation Source Code in AOO
Hello Michael;
- Messaggio originale -
Da: Michael Lam
..
Inviato: Domenica 27 Gennaio 2013 14:52
Oggetto: Re: Error Building module hsqldb - Installation Source Code in AOO
I had the same issue but it was due to JDK7, I switch and it is working
but I have a question about how the java libraries are included. As
mentioned by Kay, the current version of hsqldb is quite old. The latest
is 2.2.9 and the same goes for Lucene the included version is 2.x
whereas the latest is 4.1. How come the jar is being created as part of
the build process instead of just pulling a prebuild version?
Support for using the newer versions of hsqldb is in the Hg branch in the
older Oracle repository. Unfortuantely there was something very broken
there so we didn't import it for AOO 3.4. The code needs reviewing.
Configure can be instructed to use pre-built versions of most tools.
In FreeBSD we use something like this:
--with-system-lucene \
--with-lucene-core-jar=${JAVALIBDIR}/lucene-core-3.6.1.jar\
--with-lucene-analyzers-jar=${JAVALIBDIR}/lucene-analyzers-3.6.1.jar
However, you must make sure that you are using a version that is
compatible with the one we carry. We may have to update lucene's
support to be able to use the new versions (I opened BZ issue
121457 with some comments from the Lucene core guys about that).
On a similar note, I had an additional issue with the build complaining
about the dmake that is pull down by bootstrap being an invalid bzip2
file, not sure if other people ran into the same issue. I had another
copy of dmake on my machine and I just applied it to get pass the issue.
All of these were done from a fresh checkout from SVN.
Dmake is a build tool that we don't maintain in Apache and we hope to
deprecate one day..
It was moved here:
http://code.google.com/a/apache-extras.org/p/dmake/
Pedro.
Re: Error Building module hsqldb - Installation Source Code in AOO
FWIW; The fix, according to the hsqldb guys is: One source code comments has some UTF-7 characters which cause problems. Change the string to Knuth-Morris-Pratt to fix it However the file doesn't exist in the version of hsqldb that we carry: $ file build/hsqldb/src/org/hsqldb/lib/ build/hsqldb/src/org/hsqldb/lib/: directory $ file build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java: cannot open `build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java' (No such file or directory) $ You are supposed to use the hsqldb version that AOO provides. Pedro. Da: Alan Eduardo Puc Pech ... switchtojdk16: [java] store: [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/build/build.xml:291: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds lib: [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/build/build.xml:302: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 46 source files to /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/classes [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:39: error: unmappable character for encoding ASCII [javac] * Implements the Knuth???Morris???Pratt string search algorithm for searching [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:69: error: unmappable character for encoding ASCII [javac] * Note that the Boyer???Moore algorithm is generally considered to be the better [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:69: error: unmappable character for encoding ASCII [javac] * Note that the Boyer???Moore algorithm is generally considered to be the better [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:69: error: unmappable character for encoding ASCII [javac] * Note that the Boyer???Moore algorithm is generally considered to be the better [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:81: error: unmappable character for encoding ASCII [javac] * Boyer???Moore requires at minimum twice the memory required by Knuth???Morris???Pratt [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:81: error: unmappable character for encoding ASCII [javac] * Boyer???Moore requires at minimum twice the memory required by Knuth???Morris???Pratt [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:81: error: unmappable character for encoding ASCII [javac] * Boyer???Moore requires at minimum twice the memory required by Knuth???Morris???Pratt [javac] ^ [javac] /home/alan/ooo/main/hsqldb/ unxlngi6.pro/misc/build/hsqldb/src/org/hsqldb/lib/KMPSearchAlgorithm.java:81: error: unmappable character for encoding ASCII
Re: error building (bootstrap command)
It is unfortunately not that easy. You need to specify a lot of configure flags. Follow in detail the building guide: http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO Pedro. ps. Bienvenidos!! Da: Henry Tiquet Leyva henry.tiquet.le...@gmail.com A: dev@openoffice.apache.org Inviato: Lunedì 28 Gennaio 2013 21:29 Oggetto: error building (bootstrap command) Hello everyone, I have a problem compilling aoo, I can't execute the ./bootstrap command, I did this: 1.- autoconf 2.- ./configure 3.- ./bootstrap but it not work. how can I do to repair this error? Can anyone give me a link for find information about this? there is any forum for consult it?
Re: Apache OpenOffice in Fedora 19?
Hello; - Messaggio originale - Da: David Gerard ... A question I was wondering (for the Wikipedia article): is there any Linux distribution that presently carries AOO in its repos? I understand it's in the FreeBSD ports tree http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/ - which would be the BSD equivalent. I don't know about linux but for FreeBSD please use this link: http://www.freshports.org/editors/openoffice-3/ the -devel version is only meant for ... developers :). Pedro.
Re: simple patch to get started
Hi Fred; The mailing list tends to eat all attachments so your patch didn't make it :(. Perhaps you can open a Bugzilla report on this we can use some of those copy-paste services. Pedro. Da: Fred Ollinger folli...@gmail.com A: dev@openoffice.apache.org Inviato: Giovedì 31 Gennaio 2013 14:19 Oggetto: simple patch to get started Attached is a simple patch which should quiet some ant warnings. Also, I'm trying to get this working with Oracle's Java 7. local_dev300/hsqldb/unxlngi6.pro/misc/build/hsqldb/build/build.xml Fred
Re: [bikeshed] I like blue titles.
Da: Dave Fisher ... Can we change the red title in the website (Call for Volunteers, as of lately) to dark blue? The reasons: - The tone of red chosen looks like it was made to fit at the last moment. It has no aesthetic coherence with the rest of the website. It was chosen quickly and I was thinking it would be for unusual events. I recall it started when we were about to release 3.4 and the blog went down so we just had to release on the website. Now it appears to be a common element which is OK. It is being changed everytime there's something to communicate: Like if we break (yet) another download milestone. The red chair is becoming part of the furniture. - It makes us look desperate (or so seem to think some bloggers). The concern should be what works? Not what some bloggers think. Breaking out from the visual clutter of the page is important. We want to stand out, not blend in and be overlooked. IMHO. I like blue if it will always be there I suspect we will have it forever :(. Oh course there are other ways of standing out, like with a banner graphic. That could give us a more professional image while still standing out. What ever can be done... Again, just chose a color for the bikeshed that seems average among the proposals ;). Pedro.
Re: AOO build + bug fix
Thank you Hrishit! Just building it is a great step forward. That is a great advance indeed. What platform are you using? We need a diff file. On UNIX/linux you can try man diff and do something like this diff -ru original-path modified-path diff-file.patch original-path modified-path can be files or even directories. You then attach the resulting diff-file.patch to the bugzilla issue. And feel free to buzz us on this list so someone reviews it :-). Pedro. Da: Hrishit Patel hripat1...@gmail.com A: dev@openoffice.apache.org Inviato: Venerdì 1 Febbraio 2013 15:22 Oggetto: AOO build + bug fix Hi dev community, I've built my own AOO and now I'm working on the foolowing bug https://issues.apache.org/ooo/show_bug.cgi?id=102212 In fact I've corrected it(which was a 2 minute work), but I haven't worked with any version control before so now I'm looking into how to proceed or whom to report. cheers, hrishit
Re: [bikeshed] I like blue titles.
Thank you Dave! It's still perfectly visible without being too scandalous. I like it. Now for a new bikeshed ... I would use Volunteers wanted, instead of Volunteers needed ;). Just kidding ... :). Pedro. Da: Dave Fisher dave2w...@comcast.net A: dev@openoffice.apache.org Inviato: Venerdì 1 Febbraio 2013 17:49 Oggetto: Re: [bikeshed] I like blue titles. On Feb 1, 2013, at 1:56 PM, Tanja Meece wrote: Red immediately sends up a warning flag in my mind and that of other user's I'm sure. That was the original intent. There has to be some way to change the color. There is and it is done! It is now the same blue as the rest of the header text. Regards, Dave TMCM On Feb 1, 2013 9:43 AM, Pedro Giffuni p...@apache.org wrote: Da: Dave Fisher ... Can we change the red title in the website (Call for Volunteers, as of lately) to dark blue? The reasons: - The tone of red chosen looks like it was made to fit at the last moment. It has no aesthetic coherence with the rest of the website. It was chosen quickly and I was thinking it would be for unusual events. Firstly, I hope I am doing this properly, if not I apologize in advance. I agree. I believe that a red sends the wrong signals. It sends up more of a warning flag, rather than an invitation for volunteers. The first time I saw it I thought I'd done something wrong. I recall it started when we were about to release 3.4 and the blog went down so we just had to release on the website. Now it appears to be a common element which is OK. It is being changed everytime there's something to communicate: Like if we break (yet) another download milestone. The red chair is becoming part of the furniture. - It makes us look desperate (or so seem to think some bloggers). The concern should be what works? Not what some bloggers think. Breaking out from the visual clutter of the page is important. We want to stand out, not blend in and be overlooked. IMHO. I like blue if it will always be there I suspect we will have it forever :(. Oh course there are other ways of standing out, like with a banner graphic. That could give us a more professional image while still standing out. What ever can be done... Again, just chose a color for the bikeshed that seems average among the proposals ;). Pedro.
Re: [bikeshed] I like blue titles.
hold it right there Volunteers wanted and needed is just too much for a shed. Pedro. Da: Rob Weir robw...@apache.org A: dev@openoffice.apache.org Inviato: Venerdì 1 Febbraio 2013 18:50 Oggetto: Re: [bikeshed] I like blue titles. On Fri, Feb 1, 2013 at 6:16 PM, Dave Fisher dave2w...@comcast.net wrote: On Feb 1, 2013, at 3:04 PM, Pedro Giffuni wrote: Thank you Dave! It's still perfectly visible without being too scandalous. I like it. Now for a new bikeshed ... I would use Volunteers wanted, instead of Volunteers needed ;). Semantics are important! We want them because we need them. If we didn't need them, we'd still welcome them but we wouldn't advertise it on the homepage. So yes, semantics are important, but this is not an either/or thing. We both need and want volunteers. -Rob Just kidding ... :). It's not a bikeshed it is a good point! Done! Regards, Dave Pedro. Da: Dave Fisher dave2w...@comcast.net A: dev@openoffice.apache.org Inviato: Venerdì 1 Febbraio 2013 17:49 Oggetto: Re: [bikeshed] I like blue titles. On Feb 1, 2013, at 1:56 PM, Tanja Meece wrote: Red immediately sends up a warning flag in my mind and that of other user's I'm sure. That was the original intent. There has to be some way to change the color. There is and it is done! It is now the same blue as the rest of the header text. Regards, Dave TMCM On Feb 1, 2013 9:43 AM, Pedro Giffuni p...@apache.org wrote: Da: Dave Fisher ... Can we change the red title in the website (Call for Volunteers, as of lately) to dark blue? The reasons: - The tone of red chosen looks like it was made to fit at the last moment. It has no aesthetic coherence with the rest of the website. It was chosen quickly and I was thinking it would be for unusual events. Firstly, I hope I am doing this properly, if not I apologize in advance. I agree. I believe that a red sends the wrong signals. It sends up more of a warning flag, rather than an invitation for volunteers. The first time I saw it I thought I'd done something wrong. I recall it started when we were about to release 3.4 and the blog went down so we just had to release on the website. Now it appears to be a common element which is OK. It is being changed everytime there's something to communicate: Like if we break (yet) another download milestone. The red chair is becoming part of the furniture. - It makes us look desperate (or so seem to think some bloggers). The concern should be what works? Not what some bloggers think. Breaking out from the visual clutter of the page is important. We want to stand out, not blend in and be overlooked. IMHO. I like blue if it will always be there I suspect we will have it forever :(. Oh course there are other ways of standing out, like with a banner graphic. That could give us a more professional image while still standing out. What ever can be done... Again, just chose a color for the bikeshed that seems average among the proposals ;). Pedro.
Re: AOO build + bug fix
Thank you! - Messaggio originale - Da: Hrishit Patel On Fri, Feb 1, 2013 at 3:56 PM, Pedro Giffuni wrote: Thank you Hrishit! Just building it is a great step forward. That is a great advance indeed. What platform are you using? We need a diff file. On UNIX/linux you can try man diff and do something like this diff -ru original-path modified-path diff-file.patch original-path modified-path can be files or even directories. You then attach the resulting diff-file.patch to the bugzilla issue. I've attached the patch file. Please someone review it. It looks good to me. additional issue: It also include the fix to some other bug, the link to which i could not find because it has been removed from the bug-list now. But the original repository doesnt reflect the change needed to fix it. In the patch file lines 66-67 handles this bug. I think you are referring to https://issues.apache.org/ooo/show_bug.cgi?id=121681 I fixed it and tested the change and I added you to the issue, even when it's closed now. Thanks! Pedro.
Re: Reverting commits [was: Re: svn commit: r1441659 - /openoffice/site/trunk/templates/sidenav.mdtext
- Messaggio originale - Da: Tim Williams ... Then count me uncool then. I did it and I'd do it again in similar circumstances. It is easier to apologize to David later If I'm wrong then for us to have the trademark legally invalidated if I was right and did not act quickly. I'm not sure what to say. By uncool I meant, it's socially unacceptable around here (the ASF) and, yet, your not only ok with that but you'd do it again. The timeliness wasn't as grave as you intimate - some reasonable time could have been allowed. Please don't revert other's commits in the future... --tim I agree with Tim. It is rude to revert someone else's changes without giving the original committer the time to fix it himself or defend his position. There is no good reason to be rude with a colleague. Pedro.
Re: Reverting commits [was: Re: svn commit: r1441659 - /openoffice/site/trunk/templates/sidenav.mdtext
Hello; You are right. My comparison was insensible and way out of line. I apologize and I will take a break from the lists for a while. Pedro.
Re: Calc behavior: result of 0 ^ 0
Hello; I don't understand, I saw a bug (erroneous result returned by a function) and I fixed it respecting the standards, thereby enhancing interperability with the market leader. I am aware that Rob has a different point of view here but so far neither him nor Stephen Hawking has explained how the change would be incorrect and no example where someone has been affected by this change has been provided. Has the patch been vetoed, and if so on what basis? Pedro. Da: Dennis E. Hamilton dennis.hamil...@acm.org A: dev@openoffice.apache.org Cc: dwhyt...@gmail.com; pesce...@apache.org; 'Pedro Giffuni' p...@apache.org Inviato: Martedì 12 Febbraio 2013 13:11 Oggetto: RE: Calc behavior: result of 0 ^ 0 RESOLUTION OF THE PROPOSAL The proposed change was made under CTR (Commit then Review). There has been a subsequent review and, as Don points out, the discussion has been lengthy and vocal. The objective is to achieve consensus. I believe it is clear that there is no consensus on the proposed change and the proposal fails. I can't speak for the AOO PMC. It would be useful if Andreas helped wrap this up. If the lack of consensus is affirmed, Pedro can revert the change and adjust the Bugzilla issue. THE ESSENCE OF THE PROPOSAL The proposal is to enact the breaking change as described on the Community Wiki at https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes . It is under Changes that Impact Backward Compatibility, Calc and OpenFormula Support. Exponentiation The current version of Calc produces 1 for POWER(0,0). This is one of the implementation-defined results that is permitted by ODF 1.2 OpenFormula. It is proposed to change POWER(0,0) to result in #VALUE!. This is also permitted as the implementation-defined result. This is also compatible with Excel and the Excel 2013 support for ODF 1.2 OpenFormula in .ods Spreadsheets. ... OUTCOME The proposed change is tracked in Bugzilla Issue #114430, https://issues.apache.org/ooo/show_bug.cgi?id=114430. A patch to implement this proposal is already included in the SVN. If the proposal is not accepted as the result of CTR review, the Issue will be closed and the patch reverted. - Dennis -Original Message- From: Donald Whytock [mailto:dwhyt...@gmail.com] Sent: Tuesday, February 12, 2013 09:20 To: dev@openoffice.apache.org Subject: Re: Calc behavior: result of 0 ^ 0 ...So I got curious, and I paged back in my email archive, and it seems this is the biggest AOO dev thread since the graduation vote back in early September. At this point, does anyone care enough about changing the status quo as to put up a coherent proposal to be voted on? Don
Re: Calc behavior: result of 0 ^ 0
Ugh.. I haven't been following this thread at all ... I unsubscribed from the -dev list because I always ended up in absurd discussions and there was not much technical content either. I suspected it would be bikeshed.org material but in any case let me make things clear. - 0^0 = 1 is NOT mathematically correct. The limit of x^x when x tends to +0 is 1, however when you consider the limit when x tends to -0, the limit is infinite. This is called Indeterminate Form. http://en.wikipedia.org/wiki/Indeterminate_form If you wonder, I failed a math quiz in the University for blindly using the value my HP Calculator gave (1), so I am sort of glad that this has been a free educational experience for some of you. The implementation in OOo doesn't return explicitly a 1 value but instead relies on what the libc pow() function does. The standard libc lets you do 0^0 but it also lets you divide by zero without aborting . Modern IEEE 754 2008 implements three power functions pow(), pown() and powr(), powr() being the most similar to the real mathematical function. The implementation is non intrusive: I added a wrapper in SAL that behaves like powr() so that we don't affect other formulas that use pow() internally. So far no one has given an example where shooting yourself in the foot by expecting pow(0,0) to be 1 is a good thing. I am gladly surprised that Excel does the same, but the real reason why I went ahead and implemented a solution is to do the right thing, mathematically speaking. Mathematical correctness is not something that IMHO pertains to democracy. Sure it would be nice to have an option to adjust your results for mathematically undetermined cases like 0^0 or 0/0 but unless you are planning to implement it don't expected such features to appear magically either. I would be extremely disappointed to have to revert a correct fix for non-technical reasons. I think I would lose any motivation to improve other functions in Calc. Pedro.
Re: Calc behavior: result of 0 ^ 0
(OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Of course we can use the power function a^b in your spreadsheet when the b is a constant but you have to understand the assumptions being made before blindingly applying formulas, and we just can't assume every speadsheet user will use a restricted set of capabilities. Now, in a spreadsheet this formula would be used if you have a polinomial and you want to calculate and/or graph it's derivative. Since we don't do symbolic math in the speadsheet you would actually do this by hand and you would resolve the trivial constant^0 cases. In the case of the set theory book, do note that the author is constructing his own algebra, and it's natural that he might not want indefinite values that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. I guess looking hard it may be possible to find an elaborated case where someone manages to shoot himself in the foot but ultimately I would wonder. if this author *is* using mathematics correctly. 0^0 is a good indication that there is something wrong in your calculation and evidently Excel users have come to accept it. Pedro. *Welcome to this list ;).
Re: Calc behavior: result of 0 ^ 0
Hello;
Da: Norbert Thiebaud
...
On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote:
On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote:
(OK, I guess it's better to re-subscribe to the list).
In reply to Norbert Thiebaud*:
In the Power rule, which *is* commonly used for differentiation, we take a
series
of polinomials where n !=0. n is not only different than zero, most
importantly,
it is a constant.
Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed.
so for n=1 (which _is_ different of 0 !)
d/dx X = 1.x^0
for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0.
I know math can be challenging... but you don't get to invent
restriction on the Power Rule just to fit you argument.
I will put it in simple terms. You are saying that you can't calculate the
slope of the equation:
y =a*x + b
because in the process you need to calculate the value of x^0.
In the case of the set theory book, do note that the author is constructing
his own algebra,
The fact that you call 'Nicola Bourbaki' 'the author', is in itself
very telling about your expertise in Math.
I nicely put a link to the wikipedia page, since laymen are indeed
unlikely to know 'who' Borbaki is.
Do I really care if the name of the author is fictitious or real?
that get outside his set: 0^0 and x/0 are such cases. The text is not
a demonstration, it is simply a statement taken out of context.
You ask for a practical spreadsheet example, when one is given you
invent new 'rules' to ignore' it.
You haven't provided so far that practical spreadsheet.
You claim that 'real mathematician' consider 0^0=... NaN ? Error ?
And when I gave you the page and line from one of the most rigorous
mathematical body of work of the 20th century (yep Bourbaki... look it
up)
you and hand-wave, pretending the author did not mean it.. or even
better if this author(sic) *is* using mathematics correctly.
The thing is that you are taking statements out of context. I don't
claim being a mathematithian. I took a few courses from the career for fun.
In the case of set theory you can define, for your own purposes, a special
algebra where:
- You redefine your own multiplication operator (x).
- You don't define division.
- You make yor algebra system fit into a set of properties that
is useful for your own properties.
Once you define your own multiplication (which is not the same
multiplication supported in a spreadsheet) You work around the
issue in the power operator by defining the undefined case.
These are all nice mathematical models that don't apply to a spreadsheet.
I guess looking hard it may be possible to find an elaborated case where
someone manages to shoot himself in the foot
Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious
for shooting himself in the foot when doing math...
For those interested in the actual Math... in Math words have meaning
and that meaning have often context. let me develop a bit the notion
of 'form' mentioned earlier:
for instance in the expression 'in an indeterminate form', there is
'form' and it matter because in the context of determining extension
by continuity of a function, there are certain case where you can
transform you equation into another 'form' but if these transformation
lead you to an 'indeterminate form', you have to find another
transformation to continue...
hence h = f^g with f(x)-0 x-inf and g(x)-0 x-inf then -- once it
is establish that h actually converge in the operating set, and that
is another topic altogether -- lim h(x) x-0 = (lim f)^(lim g).
passing 'to the limit' in each term would yield 0^0 with is a
indeterminable 'form' (not a value, not a number, not claimed to be
the result of a calculation of power(0,0), but a 'form' of the
equation that is indeterminate...) at which point you cannot conclude,
what the limit is. What a mathematician is to do is to 'trans-form'
the original h in such a way that it lead him to a path to an actual
value.
in other words that is a very specific meaning for a very specific
subset of mathematics, that does not conflict with defining power(0,0)
= 1.
wrt to the 'context' of the quote I gave earlier:
Proposition 9: : Let X and Y be two sets, a and b their respective
cardinals, then the set X{superscript Y} has cardinal a {superscript
b}.
( I will use x^y here from now on to note x {superscript y} for readability )
Porposition 11: Let a be a cardinal. then a^0 = 1, a^1 = a, 1^a = 1;
and 0^a = 0 if a != 0
For there exist a unique mapping of 'empty-set' into any given set
(namely, the mapping whose graph is the empty set); the set of
mappings of a set consisting of a single element into an arbitrary set
X is equipotent to X (Chapter II, pragraph 5.3); there exist a unique
mapping of an arbitrary set into a set consisting of a single element;
and finally there is not mapping of a non-empty set into the
empty-set;
* Note in particular that 0^0 = 1
Again, I
Re: Calc behavior: result of 0 ^ 0
FWIW; - Messaggio originale - Da: Andrew Douglas Pitonyak Of course, had I implemented quaternion math using Boost, no one would be complaining. :-P Pedro. [1] http://bikeshed.org Do it, do it, do it; PLEESSEEE. :-) Quaternions are cool. I think it is easy, and likely a nice exercise for someone wanting to start AOO development. Perhaps GSoC material. After that, how about interval arithmetic! I think that is even more fun! I don't know about that, sorry ;). Pedro.
Re: Calc behavior: result of 0 ^ 0
Thank you Ricardo; My suggestion would be to leave things as they are and give the matter a rest. I personally prefer to focus on other (more necessary) developments like updating python to version 2.7.4 which will be released this weekend. We have ample time for testing and if there is new information we can revise the issue before 4.0 is released. Pedro. Da: RGB ES rgb.m...@gmail.com A: dev@openoffice.apache.org; Pedro Giffuni p...@apache.org Inviato: Mercoledì 13 Febbraio 2013 10:43 Oggetto: Re: Calc behavior: result of 0 ^ 0 Not answering any particular message, so top posting. Two points: a) Of course you can always redefine a function to fill holes on non defined points: for example, redefining sinc(x) = sin(x)/x to be 1 on x=0 makes sense because you obtain a continuous function... but that's on 1 variable: when you go to two variables things become more difficult. In fact, the limit for x^y with x *and* y tending to zero do NOT exists (choose a different path and you'll get a different limit), then there is NO way to make that function continuous on (0,0), let alone what happens when x 0... so the real question is: does it make sense to fill the hole on x^y? *My* answer (and that leads to the second point) is no because it do not give any added value. b) Considering that we are near to 90 messages on this thread it is quite clear that an agreement is not possible. On this situation it is also clear that choosing an error instead of a fixed value is the best bet. Just my 2¢ Regards Ricardo 2013/2/13 Pedro Giffuni p...@apache.org Hello; Da: Norbert Thiebaud ... On Tue, Feb 12, 2013 at 10:09 PM, Rob Weir rabas...@gmail.com wrote: On Feb 12, 2013, at 10:39 PM, Pedro Giffuni p...@apache.org wrote: (OK, I guess it's better to re-subscribe to the list). In reply to Norbert Thiebaud*: In the Power rule, which *is* commonly used for differentiation, we take a series of polinomials where n !=0. n is not only different than zero, most importantly, it is a constant. Power Rule : d/dx x^n = n.x^(n-1) for n != 0 indeed. so for n=1 (which _is_ different of 0 !) d/dx X = 1.x^0 for _all_ x. including x=0. (last I check f(x) = x is differentiable in 0. I know math can be challenging... but you don't get to invent restriction on the Power Rule just to fit you argument. I will put it in simple terms. You are saying that you can't calculate the slope of the equation: y =a*x + b because in the process you need to calculate the value of x^0. In the case of the set theory book, do note that the author is constructing his own algebra, The fact that you call 'Nicola Bourbaki' 'the author', is in itself very telling about your expertise in Math. I nicely put a link to the wikipedia page, since laymen are indeed unlikely to know 'who' Borbaki is. Do I really care if the name of the author is fictitious or real? that get outside his set: 0^0 and x/0 are such cases. The text is not a demonstration, it is simply a statement taken out of context. You ask for a practical spreadsheet example, when one is given you invent new 'rules' to ignore' it. You haven't provided so far that practical spreadsheet. You claim that 'real mathematician' consider 0^0=... NaN ? Error ? And when I gave you the page and line from one of the most rigorous mathematical body of work of the 20th century (yep Bourbaki... look it up) you and hand-wave, pretending the author did not mean it.. or even better if this author(sic) *is* using mathematics correctly. The thing is that you are taking statements out of context. I don't claim being a mathematithian. I took a few courses from the career for fun. In the case of set theory you can define, for your own purposes, a special algebra where: - You redefine your own multiplication operator (x). - You don't define division. - You make yor algebra system fit into a set of properties that is useful for your own properties. Once you define your own multiplication (which is not the same multiplication supported in a spreadsheet) You work around the issue in the power operator by defining the undefined case. These are all nice mathematical models that don't apply to a spreadsheet. I guess looking hard it may be possible to find an elaborated case where someone manages to shoot himself in the foot Sure, Leonard Euler, who introduced 0^0 = 1 circa 1740, was notorious for shooting himself in the foot when doing math... For those interested in the actual Math... in Math words have meaning and that meaning have often context. let me develop a bit the notion of 'form' mentioned earlier: for instance in the expression 'in an indeterminate form', there is 'form' and it matter because in the context of determining extension by continuity of a function, there are certain case where you can transform you equation into another 'form' but if these transformation lead you to an 'indeterminate form
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Joe Schaefer FWIW I refreshed my memory about how to compute polynomials numerically by looking back at my old copy of Numerical Recipes in C and it's always considered bad form to evaluate the terms individually, especially not by using the POWER function to do it. Most of the time you want to compute p = c[0] x^0 + ... + c[n] x^n by doing p = c[j=n]; while (j 0) p = p*x + c[--j]; which does the right thing and pulls out c[0] when x=0. Obviously there are overflow issues to deal with for large degree polynomials and large values of x, but you get the idea. Ah yes, that's an old numerical trick when n is an integer. The non-integer case is, of course, more interesting ;). What I was noting in a previous reply (to Norbert) is that you actually never even write x^0, you just write: p = c[0] + c[1] x^1 + ... + c[n] x^n so when calculating the derivative (using the power rule) you completely ignore the first term as it's a waste of time (the derivate of a constant is 0). It somewhat silly (and a waste of time) to write POWER($A1, 0) in a spreadsheet where 0 ^ 0 is 1. My HP Calculator does have a valid reason for setting 0 ^ 0 =1, but it doesn't apply to a spreadsheet so I will leave at that :-P. Pedro.
Re: Calc behavior: result of 0 ^ 0
- Messaggio originale - Da: Andrew Douglas Pitonyak ... 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. It is sort of sad as I think Calc can certainly be improved with a lot of the things that are finely implemented in Boost. On the other hand, most of what I was planning to do is already in gnumeric, so maybe it was a waste of my time to re-implement it ;). Pedro.
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.
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: 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
- 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: 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: 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: 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: 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: Proposal: How we should handle committer vetos and reverts in the future
- Messaggio originale - Da: Rob Weir On Thu, Feb 14, 2013 at 8:49 PM, Pedro Giffuni p...@apache.org wrote: - 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. We had already had the longest thread in this project's history before your patch received two vetoes. You can not say that it was not discussed. I do think the size of the flamefest has no correspondence with the scope of the original patch. Few real argumentation was given and I asked for more time to evaluate the impact of the change, which I still retain was very small. And remember, a veto is a power of an individual committer. It is not a collective right. We vote in committers because we think they will use this power carefully. We also vote in committers because we think that they will handle things properly if their changes are also vetoed. We trust our committers to do these things. 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. That is not for you alone to judge. When the police pull you over and ask you to get out of your car, that is not a good time to argue and refuse to do it. You will get your day in court. Similarly, when you get two vetoes, this is not the time to argue. Instead, revert your code, then argue your point. We are talking about a innocuous change that was evaluated in ... 3 days?.Despite the flamefest I think in 3 days too little *real* discussion took place to raise a veto. I said I didn't consider the vetos valid: invalid issues have no weight. I asked who was the natural judge here, I cannot be the judge but certainly it can't be you either. Now we know the judge is the PMC. People have real lifes around things that are not OpenOffice. We also know now that you should have waited around 3 days, specially since this was not an urgent issue. (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 The code you check in, unlike your dish, is not yours. You don't own it. You don't control it. You should not feel insulted. My commits are my responsibility. You found a bug? Sure.. the code is full of them, still that is not a reason why *you* should revert it. Also consider thinking in terms of value: for the project the code I am working on is more valuable than the code you want to revert. Someone did something to code, not to you. You were warned not to revert. You may not feel like you meant it but what you did was deeply insulting. It is not OK. 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. That's not it: proper care has to be taken considering the work flow. You actually did a mess: the log has no information on why the revert was made. The bugzilla issue was not referred to, and you reverted some header changes that you shouldn't. You obviously had no respect for the work being done or the process being followed. I personally cannot work like this: my work (code and time) receives more respect in other projects. As the result of this situation I am reevaluating my role in this project. I currently have no space or motivation.to do real development work. I still deeply care: This project is important and I see there is a group of awesome people doing
Re: Proposal: How we should handle committer vetos and reverts in the future
Thank you Herbert !! I certainly have to share that it has been a huge pleasure to work with you. The work that you and Armin and (Andre and Juergen too), is absolutely awesome. Rest assured that people like you keep me around this project. I am not leaving, I am just refocusing my priorities and there are so many good things happening around that I can save myself some trouble and spend time much more productively than considering the value of 0^0 :). cheers, Pedro. - Messaggio originale - Da: Herbert Dürr h...@apache.org A: dev@openoffice.apache.org Cc: Inviato: Venerdì 15 Febbraio 2013 11:26 Oggetto: Re: Proposal: How we should handle committer vetos and reverts in the future Hi Pedro, I personally cannot work like this: my work (code and time) receives more respect in other projects. I understand your frustration. Please be assured that you and your work are most highly respected. You have done so much for the project and helped to improve its quality very considerably in a lot of areas, also in areas that were otherwise regrettably neglected. As the result of this situation I am reevaluating my role in this project. I currently have no space or motivation.to do real development work. I still deeply care: This project is important and I see there is a group of awesome people doing a great job. I still can and will help: I intend to do important updates and platform fixes but I will likely be taking a more passive role from now on. Please reconsider and don't give up. The project is so extensive and you made and can make a difference for an influential product used by many many people. There is lots of room for enjoyable development work and fruitful cooperation. Herbert
Re: oracle java7 build bug
Hello Fred; This doesn't seem related to the jdk7 issue, I think someone else reported the same glib issue in Ubuntu. FWIW, in FreeBSD we have AOO building with jdk7 too. http://www.freebsd.org/cgi/cvsweb.cgi/ports/editors/openoffice-3-devel/files/ We even carry a patch for issue 121098 Cheers, Pedro. - Messaggio originale - Da: Fred Ollinger folli...@gmail.com A: dev@openoffice.apache.org Cc: Inviato: Venerdì 15 Febbraio 2013 13:49 Oggetto: oracle java7 build bug T his is using the patch that I had created last week which gets us past the hsqldb java7 compile errors: Entering /mnt/lfs/sources/ubuntu/local_dev300/vcl/prj cd .. make -s -r -j1 make: *** No rule to make target `/usr/include/glib-2.0/glib/gcache.h', needed by `/mnt/lfs/sources/ubuntu/local_dev300/solver/300/unxlngi6.pro/workdir/CxxObject/vcl/unx/gtk/a11y/atkaction.o'. Stop. dmake: Error code 2, while making 'all' 1 module(s): vcl need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /mnt/lfs/sources/ubuntu/local_dev300/vcl/prj Attention: if you fix the errors in above module(s) you may prolongue your the build issuing command: build --all:vcl I'm on ubuntu 11.04. Fred
Re: Proposal: How we should handle committer vetos and reverts in the future
- Messaggio originale - Da: Rob Weir ... thanks for putting some sense into this discussion. I totally agree with your point of view. and please remember accepting backwards compatibility as a technical argument is real killer which can be used to 99℅ of all commits. So Then I guess we're all darn fortunate that no one has used a backwards compatibility argument to veto 99% of all commits. IMO, breaking *functionality* may be a valid technical reason to revert a commit (it really depends on a case by case basis). Breaking backwards compatibility is a fact of real life that we can try hard to avoid but may just be necessary. All software packages of reasonable size tend to have a section for those changes nowadays. If the value 0^0 is considered functionality is a completely different issue. starting a discussion makes sense whena committer has concern, but using a veto based on backwards compatibility to revert is pure anarchy. I am in strong agreement. Committing small non-invasive changes for wider testing (CTR) is still a good thing, and a veto is not a valid instrument to prohibit the community from evaluating such changes. Changes can be proposed by anyone but only a committer can make proposals true. That why committers must be respected when they spending their spare time in the project.. Pedro.
