Re: Build System Improvements
Hi Dennis, please see my comments to your two mails inline. On 20.10.2014 19:23, Dennis E. Hamilton wrote: Concerning refactoring the build of AOO, I wonder about Cygwin alternatives. Msys2 may be superior with regard to being friendly to the Windows environment: http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/. As far as I know cygwin is primarily used to provide a Unix like shell environment with commands like ls, cp, sed, awk, etc. We are not using to compiling source code. So, in a sense, being Windows friendly is not the primary goal :-) But you are still making a valid point. At the moment we are forcing all platforms to use e.g. the cp command for copying files to reduce the complexity of the build scripts (and possibly because the authors could not be bothered to use the Windows platform). Using native commands might lead to shorter build times. I was led to this today when looking into this project: https://github.com/leanprover/lean. That's much simpler than building AOO. The clean instructions and the easy handling of multiple platforms (and being good for x64 Windows) strikes me as an excellent example. Having so little friction in beginner AOO builds seems very desirable. Making the build easier is one of my goals but I am afraid that at the moment the initial configuration is the most complicated step. And I don't want to touch that right now. I'd wager that the VC++ 2013 compiler could be used more easily There also. - Dennis Speaking of refactoring, there may be some inspiration in this report on a benchmark Windows product being taken multi-platform, multi-device: http://winsupersite.com/office/how-microsoft-taking-office-cross-platform. -Original Message- From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] Sent: Friday, October 17, 2014 08:22 To: dev@openoffice.apache.org Subject: RE: Build System Improvements orcnote inline below. -Original Message- From: Andre Fischer [mailto:awf@gmail.com] Sent: Friday, October 17, 2014 04:39 To: dev@openoffice.apache.org Subject: Re: Build System Improvements On 17.10.2014 13:21, Regina Henschel wrote: Hi Andre, will these in the long term lead to a system, where AOO can be build directly in MS Visual Studio without need of cygwin? Hi Regina, this is not a direct goal but could become possible as a side effect. One of the key ideas of the proposed approach is to further separate between dependencies and build logic and have scripts/programs transform the dependencies into actual make files. Once the dependencies are present as uniform XML files we can more easily write a transformation into Visual Studio solution files. But this will still not be a trivial task. It would help me if you or somebody else could provide a description or even a specification of Visual Studio solution/project files. orcnote I don't think you need to go all the way to solution files in order To compile native (win32 and x64) for Windows using Visual Studio, even Visual Studio 2013 Express for the Desktop. One can have makefile- controlled builds and command-line compiles just fine. Well, yes. But we already have command line based builds which work quite well. The big advantage of using of environments like Visual Studio or Eclipse is that writing/editing code becomes easier. I guess that for that we need the solution files. Developers might want to create makefile solution files, but they should not be needed in the source tree. (It might also be valuable to understand MSBuild, which is XML-based already, and that might be a That is interesting. I was not aware of MSBuild before. I will look into it. -Andre better alternative to constructing solution files. Finally, one reason to make a solution file is to use VS 2013 GIT repository integration, but that only works if pull requests become supported and cloning is to places where pulls can reach.) I think an interesting aspect of Andre's proposal is that one could Take advantage of linking and DLL creation more, not requiring full builds so much so long as there are unchanged static libraries and DLLs. This kind of refactoring might also be important for configurations on limited platforms. The idea is to build and test AOO by component layers. That might make working with GIT more practical as well. (I don't mean releasing separate components, but being able to build up dependencies in stages, even the first time as a way to start working with a fresh clone/checkout of the source tree. Of course, building smaller, specialized distros might be more-easily come by.) /orcnote -Andre Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev
Re: Build System Improvements
Am 17.10.2014 19:33, schrieb Kay Schenk: On Fri, Oct 17, 2014 at 12:32 AM, Andre Fischer awf@gmail.com wrote: As you may know, in the past years I have made a couple of experiments regarding the build system of AOO. With the resulting experience I would now like to start to work on improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. I would like to start with some under-the-hood changes to how the build process is controlled. At the moment we have prj/build.lst files that control how build.pl builds the dmake modules. Then there are makefiles.mk in directories of dmake modules and finally we have makefiles in gbuild modules. All of them are not makefiles in the classical sense, i.e. they seldomly contain directives of how to build a target. They are data files that primarily define dependencies between targets or, for example, which object files go into a shared library. They use three different, mostly unspecified and undocumented, notations. The first work item would be the conversion of these files into a unified XML syntax. At first these XML files would be converted back to the old syntax on-demand and on-the-fly so that the old build tool chain can still be used. Q: Could a build change like this just be used for SOME modules without having to convert back? The conversion back to the existing build.lst, dmake or gbuild files is just a migration step. The goal is to replace all these with a unified build system. But that second step is much harder than the first. Subsequent steps would then improve or replace parts of this tool chain. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. Best regards, Andre This sounds interesting and I can't wait to see what happens next! Is this Ant-like? Or can be used by Ant...which we use already for some things? The format will borrow some ideas from ant but should be a lot simpler. It is intended to be read by transformation scripts and I certainly don't want to write an parser for Ant files :-) -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build System Improvements
Am 18.10.2014 11:56, schrieb Andrea Pescetti: On 17/10/2014 Andre Fischer wrote: improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. This seems a reasonable approach. But this is the n-th time that someone proposes a new build system. I am aware of that and understand that you are sceptical. For that very reason I propose a first step that just introduces a different notation for our makefiles without (big) changes to the underlying build system. The next step of actually replacing parts of the build system with something better is certainly much harder and less likely to succeed. Can I ask at least if there is anything (in terms of knowledge, if not of code) that came out of https://wiki.openoffice.org/wiki/Build_System_Analysis:capstone2013_windows_build that can be reused here? The aim of that project was not reached, but still the analysis and discussion might be worth reviewing (probably you already did). And maybe there is some knowledge from that project that hasn't been documented yet. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. This is very good; had it come one month ago, we could have submitted it as a Capstone project for 2014 so that you would get a small team of students to mentor for a few months. But there might be other opportunities if you believe that new developers can work on this task without an excessive strain on you as a mentor. I do. But I need a week or two to set this all up. Regards, Andre Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Build System Improvements
As you may know, in the past years I have made a couple of experiments regarding the build system of AOO. With the resulting experience I would now like to start to work on improving the build system. I have in mind a soft conversion that gradually replaces parts of the existing build system, not a big push that takes years to complete and then breaks everything. I would like to start with some under-the-hood changes to how the build process is controlled. At the moment we have prj/build.lst files that control how build.pl builds the dmake modules. Then there are makefiles.mk in directories of dmake modules and finally we have makefiles in gbuild modules. All of them are not makefiles in the classical sense, i.e. they seldomly contain directives of how to build a target. They are data files that primarily define dependencies between targets or, for example, which object files go into a shared library. They use three different, mostly unspecified and undocumented, notations. The first work item would be the conversion of these files into a unified XML syntax. At first these XML files would be converted back to the old syntax on-demand and on-the-fly so that the old build tool chain can still be used. Subsequent steps would then improve or replace parts of this tool chain. If you don't object to this general plan then I would start the XML conversion with the prj/build.lst files as proof of concept. I would also start to write Wiki pages that explain in more detail how the current build process works, what its draw backs are, and how, in my opinion, it can be improved. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build System Improvements
On 17.10.2014 13:21, Regina Henschel wrote: Hi Andre, will these in the long term lead to a system, where AOO can be build directly in MS Visual Studio without need of cygwin? Hi Regina, this is not a direct goal but could become possible as a side effect. One of the key ideas of the proposed approach is to further separate between dependencies and build logic and have scripts/programs transform the dependencies into actual make files. Once the dependencies are present as uniform XML files we can more easily write a transformation into Visual Studio solution files. But this will still not be a trivial task. It would help me if you or somebody else could provide a description or even a specification of Visual Studio solution/project files. -Andre Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [discussion] how to stop mails being sent to multiple lists.
On 14.08.2014 14:02, jan i wrote: hi. Have you also noticed that the amount of AOO mails have exploded latelysounds good you think lots of activity SADLY the truth is different, we have a fair amoun of real mails, but something like 8 of 10 are sent to multiple ML. Can you give an example? It is unwise to send the same mail to multiple lists, for a couple of reasons: - the discussion becomes scattered over multiple ML - you force your fellow community members to read the same mail several times - you waste our bandwith If most mails are copied to most MLthen why do we have so many ML, one solution could be to only have dev@ and let the others be an alias (absolutely not one I prefer). How can we stop this tendency to blow up our inboxes ? rgds jan I - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
On 11.08.2014 20:25, jan i wrote: On 11 August 2014 20:12, Peter Kelly kelly...@gmail.com wrote: On 11 Aug 2014, at 3:42 pm, Andre Fischer awf@gmail.com wrote: Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but grown because of convenience or laziness. So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad). Maybe we need an experiment to see what is possible? I'll have a look into the code to understand the architecture better and then hopefully be able to contribute some more informed thoughts about it. From what you've described, it sounds like there is a dependence from the OO codebase to VCL, is that correct? If my initial understanding it is correct, it sounds like it would be possible to port this to iOS/Android with sufficient effort, though I think that writing a from-scratch UI would be needed, as you suggested. That is, largely to address the much smaller screen real estate and touch controls, and the types of UI layouts that are common on phones/tablets. The fact that OO can run in headless mode sounds promising, since the ability to access much of the functionality without any UI implies that a totally different UI could be put in place on top of this. I just wonder if the effort pays off. AOO contains tons of very good ideas (proven over time) but equally old code. Juergen have multiple times argued that it might be more efficient, to pick the ideas and write new code with modern tools, i tend to agree to that. Please remember AOO is a good mixture of C/C++/Java/Python/Perl (I might have missed something), whereas a new codebase would be simpler. We might be able to avoid the big bang, by using AOO in headless mode and change to new code part by part. But I agree with andre that an experiment, just moving a little part would be a nice proof. Please don't get me wrong. I did not mean to advocate porting the existing code base to iOS or Android. Only that if one where to try it, then start with an experiment to avoid nasty surprises at a later stage. If we would want to go towards mobile I would prefer a rewrite. We could certainly salvage one or the other idea but I believe that we should focus more on the mistakes that where made and try to avoid them. Remember, AOO is based on a design that was made 15 to 20 years ago. A lot of bug fixes where made and a lot of features added in the meantime. But many limitations (like VCL providing rendering of UI controls, behavior of them, event loop and some other things, or SFX2 with its slots, items and view shells) still exist. Therefore I would start fresh with a limited feature set but with a better design than before. -Andre just my 2ct. rgds jan I. -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: About debugging tokenizer of writerfilter
On 09.08.2014 03:10, Hung Mark wrote: Hi, I tried to understand why my document doesn't format correctly. I followed steps on wiki : https://wiki.openoffice.org/wiki/WriterFilter ./uno -l libwriterfilter.so -c debugservices.ooxml.ScannerTestService -- file:///home/mark/num.docx error: libwriterfilter.so: cannot get factory of demanded implementation: debugservices.ooxml.ScannerTestService dying... ./uno -l libwriterfilter.so -c debugservices.doctok.ScannerTestService -- file:///home/mark/num.doc error: libwriterfilter.so: cannot get factory of demanded implementation: debugservices.doctok.ScannerTestService dying... Is the document outdated or did I miss anything? Yes to the first part of your question, maybe to the second :-) The wiki page describes a state during the development of the OOXML writer filter. I am not sure that it was updated to keep track with development. I was not directly involved in it so I can not give you any details. But I did look into it a couple of months ago to asses whether to build on it for a better OOXML support or whether to rewrite it. There are some interesting ideas in it but not all where realized and some don't work anymore. Maybe the dumping of tokens is a case of not working anymore. Some info that might help you: The source of the ooxml/ScannerTestService can found in main/writerfilter/unocomponent/debugservices/ooxml/OOXMLTestService.cxx There are some #ifdefs that depend on a DEBUG_ELEMENT environment variable. I don't know if that is important but I also don't see a place where it is ever defined. You might run the uno command in you debugger and place a breakpoint in ScannerTestService::run(). If you don't reach it then your problem is located in the UNO framework, otherwise it is in the OOXML scanner itself. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Why is it so hard to make a Java program appear native?
On 11.08.2014 09:59, Peter Kelly wrote: An interesting discussion I came across today: http://arstechnica.com/information-technology/2014/08/why-is-it-so-hard-to-make-a-java-program-appear-native/ I know that the answer to this is not really important, but just in case. This gives you not 100% native rendering but maybe 80%: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); (and yes I realise OO doesn't use Java for it's UI, but the points raised apply to all cross-platform UI toolkits). Question: To what extent is the OO UI frontend code separate from the backend editing, file format handling, and rendering code? I'm thinking in particular here of mobile - which demands a completely different approach to user experience design than desktop. Could OO conceivably be adapted to mobile by replacing its UI? Conceivably? Probably. But the problem is in the details. AOO has put a lot of effort into separating UI from model and from underlying frameworks. For example you can use the UNO API to access a lot of functionality without bothering with the UI. You can run AOO headless (without any UI), and you can run AOO on several different GUI frameworks (Windows, Mac OSX, Linux with a mixture of X11 and Gnome/KDE). The problem is that there are dependencies between UI and model or framework. Most of them not designed but grown because of convenience or laziness. So, if you wanted to port AOO to another window system with basically the same UI as today you would probably port VCL (the UI abstraction layer of AOO). That would involve a lot of cursing but it is doable (it has been done for OSX). For a mobile device you probably don't want the same UI but something that can be operated with larger input devices then the typical mouse pointer (i.e. fingers). One way to do that would be to write the GUI from scratch and use the UNO API as a backend. I am not sure that that is possible though. If you drop VCL, you don't have SFX2 with its view shells (a mix of view and controller) or slots (a mix of remote procedure calls and value passing). That means that a) a lot of functionality has to be rewritten (not necessarily a bad thing when you consider the quality of the existing implementation) and b) that that might break the UNO API (which would be bad). Maybe we need an experiment to see what is possible? Regards, Andre -- Dr. Peter M. Kelly Founder, UX Productivity pe...@uxproductivity.com mailto:pe...@uxproductivity.com http://www.uxproductivity.com/ http://www.kellypmk.net/ PGP key: http://www.kellypmk.net/pgp-key (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Impress 4.1.0 unable to display earlier .odp files
On 21.07.2014 11:30, Rory O'Farrell wrote: On Mon, 21 Jul 2014 09:55:34 +0100 Rory O'Farrell ofarr...@iol.ie wrote: On Mon, 21 Jul 2014 09:31:45 +0100 Rory O'Farrell ofarr...@iol.ie wrote: On Sun, 20 Jul 2014 21:53:17 +0200 Andrea Pescetti pesce...@apache.org wrote: Rory O'Farrell wrote: I have tried with Impress 4.1.0 to open and display as Slide Shows some existing .odp files made and displayed with OO 3.4 (and earlier). Tomorrow I'll find a sample file to upload to Bugzilla; pending that, I thought I'd give advance warning of such instability, so that others can check out some of their existing presentations. If this is confirmed should we consider it as a showstopper? It will help to know in detail what's going wrong (are the file not displayed at all? not even opened correctly?), but if we have a regression opening old .odp files this would for sure qualify for a release blocker candidate and need investigation (and hopefully fix) before 4.1.1. On the other hand, I opened many .odp files that I had created with earlier OpenOffice versions in 4.1.0 and I didn't notice regressions. Regards, Andrea. I think I have tracked this down! (Famous last words??!!) The crash on Slide Show seems to be caused by use of Fade smoothly or Fade through black transitions between slides. Substitution of some other transitions (note - a random small selection, not extensive testing of all transitions) to replace the Fade/Fade Down transitions made the presentation stable. Could some others please test if the Fade transitions cause such instability. I have a small presentation of eleven sides (700KB) which I was preparing for a project (stillborn), which I use as a test. I'll willingly share this with anyone who is interested. I failed to reproduce this crash on an Ubuntu 14.4 (vanilla, no X or K) machine. Therefore I would like to ask you for (all or some) of the following: - the 700 KB document you mentioned above, either per personal mail or as attachment in a bug - a Bugzilla bug description - more information, like - do you use more than one display? - is the presenter screen enabled? - your graphics hardware (probably not important; don't open your computer when you don't know :-) - does it crash when the slide effect starts or ends? - does your console show a stack trace of the crash? Regards, Andre -- Rory O'Farrell ofarr...@iol.ie Also, under OO 4.1 on Xubuntu 14.04, application of Fade Smoothly or Fade to Black transitions to a presentation under construction immediately caused a crash. I've been doing a little more testing. I find the following transitions cause an immediate crash on application to a presentation under construction: Fade Smoothly Fade to Black Flipping Tiles Outside turning cube Fall Turn around Iris Turn down Rochade In general, I only tested one of each group of transitions. I assumed if (e.g.) Wipe Down worked, then probably all the other Wipe directions would be stable also. (OO 4.1 on Xubuntu 14.04) Other than Fade Smoothly, I cannot comment on stability when they are used in a Slide Show of an existing presentation. My expectation would be that such slide show might immediately crash. as happens when Fade Smoothly is used in an existing presentation. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Impress 4.1.0 unable to display earlier .odp files
On 21.07.2014 13:49, Rory O'Farrell wrote: On Mon, 21 Jul 2014 13:34:45 +0200 Andre Fischer awf@gmail.com wrote: On 21.07.2014 11:30, Rory O'Farrell wrote: On Mon, 21 Jul 2014 09:55:34 +0100 Rory O'Farrell ofarr...@iol.ie wrote: On Mon, 21 Jul 2014 09:31:45 +0100 Rory O'Farrell ofarr...@iol.ie wrote: On Sun, 20 Jul 2014 21:53:17 +0200 Andrea Pescetti pesce...@apache.org wrote: Rory O'Farrell wrote: I have tried with Impress 4.1.0 to open and display as Slide Shows some existing .odp files made and displayed with OO 3.4 (and earlier). Tomorrow I'll find a sample file to upload to Bugzilla; pending that, I thought I'd give advance warning of such instability, so that others can check out some of their existing presentations. If this is confirmed should we consider it as a showstopper? It will help to know in detail what's going wrong (are the file not displayed at all? not even opened correctly?), but if we have a regression opening old .odp files this would for sure qualify for a release blocker candidate and need investigation (and hopefully fix) before 4.1.1. On the other hand, I opened many .odp files that I had created with earlier OpenOffice versions in 4.1.0 and I didn't notice regressions. Regards, Andrea. I think I have tracked this down! (Famous last words??!!) The crash on Slide Show seems to be caused by use of Fade smoothly or Fade through black transitions between slides. Substitution of some other transitions (note - a random small selection, not extensive testing of all transitions) to replace the Fade/Fade Down transitions made the presentation stable. Could some others please test if the Fade transitions cause such instability. I have a small presentation of eleven sides (700KB) which I was preparing for a project (stillborn), which I use as a test. I'll willingly share this with anyone who is interested. I failed to reproduce this crash on an Ubuntu 14.4 (vanilla, no X or K) machine. Therefore I would like to ask you for (all or some) of the following: - the 700 KB document you mentioned above, either per personal mail or as attachment in a bug - a Bugzilla bug description - more information, like - do you use more than one display? - is the presenter screen enabled? - your graphics hardware (probably not important; don't open your computer when you don't know :-) - does it crash when the slide effect starts or ends? - does your console show a stack trace of the crash? Regards, Andre The machine on which I was testing is a two screen machine and Presenter screen was enabled. The crashes were immediate on slide effect being applied. I'll send you the 700KB document and stack trace in about five hours, with details of graphics hardware (from memory Nvidia GT7900, but I'll check details later). If desirable, I can substitute an ATI graphics card - I can do hardware! Thank you. The crash takes place when the effect is being applied when the slide transition is selected in the Slide Transition pane? If so, can you uncheck the Automatic preview box in that pane? -Andre -- Rory O'Farrell ofarr...@iol.ie Also, under OO 4.1 on Xubuntu 14.04, application of Fade Smoothly or Fade to Black transitions to a presentation under construction immediately caused a crash. I've been doing a little more testing. I find the following transitions cause an immediate crash on application to a presentation under construction: Fade Smoothly Fade to Black Flipping Tiles Outside turning cube Fall Turn around Iris Turn down Rochade In general, I only tested one of each group of transitions. I assumed if (e.g.) Wipe Down worked, then probably all the other Wipe directions would be stable also. (OO 4.1 on Xubuntu 14.04) Other than Fade Smoothly, I cannot comment on stability when they are used in a Slide Show of an existing presentation. My expectation would be that such slide show might immediately crash. as happens when Fade Smoothly is used in an existing presentation. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Impress 4.1.0 unable to display earlier .odp files
On 21.07.2014 14:45, Rory O'Farrell wrote: On Mon, 21 Jul 2014 13:59:29 +0200 Andre Fischer awf@gmail.com wrote: On 21.07.2014 13:49, Rory O'Farrell wrote: On Mon, 21 Jul 2014 13:34:45 +0200 Andre Fischer awf@gmail.com wrote: On 21.07.2014 11:30, Rory O'Farrell wrote: On Mon, 21 Jul 2014 09:55:34 +0100 Rory O'Farrell ofarr...@iol.ie wrote: Fade Smoothly Fade to Black Flipping Tiles Outside turning cube Fall Turn around Iris Turn down Rochade Most of these transitions are provided by the OGLTrans code in the slideshow/ module. It is based on a GSOC 2007 project and, to my knowledge, still regarded experimental. This would fit nicely with your observation that the crash goes away after using a different graphics driver. However, Fade Smoothly and Fade to Black are not part of OGLTrans. Therefore a faulty OpenGL driver seems not to be the (only) reason for the crash. At the moment I have no access to a computer with NVidia graphics card, so I am not sure that I will be able to find the root cause. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build error - helpcontent2
On 09.07.2014 12:12, Michal Hriň wrote: Dňa 08.07.2014 23:02, Kay Schenk wrote / napísal(a): On 07/08/2014 11:27 AM, Michal Hriň wrote: Hi, I am going through Building guide - Step by step, and I have some problem with building helpcontent2. I am on Ubuntu 12.04 and I have JDK 6 and 7 installed from distribution repository and I am trying to build 4.1.0 release. [...] /home/majkl/aoo-4.1.0/main/helpcontent2/unxlngx6.pro/bin/xhp_sdatabase_en-US.zip/home/majkl/aoo-4.1.0/main/helpcontent2/source/auxiliary/en-US/sdatabase.cfgtime taken was 2.886 seconds /usr/bin/java -cp .:../../unxlngx6.pro/class:/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/rt.jar:.:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/jaxp.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/juh.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/parser.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/xt.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/unoil.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/ridl.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/jurt.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/xmlsearch.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/LuceneHelpWrapper.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/HelpIndexerTool.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/lucene-core-2.9.4-dev.jar:/home/majkl/aoo-4.1.0/main/solver/410/unxlngx6.pro/bin/lucene-analyzers-2.9.4-dev.jar com.sun.star.help.HelpIndexerTool -lang en-US -mod sdatabase -zipdir ../../unxlngx6.pro/misc/ziptmpsdatabase_en-US -o ../../unxlngx6.pro/bin/sdatabase_en-US.zip.unxlngx6.pro Exception in thread main java.lang.UnsupportedClassVersionError: com/sun/star/help/HelpIndexerTool : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:643) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:323) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) Could not find the main class: com.sun.star.help.HelpIndexerTool. Program will exit. dmake: Error code 1, while making '../../unxlngx6.pro/bin/sdatabase_en-US.zip' 1 module(s): helpcontent2 need(s) to be rebuilt Reason(s): ERROR: error 65280 occurred while making /home/majkl/aoo-4.1.0/main/helpcontent2/util/sdatabase Ideas? Thanks! After forcing Java to v. 7, build was sucessful. I wonder why configure script recognized Java 6 when both was installed. Maybe I have ghost in the machine. From this output, it looks like your java version for this build was java 6. I think we're using 7 as the default for the builds but I'm not positive this is causing your problem. However, you might try it and explicitly declare it as part of your config options. --with-java --with-jdk-home=(path to your java 7 version) Is somewhere in the universe complete list of these build parameters ? Can you point me there ? Configure itself provides the list: main/configure --help -Andre My java version is java version 1.7.0_51 (openJDK) and I did not experience any problems with the build I did yesterday at this section. Unfortunately, we don't seem to have source for HelpIndexerTool (just the class files) so it's difficult to tell what's going on exactly. Regards, Michal Hriň - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: News about the new OOXML framework.
Another update of my progress. I can now create a validating parser, i.e. one that checks that a document conforms to the specs while it parses its content. At the moment the validation is restricted to complex types (as opposed to simple types and attributes) but I think that is the hardest part. One NFA (non-deterministic finite automaton) is created for each complex type and one for the top level elements. The NFAs are then converted into equivalent DFAs (deterministic FAs) and finally minimized (via the Hopcroft algorithm). The minimization step became necessary when I added support for the 'all' schema element which states that its children each occur once in arbitrary order. Recognizing this with an FA leads to enumerate all permutations of the children. With n children there are n! permutations. Luckily the 'all' element is used only once and then only for 7 children (7! = 5040). Here are some numbers: The 1st and 4th edition of the ECMA-376 specification (1st edition is what is used by MS Office, 4th edition is equivalent to the ISO standard) have 40 schema files. These contain 1917 complex types and 781 simple types. Used are 1851 complex types and 727 simple types (have to check if there are really unused complex types or if my optimization is broken). The non-validating parser has 1853 states and 6987 transitions. The validating parser has 129530 states and 43512 transitions after creating the NFAs. After conversion to DFAs there remain 20999 states and 73772 transitions. After minimization there are 6097 states and 34286 transitions. Please note that the time for parsing OOXML documents does not depend on the number of states or transitions. It only depends on the length of the input. The number of states and transitions only make the parser bigger. Progress and commits are tracked in issue 125035. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
News about the new OOXML framework.
I would like to give a short status update about the new OOXML framework. - Created the new module main/ooxml There are not yet any makefiles that build the contents of the ooxml/ module nor link it into the build process of OpenOffice. However, you can use e.g. Eclipse to import the Java projects that are described below. - Moved the old Office Open XML wiki pages out of the way and create two new ones: = OfficeOpenXML contains an introduction into the OOXML file format, a status overview of the implementation progress and links to more detailed information. = OOXML and ooxml (uppercase/lowercase) redirect to OfficeOpenXML so that there is no excuse to not find this page. = OOXML Framework contains more detailed information about the new framework. - Created a new Java project at ooxml/main/source/framework/SchemaParser that parses the XML schema files that come with the ECMA-376 specification files. Its purpose is to read the schema files and create a skeleton OOXML parser from it. This skeleton can then be filled in with code for importing certain elements of OOXML documents. - Created a new Java project at ooxml/main/source/framework/JavaOOXMLParser. Its purpose is testing and debugging of and experimenting with the schema parser. It is not intended to become a runtime component of OpenOffice. The SchemaParser is able to parse all files of the ECMA-376 specification both in the old (1st edition of 2006) and new (4th edition of 2012) versions. It looks like we need both since the new one is the current standard (equivalent to the ISO standard) while the old on is actually used. Not all details of the schema files are handled yet. The JavaOOXMLParser, based on parser tables created by the SchemaParser, is already able to parse the large DOCX file of the 1st edition specification. When pretty printed it is about 90 MB large. It takes the parser about 90 s to read it. Note that the parser is not optimized in any way (if it where then it would be optimized for readability, not for speed) and that it writes about 650 MB of log files in the process. If anyone would like to play with the parsers, I will gladly provide more details. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: refererence for dmake?
On 23.05.2014 00:05, Kay Schenk wrote: Does someone have a link to an actual reference guide for dmake? I found one at one time but now, not so easy, and I didn't save it. :( Thanks. Strangely enough, OpenOffice.org seems to be the best source of information regarding dmake: http://www.openoffice.org/tools/dmake/ There the dmake man pages are listed up to version 4.11 -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] New OOXML import framework
On 20.05.2014 23:38, Andrea Pescetti wrote: On 19/05/2014 Andre Fischer wrote: As one of the first tasks in the OOXML area I would like to propose to redesign and re-implement the OOXML parser. I can only agree with this one. We've already discussed it many times, but even the many users who prefer ODF need a good support for OOXML for interoperability, and better support for the Microsoft Office native formats is consistently in the top requests. I propose a new and unified approach that will essentially replace the current design and implementation. Sounds good. Especially the idea to be able to automatically know how much of the specification is covered will be helpful. I also propose to focus first on Impress. Its complexity regarding OOXML is less than that of Writer and Calc And this is probably good for users too. In my experience, the import of .PPTX files is the most unsatisfactory one at the moment, with many obvious deficiencies. Improving this one first would already give good results for users. I have made several experiments regarding the reading of the specification and generation of parsers and am confident that the outlined approach will work. A not-so-original question: we have another Apache project, POI, http://poi.apache.org/ that among the other things has an OOXML parser. If we are starting from scratch, why not reusing their code? And, if there are reasons for not reusing it, could we validate this roadmap with the POI developers, who are probably more familiar with OOXML parsing than the average reader of this list? First, we are not really starting from scratch. There are several components to importing OOXML files. Two important ones are the parser that reads (OO)XML streams and turns them into events for start tags, end tags, text, etc. The second part are the callbacks that are called for each of these events. This second part is the larger and more important part. I want to replace the parser but would like to migrate as much as possible of the second part callbacks as possible. Most of the work in the OOXML import/export project, however, will be spent in other areas: - Implementing features that exist in MS Office but not in OpenOffice. Examples are SmartArt shapes (for all applications). - Improve features in OpenOffice that are not working as well as they should/could. Examples are pivot tables in Calc or the slide show in Impress. - Support existing features in OpenOffice that are just not handled by the OOXML importer. Regarding POI, there are several reasons not to use it: - As said above, the existing import code is to be migrated to the new framework. The new framework should offer an interface that supports this migration. - POI is implemented in Java. - As far as I understand POI (I don't find its documentation very helpful) is more like a DOM tree with better access to its nodes then a streaming parser. That would result in lower execution speed and larger memory consumption. - OOXML / MS Office is supported up to 2007. That seems like an undesirable restriction. - The original naming (see http://en.wikipedia.org/wiki/Apache_POI) does not imply professional development of the POI project. Regards, Andre Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PROPOSAL] New OOXML import framework
On 20.05.2014 00:28, Kay Schenk wrote: [top posting for a moment] Thank you for this initial introduction to planning better support for OOXML. The reality is this is necessary, and I would imagine most involved in the project realize this. OK, just a bit more below. On 05/19/2014 06:39 AM, Andre Fischer wrote: The compile time part of the framework is to be implemented in Java to allow an efficient and fast development process. Does this basically mean that we will need to use both Java and C++ for future builds? We already need Java and C++ for builds. This does not change. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [CODE]: proposal to integrate Google test framework as replacement for cppunit
On 16.05.2014 15:41, Jürgen Schmidt wrote: Hi, I am currently investigating in Google's C++ test framework [1] which seems to be quite powerful and a good replacement for cppunit which has not the proper license. My idea is to use gtest as general C++ unit testing framework in our build environment and replace long term all cppunit based tests with new or adapted tests using gtest. A further goal is to use this testing framework for new C++ unit tests and enable these new unit tests by default. Means I plan to introduce a new build requisite and let the user actively disable unit testing on demand (eg. configure ... --disable-unit-tests). I believe it is a good thing to enable these unit test by default and let them disable on demand. We want to get informed if something gets wrong as soon as possible. But we will have different options to complete a build even if an unit tests fails. But more detailed information will come later. For the moment I just want to propose this enhancement (from my pov) and trying to build it on Linux, Mac and Windows. +1 It will be very helpful in upcoming development work. -Andre Juergen [1] https://code.google.com/p/googletest/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PROPOSAL] Focus on OOXML
As you may know, the OOXML support of OpenOffice is not very good. It is also a feature that many of our users are asking for. Therefore I would like to propose that we focus our work on OOXML import and export. OOXML support consists of three parts: the import, the export, and the implementation of features that are missing in OpenOffice. It is a large task and will easily occupy us for two releases or more. It is likely that much of the initial work will not be very visible and will not contribute much to the next release. But I am convinced that it is preferable to start working on this important feature now than on some more obvious UI changes (but there are some smaller features that we can and should still do, like making the UI more flat or replacing the application icons). In a separate proposal I will talk more about the technical aspects of the OOXML support. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PROPOSAL] New OOXML import framework
As one of the first tasks in the OOXML area I would like to propose to redesign and re-implement the OOXML parser. At the moment each application has its own OOXML import design. Those of Impress and Calc are basically classic hand written push parser designs while that of Writer is semi-automatically derived from the WordprocessingML specification. For all three designs there is hardly any documentation and their implementation is hard to understand and hard to maintain. All that means that you have to work hard to obtain a working knowledge about the OOXML parser for one application and then, once you have it, can not transfer it to the other applications. I propose a new and unified approach that will essentially replace the current design and implementation. Using the same framework in all applications has several advantages: - You only have to learn how to use one well documented framework instead of three different and badly documented XML import techniques. - It exploits the information given by the OOXML schema to produce automatically some of the code that has to be hand written today. - It allows automatic analysis of the coverage of the OOXML specification so that we can easily see which parts have already been implemented and which are still missing. - It will be much more easily understandable than the current OOXML import (especially that of Writer). The one big downside is that the new design requires basically a reimplementation of the OOXML import. But to everyone who has seen the current implementation might not see that as a downside at all :-) Development and migration I propose to do the implementation in a new module (possibly called main/ooxml/) with the goal to eventually (i.e. in a couple of releases) replace main/oox/ and other places that contain OOXML import code. It will not be active by default until every one agrees that it is release ready. Of course, there will be switches to easily (but not accidentally) activate it for development builds. I also propose to focus first on Impress. Its complexity regarding OOXML is less than that of Writer and Calc and the still existing expertise in this area of OpenOffice is probably larger than in Writer and definitely larger than in Calc. Development will start with implementation of the new framework that is hinted at above and explained in more detail below. Then the existing Impress import is migrated to the new design by copying and adapting the code. The existing import in main/oox/ remains unchanged. The new framework The design of the new framework is based on exploiting the OOXML specification (plural because there are different versions, migration addendums and MS Office specific extensions). A parser generator reads the specs and creates the actual OOXML parser from that. The generated parser will basically be a (nested) stack automaton where each state corresponds roughly to a complex type as defined by the spec. Transitions from on state to another correspond to start and end tags that move from one complex type to another. The actions that are executed on transitions and which do the actual import work, still have to be provided manually. With an intermediate DSL (domain specific language) that represents the interface between OOXML parser and developer, even this step will become more easy and more robust. The use of an intermediate DSL also allows tweaking of the rules derived from the OOXML specification should the need arise (to e.g. cope with OOXML files that are not 100% conformant to the specs). The compile time part of the framework is to be implemented in Java to allow an efficient and fast development process. The runtime part of the framework, including the generated parser will be implemented in C++ and be an integral part of OpenOffice. Details At the moment we are using a bare bones XML push parser for reading OOXML files. That means that as the XML parser reads the stream of XML elements it asks the OOXML import code to handle start tags, end tags, and the text in between. It is the task of these callbacks to provide so called contexts for each element. These contexts can then be used to make information like attribute values (which the parser only provides to start tags) accessible to the callbacks of text and end tags. The creation of contexts and persistence of intermediate data is done manually in the existing import code. The new import framework, however, will create it automatically, based on the OOXML specifications and semi automatically based on DSL requests. The automatic part is extracted from the specs and responsible for preprocessing attribute value (e.g. conversion from string to boolean, integer, float/double or enumerations). The semi automatic part is driven by developer supplied information in DSL files and defines the subset of attributes that are really evaluated by the
Re: Need help to understand code moVert.get( XML_horz ) != XML_horz
On 24.04.2014 18:36, Regina Henschel wrote:
Hi all,
in file trunk\main\oox\source\drawingml\textbodyproperties.cxx
there is the part
void TextBodyProperties::pushToPropMap( PropertyMap rPropMap ) const
{
rPropMap.insert( maPropertyMap.begin(), maPropertyMap.end() );
// #160799# fake different vertical text modes by top-bottom
writing mode
if( moVert.get( XML_horz ) != XML_horz )
rPropMap[ PROP_TextWritingMode ] =
::com::sun::star::text::WritingMode_TB_RL;
}
moVert is a member in
struct TextBodyProperties
{
PropertyMap maPropertyMap;
OptValue sal_Int32 moRotation;
OptValue sal_Int32 moVert;
explicitTextBodyProperties();
voidpushToPropMap( PropertyMap rPropMap ) const;
};
in file trunk\main\oox\inc\oox\drawingml\textbodyproperties.hxx
Why is it not simple
if (moVert != XML_horz)
moVert is defined as
OptValue sal_Int32 moVert;
The oox::OptValue template class, defined in
oox/inc/oox/helper/helper.hxx, does not provide direct access to its
value. You have to call the get() method to read the
valuehttp://aoodev1:8080/source/xref/current/main/oox/inc/oox/helper/helper.hxx.
Looking at the code you pasted, I am asking myself if there should not
be a call to OptValue::has() before the get() method is called.
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Installation guide are asked to review and update when fix bug 124599
On 10.04.2014 06:55, Yuzhen Fan wrote: Hi all, Bug 124599 [2] is verified fixed in AOO 4.1.0 RC2, from current behaviors and comments provided in this bug, the expected behaviors for upgrade on Windows could be: Good idea. Good text but maybe a native speaker can tweek the wording. -Andre 1. If the former version is 3.x, there will be a check box in Installation Wizard providing the option to keep or remove the former version - If select Remove all older product versions, then 3.x will be removed and 4.x will be installed with 1 startup group, 1 desktop icon and 1 entry in the Add/Remove Programs list. This artifact is for 4.x - If de-select Remove all older product versions, then 4.x will be installed with keeping 3.x, there will be 2 startup groups, 2 desktop icons and 2 entries in the Add/Remove Programs list. These artifacts are one suite for 3.x and the other suite for 4.x 2. If the former version is also 4.x, but older than current installing one(e.g. install 4.1.0 over 4.0.0), then the older one will be removed and the newer one will be installed with 1 startup group, 1 desktop icon and 1 entry in the Add/Remove Programs list. This artifact is for the newer one. I think above behaviors are acceptable, I propose to update the installation instructions [1] according those. Any comments, or any objections? [1] http://www.openoffice.org/download/common/instructions.html#winoverview [2] Issue 124599 - Windows 4.1.0 installer does not recognize former versions correctly On Wed, Apr 9, 2014 at 12:37 AM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:39 AM, Yuzhen Fan fanyuz...@gmail.com wrote: Hi, The current installation instructions [1] (last updated on 2014-03-26) does not differentiate the clean installation and upgrade installation for Windows, thus it does not state the option to keep or delete the old version for an upgrade installation. I propose development update the installation instructions [1] when submit the fix to bug 124599 [2], to provide what is expected to see with details as below: 1. Upgrade from old version to relative new version (e.g. from 3.3 to 3.4.1, from 3.4.1 to 4.1.0, from 4.0.0 to 4.1.0, etc) 2. Specify the different behavior/experience on all platforms (Windows, Linux and Mac) - I do not see problems in the current instructions on Linux and Mac, but need confirmation That is essential, because for testers we need this as criteria for testing, and for end users we need this as instructions for guiding. You are right. We need to have our installations instructions accurate! Commmitters can directly edit this page and commit. Others can submit patches which we can review. We could use help from all folks using our installation binaries on this. [1] http://www.openoffice.org/download/common/instructions.html#winoverview [2] Issue 124599 - Windows 4.1.0 installer does not recognize former versions correctly -- Regards, Yu Zhen -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO Weekly News?
On 06.04.2014 18:03, Kay Schenk wrote: On 04/06/2014 07:10 AM, Rob Weir wrote: On Fri, Apr 4, 2014 at 2:40 PM, Tal Daniel tal.re...@gmail.com wrote: Rob Weir wrote: I noticed this blog post from another Apache project, CouchDB: https://blogs.apache.org/couchdb/entry/couchdb_weekly_news_april_3 Isn't that a cool idea? Sounds like a good idea, to summarize key discussions, and news, for the rest of us who can't track all the forum posts. Weekly? Monthly? I don't know. Maybe something in the middle, like every two weeks? It depends on the pace of interesting things on the lists, forums, news, etc. One easy way to do this would be to have a wiki page called AOO Weekly News (or something like that). Anyone in the community can add something there. Then each week (or month or whatever) at an agreed-upon time, we cut and past the wiki content into a blog post and press post. The one thing to test is whether text formatting and hyperlinks are preserved when copying and pasting from wiki to blog. But if that does work, this could be an easy solution. -Rob I like this idea. Yes, good idea. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.0 (RC)
On 03.04.2014 09:56, Jürgen Schmidt wrote: Hi all, this is a call for vote on releasing the available release candidate (RC) as Apache OpenOffice 4.1.0. Another problem came up that looks serious enough so that I would like to cancel this vote, if nobody objects. Juergen, who started the vote, is on vacation today, so I need your help to do that. The problem is described by issue 124599 [1]. Here is a summary: When you install the RC on Windows then a previously installed version (3.* and 4.*) is not removed. For versions 3.* this leads to a parallel installation (because there are different installation paths). For versions 4.* the files of the older version are overwritten but registry entries and links on the desktop remain. If you install the RC on a system with no prior installation of AOO then there are no problems. This problem is caused by my patch related changes and is therefore restricted to Windows. Linux and Mac are not affected. I am currently working on a fix which will probably consist of a small change in our Perl program for creating the downloadable installer. That means that it requires an SVN commit and therefore a rebuild on all platforms. So, even if Mac and Linux are not directly affected, they still have to be rebuilt so that they report the correct SVN revision. If you don't object to a cancellation of the vote then the current plan is to provide a fix today, rebuild and upload tomorrow and re-start the vote on the second RC on sunday or monday depending on how smooth this process works. Regards, Andre [1] https://issues.apache.org/ooo/show_bug.cgi?id=124599 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Re issue 124599
On 04.04.2014 17:01, Andre Fischer wrote: Issue 124599 is the release blocker that requires a second RC. We have a bug fix, the patch is attached to the issue. Question is, how to proceed without Juergen to approve the release blocker flag? Does anybody else feel like a stand in for Juergen or should I just proceed? After all, if I stop his vote, I should probably fix the bug so that we/he can start the next vote. -Andre Herbert just reminded me that the upload speeds on the weekend are so much better then during the week. So I think that it would be good to check in the patch right now, start the builds and upload. Then we can decide on Monday how to proceed. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Regarding the repackaging of Windows RC builds
As you may have seen in another thread, we have to rebuild the Windows binaries. This is necessary to be able to install a 4.1 full installation set over an already installed 4.0.1. At the moment you get a dialog with text another version of this product is already installedand then the installation process is terminated. I will try to explain the technical details, as far as I understand them. The full installation sets of the RC build (and the release, of course) are basically just a wrapper around an MSI file and a lot of data files. The MSI controls how the data files are unpacked and copied into c:\Program Files (X86)\OpenOffice 4. An MSI contains, among a lot of other information, a product code and an upgrade code. Both are UUIDs and are used by Windows to check that the program you are installing (Apache OpenOffice) is not already installed. For an update from 4.0.1 to 4.1 Windows provides an alternative mechanism in from of MSP patch files. I have added initial support for creating MSP files to AOO in the second half of 2013 and Juergen has built MSP files for all languages so that we can check that these work without error. The problem with all this is that MSIs and MSPs have competing requirements regarding product codes and upgrade codes. For MSPs (in its minor upgrade variant, which lies in size and scope between small updates and major upgrades) the product codes have to remain the same and the upgrade code has to be different. The identical product code represents the Windows view that both are an OpenOffice 4 with some minor differences. For the MSIs the identical product code is interpreted so that both versions are the same product. Therefore you are not allowed to install both at the same time. I have to figure out how to trigger first to uninstall the old version and then install the new one. I thought that that where the default but apparently I never tested it. In the meantime we will re-build the installation sets with randomly chosen product codes. They replace a previously installed 4.0.1 just as you would expect. The only downside with that is that when the 4.2 (or whatever the next version will be called) is released, we will not be able to provide a single patch that can be applied to both a 4.1 resulting from a full installation and a 4.0.1 that was patched to version 4.1 with an MSP. The reason for this is that the two have different product codes and an MSP patch can only target one specific product code. As patches are still not officially released this is probably not a big problem. One final detail. To fix this problem we don't have to change any source code. The source release remains unmodified and the SVN revision remains the same. We just have to go to instsetoo_native and run the build command without the release=t flag and create new installation sets. I am sorry for the inconvenience. Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [REVIEW REQUEST] Re: review granted: [Issue 124553] Highlight of table with comment and text causes crash : [Attachment 83037] Initialize pointers in ScAccessibleCell contructor.
On 01.04.2014 12:11, Oliver-Rainer Wittmann wrote: Hi, On 01.04.2014 11:04, bugzi...@apache.org wrote: Oliver-Rainer Wittmann o...@apache.org has granted review: Issue 124553: Highlight of table with comment and text causes crash https://issues.apache.org/ooo/show_bug.cgi?id=124553 Attachment 83037: Initialize pointers in ScAccessibleCell contructor. https://issues.apache.org/ooo/attachment.cgi?id=83037action=edit --- Additional Comments from Oliver-Rainer Wittmann o...@apache.org patch is fine, but additionally method SwAccessibleCell::GetTable() which sets the forgotten initialized members is not needed. code will be moved into constructor. I have refined the patch as stated and made it already available on trunk, revision 1583589 Patch looks good. -Andre Please provide me a review. Thx in advance, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: AOO 4.1 Beta Survey Results
On 25.03.2014 19:52, Rob Weir wrote: 9. Invisible scrollbars This is a problem with the default theme (Adwaita) of the gnome shell, which is used by Fedora 20. There are other paint errors as well. See issue 124482 [1] for details. -Andre [1] https://issues.apache.org/ooo/show_bug.cgi?id=124482 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Bug/Issue: There and back again
I never saw an announcement of this, so I am writing this summary instead. The AOO Bugzilla issue tracker has a feature that turns text of the form 'bug number' into an HTML link to the referenced bug. Some days ago this suddenly changed and only the pattern 'issue number' was recognized, see also bug 124460. Apparently this has been fixed. Now both patterns work in parallel. It would be nice if in the future there would be an announcement before such a change where made and we had the chance to discuss it. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Be careful before the release
On 24.03.2014 10:22, Herbert Duerr wrote: We're on a good way to a healthy AOO 4.1 release so we should avoid the pitfalls that prevented a timely AOO 4.1 Beta release. Let's examine this negative example a bit further, so we can all learn from it: A commit [1] stopped the Beta and forced the only respin that was needed despite the massive changes+improvements that went into the code base. [1] http://svn.apache.org/r1547732 The commit broke the installation of language packs and this breakage wasn't discussed before. The responsible developer sneaked that train-wreck in with a mega-patch under a non-suspicious comment. I don't remember him discussing the breakage of language packs before and that the creation of patches could negatively influences the usability of the language packs wasn't discussed either. I was the one who caused this build breaker and I am sorry for it. It was not the first and will not be the last build breaker that I introduced. I did not announce it in advance, because -- maybe this is hard to believe -- I did not do it on purpose. I also don't have a crystal ball that let's me see my future errors. Otherwise all my code changes would be error free, which, sadly, they are not. It was an honest mistake in a very complex feature (enabling our build system to create patches). I made the error in a file that was directly linked to the new feature. I did not see, at the time, that it would affect the regular build. Of course one could say It happens, but since that developer gets VERY annoying if It happens to anyone else the same casual attitude would be inappropriate. What's worse is that the commit comment [2] for unbreaking the language packs was Wrong initialization of . which is completely unusable. It didn't even mention language packs. That they were broken and now they are fixed. And what's that '.' Is this some magic hyper-linked dot? We should better use commit messages that can stand on their own. You are absolutely right. As an explanation, but not as excuse: what happend with this particular comment is, if I recall correctly, that I accidentally hit RETURN in mid-sentence. And then I was too lazy to look up SVN documentation and find out how to fix the comment. Instead I relied on all the necessary information being present in the issue description (for example see https://issues.apache.org/ooo/show_bug.cgi?id=124272#c11) and provided the correct comment in the issue (https://issues.apache.org/ooo/show_bug.cgi?id=124272#c14). I had the chance to fix the broken comment when I merged the change into trunk. But that seemed to me to be a bit dishonest, like I where trying to cover up a mistake. [2] http://svn.apache.org/r1573613 So in short: Be careful, be professional, don't do unto others what you wouldn't want them do unto you, and yes It happens and we have to deal with it. Positively if possible that is. I am not exactly sure what that is supposed to mean. If you have a problem with anything I have done, except from the build breaker, please be more explicit. I just have one wish. I don't have a problem with my errors being pointed out in the public. After more than a decade as developer in an open source project I have grown a thick skin. But please don't do that to others. That might discourage potential developers from joining our project. Regards, Andre Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Bug 124386] Improve Help for Version Selector
On 18.03.2014 14:54, Ariel Constenla-Haile wrote: On Tue, Mar 11, 2014 at 12:05:31PM +0100, Herbert Duerr wrote: Since many entries in our bugzilla database are not about bugs, but about new features or enhancements I'd also like to use the term issue instead of bug, when Bugzilla refers to such an entry. Isn't it possible to use both? The recent change turns all bug XXX into simple text, for example https://issues.apache.org/ooo/show_bug.cgi?id=124366#c1 used to have a link in See bug 119006 for more information. Thanks for bringing this to my attention and thanks to Rainer for creating bug/issue 124460 for this. Fooled by the title of the thread I did not read the proposed patch carefully enough to see the unrelated part about the bug-issue renaming. Could we please discuss or at least announce such changes with more meaningful titles in the future? -Andre Regards - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: openoffice.lst, can wJRE be deleted?
On 13.03.2014 23:15, Kay Schenk wrote: On 03/13/2014 06:49 AM, Raphael Bircher wrote: Hi all In openoffice.lst there is still a configuration for the with JRE build. We have anymor Builds with JRE, and I doubt that we will have in future. The license of Java is not ALv2 compatible, right. So the question is, can we delete this part? Greetings Raphael I would think so unless others have a different opinion. I agree that removing this entry from openoffice.lst is a good idea. Raphael, do you want to do it or shall I? I already have two modules on my to-remove list for Monday already. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Proposal to delete unused modules
I would like to propose to delete two unused modules: main/splitbuild and main/writerperfect - splitbuild looks like a collection of files that drive (drove) some sort of build script to build selected parts of OpenOffice. It may or may not be related to what is described in [1]. splitbuild depends on postprocess but nothing depends on splitbuild, therefore it is not used in any of our builds. - writerperfect is a second module that is not used anymore. The only module that depends on writerperfect is splitbuild. = There are some references in sysui to the wpf file format (application/vnd.writerperfect). = There is a configure switch --with-system-libwpd. It would trigger the building of library libwpft, which is referenced in postprocess and scp2, but without a dependency on module writerperfect this library is never built and using --with-system-libwpd could only lead to an error. Does anybody know of any reason not to delete the two modules? Regards, Andre [1] https://wiki.openoffice.org/wiki/Build_Environment_Effort/Split_Build - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Anything we can do about premature redistribution?
On 10.03.2014 08:32, Jürgen Schmidt wrote: On 3/9/14 8:49 PM, Marcus (OOo) wrote: Am 03/09/2014 07:33 PM, schrieb Kay Schenk: On Sun, Mar 9, 2014 at 10:08 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 03/08/2014 12:09 AM, schrieb Andrea Pescetti: Rob Weir wrote: http://linux.softpedia.com/get/Office/Office-Suites/ Apache-OpenOffice-253.shtml Or maybe a disclaimer in the voting thread email? Andrew's comments show clearly that these editors do not care to be careful or factual, or even read those disclaimers, unfortunately. We can be successful only if we manage to block their downloads. They link to our binaries hosted on SourceForge (which is fine). Just thinking loud, but if it was possible (on the Sourceforge side) to deny all download requests that do not come from the openoffice.org or the sourceforge.net domains, then the project would effectively be in control. The embargo could be lifted just after the release. I'm a bit confused by this statement. There are MANY sites the re-route to SourceForge for our downloads, and this is perfectly fine. The concern is for the inadvertent download of not yet released Beta which is available from the following URL space which is not even SourceForge: http://ci.apache.org/projects/openoffice/milestones OK, for the Beta release in special this is true. It's not yet available on Sourceforge - at least I cannot see it. it is there as well, hdu started the synch when the bits where ready on the Apache server for some further testing purposes (especially upload performance). And of course to have them in place in time for today. It was probably a little bit early but independent where we upload the bits they will be grabbed immediately. Which is not necessarily bad if they would do their job a little bit better ;-) There was no official release announcement. Is it possible to upload to some kind of staging area on sourceforge that is not accessible to the public? Keep the bits there until our vote has finished and them move them to the download area? -Andre Juergen In general, they link to our binaries at Sourceforge. Correct? So, I think the restriction would need to be from ci.apache.org, not SourceForge. For the Beta release this is true. However, I don't know how long this makes sense. Marcus For me this sounds like a great idea. Maybe we should start with denying all download requests that some from these bad websites. @Roberto: Can you tell us if this possible? If yes, is it much effort for you? Sure, sites could still copy all binaries being voted upon and offer them locally, but this would require a more significant effort. on their side. And more HDD space and more own bandwith - which is also not what they want. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building OpenOffice using VS2012 Express?
On 09.03.2014 10:25, LOH KOK HOE wrote: Dear all, Has anyone successfully build OpenOffice using VS2012 Express? I'm currently experiencing some error while following command is issue: ./configure --with-dmake-url= https://dmake.apache-extras.org.codespot.com/files/dmake-4.12.2.tar.bz2--with-cl-home=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC Maybe this is a problem with the path syntax and quoting. Can you try a different quoting for the --with-cl-home option? I use something like ---with-cl-home=/cygdrive/c/Progrram Files (x86)/Microsoft Visual Studio... -Andre And I have this error: checking for mspdb80.dll... no checking for mspdb71.dll... no checking the Microsoft C/C++ Compiler... found (/cygdrive/c/PROGRA~2/Microsoft Visual Studio 11.0/VC/bin/cl.exe) checking the Version of Microsoft C/C++ Compiler... found Compiler version in ./configure: line 8127: /cygdrive/c/PROGRA~2/Microsoft: is a directory ./configure: line 8138: test: : integer expression expected configure: error: Compiler too old. Use Microsoft C/C++ .NET 2008. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 11:54, Andre Fischer wrote: On 05.03.2014 09:30, Andre Fischer wrote: I have created issue 124361 for this. The 4555 warning is triggered by the hash_map wrapper in module stl_port/ when it includes unordered_map. Luckily this allows us to turn of the warning temporarily for just this header. Revision 1575930 enables exception support for all source files of sc. So if you experience any problems, this is the change to roll back :-) -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building OpenOffice using VS2012 Express?
On 10.03.2014 14:42, LOH KOK HOE wrote: This is interesting. On Windows 8, when I issue the command dir /x in command prompt to retrieve Microsoft Visual Studio 11.0's unique name, it shows nothing. Why this could happened? How you guys workaround on this issue? I have not made the transition from Windows7 to Windows 8, so I can not comment. Internally we use the cygpath command to convert from long to 8.3 file names. If OpenOffice still builds on Windows 8 then this technique still works and Windows 8 can still interpret 8.3 file names. -Andre On Mon, Mar 10, 2014 at 6:31 PM, Andre Fischer awf@gmail.com wrote: On 10.03.2014 10:42, John O'Sullivan wrote: I copied my Visual Studio Express 2008 into a short dir tree with no spaces in the dir names to work around this issue. I took the Common7 and VC subdirs from C:\Program Files (x86)\Microsoft Visual Studio 9.0 into another dir, and all worked smoothly. The long filenames have only to be understood by configure. They are then converted to 8.3 syntax, unreadable but without spaces. Look into the winenv.set.sh and you won't see that many spaces in directories. -Andre Cheers John On Mon, Mar 10, 2014 at 8:41 AM, Andre Fischer awf@gmail.com wrote: On 09.03.2014 10:25, LOH KOK HOE wrote: Dear all, Has anyone successfully build OpenOffice using VS2012 Express? I'm currently experiencing some error while following command is issue: ./configure --with-dmake-url= https://dmake.apache-extras.org.codespot.com/files/dmake- 4.12.2.tar.bz2--with-cl-home=/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 11.0/VC Maybe this is a problem with the path syntax and quoting. Can you try a different quoting for the --with-cl-home option? I use something like ---with-cl-home=/cygdrive/c/Progrram Files (x86)/Microsoft Visual Studio... -Andre And I have this error: checking for mspdb80.dll... no checking for mspdb71.dll... no checking the Microsoft C/C++ Compiler... found (/cygdrive/c/PROGRA~2/Microsoft Visual Studio 11.0/VC/bin/cl.exe) checking the Version of Microsoft C/C++ Compiler... found Compiler version in ./configure: line 8127: /cygdrive/c/PROGRA~2/Microsoft: is a directory ./configure: line 8138: test: : integer expression expected configure: error: Compiler too old. Use Microsoft C/C++ .NET 2008. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RIP soldep
I have just removed the unused module soldep. It seems to have contained ancient parts of the build system. I saw references to the old build servers that, on Windows, had to be mounted on r:, n:, w:. I saw Perl parsers for reading build.lst files and convert them to XML. I saw handwritten C++ parsers for reading these XML files that use handwritten implementations of hash maps. Sometimes I think we should build a museum for code that has no other place. But then again, much of our code that would belong into such a museum is still actively used. More information can be found in issue 124316. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [VOTE]: Release Apache OpenOffice 4.1.0 Beta (RC)
+1 Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Iterator debugging
With the transition from stlport to system STL we lost some (most?) debugging support for STL on Windows. The MSVC STL offers debugging support but that is not activated in our builds. There is, for example the _HAS_ITERATOR_DEBUGGING environment variable that is responsible for activating iterator debugging. However, that only works when doing a retail build (compiler message is warning CRT1005: Iterator debugging not supported in retail builds.) Does anybody know how to turn off retail builds? Building a non-pro version of OpenOffice is apparently not enough. Additional ideas for debugging system STL are also welcome. Regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Compiler warnings
I am currently working on some bug in the sc module and find that it is really hard to even find compiler errors among the many warning messages. Some of these warnings are caused directly by code in sc but the majority of the warnings originate in header files. Platform is Windows. The most annoying warnings are warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc and even more (because of the warning text that is repeated again and again) warning C4555: expression has no effect; expected expression with side-effect (see full text below) Any ideas how to silence these two? re C4530: One option would be to compile all sc code with exceptions enabled. Does anyone know of a reason not to do that? Best regards, Andre PS: here is the complete output for one instance of the C4555 warning: C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1137) : warning C4555: expression has no effect; expected expression with side-effect C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1126) : while compiling class template member function 'void std::list_Ty,_Ax::_Splice(std::list_Ty,_Ax::_Const_iterator_Secure_validation,std::list_Ty,_Ax ,std::list_Ty,_Ax::_Const_iterator_Secure_validation,std::list_Ty,_Ax::_Const_iterator_Secure_validation,unsigned int,bool)' with [ _Ty=std::pairconst String,OpCode, _Ax=std::allocatorstd::pairconst String,OpCode, _Secure_validation=true ] C:\PROGRA~2\MICROS~1.0\VC\include\xhash(205) : see reference to class template instantiation 'std::list_Ty,_Ax' being compiled with [ _Ty=std::pairconst String,OpCode, _Ax=std::allocatorstd::pairconst String,OpCode ] C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/unordered_map(86) : see reference to class template instantiation 'stdext::_Hash_Traits' being compiled with [ _Traits=std::tr1::_Umap_traitsString,OpCode,stdext::_Hash_compareString,formula::StringHashCode,std::equal_toString,std::allocatorstd::pairString,OpCode,false ] C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\stl\hash_map(59) : see reference to class template instantiation 'std::tr1::unordered_map_Kty,_Ty,_Hasher,_Keyeq,_Alloc' being compiled with [ _Kty=String, _Ty=OpCode, _Hasher=formula::StringHashCode, _Keyeq=std::equal_toString, _Alloc=std::allocatorstd::pairString,OpCode ] C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\formula/FormulaCompiler.hxx(109) : see reference to class template instantiation 'std::hash_map__K,__T,__H,__E' being compiled with [ __K=String, __T=OpCode, __H=formula::StringHashCode, __E=std::equal_toString ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 10:01, Herbert Duerr wrote: On 05.03.2014 09:30, Andre Fischer wrote: I am currently working on some bug in the sc module and find that it is really hard to even find compiler errors among the many warning messages. Some of these warnings are caused directly by code in sc but the majority of the warnings originate in header files. Platform is Windows. The most annoying warnings are warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc and even more (because of the warning text that is repeated again and again) warning C4555: expression has no effect; expected expression with side-effect The problem is in MSVC2008's list header. They probably fixed that in their newer versions. Another reason to update our build environment on that platform to something newer. The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Please explain how that can be filtered out easily. Any ideas how to silence these two? We could disable such warnings altogether by adding e.g. the -wd4555 option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and main/solenv/gbuild/platform/windows.mk How do we do that only for the system headers? -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 11:28, Herbert Duerr wrote: On 05.03.2014 10:28, Andre Fischer wrote: On 05.03.2014 10:01, Herbert Duerr wrote: The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Please explain how that can be filtered out easily. e.g. by piping the output through the command perl -ne 'print if not /^.*list.1137/../^\S/' It removes all list.1137 lines and their indented followup lines. Unfortunately also one more line but perl experts can probably fix that easily. Of course, on the command line this is easy, but I am building inside emacs. Any idea how to do it there? -Andre Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 12:38, John O'Sullivan wrote: Use MSVC's WD flag to disable the warning. You'll probably need to hack wntmsci11.mk... I wouldn't like to turn off this warning globally. I only don't want to see it for system headers that I can't change anyway. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 10:01, Herbert Duerr wrote: On 05.03.2014 09:30, Andre Fischer wrote: re C4530: One option would be to compile all sc code with exceptions enabled. That sounds reasonable. Does anyone know of a reason not to do that? Not that I'm aware of. I am neither, that's why I ask :-) Exception support does make object files larger and possibly a bit slower. The question is, is that significant? Module sw nowadays has exception support for all its files. And not changing at least the files in sc/ for which there are warnings might lead to memory leaks when there are exceptions. So it is probably best to activate support for exceptions module wide. -Andre Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 11:53, Herbert Duerr wrote: On 05.03.2014 11:45, Andre Fischer wrote: On 05.03.2014 11:28, Herbert Duerr wrote: On 05.03.2014 10:28, Andre Fischer wrote: On 05.03.2014 10:01, Herbert Duerr wrote: The warning expression has no effect itself is interesting enough, just not in in list header. Fortunately terms like list(1137) can be filtered out easily. Please explain how that can be filtered out easily. e.g. by piping the output through the command perl -ne 'print if not /^.*list.1137/../^\S/' It removes all list.1137 lines and their indented followup lines. Unfortunately also one more line but perl experts can probably fix that easily. Of course, on the command line this is easy, but I am building inside emacs. Any idea how to do it there? As I don't use emacs I had to rely on my googling skills instead and found [1] that looks relevant. Does it help? No, building in emacs works a little different. But keep trying :-) -Andre [1] http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 14:49, jan i wrote: On 5 March 2014 14:42, Andre Fischer awf@gmail.com wrote: On 05.03.2014 10:01, Herbert Duerr wrote: On 05.03.2014 09:30, Andre Fischer wrote: re C4530: One option would be to compile all sc code with exceptions enabled. That sounds reasonable. Does anyone know of a reason not to do that? Not that I'm aware of. I am neither, that's why I ask :-) Exception support does make object files larger and possibly a bit slower. The question is, is that significant? Module sw nowadays has exception support for all its files. And not changing at least the files in sc/ for which there are warnings might lead to memory leaks when there are exceptions. So it is probably best to activate support for exceptions module wide. On ubuntu, the slower is not measureable. It is basically to extra function calls, and a word extra on heap, I assume it is identical on windows. On ubuntu object files seems to be 5-10% bigger, but the final exe (I use this in e.g. genLang) in my case is less than 1% bigger. Thanks, that is good to know. I remember vaguely that the size increase on Solaris was more noticeable. But that was years ago. -Andre I had problems with exceptions in modules where java is called (just a warning). rgds jan I. -Andre Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Compiler warnings
On 05.03.2014 14:18, Rob Weir wrote: On Wed, Mar 5, 2014 at 7:32 AM, jan i j...@apache.org wrote: On 5 March 2014 12:46, Andre Fischer awf@gmail.com wrote: On 05.03.2014 12:38, John O'Sullivan wrote: Use MSVC's WD flag to disable the warning. You'll probably need to hack wntmsci11.mk... I wouldn't like to turn off this warning globally. I only don't want to see it for system headers that I can't change anyway. Use #pragma to disable/enable the warnings. Put the #pragma around the include statement. Or use a push/pop set of pragmas, which handles nested inclusion scenarios safer: http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx -Rob Thanks John, Rob, Jan, I think I have this warning under control now. As suggested I use #if defined(_MSC_VER) #pragma warning(push) #pragma warning(disable:4555) #include ... #pragma warning(pop) #endif After putting this in hash_map and still seeing warnings 4555 I thought that maybe not only the definition of the list template had to be treated this way but also the template instantiation, which would have required a lot more work. Luckily I just had to do the same fix for the list template. No more 4555. -Andre rgds jan I. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Help wanted for a new volunteer to fix bug 122003 ( missing titels)
On 01.03.2014 02:12, Reem Elnagar wrote: Hi :) It was written in the oreintation that after building OpenOffice I should try fixing easy bugs. So I chose to start with that bug 122003, so can any one help me with some guidelines on how to fix it. Thanks in advance and much appreciated :) This issue seems already to be worked on and may even be fixed (although the 'assigned to' and 'status' fields are not set). And this bug is about the OpenOffice web site not its source code. This may or may not be what you want to work on. Maybe you can pick another one? Thanks for your interest, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Build error on Mac OS X 10.7 with AOO main in testtools
On 03.03.2014 10:03, Raphael Bircher wrote:
Hi at all.
I have a build error on my Mac OS X 10.7 in testtools
/Users/nacnaub/Documents/AOO_main/main/solenv/bin/createcomponent.xslt
constructors.component
:
DYLD_LIBRARY_PATH=/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/lib${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}
xsltproc --nonet --stringparam uri './cppobj.uno.dylib' -o
../../unxmaccx.pro/misc/cppobj.component \
/Users/nacnaub/Documents/AOO_main/main/solenv/bin/createcomponent.xslt
cppobj.component
:
DYLD_LIBRARY_PATH=/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/lib${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}
xsltproc --nonet --stringparam uri \
'vnd.sun.star.expand:${MY_CLASSDIR_URL}testComponent.jar' -o
../../unxmaccx.pro/misc/testComponent.component \
/Users/nacnaub/Documents/AOO_main/main/solenv/bin/createcomponent.xslt
testComponent.component
:
DYLD_LIBRARY_PATH=/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/lib${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}
xsltproc --nonet --stringparam prefix
/Users/nacnaub/Documents/AOO_main/main/testtools/source/bridgetest/../../unxmaccx.pro/misc/
-o ../../unxmaccx.pro/lib/uno_services.rdb \
/Users/nacnaub/Documents/AOO_main/main/solenv/bin/packcomponents.xslt
../../unxmaccx.pro/misc/uno_services.input
cd ../../unxmaccx.pro/lib :
DYLD_LIBRARY_PATH=/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/lib${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}
/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/bin/uno \
-ro uno_services.rdb -ro uno_types.rdb \
-s com.sun.star.test.bridge.BridgeTest -- \
com.sun.star.test.bridge.CppTestObject
/bin/bash: line 1: 51041 Segmentation fault: 11
DYLD_LIBRARY_PATH=/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/lib${DYLD_LIBRARY_PATH:+:${DYLD_LIBRARY_PATH}}
/Users/nacnaub/Documents/AOO_main/main/solver/410/unxmaccx.pro/bin/uno -ro
uno_services.rdb -ro uno_types.rdb -s com.sun.star.test.bridge.BridgeTest --
com.sun.star.test.bridge.CppTestObject
dmake: Error code 139, while making 'runtest'
Is this a reproducable problem? It it is then rebuild cpputools (this
is where the 'uno' executable is built), deliver and try again to build
testtools.
-Andre
1 module(s):
testtools
need(s) to be rebuilt
Reason(s):
ERROR: error 65280 occurred while making
/Users/nacnaub/Documents/AOO_main/main/testtools/source/bridgetest
When you have fixed the errors in that module you can resume the build by
running:
build --from testtools
Any touch what's wrong?
Greetings Raphael
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Fighting epm
On 28.02.2014 06:24, Raphael Bircher wrote: Hi at all For some reasons I have problemes with epm on Ubuntu 12.04. I run into the fellowing build error: dmake: Error: -- `./unxlngi6.pro/misc/3ade8cfe7e59ca8e65052644fed9fca4-epm-3.7.unpack' not found, and can't be made The epm swithch I Used is the fellowing: --with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz Did configure run without errors? Do you see the 3ade8cfe7e59ca8e65052644fed9fca4-epm-3.7.tar.gz in ext_sources/ ? -Andre Maybe someone can help me Greetings Raphael - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Beta naming
Juergen, Oliver and I have changed product names and some images to contain the word 'beta'. I would like to explain some of the technical background and constraints. How to use: --- Go to instsetoo_native/util and run dmake openofficebeta to build the beta version of OpenOffice for all languages and supported package formats on the platform or dmake openofficebeta_language/format to do the same for the specified language and package format (run dmake help for details on language and package format). What has changed: - Most places that show the name 'OpenOffice' or 'Apache OpenOffice' now display 'OpenOffice Beta' or 'Apache OpenOffice Beta'. Examples are the title bar of application windows, the about box, installation dialogs (if they exist on your platform), and the download packages. Some images now contain the word 'beta' in big red letters. These are the splash screen, the start center and the about box. Guiding principle here was not to make the images pretty but to make the beta status obvious. How that is implemented: instsetoo_native/util/openoffice.lst contains a description of the different 'products' like the regular OpenOffice, developer versions, language packs and the SDK. For the beta we have copied the Apache_OpenOffice product (which defines the regular OpenOffice) and basically added the word 'Beta' to all variants of the product name. The same was done for the languagepacks and the SDK. See openoffice.lst if you are interested in the details. Some changes where necessary to add the make targets to instsetoo_native/util/makefile.mk and to replace the images. Guiding principle for the changes was to minimize changes of the existing workflow to not introduce regressions or beta-specific artifacts. Constraints: The format of openoffice.lst and the meaning of its content are largely undocumented and don't allow too fine a control over how the product names can be changed. For example placing the 'Beta' after the version number, eg 'OpenOffice 4.1 Beta' is not easily possible, so 'OpenOffice Beta 4.1' has to do for now. Maybe we can improve that for the next release. You can experiment with finding a better solution by changing the variables in the Apache_OpenOffice_Beta section in openoffice.lst, build a new installation set (building just instsetoo_native should be sufficient for most changes), and install it. The images posed a different set of constraints due to limited free space. Again, the guiding principle was to change as little as possible. The 'beta' text is added without changing or moving any other content. The images are available here: default_images/introabout/beta/intro.png(splash screen) default_images/introabout/beta/about.png(about dialog) framework/res/beta/backing.png (start center) With more time and your input we can improve both product names and images but for the time being the current state is as good as was possible in available time. Best regards, Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Beta naming
On 28.02.2014 10:14, Andre Fischer wrote: dmake openofficebeta_language/format That should be dmake openofficebeta_language.format (. instead of /) -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How to search for files to modify to fix a bug?
On 25.02.2014 20:21, Tenzin Chhosphel wrote: Hi all, I am just starting out to fix bugs. I spent some time around Bugzilla and now have a decent knowledge about how it works. And I understand finding the right files to fix is big part of fixing a bug. It seems there's no set of rules on how to find the files of interest. But, I bet there's some logical way to look for those files that needed to be modified to fix a bug. Any ideas/suggestions/advices on how to do that is much appreciated. It is hard to give a general answer to your question, but if you have a concrete problem/bug that you would like to work on, then maybe we can help you. -Andre Thanks, Tenzin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How could I make a build on writer module?
On 25.02.2014 15:20, LOH KOK HOE wrote: I can see the sw library is inside the workdir, anyhow it is still not an executable. I'm just curious to know how could I run sw module in debug mode while fixing a defect so that I could understand whether my fix is correct. The worst is I'll never run an executable until I rebuild the installer and then install it into the system and test it from there. This is too costly as I'm just trying to verify my fix. Please have a look at https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO#Partial_Builds The general idea: a) Edit code in module sw/ b) Build sw c) Deploy sw libraries to your installed office d) Run soffice.bin in your debugger e) Find bug f) Go to a) -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: How could I linked the dependencies of soffice.bin?
On 25.02.2014 15:46, LOH KOK HOE wrote: I just make a build and the executable file (soffice.bin) was locate at /main/solver/410/unxlngx6.pro/bin. When I execute the file, it shows me: ./soffice.bin: error while loading shared libraries: libsofficeapp.so: cannot open shared object file: No such file or directory What happens when you start soffice (without the .bin extension)? This is a script that sets some envirnment values that control (among other) where to look for the libraries. -Andre When I use `strace -f ./soffice.bin` command, I can see there are bunch of dependencies shown up. May I know how could I link these dependencies together if I execute soffice.bin directly? THanks @! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: dmake clean
On 19.02.2014 16:03, Steele, Raymond wrote: Yes, we have made many local modifications. Gladly, we had the backup. Couldn't a check be placed in the make file to ensure $INPATH is set? That would be the minimal solution. I have created issue 124263 [1] for it. I have some trouble to reproduce your problem because a) I don't want to delete my object files at the moment :-) b) When INPATH is not set then typically the whole solar environment is not set. But in that case dmake complains that it can not find startup.mk. Unless dmake is in PATH. But that is usually not the case when the solar environment is not set ... -Andre [1] https://issues.apache.org/ooo/show_bug.cgi?id=124263 -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Tuesday, February 18, 2014 4:49 PM To: OOo Apache Subject: EXTERNAL: Re: dmake clean On Tue, Feb 18, 2014 at 3:01 PM, Steele, Raymond raymond.ste...@lmco.comwrote: I see in the Makefile: clean .PHONY -rm -rf */$(INPATH) -rm -rf solver/*/$(INPATH) I am going to make an assumption that I performed the dmake clean and $INPATH was not set, therefore rm -rf */ was performed From: Steele, Raymond Sent: Tuesday, February 18, 2014 3:58 PM To: dev@openoffice.apache.org Subject: dmake clean I am not sure why, but I just did a dmake clean in ../main and once if finished all the module directories including source was deleted. Thankfully, I had a backup. Can anyone explain this? Raymond Hello Raymond -- Yes, an incredibly annoying thing and one I have experienced as well. If you source your env script and THEN do dmake clean, only the bits generated toward the native build will disappear. The clean script does a MUCH bigger remove if you don't do that first. The first time this happened to me, I freaked a bit, but as I hadn't made any local mods, an svn update got everything back. It's good that you had a backup since I'm assuming you made local mods that you wanted to keep. The build doc needs a bit of updating to help others avoid this pitfall. Happy coding! -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bug 124268 - OOXML import problems
On 20.02.2014 09:37, Rainer Bielefeld wrote: Hi, I think we should decide whether we want to use a tracking bug [2] or a Key word (interop_OOXML) [2]. Using both in parallel only makes it more difficult to create reliable queries. I don't think so. I have created [1] to have list of bugs with interesting documents that highlight certain problems of the OOXML import. It is assigned to me, so you can see this as a personal list. Key words, in contrast, are global. I have no intention to start tracking all OOXML bugs. By the way, the interop_OOXML keyword has been used only five times. I assume that we have more OOXML problems than that. -Andre CU Rainer Hyperlinks: [1] https://issues.apache.org/ooo/show_bug.cgi?id=124268 [2] https://issues.apache.org/ooo/buglist.cgi?keywords=interop_OOXML%2C%20keywords_type=allwordslist_id=126117query_format=advanced - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Question on building OpenOffice
On 19.02.2014 00:22, Reem Elnagar wrote: Hi :) I had a problem while building open office it was written in the step by step building guide in Ubuntu https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step to write the command source LinuxX86-64Env.Set.sh but when I did that I got No such file or directory can anyone tell what went wrong ? Thanks in advance :) This file is created when configure runs without error. Please check the output of configure to see if there where any errors. If you are on a 32 bit system, then the file name is slightly different. Does a ls main/Linux*.Set.sh list anything? -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: deleted files still showing in repository browse -- help!
On 18.02.2014 23:06, Kay Schenk wrote: In this repository -- http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/documentation/online_help/helpauthoring/ I did an svn delete yesterday on all files named OOo2HelpAuthoring-number.html Just the ones followed by a number, not the others, and not the png files. Yet, they are still showing in the web browse of the repository. In my local repo, even deleting the whole directory, followed by an svn update yields the correct files. So, does anyone know why these files are still stuck like this in the web browse mode? You still need an svn commit to, well, commit your local changes to the svn server. and, oops! I didn't realize svn delete wouldn't prompt me for a log message so there was none. :/ That is strange, svn delete should not need a log message. But the following svn commit should. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: deleted files still showing in repository browse -- help!
On 19.02.2014 09:07, Andre Fischer wrote: On 18.02.2014 23:06, Kay Schenk wrote: In this repository -- http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/documentation/online_help/helpauthoring/ I did an svn delete yesterday on all files named OOo2HelpAuthoring-number.html Just the ones followed by a number, not the others, and not the png files. Yet, they are still showing in the web browse of the repository. In my local repo, even deleting the whole directory, followed by an svn update yields the correct files. So, does anyone know why these files are still stuck like this in the web browse mode? You still need an svn commit to, well, commit your local changes to the svn server. and, oops! I didn't realize svn delete wouldn't prompt me for a log message so there was none. :/ That is strange, svn delete should not need a log message. But the following svn commit should. Sorry, I did not read the rest of the thread. Not quite awake. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: I have posted 3 wiki for OOXML export
On 19.02.2014 02:30, shzh zhao wrote: 1. shape export https://cwiki.apache.org/confluence/display/OOOUSERS/Shape+Export+in+OOXML+Export 2. DrawingML shape export https://cwiki.apache.org/confluence/display/OOOUSERS/DrawingML+export+in+OOXML+export 3. UT method in OOXML export https://cwiki.apache.org/confluence/display/OOOUSERS/UT+method+in+OOXML+Export VML shape export will be added later. Great. Thanks for the information. Especially the idea about using POI as a test tool is interesting. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Paste screenshots in AOO writer 4.1 bêta
On 18.02.2014 10:08, Guy Waterval wrote: Hi all, I dont know if this issue is relevant or not, just for info. I generally use greenshot to make screenshots and copy them from greenshot to the clipboard before pasting them in Writer. http://getgreenshot.org/ I have noticed a little issue with writer in the latest bêta AOO 4.1 under Windows 7.0 (not tested in other OS). In Impress, Draw and Calc all is OK, but not in Writer, the command Paste or Ctr+V gives no results (in AOO 4.01 it was OK). If I make screenshots with the simple Windows Printscreen command, all is OK, also in Writer. So, only to indicate a change noticed between AOO 4.01 and AOO 4.1 bêta, not obligatory a bug. What does Edit-Paste Special list as available data formats? -Andre A+ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Trace Output
On 18.02.2014 16:56, Steele, Raymond wrote: I configured the OpenOffice build without debug and disabled symbols, but I am still getting 'trace' output in the terminal when I run ./soffice. How do I disable this? Raymond Can you give us an example? With that we can find the place in the source and understand why it is still printed. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: dmake clean
On 19.02.2014 00:48, Kay Schenk wrote: On Tue, Feb 18, 2014 at 3:01 PM, Steele, Raymond raymond.ste...@lmco.comwrote: I see in the Makefile: clean .PHONY -rm -rf */$(INPATH) -rm -rf solver/*/$(INPATH) I am going to make an assumption that I performed the dmake clean and $INPATH was not set, therefore rm -rf */ was performed From: Steele, Raymond Sent: Tuesday, February 18, 2014 3:58 PM To: dev@openoffice.apache.org Subject: dmake clean I am not sure why, but I just did a dmake clean in ../main and once if finished all the module directories including source was deleted. Thankfully, I had a backup. Can anyone explain this? Raymond Hello Raymond -- Yes, an incredibly annoying thing and one I have experienced as well. If you source your env script and THEN do dmake clean, only the bits generated toward the native build will disappear. The clean script does a MUCH bigger remove if you don't do that first. The first time this happened to me, I freaked a bit, but as I hadn't made any local mods, an svn update got everything back. It's good that you had a backup since I'm assuming you made local mods that you wanted to keep. The build doc needs a bit of updating to help others avoid this pitfall. Thanks for bringing this to my attention. Up to now I thought that the worst that 'dmake clean' would do would be to delete dmake as well. I will see what I can do. -Andre Happy coding! - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE][DISCUSS] How to download AOO 4.1.0 Beta?
On 14.02.2014 22:32, Rob Weir wrote: On Fri, Feb 14, 2014 at 3:53 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: As this is our first beta release at Apache, I would like to clarify some things before it's maybe too late to change the facts and to prepare webpages: 1. Target group It is intended to be downloaded for the general public, right? 2. Hosting We are planning to host the files at Sourceforge, right? 3. File names: Of course the file names of the install files have to show a difference compared to the general release files. Suggestion: Apache_OpenOffice_4.1.0_Beta_Win_x86_install.exe *If* there is a need to publish another round, it could be extended with a number like: Apache_OpenOffice_4.1.0_Beta2_Win_x86_install.exe 4. Directory structure: Is it OK to expect to use the same dir structure like we have currently for 4.0.1? In general, yes, but please keep in mind that our Mac builds are now 64bit. I assume that the directories that contain the Mac downloads got renamed (Servers are currently down so I can not check). -Andre The above makes sense to me. 5. Download webpage: Is it OK to expect to offer the download on our main download webpage? http://www.openoffice.org/download/ If yes, I can build up a download offer like we have for the green box. To ease the download as best as possible. I would not make this the default download option for users. We still want most users to download AOO 4.0.1. So keep the first box on /download.html as it is now. Maybe a yellow box (yellow == caution) with language that makes it clear that this is beta and gives the URL for reporting bugs. Were you thinking of a language/platform switch logic for the beta? Or just a link to a beta_other.html page with a table of links? If we do the table, then we would have room on the same page to give a prominent warning, a link to BZ, Release Notes, etc. Thanks! -Rob Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: svn commit: r1568331 - in /openoffice/trunk/main: default_images/introabout/intro.png ooo_custom_images/dev/introabout/intro.png ooo_custom_images/dev_nologo/introabout/intro.png ooo_custom_images
On 17.02.2014 09:33, Oliver-Rainer Wittmann wrote: Hi, good catch. One minor remark: openoffice/trunk/main/default_images/introabout/intro.png and openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png does not carry the ASF logo anymore. I think these should carry the ASF logo while the other two do not. Because of the nologo part in their name? These images exist for a long time and I don't think that nologo refers to the ASF logo. I don't know what they should display, I don't even know if they (all intro.png's outside default_images/) are still used. -Andre Best regards, Oliver. On 14.02.2014 16:02, a...@apache.org wrote: Author: af Date: Fri Feb 14 15:02:32 2014 New Revision: 1568331 URL: http://svn.apache.org/r1568331 Log: 124224: Using the modern logo once again. Modified: openoffice/trunk/main/default_images/introabout/intro.png openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png Modified: openoffice/trunk/main/default_images/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/default_images/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 14.02.2014 22:37, Steele, Raymond wrote: Andre, I think we are going to keep that section commented out for now. We are not sure what to do. Do you think commenting out that section will have a big impact at runtime? Not big. It is probably OK to move on and come back later when you have some sort of enlightenment. -Andre We are working on the Save now (described below). *From:*Andre Fischer [mailto:awf@gmail.com] *Sent:* Friday, February 07, 2014 2:18 AM *To:* Steele, Raymond; Andre Fischer; a...@openoffice.apache.org; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org *Cc:* Meffe, David K *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 07.02.2014 00:04, Steele, Raymond wrote: Andre, When we commented out the section below, we were able to get the application to work correctly I would expect subtle errors in the sidebar, like panels not updating after context changes or when switching between application windows. (although it did not let us save a spreadsheet to disk for some reason. Each time we hit okay to save after supplying a unique name, the filechooser closes, but instantly reappears again. It did let us save it as another format, such as .dif). Strange, this change should not modify the saving of the document. That is probably an unrelated problem. However, the application crashes when we replace the lines with: ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE); WeakReferenceSidebarController xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); I've attached the stack trace of that crash. It crashes right after the SidebarController destructor on line 177 (which is empty). Stepping from the destructor brings us into boost's checked_delete.hpp and eventually crashes at line 34 delete x. See attached stack trace. m_RefCount was 3 for us as well. Also strange. All this does not fit together. If the ref count is larger than 0 then the SidebarController should not be deleted. And if it where deleted, then not from Reference...::iquery. And boost::scoped_ptrWindow should have no problem deleting the control (I have not enough information to say which one it is). All controls are created in the initializer of the constructor and should be fully created and initialized by the time the crash is triggered. All this looks like the actual problem happens earlier, maybe some memory overwrite. Maybe you can use valgrind (or some other memory checker) to see if there is a memory problem? Thanks for taking the time to look into this, we are grateful. Would you happen to be located in the U.S.? No problem. I am a little worried that you have discovered a problem that lurks on all platforms and Solaris is the only one where it leads to an actual crash. And, no, I am not located in the US. I am in Germany. -Andre *From:*Andre Fischer [mailto:awf@gmail.com] *Sent:* Thursday, February 06, 2014 2:03 AM *To:* Steele, Raymond; a...@openoffice.apache.org mailto:a...@openoffice.apache.org; Herbert Duerr (h...@apache.org mailto:h...@apache.org); dev@openoffice.apache.org mailto:dev@openoffice.apache.org *Cc:* Meffe, David K; awf@gmail.com mailto:awf@gmail.com *Subject:* Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault On 05.02.2014 20:02, Steele, Raymond wrote: Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Raymond, there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier. - Comment out the last few lines: /* WeakReferenceSidebarController xWeakController (this); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); */ That should tell us whether the crash is caused just by storing the weak reference. The sidebar should still work in general but some updates may be lost. - Replace the last few lines by this: ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE); WeakReferenceSidebarController xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count). - Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController
Re: OO 4.01 Compiled for Solaris 11 x86 Save As Stuck in a Loop
On 14.02.2014 23:06, Steele, Raymond wrote:
We are attempting to use the newly build OpenOffice 4.0.1 for Solaris
11 x86, but the 'Save As' to disk of any document type (i.e. .ods)
continuous to prompt for a file name. Each time we hit okay to save
the document after supplying a unique name, the FilePicker closes, but
instantly reappears again.
I have narrowed it down to the following code located in
sfx2/source/doc/guisaveas.cxx lines 1497-1520
The program gets stuck in the while loop below. The variable 'bExit'
is never set to sal_True, so the loop continuous. I provide a name to
the FilePicker interface, click Save and the loop continuous,
redisplaying the dialog. To resolve the issue, I added bExit =
sal_True after line 1513 so that the loop discontinuous. I am not sure
if this will have effects in other situations, maybe someone can
provide some feedback, but for now. I am able to save.
sal_Bool bExit = sal_False;
1497 while ( !bExit )
1498 {
1499 bUseFilterOptions = aModelData.OutputFileDialog(
nStoreMode, aFilterProps, bSetStandardName, aSuggestedName,
bPreselectPassword, aSuggestedDir, nDialog, sStandardDir, aBlackList );
1500
1501 // in case the dialog is opend a second time the folder
should be the same as before, not what was handed over by parameters
1502 aSuggestedDir = ::rtl::OUString();
1503 if ( nStoreMode == SAVEAS_REQUESTED )
1504 {
1505 // in case of saving check filter for possible alien warning
1506 ::rtl::OUString aSelFilterName =
aModelData.GetMediaDescr().getUnpackedValueOrDefault(
1507 aFilterNameString,
1508 ::rtl::OUString() );
1509 sal_Int8 nStatusFilterSave = aModelData.CheckFilter(
aSelFilterName );
1510 if ( nStatusFilterSave == STATUS_SAVEAS_STANDARDNAME )
These are equal during runtime
1511 {
1512 // switch to best filter
1513 bSetStandardName = sal_True; bSetStandardName is set to
sal_True here, but bExit is not, so the loop continuous. Setting bExit
following this line allows the program to save.
++bExit = salTrue;
1514 }
1515 else if ( nStatusFilterSave == STATUS_SAVE )
1516 {
1517 // user confirmed alien filter or good filter is used
1518 bExit = sal_True;
1519 }
1520 }
1521 else
1522 bExit = sal_True;
1523 }
I tried this on Windows7. I come through the else if (line 1518).
When saving a Writer document aSelFilterName is writer8. What is the
value in your case?
-Andre
Raymond Steele
U-2 Mission Planning
Software Engineer Sr
Lockheed Martin -- ISGS Defense
1300 S. Litchfield Rd.
Goodyear, AZ 85338
Email: raymond.ste...@lmco.com
Business phone: 623-925-6402
Re: svn commit: r1568331 - in /openoffice/trunk/main: default_images/introabout/intro.png ooo_custom_images/dev/introabout/intro.png ooo_custom_images/dev_nologo/introabout/intro.png ooo_custom_images
On 17.02.2014 12:05, Oliver-Rainer Wittmann wrote: Hi, On 17.02.2014 11:10, Andre Fischer wrote: On 17.02.2014 09:33, Oliver-Rainer Wittmann wrote: Hi, good catch. One minor remark: openoffice/trunk/main/default_images/introabout/intro.png and openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png does not carry the ASF logo anymore. I think these should carry the ASF logo while the other two do not. Because of the nologo part in their name? Please have a second look ;-) The two above mentioned images does _NOT_ have a nologo part in their path/name. These two images carried the ASF logo before Jürgen's accidental change on 2014-02-12. I know. I interpreted that as another oversight. Why would we want the ASF logo in one variant of intro.png but not the other? Is there anybody who actually *knows* a) whether the non default_images/ variants are still used (otherwise we don't have to bother anyway) b) whether the ASF logo should be in some intro.png variants -Andre Best regards, Oliver. These images exist for a long time and I don't think that nologo refers to the ASF logo. I don't know what they should display, I don't even know if they (all intro.png's outside default_images/) are still used. -Andre Best regards, Oliver. On 14.02.2014 16:02, a...@apache.org wrote: Author: af Date: Fri Feb 14 15:02:32 2014 New Revision: 1568331 URL: http://svn.apache.org/r1568331 Log: 124224: Using the modern logo once again. Modified: openoffice/trunk/main/default_images/introabout/intro.png openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png Modified: openoffice/trunk/main/default_images/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/default_images/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/dev/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/dev_nologo/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. Modified: openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png URL: http://svn.apache.org/viewvc/openoffice/trunk/main/ooo_custom_images/nologo/introabout/intro.png?rev=1568331r1=1568330r2=1568331view=diff == Binary files - no diff available. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE][DISCUSS] How to download AOO 4.1.0 Beta?
On 17.02.2014 20:44, Marcus (OOo) wrote: Am 02/17/2014 09:37 AM, schrieb Andre Fischer: On 14.02.2014 22:32, Rob Weir wrote: On Fri, Feb 14, 2014 at 3:53 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: As this is our first beta release at Apache, I would like to clarify some things before it's maybe too late to change the facts and to prepare webpages: 1. Target group It is intended to be downloaded for the general public, right? 2. Hosting We are planning to host the files at Sourceforge, right? 3. File names: Of course the file names of the install files have to show a difference compared to the general release files. Suggestion: Apache_OpenOffice_4.1.0_Beta_Win_x86_install.exe *If* there is a need to publish another round, it could be extended with a number like: Apache_OpenOffice_4.1.0_Beta2_Win_x86_install.exe 4. Directory structure: Is it OK to expect to use the same dir structure like we have currently for 4.0.1? In general, yes, but please keep in mind that our Mac builds are now 64bit. I assume that the directories that contain the Mac downloads got renamed (Servers are currently down so I can not check). This is currently the complete path to the AOO 4.0.1 install files, example for English US: http://sourceforge.net/projects/openofficeorg.mirror/files/4.0.1/binaries/en-US/ There is no part included to reflect the OS and I don't know of an idea to do so. Or have I misunderstood you? Looks like I assumed wrong. I had the directory structure of the snapshot builds in mind, which obviously differ from that of the release. So we only keep in mind that the names of the Mac binaries change (not sure if that is relevant). -Andre Marcus The above makes sense to me. 5. Download webpage: Is it OK to expect to offer the download on our main download webpage? http://www.openoffice.org/download/ If yes, I can build up a download offer like we have for the green box. To ease the download as best as possible. I would not make this the default download option for users. We still want most users to download AOO 4.0.1. So keep the first box on /download.html as it is now. Maybe a yellow box (yellow == caution) with language that makes it clear that this is beta and gives the URL for reporting bugs. Were you thinking of a language/platform switch logic for the beta? Or just a link to a beta_other.html page with a table of links? If we do the table, then we would have room on the same page to give a prominent warning, a link to BZ, Release Notes, etc. Thanks! -Rob Thanks Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [Proposal] Update Icons for AOO 4.1
On 18.02.2014 04:36, Samer Mansour wrote: I know for windows 48x48 is used in windows 8 in a lot of defaults. I'm hoping I'm not too late to get the list of all icons sizes/formats needed to finish this before the next release. Anyone know when the next release is? On Mon, Feb 17, 2014 at 10:24 PM, Samer Mansour samer...@gmail.com wrote: cwiki is back up now I've uploaded the application icons in a zip to https://cwiki.apache.org/confluence/display/OOOUSERS/AOO4.1+-+Desktop+Icons Scroll down to feb 17th, I went with my last design and did the final pixel tweaking so anti-aliasing doesn't blur the pixels in the icons. Its the circle with the gull and the context offset in the lower left corner. Samer, thanks for your work. I have one remark and one (possibly stupid) question: - The PNG icons for Calc have slight transparancy in their background color. As this does not exist in the SVG nor in icons for other applications, I assume this is a mistake. - Maybe I have missed this in a previous mail, but what does the @2 part of some of the icons mean? Is that a Mac thing? Regards, Andre Samer On Mon, Feb 17, 2014 at 12:54 PM, Kay Schenk kay.sch...@gmail.com wrote: On 02/17/2014 08:41 AM, Samer Mansour wrote: Sorry about this situation. I will produce the following pngs for macOS today. The cwiki seems to be down, so I can e-mail you the sources and finished products directly icon_16x16.png icon_16...@2.png (32x32) icon_32x326.png icon_32...@2.png (64x64) icon_128x128.png icon_128x...@2.png (256x256) icon_256x256.png icon_256x...@2.png (512x512) icon_512x512.png icon_512x...@2.png (1024x1024) Can you compile a list of formats we need? ie windows and mac, and what ever else we need. Hi Samer -- Since both wikis are currently down, can you put sources people.apache.org area somewhere so we could get to them? We can do the rendering once we have the .svg files without any problem. I think Jürgen is on vacation this week. Thanks for all your wonderful work on these updates. On Thu, Feb 13, 2014 at 4:15 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 12/16/13 10:19 AM, Jürgen Schmidt wrote: On 12/13/13 6:37 AM, Samer Mansour wrote: Just so you don't think I died in a fire. I'm just under a lot of pressure at my new workplace and I'm working weekends because we're flying by the edge of our seats at this start up. I just ordered my family gifts online. I'm trying to get my priorities right. I will have this done before the new year. Just need to squeeze it in. Hi Samer, no pressure and your new job should have of course a higher prio. Thanks for keeping us updated I assume that we get no new icons for AOO 4.1, correct? Maybe you can share the source files and somebody else is interested to continue. I like the new icons and would like to see them in the office as soon as possible. Kind regards Juergen Juergen On Mon, Nov 25, 2013 at 7:36 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/23/13 6:45 PM, Samer Mansour wrote: I think I found what we need with the following: https://cwiki.apache.org/confluence/download/ attachments/34834886/logo-w-offset3.png?version=6 modificationDate=1385227784594 (from https://cwiki.apache.org/confluence/display/OOOUSERS/ AOO4.1+-+Desktop+Icons ) The application icons will have the bird and the circle branding. When the application icon is 16x16 I will drop the gull. The file icons are absolutely an improvement off the old file icons, keep that in mind. I won't be placing the gulls in the file icons. The file icon at 32x32 has 17x20 inside for the application context and that's being dedicated to the context. I can have the rough icons ready in a week and a half. just to ensure that we get all sizes we need The main.icns file on MacOS contains icon_16x16.png icon_16...@2.png (32x32) icon_32x326.png icon_32...@2.png (64x64) icon_128x128.png icon_128x...@2.png (256x256) icon_256x256.png icon_256x...@2.png (512x512) icon_512x512.png icon_512x...@2.png (1024x1024) Juergen Samer Mansour On Wed, Nov 20, 2013 at 4:04 PM, Samer Mansour samer...@gmail.com wrote: I've been so busy at work in the last week, let me set myself a reminder to review this on Saturday and give everyone an update and propose how to move forward. On Mon, Nov 18, 2013 at 4:47 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 11/4/13 8:23 PM, Samer Mansour wrote: This is just a reminder that this coming Nov 9th is the end of the 30 day window for list folk to submit ideas, whether in words or images. After this date, I will compile the ideas and feedback. Hi Samer, any news on this? I believe we should integrate new icons as soon as possible Juergen Samer Mansour On Wed, Oct 9, 2013 at 11:01 PM, Samer Mansour samer...@gmail.com wrote: Hello, I'm proposing to have the icons (and related assets) updated for AOO 4.1 release. I would
Re: Md5sum failed
On 14.02.2014 03:16, njia1297-ubu...@yahoo.com wrote: Checksums do not match... thought someone should know. Can you provide more information? Which file did you check? Where did you download it from ? -Andre == William - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: User data storage
On 14.02.2014 08:52, Oliver-Rainer Wittmann wrote: Hi, On 13.02.2014 21:09, jonasalfreds...@gmail.com wrote: I recommend the DevGuide [1] and the related configuration chapter. And SDK contains a sample in Java that shows how to access the configuration. I'm new to this and has just recently completed my first build of the aoo. The code I'm looking at is C++ in the cui module and not Java. Is it not right that Java is used for users to develop extensions and addins not for correcting aoo bugs. My aim is to commit a bugfix to the aoo codebase. What I am looking for is pointers into the C++ codebase where user configuration is read and written. Some time ago I have written a simple class for accessing the configuration: header: sd/source/ui/inc/tools/ConfigurationAccess.hxx implementation: sd/source/ui/tools/ConfigurationAccess.cxx used here: sd/source/framework/module/ModuleController.cxx and here: sd/source/ui/sidebar/RecentlyUsedMasterPages.cxx once you know the UNO intefaces to implement and services to use you can find other examples via OpenGrok (http://opengrok.adfinis-sygroup.org/source/) -Andre Is this not the correct forum for aoo developers, but aoo addin developers? This is the general mailing list for AOO - it is the right place for your requests. I think Jürgen pointed you to the DevGuide as the configuration is also available via the UNO-API and thus can be used by extension developers. To get familiar with the configuration management this is a good start, I think. You probably have to define a new schema first to store your data. For testing you can do that via an extension and you can use Java to play around with the API. The same API is also available in the C++ code. Thus, the code used in an extension could be converted into C++ code. Best regards, Oliver. [1] https://wiki.openoffice.org/wiki/Documentation/DevGuide/Config/Configuration_Management Juergen /Jonas -- View this message in context: http://openoffice.2283327.n4.nabble.com/User-data-storage-tp4658954p4658974.html Sent from the Development mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Getting started with development
On 10.02.2014 18:32, Pranet Verma wrote: Hi, Thanks for the link. I completed the build earlier, but i'm still not able to achieve the task listed here https://wiki.openoffice.org/wiki/Tutorial_Start 1) This is the exact change i made in the file(Accelerators.xcu): (after line 123) !-- Tutorial-1 -- node oor:name=T_MOD1 oor:op=replace prop oor:name=Commandvalue xml:lang=x-no-translateI10N SHORTCUTS - NO TRANSLATE/value value xml:lang=en-US.uno:About/value /prop /node !-- -- 2) Now the next steps says *You can copy your changed Accelerators.xcu file directly into the install directory (\OpenOffice.org 3\Basis\share\registry\data\org\openoffice\Office\Accelerators.xcu).* - Im unable to find this file. When they say install directory, Im assuming they mean : opt/openoffice4/ Sadly, this information is outdated. So i tried the next option: *Or, you can build the module and rebuild the installer (this assumed you have previously fully built it, if not then just do the usual build --all -P4 from the instsetoo module).* Did this one i think. Just followed the building guide and got the software running earlier. So far so good(I think) *From the $SRCROOT\officecfg directory call build, then deliver to send the changed Accelerators.xcu file to the solenv module.* Im assuming this is: source/aoo-trunk/main/officecfg. There is no option to call build or deliver (these are terminal commands here?) The module postprocess/ has to be built, too. So, do cd officecfg build deliver cd ../postprocess build deliver cd ../instsetoo_native build And install the new set of packages (I assume you are working on Linux). The part that is missing from the Wiki page seems to be that several XCU files have to be combined into main.xcd (that is done in postprocess/). You can skip building a new installation set cd ../instsetoo_native build and just copy main.xcd into your installed office like cd .. # (to get back to main/) cp solver/410/platform/xml/main.xcd office-installation/share/registry/main.xcd where platform the content of the $INPATH environment variable and office-installation is something like /opt/openoffice4/ If you succeed then we can think about updating the Wiki page. -Andre EDIT: i called ./bootstrap and then source LinuxX86Env.Set.shhttp://linuxx86env.set.sh/ from main/ and then repeated the above step. It worked. Ouput: deliver -- version: 275594 Module 'officecfg' delivered successfully. 1 files copied, 247 files unchanged *Then change to the instsetoo module and call build, then install.* I dont need to do build -all here do I? I just used build, and it did so. 3)After installing when I run, the software and press ctrl+T nothing happens. Could you please tell me where I'm going wrong? Thank You On Fri, Feb 7, 2014 at 10:43 PM, Rob Weir robw...@apache.org wrote: On Thu, Feb 6, 2014 at 10:03 AM, Pranet Verma pranetve...@gmail.com wrote: Hi, Could you please tell me how to get started with Open Office development? I began by following this guide : https://wiki.openoffice.org/wiki/Development , but after building the source and installing the program when I reached the first tutorial ( https://wiki.openoffice.org/wiki/Tutorial_Start ) it failed(I'm pretty sure i followed all the steps but ctrl+T just doesnt work like its supposed to) . The page does seem to be outdated to me (considering some folder name and syntax of files do not match with the guide, though i may be wrong), I was wondering if there was a better source to learn from. I'm reasonably comfortable with c/c++ , and am pretty active in competitive programming, but developments new for me , so any help is appreciated. Also, if possible could you direct me to modules using c/c++ specifically? Im open to learning new languages, but to start with I would prefer working in a familiar environment. Hi Pranet, Welcome to the Apache OpenOffice project! I'd recommend taking a look at our New Volunteer orientation pages for some useful background on the project and how it works: http://openoffice.apache.org/orientation/ The page on getting started with development is the key one: http://openoffice.apache.org/orientation/intro-development.html That will get you started on downloading the source code and doing your first build of OpenOffice. Getting a build running on Linux is pretty easy. Windows takes a bit more effort to set up the pre-reqs. (I've never done a Mac build, but I hear it is easy as well). Either way, give it a try and post further messages if you get stuck. Regards, -Rob Thank You - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Windows 8
On 08.02.2014 14:06, Varun Bezzam wrote: Hi Everybody! I have noticed that the official Building on Windows page does not have any information on Building For Windows 8. My laptop runs Windows 8. Is this a problem? Should I install a different OS? No, don't install a different OS :-) But you may also want to look at [1] and [2]. And it would be great if you note anything that does not work on Windows 8 as described and how you solved it, so that we can add a section for Windows 8 to the wiki pages. Thanks, Andre [1] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO [2] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7 Thanks for your help, Varun. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenOffice icons panels
On 09.02.2014 18:39, Απόστολος Συρόπουλος wrote: Hello, I have recently built OpenOffice on Solaris. There are still some problems which I try to sort out. One of them is that the panel with the File, Edit, etc menues is empty and there are no icons on panel under this. In fact the whole upper panel is empty. Could you please let me know which package contains this images etc and where they should go in the solver folder? All I know is that the icons can be found in main/default_images and a few in main/ooo_custom_images and that the icons/images are processed in main/packimages into some sort of archive/texture map. Menus and toolbars are described by XML files in main/module/uiconfig/*/menubar and main/module/uiconfig/*/toolbar. The implementation of toolbars is done in - vcl (low level) vcl/source/window/menu.cxx vcl/source/control/menubtn.cxx vcl/source/window/toolbox*.cxx - framework (high level) framework/source/uielement/menubar*.cxx framework/source/uielement/toolbar*.cxx -Andre Thank you! A.S. -- Apostolos Syropoulos Xanthi, Greece - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: My self-build AOO starts and then closes immediately
On 08.02.2014 13:59, Regina Henschel wrote: Hi all, I have build r1565724 as debug build. I have installed the resulted binaries administrative with setup -a. I can start it, but it closes immediately, without any error message. The folder 'user' is created, but the welcome screen does not appear. There are no remaining processes, it really closes. A part of this is the normal behavior on the first start: OpenOffice starts, shows the splash screen, does some initialization and at about 50% of the progress bar, it shuts down and restarts. Looks like the restart does not work. What happens when you start soffice.bin instead of soffice.exe ? -Andre The daily build r1565724 from buildbot installs fine. Any idea, what is wrong with my build? Kind regards Regina My configure: ./configure \ --with-directx-home=/cygdrive/c/Program Files/Microsoft DirectX SDK (June 2010) \ --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC \ --disable-activex \ --with-mozilla-build=/cygdrive/c/mozillabuild \ --enable-dbgutil \ --enable-category-b \ --with-asm-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/bin \ --with-jdk-home=/cygdrive/c/Program Files/Java/jdk1.6.0_38 \ --with-ant-home=/ant \ --with-mspdb-path=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE \ --without-junit \ --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2; \ --without-fonts \ --with-atl-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/atl71 \ --with-atl-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/ATL/i386 \ --with-mfc-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/mfc42 \ --with-mfc-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/Mfc/i386 \ --with-vendor=Regina_Henschel \ --with-build-version=r1565610 2014_02_07 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: a mistake in drawingml.hxx?
On 10.02.2014 11:08, shzh zhao wrote: in oox\inc\oox\export\drawingml.hxx there is a line like #include svx/escherex.hxx if you search 'escherex.hxx' ,you can find it in filter/inc/filter/msfilter. can anyone fix this bug in the code base? I assume you found this while working on the OOXML export? This makes you the one who can best fix it :-) Probably the escherex.hxx file got moved from svx/ to filter/ after the OOXML code was written and later abandoned. That would mean that the obvious fix is to replace #include svx/escherex.hxx with #include filter/msfilter/escherex.hxx But, at the moment, you are probably the only one who can judge whether that works or not. -Andre - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Successful 1st Build!
On 06.02.2014 20:37, Tenzin Chhosphel wrote: Hi all, I had previously introduced myself and subscribed to the dev list with another email. But, I'll be using this e-mail: chhos...@gmail.com from now on so I am reintroducing myself shortly. I am Tenzin Chhosphel from New York City. I am currently a computer science major at City College - CUNY, a rising senior. I have hands-on experience on multiple languages: C, Objective-C, Java, etc. but I primarily code in C++. I have successfully built OpenOffice on Ubuntu 12.04 Great. Did you experience any problems that should be handled in the building guide? and ready for coding, debugging, and woking. So what projects can I contribute, where can I get started? OpenOffice has a wide range of features that include areas like graphics, text processing, numerical computations, database etc. If you tell us a little about your interests and goals then we can probably find something for you to work on. -Andre Thanks, Tenzin - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Solaris GCC or Sun Studio?
On 07.02.2014 11:32, Απόστολος Συρόπουλος wrote: Hello, As far it regards Solaris,I have noticed that the building scripts of OpenOffice assume that one is building with Sun Studio. This compiler is a bit outdated and of course GCC is available for most platforms. Since LibreOffice has removed support for Sun Studio, I guess it would be a goof idea to remove support for Sun Studio. It adds complexity without reason. For example, I tried to compile a module and it failed just because it assumed that I was using Sun Studio. Today that would be Oracle Solaris Studio, current version seems to be 12.3. There is no buildbot for the Solaris version of OpenOffice and it is not tested. So, in a sense, we have already dropped support for Solaris :-) But there are others on this list that are currently doing a Solaris build. Anybody still using Sun|Oracle Studio? By the way, is clang also available on Solaris? -Andre Kind regards, A.S. -- Apostols Syropoulos Xanthi, Greece - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 05.02.2014 20:02, Steele, Raymond wrote: Andre, We are not seeing any exception before the actual crash. Maybe I am not looking in the right place, but we've been using dbx intercept command to track any. Any other suggestions? Raymond, there a few thing you can do to find out if this is a local problem (broken in the constructor) or something more fundamental that is possibly caused by an error that happened much earlier. - Comment out the last few lines: /* WeakReferenceSidebarController xWeakController (this); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); */ That should tell us whether the crash is caused just by storing the weak reference. The sidebar should still work in general but some updates may be lost. - Replace the last few lines by this: ReferenceSidebarController xThis (this, SAL_NO_ACQUIRE); WeakReferenceSidebarController xWeakController (xThis); maSidebarControllerContainer.insert( SidebarControllerContainer::value_type( rxFrame, xWeakController)); That removes one (of two) acquire calls (I don't know yet why there is a second acquire, after all the purpose of the weak reference is just /not/ to increase the reference count). - Check the value of the reference count of 'SidebarController* this' (in OWeakObject::acquire, cppuhelper/source/weak.cxx) when line 168 of the SidebarController constructor is executed. In my case it is 3. -Andre Also, I've attached the stack trace of the first and second notifyContextChangeEvent. They are different. That is OK. They should be different. But the stack trace of the second call looks broken. The top two frames (notifyContextChangeEvent being called from Reference constructor) indicate that something is very wrong, like the vtable overwritten or not fully created. One explanation (although I cannot say how probable that is) could be that the Solaris compiler has not fully created/initialized the vtable in the constructor. Raymond *From:*Steele, Raymond *Sent:* Wednesday, February 05, 2014 9:48 AM *To:* 'a...@openoffice.apache.org'; Herbert Duerr (h...@apache.org); dev@openoffice.apache.org *Cc:* Meffe, David K; 'awf@gmail.com' *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Hi Andre, Thanks for the response. We are looking at that now. In the constructor of SidebarController at line 168 WeakReference..., on your system, does the code step to Reference.h: Line 359 -- XInterface operator, as it does during our run? It appears that at runtime Reference.hxx: Line 136 - _pInterface-acquire() that occurs after WeakReference.. does not execute as it does after addContextChangeEventListener a few lines above WeakReference. Do you see a similar behavior? Can you provide the first 5-10 steps your code takes after WeakReference (line 168)? Here are the requested frames cppuhelper3MSC.dll!cppu::OWeakObject::acquire() Line 204 C++ cppuhelper3MSC.dll!cppu::WeakComponentImplHelperBase::acquire() Line 236 + 0x9 bytesC++ sfx.dll!cppu::WeakComponentImplHelper4com::sun::star::ui::XContextChangeEventListener,com::sun::star::beans::XPropertyChangeListener,com::sun::star::ui::XSidebar,com::sun::star::frame::XStatusListener::acquire() Line 70 + 0xc bytesC++ sfx.dll!com::sun::star::uno::Referencesfx2::sidebar::SidebarController::Referencesfx2::sidebar::SidebarController(sfx2::sidebar::SidebarController * pInterface) Line 136 + 0x12 bytesC++ sfx.dll!sfx2::sidebar::SidebarController::SidebarController(sfx2::sidebar::SidebarDockingWindow * pParentWindow, const com::sun::star::uno::Referencecom::sun::star::frame::XFrame rxFrame) Line 168 + 0x12 bytesC++ Thanks! Raymond *From:*Steele, Raymond *Sent:* Tuesday, February 04, 2014 3:59 PM *To:* a...@openoffice.apache.org mailto:a...@openoffice.apache.org; Herbert Duerr (h...@apache.org mailto:h...@apache.org); dev@openoffice.apache.org mailto:dev@openoffice.apache.org *Cc:* Meffe, David K *Subject:* RE: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault Herbert, Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 with an equivalent throw/catch feature (intercept/whocatches) and have found that the cases where we tried to intercept exceptions, they were unhandled. This includes inside the SidebarController where we have tracked the problem origination. We have stepped through the code multiple times and while we have found that the problem originates in the SidebarController, we cannot explain how it happens. Using the debug tool we see that the SidebarController constructor doesn't complete because the segmentation fault occurs when the notifyContextChangeEvent is called a second time. The first time it is called it is located in the addContextChangeEventListener where
Re: About openxml handling code
On 03.02.2014 18:54, Mayur wrote:
Found something interesting. Writer seems to reject any graphics in OOXML
documents - even VML ones. But there does seem to be code to support it.
Only, if a couple of tiny glitches were fixed, possibly Writer will start
showing VML shapes (at least). That'd work for all the 2007 MS word
documents, as well as for some 2010 documents which would have the vml data
in their mc:Alternativecontent tags. Here're the problems:
i. A function getNamespace( ) in
oox/source/shape/ShapeContextHandler.cxx always returned 0. The problem
seems to be a
rather strange looking definition of the NMSP_MASK constant in
oox/source/token/namespaces.hxx.tail. It says there:
*const sal_int32 TOKEN_MASK* = static_castsal_int32* ( (1
16) - 1 ); *
* const sal_Int32 NMSP_MASK = static_cast sal_Int32 (
SAL_MAX_INT16 ~TOKEN_MASK );*
Why SAL_MAX_INT16? That would translate into (for windows)
* TOKEN_MASK = static_castlong(0x); // 65535*
*and NMSP_MASK = static_castlong(0x7FFF ~TOKEN_MASK). //
which is 0x7FFF 0x = 0.*
And
Where as really, we should be looking for is the namespace value
which is in the higher two bytes. i.e. the following change fixes it.
*const sal_Int32 NMSP_MASK = static_cast sal_Int32 (
SAL_MAX_INT32 ~TOKEN_MASK );*
That should set NMSP_MASK to the required 0x to obtain the
higher two bytes.
Good analysis.
To my mind, this sort of compactness isn't called for. Maybe, we
could have simply used a compact struct to store namespace and tag.
I always wondered why we keep namespace and token separable once they
have been read into memory. While the XML file is scanned it does makes
sense to use the same token for names in different namespaces. This
keeps the number of tokens and thus the complexity of the scanner small
(well, as small as possible). But once we have the tag (namespace and
name) in memory we should not have to extract namespace or name from a
tag. After all, if I have a name n in two namespaces a and b then a:n
and b:n are two different things and we can use enum values a_n and b_n
with arbitrary values to represent them. But maybe I am missing something?
-Andre
ii. In oox/source/vml/vmldrawingfragment.cxx, there's a switch in the
function onCreateContext that says:
case VMLDRAWING_WORD:
if ( isRootElement() ) {... }
Is this so that whenever a vml file is received as a separate
document fragment, only then we create a shape context? Why not for the
inline (v:rect or other) objects? I tried removing the check, and instead
checking simply if nElement is a VML, then vml drawings were suddenly
visible in writer.
Is this a valid fix?
On Wed, Jan 29, 2014 at 1:24 PM, Andre Fischer awf@gmail.com wrote:
On 28.01.2014 13:47, Mayur wrote:
Hi,
I am very new to the OpenOffice code, and need some help understanding the
open-xml handling code. Could someone please answer the following
questions?
i. There seem to be two distinct pieces of code that do open-xml parsing
in different ways. There's one part in writerfilter that has some
generated code (xslt based) that provides factories and classes for
creating different object types. And then, for sc and sd, all of the
parsing code is in the oox module and seems to be hand-written. Why is
that? Are there plans to move the parsing code to a common module?
(perhaps
oox ...)
Re why: OOXML import has been developed while OpenOffice was maintained by
Sun, later Oracle. There where at least three development teams involved
(for Writer, Calc, Draw/Impress). Sometimes they did not communicate with
each other as well as they should have. Having different modules is one of
the results. But, as far as I know, writerfilter has some calls into oox
for shared functionality.
Re future plans: Some of us are thinking about improving the OOXML
support. Consolidation of the code base into one module is a long term
goal.
ii. Probably a related question - why are drawing-ml shapes and pictures
not supported in sw, while they are supported in sc and sd? The parsing
code seems to be there. The tag wps:wsp has very little delta with the
p:sp
tag. Is this in works?
Well, see my above comments.
And, parsing OOXML is the easy part, importing the data into the
application model is the hard part. Calc and Impress use the same model
for representing graphical objects, Writer has its own.
If you are interested in OOXML import/export then maybe we can work
together on improving it?
Regards,
Andre
thanks,
mayur
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
-
To unsubscribe, e-mail: dev-unsubscr
Re: EXTERNAL: Re: OO 4.01 Compiled for Solaris 11 x86 Runtime Memory Fault
On 04.02.2014 23:58, Steele, Raymond wrote: Herbert, Raymond and I have been using the dbx debugger feature of Solaris Studio 12.3 with an equivalent throw/catch feature (intercept/whocatches) and have found that the cases where we tried to intercept exceptions, they were unhandled. This includes inside the SidebarController where we have tracked the problem origination. We have stepped through the code multiple times and while we have found that the problem originates in the SidebarController, we cannot explain how it happens. Hi, my name is Andre. I am the one who wrote the sidebar framework. I don't know if I can help (I can not reproduce this problem on a platform which I have access to) but I will try. Which exceptions (before the actual crash) do you see? Using the debug tool we see that the SidebarController constructor doesn't complete because the segmentation fault occurs when the notifyContextChangeEvent is called a second time. The first time it is called it is located in the addContextChangeEventListener where it appears to work as expected, even the acquire function appears to call the ContextChangeEventMultiplexer without any errors. The following lines are what we see as we step-by-step through the execution of the SidebarController.cxx constructor when we select the Spreadsheet or the Text Document. The first time the notifyContextChangeEvent is called: SidebarController: Line 147 - addContextChangeEventListener is called Reference.h: Line 359 - XInterface operator - is called Reference.h: Line 217 - castFromXInterface is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface-acquire(); compbase4.hxx: Line 70- WeakComponentHelperBase::acquire prototype implbase.hxx: Line 236 - WeakObject::acquire definition - ContextChangeEventMultiplexer receives and processes event. - In ContextChangeEventMultiplexer addContextChangeEventListener adds and calls the notifyContextChangeEvent - SidebarController::notifyContextChangeEvent: Line 257 is called. The rEvent associated with the notifyContextChangeEvent is a valid address - The rEvent STRUCT contains the application name and context name references Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Processing continues as normal from this point till line 168 of SidebarController.cxx The second time the notifyContextChangeEvent is called: I checked what is happening on Windows: - there should be exactly one call to the SidebarController constructor per application window. The constructor is called from the SidebarDockingWindow constructor. A second call, as described in your earlier mail should not take place. Can you check the stack trace of that second call and see who makes that call? - While in the constructor of SidebarController I see only one call to notifyContextChangeEvent(). As you found out it is triggered by the SidebarController registering itself as listener (it is being informed of the current context). The second call (while inside the constructor) is not necessarily an error but I would like to know what triggers it. The second call that I see is triggered after the SidebarController is constructed and is made (indirectly) from SfxViewFrame::DoActivate(). Can you show me the stack trace of that second call? SidebarController: Line 168 - the xWeakController(this) is called Reference.hxx: Line 134 - castToXInterface is called Reference.h: Line 232 - function castToXInterface Reference.hxx: Line 135 - if(_pInterface) Reference.hxx: Line 136 - _pInterface-acquire(); (Why does this not behave like the first call above? Should there be a call to WeakComponentHelperBase::acuire? The next step appears to skip all these procedures.) SidebarController::notifyContextChangeEvent: Line 257 is called, the rEvent is pointing to a reference that cannot be accessed. - The dbx dump has an rEvent = STRUCT - The dbx print of the rEvent says that it is referenced through a nil pointer Context.cxx: Line 51 - msContext(rsContext) ustring.hxx: Line103 - pData = str.pData - Accessing the pData in the string has been corrupted and causes the following Segmentation Fault: - Signal SEGV(no mapping at the fault address) in rtl::OUString::OUString at line 103 in file ustring.hxx We are trying to do our due diligence on this problem and we have been investigating it as best we can, but we are lacking in knowledge that the community can provide, which is why we are seeking help. Also the errors don't seem to make sense, so we believe we are dealing with a bug. We hope we are not being an inconvenience, and we definitely appreciate the help. We are investigating
Re: Bottom up build
On 30.01.2014 23:10, Rob Weir wrote: On Wed, Jan 29, 2014 at 4:18 AM, Andre Fischer awf@gmail.com wrote: I would like to report some observations that I made when thinking about how to make building OpenOffice with one global makefile feasible. It will probably the last of build related mails in the near future. Traditional make uses a top-down approach. It starts with a target, 'all' by default, and looks at its dependencies. When one of those has to be made or is newer then the target then the target also has to be made. This is done recursively and depth-first. Every file on which 'all' has a direct or indirect dependency has to be checked. If we would build OpenOffice with one makefile (included makefiles don't count) then that are a lot of files to check. There are about 9800 cxx files, 3500 c files, 12000 hxx files, and lot of external headers. Checking the modification time of so many files is one of the reasons for the delay in , say, sw/ between starting make and its first action. As I don't have all global dependencies in a format that would allow experimation, I tried how long it would take to get the mtime (time of last modification) for all files, source, generated, compiled, linked, about 12. I wrote a small Java program for that. With a warm cache that takes about 23s. When run in 4 threads this reduced to less than 8s. Could be worse. But it also could be better because in general there are only a few files modified, usually files that you modified yourself in an editor. There is another approach, introduced, as far as I know, by the tup [1] build tool, that is bottom up. If you had something similar to the oracle of complexity theory, that gave you the list of modified files since the last build, you could find the depending files much faster. Faster for two reasons. Firstly, there is only one path in the dependency tree up towards the root (while there are many down from the root). Only targets on this path are affected by the modified file. Secondly, the dependency analysis is comparatively cheap. The expensive part is to determine the file modification times. If they where miraculously given then even the top-down approach would not take noticably longer. So I made another experiment to see if such an oracle can be created. Java 7 has the java.nio.file.WatchService that lets you monitor file modfifications in one directory. I registered it to all directories in our source tree (some 16000 directories). With the WatchService in place every file modification can be recorded and stored for later. On the next build you only have to check the set of modified files, not all files. Registering the directory watchers takes a couple of seconds but after that it does not cause any noticeable CPU activity. Any file modifications are reported almost at once. I do not have the framework in place to start a build with this information but I would expect it to be as fast as compiling the modified files and linking takes. The tup website references a paper [2] in which the established top-down approaches are called alpha alogithms and the new bottom-up approach is called beta algorithm. Tup has implemented a file modification watcher (in C or C++) only for Linux. On Windows it just scans all files (for which it needs a little more time than my Java program, maybe it does not use more than one thread). This is something that we should keep in mind for when we ever should get a build solution with global dependencies and this build tool would turn out to be too slow. If can find the source code of my Java experiments at [3]. If nothing else you can see an application of the ForkJoinPool that allowed my to write the parallel file system scan in just a few lines. There is also an alternative implementation that uses the ExecutorService (with a fixed thread pool) which needs a few more lines of code. And there is of course the use of the WatchService. Has anyone read this book? http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620 It was on my list to read for many years. From what I've seen it suggests design approaches to the improve build times. So things that go beyond what you can do by just changing build files, more fundamental changes to how interfaces are defined. I have not but I might, thanks for the hint. I agree that improving our software design is always a good idea but I would not change our design just to make the build faster. Many of our code related problems are caused by the design and the limitations of the build system. Examples are the individual building of directories (in dmake modules) and creation of one library per directory or by the many ugly tricks that avoid becoming incompatible (the need to compile files in other modules). Otherwise I wonder if we're trying to optimize a bubble sort? I would smile about this if I had not seen a handcrafted sort algorithm in our build scripts
Re: scripts to assist in editing helpcontent2
On 30.01.2014 09:10, Oliver-Rainer Wittmann wrote: Hi, On 30.01.2014 02:34, Kay Schenk wrote: I decided to assist with the task of adding help information the four functions added to scalc some time ago (see mail thread: http://markmail.org/message/ojaxtd6uez4wk3rf) so I fist tracked down the help files in which to add the information. Then a major stumbling block -- how to create the needed header ids, bookmark ids, paragraph ids for my proposed additions. I ended up constructing a script that went through all the help files and culled out the ids that had already been used producing 3 little files corresponding to header ids, bookmark ids and paragraph ids, thinking new ones could be chosen using these lists. Really crazy results -- not all nice numerical id sequences but oh well. Anyway, where's a good place for this if someone else needs to use them? I think the wiki takes attachments? Should I just upload there along with some instructions for use? What about http://svn.apache.org/viewvc/openoffice/devtools/ ? If the script would make our build easier then it might also go to main/solenv/bin/ -Andre Best regards, Oliver - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Building on Mac
Yesterday I was trying to make a new build on OSX. I have not used this platform for a while so I instead of updating my SVN repository, I cloned the new GIT repository. That went as smooth as expected (thanks to everybody involved setting it up). But my configure failed. It complained that there was no xcode installed. This is probably due to the transition from 32bit to 64 bit. The only information I found about what to do is a short notice regarding build requirements [1]. That brought me as far as asking me for my Apple Developer Id. I have one, but not readily available, so I can not continue right now. So, I have some questions: 1. Is it possible to build on OSX with only freely available tools (that don't require registration)? 2. Is there anybody with access to a Mac who is willing to extend the building guide to cover OSX? [2] and [3] describe in some detail how to build OpenOffice on Windows and Linux (in its Ubuntu flavor) but hardly a word on OSX. Is there another page buried in our Wiki? 3. I remember that I also had to set up macports [4] for some frequently used shell commands (I think) but that is not mentioned anywhere in the building guide. Is it not needed anymore? I think that it is not enough that it is theoretically possible to build OpenOffice on Mac OSX. It should also be documented in a public place so that everybody can do it. Regards, Andre [1] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Building_on_MacOsX [2] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO [3] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step [4] http://www.macports.org/ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building on Mac
On 30.01.2014 10:24, Herbert Duerr wrote: On 30.01.2014 09:40, Andre Fischer wrote: 1. Is it possible to build on OSX with only freely available tools (that don't require registration)? Apple's XCode development environment is available for free in either their app store or in their downloads for developers area. Apple requires a registrations for both. Instead of free I should have used the word open as in open source. Registration seems not to be compatible with that concept. Since an Xcode download is a plain disk-image file that could be easily redistributed there might be alternative channels for them, but I'd strongly recommend to use the reliable and legal download locations from the original provider Apple. If there are direct download links at Apple that don't require registration then they are not well publicized. If anyone knows such a link please provide it. I am not asking for ways around the registration. I am asking for alternatives that maybe do not come from Apple. Does macports provide a gcc/clang compiler? 2. Is there anybody with access to a Mac who is willing to extend the building guide to cover OSX? [2] and [3] describe in some detail how to build OpenOffice on Windows and Linux (in its Ubuntu flavor) but hardly a word on OSX. Once XCode is installed it's just the plain generic svn-checkout, configure and build steps documented in [1]. The good thing about XCode is that it provides all that's needed. So? The same is true for Linux and Windows and we still have detailed building guides for them. 3. I remember that I also had to set up macports [4] for some frequently used shell commands (I think) but that is not mentioned anywhere in the building guide. Is it not needed anymore? I don't have macports or fink installed and can build just fine. All our build requirements are covered by Xcode. Of course these tool sets provide a lot of value, e.g. if anyone prefers to write his helper scripts in e.g. Lisp then macports is a good way to get a lisp interpreter for free. But our build doesn't require any of this. Ah, I didn't know that. I think that it is not enough that it is theoretically possible to build OpenOffice on Mac OSX. It should also be documented in a public place so that everybody can do it. Get XCode 4.5 and install it. What about the ... or later on the build requirements page. The referenced download page offers by default XCode 5. Does that work? Do the generic AOO build [1]. [1] https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO By the way, I'm working on enabling an AOO build with newer XCode versions, that no longer provide a 10.7 SDK. I'd suggest to not give up so easily. If a download requires a registration then annoying as it may be, it is nothing a reasonably experienced developer cannot handle. Even Mac newbies often manage to get things from the App Store. Not without their passwords. And you are right, I am not an experienced developer on the Mac platform. More reason to have proper documentation. I still have not given up hope that sometime somebody will provide it. -Andre Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Bottom up build
I would like to report some observations that I made when thinking about how to make building OpenOffice with one global makefile feasible. It will probably the last of build related mails in the near future. Traditional make uses a top-down approach. It starts with a target, 'all' by default, and looks at its dependencies. When one of those has to be made or is newer then the target then the target also has to be made. This is done recursively and depth-first. Every file on which 'all' has a direct or indirect dependency has to be checked. If we would build OpenOffice with one makefile (included makefiles don't count) then that are a lot of files to check. There are about 9800 cxx files, 3500 c files, 12000 hxx files, and lot of external headers. Checking the modification time of so many files is one of the reasons for the delay in , say, sw/ between starting make and its first action. As I don't have all global dependencies in a format that would allow experimation, I tried how long it would take to get the mtime (time of last modification) for all files, source, generated, compiled, linked, about 12. I wrote a small Java program for that. With a warm cache that takes about 23s. When run in 4 threads this reduced to less than 8s. Could be worse. But it also could be better because in general there are only a few files modified, usually files that you modified yourself in an editor. There is another approach, introduced, as far as I know, by the tup [1] build tool, that is bottom up. If you had something similar to the oracle of complexity theory, that gave you the list of modified files since the last build, you could find the depending files much faster. Faster for two reasons. Firstly, there is only one path in the dependency tree up towards the root (while there are many down from the root). Only targets on this path are affected by the modified file. Secondly, the dependency analysis is comparatively cheap. The expensive part is to determine the file modification times. If they where miraculously given then even the top-down approach would not take noticably longer. So I made another experiment to see if such an oracle can be created. Java 7 has the java.nio.file.WatchService that lets you monitor file modfifications in one directory. I registered it to all directories in our source tree (some 16000 directories). With the WatchService in place every file modification can be recorded and stored for later. On the next build you only have to check the set of modified files, not all files. Registering the directory watchers takes a couple of seconds but after that it does not cause any noticeable CPU activity. Any file modifications are reported almost at once. I do not have the framework in place to start a build with this information but I would expect it to be as fast as compiling the modified files and linking takes. The tup website references a paper [2] in which the established top-down approaches are called alpha alogithms and the new bottom-up approach is called beta algorithm. Tup has implemented a file modification watcher (in C or C++) only for Linux. On Windows it just scans all files (for which it needs a little more time than my Java program, maybe it does not use more than one thread). This is something that we should keep in mind for when we ever should get a build solution with global dependencies and this build tool would turn out to be too slow. If can find the source code of my Java experiments at [3]. If nothing else you can see an application of the ForkJoinPool that allowed my to write the parallel file system scan in just a few lines. There is also an alternative implementation that uses the ExecutorService (with a fixed thread pool) which needs a few more lines of code. And there is of course the use of the WatchService. Regards, Andre [1] http://gittup.org/tup/ [2] http://gittup.org/tup/build_system_rules_and_algorithms.pdf [3] http://people.apache.org/~af/test.zip - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: switch trunk from Mac 32bit to 64bit
On 28.01.2014 23:18, Marcus (OOo) wrote: Am 12/19/2013 05:58 PM, schrieb jan i: On 19 December 2013 17:29, Herbert Duerrhdu_...@alice.de wrote: The new Mac port looks quite good. I uploaded a current version to my page [1]. Jürgen already mentioned it will only work for OSX 10.7 and up. It is based on todays trunk, which already contains a lot of fixes and enhancements compared to our latest release. For details you can have a look at our progress tracking page [2]. [1] http://people.apache.org/~hdu/ [2] http://people.apache.org/~hdu/izlist9.htm In the early days of next year I plan to update our trunk so the new port becomes active. To build it yourself you'll need XCode4 then. XCode4 comes with the 10.7 SDK. +1 the wiki build instructions should also be updated. I've created a new webpage for sys reqs: http://ooo-site.staging.apache.org/dev_docs/source/sys_reqs_aoo41.html Thanks, great work. Maybe we should not state so prominently that we are not Windows 8 certified. We don't have the goal to be and probably never will. As far as I know we also not certified on any other Windows, or any other OS. -Andre Of course it is not yet linked from somewhere. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Capstone project and new build
On 28.01.2014 10:39, jan i wrote: Hi. Last week the capstone project managed to completely generate a module (hwpfilter) without using build and/or makefiles. It is all done in a visual studio solution. That is really good news. Thank you and everybody involved for your great work. Do you have a link to your changes? I would like to see what you have done. -Andre The next targets are: 1) expand the solution to multiple modules (this is more or less just work) 2) define a xslt that generates a Makefile (we have tested that we can store the extra information needed in the vxproj file) 3) Define a way to set common defines in all vxproj files (most likely a xslt) 4) Document the new system. The project started with 4 students, 1 left the project and 1 is less active, however the remaining 2 really do a good job. We have defined the branch capstone, but only use it locally and to merge from trunk, so at this point in time the solution is not available. rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: About openxml handling code
On 28.01.2014 13:47, Mayur wrote: Hi, I am very new to the OpenOffice code, and need some help understanding the open-xml handling code. Could someone please answer the following questions? i. There seem to be two distinct pieces of code that do open-xml parsing in different ways. There's one part in writerfilter that has some generated code (xslt based) that provides factories and classes for creating different object types. And then, for sc and sd, all of the parsing code is in the oox module and seems to be hand-written. Why is that? Are there plans to move the parsing code to a common module? (perhaps oox ...) Re why: OOXML import has been developed while OpenOffice was maintained by Sun, later Oracle. There where at least three development teams involved (for Writer, Calc, Draw/Impress). Sometimes they did not communicate with each other as well as they should have. Having different modules is one of the results. But, as far as I know, writerfilter has some calls into oox for shared functionality. Re future plans: Some of us are thinking about improving the OOXML support. Consolidation of the code base into one module is a long term goal. ii. Probably a related question - why are drawing-ml shapes and pictures not supported in sw, while they are supported in sc and sd? The parsing code seems to be there. The tag wps:wsp has very little delta with the p:sp tag. Is this in works? Well, see my above comments. And, parsing OOXML is the easy part, importing the data into the application model is the hard part. Calc and Impress use the same model for representing graphical objects, Writer has its own. If you are interested in OOXML import/export then maybe we can work together on improving it? Regards, Andre thanks, mayur - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Capstone project and new build
On 29.01.2014 08:53, jan i wrote: On 29 January 2014 08:46, Andre Fischer awf@gmail.com wrote: On 28.01.2014 10:39, jan i wrote: Hi. Last week the capstone project managed to completely generate a module (hwpfilter) without using build and/or makefiles. It is all done in a visual studio solution. That is really good news. Thank you and everybody involved for your great work. Do you have a link to your changes? I would like to see what you have done. At the moment I keep the actual files of the radar, because it undergoes rapid changes. However I think we see each other at the end of the week and there I can show you and we can discuss my makefile idea. That is good enough for me :-) See you in Brussels. -Andre rgds jan I. The project started with 4 students, 1 left the project and 1 is less active, however the remaining 2 really do a good job. We have defined the branch capstone, but only use it locally and to merge from trunk, so at this point in time the solution is not available. rgds jan I. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building sw/ with ninja
On 23.01.2014 19:23, Kay Schenk wrote: On Wed, Jan 22, 2014 at 5:32 AM, Andre Fischer awf@gmail.com wrote: Not quite a week ago I wrote about an idea to use XML files to store the declarative part of our makefiles: dependencies of libraries on source files, which resources are to be created and so on. In the meantime I have found the time to do make (conduct?) an experiment. I am now able to build module sw from the XML files with the help of the ninja build 'system' [3]. Most of the work of converting the XML files into one single build.ninja file was done on one weekend. You can see the source code at [1] ([2] contains everything zipped together). I think link [2] needs to be: [2] http://people.apache.org/~af/build.ziphttp://people.apache.org/build.zip instead of -- http://people.apache.org/build.zip http://people.apache.org/build.zip Yes, thank you. I am looking forward to checking this out. Great, but please be aware that this is just an experiment. At the moment it only works on Windows. -Andre The results are promising. It runs faster and the build.ninja generator looks more maintainable than our solenv/gbuild/... makefiles. But I am certainly biased. Before I give you some numbers, I should say that I have collected the numbers totally unscientifically and it may be necessary to add some missing steps to the ninja build. To the best of my knowledge all C++ files are compiled, libraries linked, resource files built, XML files copied. Only the single sw.component file somehow escaped. I ran my experiments on ani7 2.2GHz, 8GB notebook. Complete build of a clean module: gbuild about 9m30s (make -sr -j8) ninja about 7m15s (ninja) Cleaning up gbuild about 40s (make clean) ninja less then 1s(ninja -t clean) rebuild after touching one single header (sw/inc/section.hxx) gbuild about 1m10s (make -sr -j8) ninja about50s (ninja) Building an already built module (nothing to do): depends very much on whether the disk cache is warm or cold. Best times: gbuild more than 3s (make -sr -j8) ninjaabout 0.4s(ninja) Why is ninja faster than make/gbuild? - Make runs each recipe in its own shell (bash), ninja executes its command directly. - Ninja understands the header dependencies created by gxx/clang and msvc and stores them in a compact format that can be read in very fast on startup. - I avoided some steps of build that are unnecessary in ninja = Ninja creates directories for the targets it makes. Gbuild creates them explicitly. = GBuild first creates empty dependency files and later, in a second step, fills them with the actual dependency information created by one of the C/C++ compilers. But, for me, these numbers are just a welcome side effect. More important to me is maintainability. Ninja follows a very different approach from (GNU) make. Its lack of even simplest control structures such as if/then/else or foreach, requires the generation of the main makefile (by default that is called build.ninja) by program or script. This leads to my current approach: - Use XML to represent the static data (C++ files, libraries, resource files, XML files). - Use a Perl script to translate the XML files into the build.ninja file. The best tool for each job (XML: data representation, Perl: data processing). Instead of Perl we could use any language that is part of our current build requirements (Java, C/C++, Python (we would have to compile that first, though)). Look at the Perl files in [1] or [2] (build/source/ninja/*pm) and compare them to solenv/gbuild/*mk and see which you can understand better. I think this could be one way to set up a better maintainable build system that is even slightly faster then what we currently have. Best regards, Andre [1] http://people.apache.org/~af/build/ [2] http://people.apache.org/build.zip [3] http://martine.github.io/ninja/manual.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: My Windows Build Settings
On 23.01.2014 15:31, Rob Weir wrote: I've noticed a few questions recently about getting a Windows build environment set up. I'm not the world's greatest expert on this, but I was able to get a build running. If I can do it, then anyone can do it ;-) This was on a Windows 7 32-bit system, a clean OS install, with all current Windows patches. No VC++ installed, just the free SDK. Here are the commands I used, after installing the pre-req's: -- autoconf SDK_PATH=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0 SourceMain=`pwd` ./configure --with-frame-home=$SDK_PATH --with-psdk-home=$SDK_PATH --with-midl-path=$SDK_PATH/bin --with-directx-home=C:/Program Files/Microsoft DirectX SDK (June 2010) --with-ant-home=/cygdrive/c/ant --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2; --with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz; --enable-pch --disable-atl --disable-activex --disable-binfilter --without-junit You don't need --disable-binfilter anymore, binfilter has been removed. You also don't need --with-epm-url, epm is a *nix tool. Better use --with-nsis-path to create the EXE installer. Add --enable-category-b and --enable-bundled-dictionaries if you want the full feature set of OpenOffice. -Andre ./bootstrap source winenv.set.sh cd instsetoo_native/ build --all -- Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Reporting a problem with the OpenOffice website
On 23.01.2014 13:50, Sune Drougge wrote: My problem is with BASE. On opening a database BASE is indicating that I have 40 items and it indicate this as: 40* There are more items in the database and when pressing the button for last item ( | ) the rest of the items are shown. Can you help me or direct me to anyone that can? This is a know bug or a known feature, depending on who you ask [1] ( I tend to see it as a bug). The * means that the total number of the table rows is not yet known. I am sorry that I can not be of more help. -Andre [1] https://issues.apache.org/ooo/show_bug.cgi?id=22831 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Building sw/ with ninja
Not quite a week ago I wrote about an idea to use XML files to store the declarative part of our makefiles: dependencies of libraries on source files, which resources are to be created and so on. In the meantime I have found the time to do make (conduct?) an experiment. I am now able to build module sw from the XML files with the help of the ninja build 'system' [3]. Most of the work of converting the XML files into one single build.ninja file was done on one weekend. You can see the source code at [1] ([2] contains everything zipped together). The results are promising. It runs faster and the build.ninja generator looks more maintainable than our solenv/gbuild/... makefiles. But I am certainly biased. Before I give you some numbers, I should say that I have collected the numbers totally unscientifically and it may be necessary to add some missing steps to the ninja build. To the best of my knowledge all C++ files are compiled, libraries linked, resource files built, XML files copied. Only the single sw.component file somehow escaped. I ran my experiments on ani7 2.2GHz, 8GB notebook. Complete build of a clean module: gbuild about 9m30s (make -sr -j8) ninja about 7m15s (ninja) Cleaning up gbuild about 40s (make clean) ninja less then 1s(ninja -t clean) rebuild after touching one single header (sw/inc/section.hxx) gbuild about 1m10s (make -sr -j8) ninja about50s (ninja) Building an already built module (nothing to do): depends very much on whether the disk cache is warm or cold. Best times: gbuild more than 3s (make -sr -j8) ninjaabout 0.4s(ninja) Why is ninja faster than make/gbuild? - Make runs each recipe in its own shell (bash), ninja executes its command directly. - Ninja understands the header dependencies created by gxx/clang and msvc and stores them in a compact format that can be read in very fast on startup. - I avoided some steps of build that are unnecessary in ninja = Ninja creates directories for the targets it makes. Gbuild creates them explicitly. = GBuild first creates empty dependency files and later, in a second step, fills them with the actual dependency information created by one of the C/C++ compilers. But, for me, these numbers are just a welcome side effect. More important to me is maintainability. Ninja follows a very different approach from (GNU) make. Its lack of even simplest control structures such as if/then/else or foreach, requires the generation of the main makefile (by default that is called build.ninja) by program or script. This leads to my current approach: - Use XML to represent the static data (C++ files, libraries, resource files, XML files). - Use a Perl script to translate the XML files into the build.ninja file. The best tool for each job (XML: data representation, Perl: data processing). Instead of Perl we could use any language that is part of our current build requirements (Java, C/C++, Python (we would have to compile that first, though)). Look at the Perl files in [1] or [2] (build/source/ninja/*pm) and compare them to solenv/gbuild/*mk and see which you can understand better. I think this could be one way to set up a better maintainable build system that is even slightly faster then what we currently have. Best regards, Andre [1] http://people.apache.org/~af/build/ [2] http://people.apache.org/build.zip [3] http://martine.github.io/ninja/manual.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building sw/ with ninja
On 22.01.2014 14:45, Rob Weir wrote: On Wed, Jan 22, 2014 at 8:32 AM, Andre Fischer awf@gmail.com wrote: Not quite a week ago I wrote about an idea to use XML files to store the declarative part of our makefiles: dependencies of libraries on source files, which resources are to be created and so on. In the meantime I have found the time to do make (conduct?) an experiment. I am now able to build module sw from the XML files with the help of the ninja build 'system' [3]. Most of the work of converting the XML files into one single build.ninja file was done on one weekend. You can see the source code at [1] ([2] contains everything zipped together). The results are promising. It runs faster and the build.ninja generator looks more maintainable than our solenv/gbuild/... makefiles. But I am certainly biased. Before I give you some numbers, I should say that I have collected the numbers totally unscientifically and it may be necessary to add some missing steps to the ninja build. To the best of my knowledge all C++ files are compiled, libraries linked, resource files built, XML files copied. Only the single sw.component file somehow escaped. I ran my experiments on ani7 2.2GHz, 8GB notebook. Complete build of a clean module: gbuild about 9m30s (make -sr -j8) ninja about 7m15s (ninja) Cleaning up gbuild about 40s (make clean) ninja less then 1s(ninja -t clean) rebuild after touching one single header (sw/inc/section.hxx) gbuild about 1m10s (make -sr -j8) ninja about50s (ninja) Building an already built module (nothing to do): depends very much on whether the disk cache is warm or cold. Best times: gbuild more than 3s (make -sr -j8) ninjaabout 0.4s(ninja) Why is ninja faster than make/gbuild? - Make runs each recipe in its own shell (bash), ninja executes its command directly. - Ninja understands the header dependencies created by gxx/clang and msvc and stores them in a compact format that can be read in very fast on startup. - I avoided some steps of build that are unnecessary in ninja = Ninja creates directories for the targets it makes. Gbuild creates them explicitly. = GBuild first creates empty dependency files and later, in a second step, fills them with the actual dependency information created by one of the C/C++ compilers. But, for me, these numbers are just a welcome side effect. More important to me is maintainability. Ninja follows a very different approach from (GNU) make. Its lack of even simplest control structures such as if/then/else or foreach, requires the generation of the main makefile (by default that is called build.ninja) by program or script. This leads to my current approach: - Use XML to represent the static data (C++ files, libraries, resource files, XML files). - Use a Perl script to translate the XML files into the build.ninja file. The best tool for each job (XML: data representation, Perl: data processing). Instead of Perl we could use any language that is part of our current build requirements (Java, C/C++, Python (we would have to compile that first, though)). Look at the Perl files in [1] or [2] (build/source/ninja/*pm) and compare them to solenv/gbuild/*mk and see which you can understand better. I think this could be one way to set up a better maintainable build system that is even slightly faster then what we currently have. Do you get a sense for how well-maintained Ninja is? Are there many contributors? Many users? I only know that it was developed by/for the chrome project [4] and that cmake has support for ninja as back end. Are we confident it will be around in 5 years? I worry (but only a little) of another DMake. Then I probably should not tell you that I may make a similar experiment with tup as backend. -Andre [4] http://www.aosabook.org/en/posa/ninja.html [5] http://gittup.org/tup/ -Rob Best regards, Andre [1] http://people.apache.org/~af/build/ [2] http://people.apache.org/build.zip [3] http://martine.github.io/ninja/manual.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Building sw/ with ninja
On 22.01.2014 14:58, Andre Fischer wrote: On 22.01.2014 14:45, Rob Weir wrote: On Wed, Jan 22, 2014 at 8:32 AM, Andre Fischer awf@gmail.com wrote: Not quite a week ago I wrote about an idea to use XML files to store the declarative part of our makefiles: dependencies of libraries on source files, which resources are to be created and so on. In the meantime I have found the time to do make (conduct?) an experiment. I am now able to build module sw from the XML files with the help of the ninja build 'system' [3]. Most of the work of converting the XML files into one single build.ninja file was done on one weekend. You can see the source code at [1] ([2] contains everything zipped together). The results are promising. It runs faster and the build.ninja generator looks more maintainable than our solenv/gbuild/... makefiles. But I am certainly biased. Before I give you some numbers, I should say that I have collected the numbers totally unscientifically and it may be necessary to add some missing steps to the ninja build. To the best of my knowledge all C++ files are compiled, libraries linked, resource files built, XML files copied. Only the single sw.component file somehow escaped. I ran my experiments on ani7 2.2GHz, 8GB notebook. Complete build of a clean module: gbuild about 9m30s (make -sr -j8) ninja about 7m15s (ninja) Cleaning up gbuild about 40s (make clean) ninja less then 1s(ninja -t clean) rebuild after touching one single header (sw/inc/section.hxx) gbuild about 1m10s (make -sr -j8) ninja about50s (ninja) Building an already built module (nothing to do): depends very much on whether the disk cache is warm or cold. Best times: gbuild more than 3s (make -sr -j8) ninjaabout 0.4s(ninja) Why is ninja faster than make/gbuild? - Make runs each recipe in its own shell (bash), ninja executes its command directly. - Ninja understands the header dependencies created by gxx/clang and msvc and stores them in a compact format that can be read in very fast on startup. - I avoided some steps of build that are unnecessary in ninja = Ninja creates directories for the targets it makes. Gbuild creates them explicitly. = GBuild first creates empty dependency files and later, in a second step, fills them with the actual dependency information created by one of the C/C++ compilers. But, for me, these numbers are just a welcome side effect. More important to me is maintainability. Ninja follows a very different approach from (GNU) make. Its lack of even simplest control structures such as if/then/else or foreach, requires the generation of the main makefile (by default that is called build.ninja) by program or script. This leads to my current approach: - Use XML to represent the static data (C++ files, libraries, resource files, XML files). - Use a Perl script to translate the XML files into the build.ninja file. The best tool for each job (XML: data representation, Perl: data processing). Instead of Perl we could use any language that is part of our current build requirements (Java, C/C++, Python (we would have to compile that first, though)). Look at the Perl files in [1] or [2] (build/source/ninja/*pm) and compare them to solenv/gbuild/*mk and see which you can understand better. I think this could be one way to set up a better maintainable build system that is even slightly faster then what we currently have. Do you get a sense for how well-maintained Ninja is? Are there many contributors? Many users? I only know that it was developed by/for the chrome project [4] and that cmake has support for ninja as back end. Are we confident it will be around in 5 years? I worry (but only a little) of another DMake. Then I probably should not tell you that I may make a similar experiment with tup as backend. There are two different and independent ideas: - Use an easy to read data format for expressing module data (C++ files, libraries, etc.) that is independent from the actual build tool. - Use ninja as a back end. The first part is much easier to accomplish and enables us to make experiments regarding different back ends. Our current gbuild system would be a natural choice for the first back end. Pure make might be the second. And maybe ninja would be the third. -Andre -Andre [4] http://www.aosabook.org/en/posa/ninja.html [5] http://gittup.org/tup/ -Rob Best regards, Andre [1] http://people.apache.org/~af/build/ [2] http://people.apache.org/build.zip [3] http://martine.github.io/ninja/manual.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr
