Re: scripts to assist in editing helpcontent2
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/ ? Best regards, Oliver - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
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: scripts to assist in editing helpcontent2
On 30 January 2014 09:19, Andre Fischer awf@gmail.com wrote: 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/ I understand it more as a script for people adding new items. so devtools would be the best place. rgds jan I. -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
Re: Building on Mac
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. 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. 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. 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. 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. 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. Herbert - 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
Newbie to openoffice
Hi, I am kamini from India.I am an engineering graduate and have been working in the field of software Testing since 5 years. I found openoffice to be quite exciting as its an open source application development. Looking forward to join the QA team so I learn more on testing and an opportunity to work with people around the globe. Regards, Kamini.
Re: Newbie to openoffice
Hi, KAMINI Welcome to join in QA team If you have interest on AOO 4.1 FVT, please send your platform and Testlink ID (if you haven't a Testlink account, you can register one[1]), and I will assign test cases to you. You should also get installation sets from dev snapshot [2] and report issues in Bugzilla [3] [1]http://aootesting.adfinis-sygroup.org/index.php [2]http://ci.apache.org/projects/openoffice/#linsnap [3] https://issues.apache.org/ooo/ Thank you! On Thu, Jan 30, 2014 at 5:21 PM, Kamini Bonde kamini.bend...@gmail.comwrote: Hi, I am kamini from India.I am an engineering graduate and have been working in the field of software Testing since 5 years. I found openoffice to be quite exciting as its an open source application development. Looking forward to join the QA team so I learn more on testing and an opportunity to work with people around the globe. Regards, Kamini.
Beaten on our own turf ??
Hi. There are about 2 days left of call for papers to apacheCon Denver call for papershttp://events.linuxfoundation.org/events/apachecon-north-america/program/cfp apachecon 2014 http://www.apachecon.com/ Can it really be correct, that we are our representation at our own conference is at minimum ? All of you who consider going, should also consider giving a presentation. There are room for 150 talks in total, so everything is welcome. A talk about how do we cope with milllions of users, would be interesting for a lot of other apache projects (and maybe give us more understanding for our sometimes special needs). A talk about our ecosystem, our presence in the social media etc, would be equally interesting. I cannot participate, but I help behind the scenes, and I promise to make up for when apacheCon EU rolls out (it is now a fact that it will come this autumn, city and time is still being negotiated). If anybody want to give a presentation, but need help, please email me directly, and I will try to help as much as I can. Please lets show how big a project and ecosystem we are, submit a talk. rgds jan Iversen.
Updated download count, just in time for Fosdem
For anyone putting together slides for Fosdem, last night the count reached 89,574,732. We should hit 90 million by Saturday February 1st. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: scripts to assist in editing helpcontent2
On Thu, Jan 30, 2014 at 12:19 AM, Andre Fischer awf@gmail.com wrote: 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 It doesn't make building easier -- the entries just show which ids have already been used for bookmark, paragraph and header ids so these values will not be reused. If you look at the content of the .xhp files in helpcontent2, you'll see what I'm talking about. I will make the script a little nicer and think about devtools. 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 -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: 64bit Mac crashs often after start
Hi Herbert, could you please point out where the MacOSX crash reports are located? Experiencing an exception in the awt event thread when loading a scripting engine and running a macro via the Java based scripting engine (latest, 64 bit AOO on MacOSX). Would like to submit it with a bug report. TIA Rony G. Flatscher (mobil/e) Am 29.01.2014 um 08:40 schrieb Herbert Duerr h...@apache.org: Hi Raphael, On 01/29/2014 08:07 AM, Raphael Bircher wrote: I recognise that the OSX 4.0.1 often crachs after start. It is not realy reproducible, but I have the feeling that there is something wrong. I just whant to let you know, so we can keep a eye on this. System: 10.9 Mavericks. I will try to get more information about this behavior The Mac crash reporter will have some interesting details about this. Please copy and paste such a report into a text document and attach it to a new issue. I also suggest to experiment with enabling/disabling extensions, the update checker and with the java settings. 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: scripts to assist in editing helpcontent2
We have other issue about help content: https://issues.apache.org/ooo/show_bug.cgi?id=123246 - Mail original - De: Andre Fischer awf@gmail.com À: dev@openoffice.apache.org Envoyé: Jeudi 30 Janvier 2014 09:19:55 Objet: 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: scripts to assist in editing helpcontent2
On Thu, Jan 30, 2014 at 11:57 AM, FR web forum ooofo...@free.fr wrote: We have other issue about help content: https://issues.apache.org/ooo/show_bug.cgi?id=123246 OK. Thanks for this... - Mail original - De: Andre Fischer awf@gmail.com À: dev@openoffice.apache.org Envoyé: Jeudi 30 Janvier 2014 09:19:55 Objet: 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: switch trunk from Mac 32bit to 64bit
Am 01/30/2014 08:38 AM, schrieb Oliver-Rainer Wittmann: Hi Markus, below you find the output of my iMac running Mac OS X 10.7 thanks for the 10.7 data. At least here I can do some scripting changes. From my point of view it should be assured that Mac users running Mac OS X 10.6 or earlier are _not_ directed to a download of AOO 4.1. Instead they should be directed to AOO 4.0.1 together with a note saying that AOO 4.1 needs Mac OS X version 10.7 or later. This depends on when 4.0.1 will be available in the archive. So, let's see what will be possible. Nevetheless, as I don't know if older and newer browsers than 10.7 identifying itself in the same way, I need more data. @Oliver: Can you help me here, too? Thanks Marcus On 28.01.2014 23:24, Marcus (OOo) wrote: Am 12/20/2013 02:47 PM, schrieb Herbert Duerr: On 19.12.2013 17:58, jan i wrote: On 19 December 2013 17:29, Herbert Duerr hdu_...@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. +1 Do we also need to update information on the download page (e.g. that we only support OSX 10.7 and up) ? As Jürgen already mentioned the installation files are already protected. We should also update the release notes, etc. If it is possible to know the OS version from e.g. the browser's User Agent then we should update the download page too. Maybe we already have such a mechanism. Does anyone happen to have OSX 10.3 or earlier? What happens when you go to the OpenOffice download page? Good point. Can someone help me and test the download webpage with different OSX versions? I need the user agent text fromthe used browsers (Firefox and Safari). Or better, please use this webpage and send me the raw data from the table: http://www.openoffice.org/download/test/analyze.html If there is a way to recognize the differences, then I can build something around the scripting. Otherwise I would suggest a general hint text when OSX in general was detected. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Reporting a problem with the OpenOffice website
I have been using OpenOffice for a few years, originally the Sun Microsystems official version. Since installing 4.0.1 I have been unable to get any work done as OpenOffice crashes almost immediately no matter what file I open. Proceeds to file recovery than crashes again. I have read everything I can understand in the user help section and can not fix the issue. I uninstalled 4.0.1 and installed the previous version 3.4.? but now it crashes also. I must abandon use of this product as it prevents me from accomplishing useful work. This is a very large and complex product and would be wonderful if it worked. For future users perhaps you should concentrate on the fundamentals, stability and ease of updating. Richard Tomlinson - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bottom up build
On Wed, Jan 29, 2014 at 1:54 AM, jan i j...@apache.org wrote: On 29 January 2014 10:18, 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. It's really interesting to read these observations and test cases... we have a large and complicated source tree and just seeing what can be observed about it is fascinating to me. Thanks for writing down your observations which I find highly interesting. I hope your stop on writing about build does not include giving your opinion on my ideas in the future as well. For the record the capstone project, and my little hobby project Build R.I.P. follow a third idea: We have a clear seperation of module build and central (total) build. +1 I would certainly go for this. A while back someone asked about ye olde ld approach -- all modules compiled/built and then linked later down the road. If we could somehow do something to get back to that idea in a more friendly modern way, it would certainly make working on specific areas more feasible.
Sketches and diagrams in open source software development
Hello everybody, I'm a Ph.D. student at the Software Engineering Group of Trier University (Germany). Our group is currently investigating the use of sketches and diagrams in software development. I'm especially interested in how software developers create, use, and share sketches and diagrams in large open source projects like Open Office. I write to this mailing list to ask for hints on where to find sketches and diagrams related to the development of Open Office (maybe your version control system, bug tracking system, or wiki?). I'm primarily looking for sketches and diagrams directly related to source code (e.g. architecture diagrams, sketches visualizing a bug or a certain data structure). Thank you for any help you can provide! Best regards, Sebastian smime.p7s Description: S/MIME Cryptographic Signature
Re: Bottom up build
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. Otherwise I wonder if we're trying to optimize a bubble sort? -Rob 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Bottom up build
On 30 January 2014 23:10, Rob Weir robw...@apache.org 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. Have read it, the book goes more into C++ structures and design, than the actual build process. If you have a pure C++ project, you can do a lot of speed improvement by definining the classes for speed instead of purity. Its quite a good book, but have very little for the AOO build system. Otherwise I wonder if we're trying to optimize a bubble sort? No we are trying to moving away from 3-4 build components trying to do the same thing and each sub-optimized. In other words, our
New to openoffice
Hi all, I am new to openoffice, Infact i am new to opensource development can anyone pleas suggest me where and how to start. Thanks in advance. Aayush.
Re: Updated download count, just in time for Fosdem
Yes, numbers of downloads is very stabile in last several months: about 5 milion downloads per month. Regards, Wlada 2014-01-30 Rob Weir robw...@apache.org For anyone putting together slides for Fosdem, last night the count reached 89,574,732. We should hit 90 million by Saturday February 1st. Regards, -Rob - 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
I'm sorry to hear you are having a stability problem. Please try resetting your user profile as explained in this tutorial on the user forum: https://forum.openoffice.org/en/forum/viewtopic.php?f=74t=12426 You don't need to register on the forum to read it. Best regards, Francis On Thu, Jan 30, 2014 at 2:54 PM, Richard Tomlinson rich...@tomlinson.netwrote: I have been using OpenOffice for a few years, originally the Sun Microsystems official version. Since installing 4.0.1 I have been unable to get any work done as OpenOffice crashes almost immediately no matter what file I open. Proceeds to file recovery than crashes again. I have read everything I can understand in the user help section and can not fix the issue. I uninstalled 4.0.1 and installed the previous version 3.4.? but now it crashes also. I must abandon use of this product as it prevents me from accomplishing useful work. This is a very large and complex product and would be wonderful if it worked. For future users perhaps you should concentrate on the fundamentals, stability and ease of updating. Richard Tomlinson - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: New to openoffice
On Thu, Jan 30, 2014 at 2:22 PM, Aayush Yadav aayushyadav...@gmail.comwrote: Hi all, I am new to openoffice, Infact i am new to opensource development can anyone pleas suggest me where and how to start. Thanks in advance. Aayush. Hello and welcome -- You could start by taking a look at our Orientation modules -- http://openoffice.apache.org/orientation/index.html This series will describe how OpenOffice works within the context of the Apache Software Foundation but also has some links to general information about participating in any open source project. -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: Beaten on our own turf ??
jan i wrote: Can it really be correct, that we are our representation at our own conference is at minimum ? All of you who consider going, should also consider giving a presentation. I definitely share the recommendation, but it is known that European events attract more talks in our case. I think the situation wasn't much different last year, honestly, with only a couple talks at ApacheCon US and more activity at FOSDEM just a few weeks before that. And we had a full day programme at ApacheCon Europe last time it was held (November 2012). Please lets show how big a project and ecosystem we are, submit a talk. We have many ways to show how big we are. I attend events every time it makes sense to be there, sure. ApacheCon, with a non-trivial admission fee for the general public (up to 1400$), is hardly an event where one can expect to enlarge the community or create awareness outside of the people who are already active in Apache. For those who haven't looked at http://events.linuxfoundation.org/events/apachecon-north-america/attend/register I must say that committers can enjoy a very good discount this year, with the committer fee at 275$. So US-based people, and especially US-based committers, should definitely not miss ApacheCon US, and while at it propose a talk: OpenOffice has a lot of peculiarities that other Apache community members can be interested in. For Europe-based people, ApacheCon EU 2014 will be a more convenient occasion... but if someone can do both, wonderful! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Beaten on our own turf ??
On Thu, Jan 30, 2014 at 4:57 PM, Andrea Pescetti pesce...@apache.orgwrote: jan i wrote: Can it really be correct, that we are our representation at our own conference is at minimum ? All of you who consider going, should also consider giving a presentation. I definitely share the recommendation, but it is known that European events attract more talks in our case. I think the situation wasn't much different last year, honestly, with only a couple talks at ApacheCon US and more activity at FOSDEM just a few weeks before that. And we had a full day programme at ApacheCon Europe last time it was held (November 2012). Please lets show how big a project and ecosystem we are, submit a talk. We have many ways to show how big we are. I attend events every time it makes sense to be there, sure. ApacheCon, with a non-trivial admission fee for the general public (up to 1400$), is hardly an event where one can expect to enlarge the community or create awareness outside of the people who are already active in Apache. For those who haven't looked at http://events.linuxfoundation.org/events/apachecon-north- america/attend/register I must say that committers can enjoy a very good discount this year, with the committer fee at 275$. Thanks for sharing this -- I don't think we've received any widespread notification of this discount. So US-based people, and especially US-based committers, should definitely not miss ApacheCon US, and while at it propose a talk: OpenOffice has a lot of peculiarities that other Apache community members can be interested in. For Europe-based people, ApacheCon EU 2014 will be a more convenient occasion... but if someone can do both, wonderful! Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Cats do not have to be shown how to have a good time, for they are unfailing ingenious in that respect. -- James Mason
Re: [Bugzilla] Proposal: Further value for field Version - namely pre 3.4.0
Hi, On 22.01.2014 11:06, Oliver-Rainer Wittmann wrote: Hi, On 18.01.2014 01:20, Andrea Pescetti wrote: Oliver-Rainer Wittmann wrote: I would like to tag issues which occurs in pre 3.4.0 version appropriately This would be helpful for me too. Probably two new categories: - 3.3.0 or earlier - 3.4.0-beta This would allow to file all bugs appropriately. The latter category would be useful only for QA purposes, I believe 3.4.0-beta does not have a significant number of users. We have the version field for (in theory) the first version containing the bug (in practice, most people set it to the version where they observed the bug). Then we have the Latest confirmation on field to check whether the bug still applies to the latest release. No objections have been raised in the last days. Thus, could someone with corresponding karma create the following new values for field Version in Bugzilla: - 3.3.0 or earlier - 3.4.0-beta Could someone please work on this. Thx in advance. Best regards, Oliver. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
