Re: [dev] HG service down?
Hi Pavel, a significant part of the site where hg.services.openoffice.org is hosted has problems with outbound network traffic, probably a router is down or something. It's not specific to our hg service, a number of other services are affected as well. The ticket says they are working on it, I guess the service will be back soon. Sorry for the inconvenience. Heiner On 11/10/2010 04:51 PM, Pavel Laštovička wrote: Hello, what has happened with hg.services.openoffice.org? I cannot even ping it. Pavel Laštovička -- Jens-Heiner Rechtien | Release Engineer Oracle Office GBU ORACLE Deutschland B.V. Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Please note: DEV300: gcc-3.4.x support discontinued
Hi, with the OOO330 branch-off done we can finally drop support for all versions of gcc-3 including gcc-3.4.x on DEV300 - please see: http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Working with OOO330 and DEV300
Hi, as already announced, we'll branch off OOO330 (OOo-3.3 release code line) from DEV300 (main development code line) after the finalization of milestone DEV300 m84. Release Engineering will handle the migration of OOO330 release code line bug fixes/changes to DEV300 slightly different this time. This should not affect development in any way, but it might be worthwhile to be aware of the change. Since the introduction of the CWS system many years ago RE merged each release code line CWS individually into the main code line. This worked usually quite well but was occasionally a bit tedious. From now on we'll pull/merge summarily all OOO330 changesets into DEV300 as first thing at the start of a new DEV300 milestone. This ensures that there is no way that an OOO330 CWS or masterfix is forgotten. We also won't need to track the integrate status of each OOO330 CWS for DEV300 anymore, thus there will be no more new mycws_DEV300 entries in EIS. But wait, what if some OOO330 changesets should not be merged in DEV300? These changesets will be either dummy merged* into DEV300 or merged and immediately backed out with an inverse patch. Thus *all* OOO330 changesets will be in DEV300 but a few of them might not have an effect on the code line. Please, if you have OOO330 stuff which shouldn't be applied on DEV300 bundle it in it's own dedicated CWS and tell us about it (email and CWS comment) so that we can pull and dummy merge this CWS first before we get the changesets via the summarily pull/merge of the latest OOO330 milestone. This approach doesn't differ from what we had before - we always demanded that a CWS is either completely merged or not at all - and experience tells us that it's seldom a problem. What happens if the release code line and the development code line differ so much that pull/merging OOO330-DEV300 results in conflicts that RE can't easily resolve? Well, RE might ask you to update your (already OOO330 integrated) CWS with the latest stuff from DEV300 which is then pull/merged by us before the rest of OOO330 is pull/merged. So it might be a wise idea to not immediately delete your local copy of your freshly integrated OOO330 CWS - just wait until the stuff is also in DEV300. Anyway, it's still a bad idea to do wild feature development/restructuring/refactoring on a release code line but now you and not RE will do the cleanup :-) Lastly: RE will do always complete builds on DEV300 milestones from now on. No need to mark modules as incompatible anymore on DEV300. OOO330, on the other hand, is handled like before. Best regards, Heiner *) dummy merge: pull a few changesets and configure in .hgrc [ui] merge = internal:local before doing the merge. This way all changes from the pulled changesets are discarded but the changesets are still recorded as merged. -- Jens-Heiner Rechtien jens-heiner.recht...@sun.com Registered Office: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Commercial register of the Local Court of Munich: HRB 161028 Managing Directors: Jürgen Kunz - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] The OOo HG and SVN server is down
Hi, the OpenOffice.org SCM server for the Mercurial and Subversion repositories is down. Other services (for example the OpenGrok indexer) hosted on the server are affected as well. We are working on this. Sorry for the inconvenience, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Large source file
Hi, Thorsten Behrens wrote: Pavel Janík wrote: does this file make sense in the source code? -rw-r--r--1 pavelpavel75159156 Apr 21 18:35 sdext/source/pdfimport/xpdftest/binary_1_out.def Oh ... please don't do this. Things like this kill every effort to speed up the handling of the sources. Hi Pavel, good catch, was not aware this was/grew *that* large - one option would be to distill book.pdf (same dir) into a similarly-representative testcase, another is somewhat lamer, but equally effective: pack all *.def files with gzip, apply attached patch. $ du -sb sdext/source/pdfimport/xpdftest/ 3835812 sdext/source/pdfimport/xpdftest/ The hg storage is already compressed. This buys nothing for the cloning operations, in fact it goes a long way to make it even worse. Please don't do this. I would rather live with a 75 MB Blob in the working directory. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Problems building OOO320_m14 on Windows.
Hi Kristján, what most developers do is, strangely, written in a footnote in the windows build section. http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows#cite_note-Foot8-7 But it doesn't really signify, doing a 'dmake' in SRC_ROOT is documented in the build guide and thus should work as well. Regards, Heiner Kristján Bjarni Guðmundsson wrote: Hi Heiner. So what build system should I have been using? I was simply using the guide available here: http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows dmake seems to create makefile.mk from the makefile.rc file.and this is then called from dmake. Are there some switches I am missing? - - - - - - - - - Áframsendur póstur - - - - - - - - - - From: Jens-Heiner Rechtien jens-heiner.recht...@sun.com To: dev@openoffice.org Date: Tue, 30 Mar 2010 16:22:53 +0200 Subject: Re: [dev] Re: Problems building OOO320_m14 on Windows. Hi Kristján, both the CWS changefileheader3 and the OOO320 milestone m14 have certainly been build several times before release. It's just that only very few developers still use the ancient makefile.rc - a nice example for the evils of having multiple build systems. I wasn't even aware that it still exists ... Will be fixed in the next milestone. Regards, Heiner Kristján Bjarni Guðmundsson wrote: Ok I see the problem now, it seems that the makefile.rc was messed up when changing copyright notice and invalid remarks where created: http://hg.services.openoffice.org/OOO320/diff/659920c8492d/makefile.rc This means that the current OOO320_m14 release can't be built directly from source without first fixing makefile.rc. This is amazing, no one has actually tried to test build the release? Þann 29. mars 2010 20:51, skrifaði Kristján Bjarni Guðmundsson kristjanbja...@gmail.com: I am trying to build OOO320_m14 on Windows in CygWin 1.5.25 Here is my configure: ./configure \ --disable-nss-module \ --with-use-shell=bash \ --disable-activex \ --disable-directx \ --disable-epm \ --disable-atl \ --disable-build-mozilla \ --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC \ --with-ant-home=/cygdrive/c/Winapps/Java/ant \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1/Bin \ --with-asm-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/Bin \ --with-jdk-home=/cygdrive/c/Winapps/Java/jdk16 \ --with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5 After running dmake I get this error: dmake: makefile.mk: line 3: Warning: -- Duplicate target [OR] dmake: makefile.mk: line 3: Error: -- Expecting macro or rule defn, found neither Can somebody help me with this? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Problems building OOO320_m14 on Windows.
Hi Kristján, both the CWS changefileheader3 and the OOO320 milestone m14 have certainly been build several times before release. It's just that only very few developers still use the ancient makefile.rc - a nice example for the evils of having multiple build systems. I wasn't even aware that it still exists ... Will be fixed in the next milestone. Regards, Heiner Kristján Bjarni Guðmundsson wrote: Ok I see the problem now, it seems that the makefile.rc was messed up when changing copyright notice and invalid remarks where created: http://hg.services.openoffice.org/OOO320/diff/659920c8492d/makefile.rc This means that the current OOO320_m14 release can't be built directly from source without first fixing makefile.rc. This is amazing, no one has actually tried to test build the release? Þann 29. mars 2010 20:51, skrifaði Kristján Bjarni Guðmundsson kristjanbja...@gmail.com: I am trying to build OOO320_m14 on Windows in CygWin 1.5.25 Here is my configure: ./configure \ --disable-nss-module \ --with-use-shell=bash \ --disable-activex \ --disable-directx \ --disable-epm \ --disable-atl \ --disable-build-mozilla \ --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC \ --with-ant-home=/cygdrive/c/Winapps/Java/ant \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1/Bin \ --with-asm-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/Bin \ --with-jdk-home=/cygdrive/c/Winapps/Java/jdk16 \ --with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5 After running dmake I get this error: dmake: makefile.mk: line 3: Warning: -- Duplicate target [OR] dmake: makefile.mk: line 3: Error: -- Expecting macro or rule defn, found neither Can somebody help me with this? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: Problems building OOO320_m14 on Windows.
Hi, makefile.rc now fixed in the repository. Regards, Heiner Jens-Heiner Rechtien wrote: Hi Kristján, both the CWS changefileheader3 and the OOO320 milestone m14 have certainly been build several times before release. It's just that only very few developers still use the ancient makefile.rc - a nice example for the evils of having multiple build systems. I wasn't even aware that it still exists ... Will be fixed in the next milestone. Regards, Heiner Kristján Bjarni Guðmundsson wrote: Ok I see the problem now, it seems that the makefile.rc was messed up when changing copyright notice and invalid remarks where created: http://hg.services.openoffice.org/OOO320/diff/659920c8492d/makefile.rc This means that the current OOO320_m14 release can't be built directly from source without first fixing makefile.rc. This is amazing, no one has actually tried to test build the release? Þann 29. mars 2010 20:51, skrifaði Kristján Bjarni Guðmundsson kristjanbja...@gmail.com: I am trying to build OOO320_m14 on Windows in CygWin 1.5.25 Here is my configure: ./configure \ --disable-nss-module \ --with-use-shell=bash \ --disable-activex \ --disable-directx \ --disable-epm \ --disable-atl \ --disable-build-mozilla \ --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC \ --with-ant-home=/cygdrive/c/Winapps/Java/ant \ --with-frame-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-psdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1 \ --with-midl-path=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1/Bin \ --with-asm-home=/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/Bin \ --with-jdk-home=/cygdrive/c/Winapps/Java/jdk16 \ --with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5 After running dmake I get this error: dmake: makefile.mk: line 3: Warning: -- Duplicate target [OR] dmake: makefile.mk: line 3: Error: -- Expecting macro or rule defn, found neither Can somebody help me with this? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] ANNOUNCEMENT: OOO320 release code line goes Mercurial
ANNOUNCEMENT: OOO320 release code line goes Mercurial = With the OOo 3.2 release safely out of the door we'll switch the OOO320 release code line (or rather now: maintenance code line) to Mercurial. The next milestone on this code line will be Mercurial only. Please find the OOO320 repository here: http://hg.services.openoffice.org/OOO320 A nightly mercurial bundle for speedier download can be found here http://hg.services.openoffice.org/bundle/OOO320.hg Starting with the next milestone OOO320 m13 you should be able to work with this code line in the same fashion as you do with the DEV300 code line. If you need a CWS on OOO320 m12 basis now (or if you have an existing CWS already) you can and should stay with SVN. We'll do the migration SVN-HG when your CWS is nominated for integration. In the case that you need to update a SVN based CWS to a milestone OOO320 m13 or later (very rare on this code line), please mail me (h...@openoffice.org) and we'll arrange for the migration. Best regards, Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] Please read: SVN and HG server maintenance
Hi, the new disk has been successfully installed and the RAIDZ pool on the system has been resilvered. The OOo SCM server is now again working with full speed and reliability. Regards, Heiner Jens-Heiner Rechtien wrote: Hi, the OpenOffice.org SCM server for HG and SVN (hg.services.openoffice.org, svn.services.openoffice.org) will be rebooted tonight (Dec. 21/22, around midnight CET) for disk replacement. This will take just a few minutes. Hot swapping the disk should have worked, but failed for some reasons. The broken disk was also responsible for the terrible performance of the server in the last few days. It's now taken offline until the replacement, so performance should be almost nominal. Please don't schedule long running HG or SVN jobs today and do not access the HG or SVN services during the reboot. Thanks Heiner - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Please read: SVN and HG server maintenance
Hi, the OpenOffice.org SCM server for HG and SVN (hg.services.openoffice.org, svn.services.openoffice.org) will be rebooted tonight (Dec. 21/22, around midnight CET) for disk replacement. This will take just a few minutes. Hot swapping the disk should have worked, but failed for some reasons. The broken disk was also responsible for the terrible performance of the server in the last few days. It's now taken offline until the replacement, so performance should be almost nominal. Please don't schedule long running HG or SVN jobs today and do not access the HG or SVN services during the reboot. Thanks Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Eric, looks fine and I'm looking forward to that ClassRoom. Regards, Heiner eric.bachard wrote: Hello Heiner, Jens-Heiner Rechtien a écrit : Migration to Mercurial == OpenOffice.org developers, here - as promised - some information about the migration of the DEV300 code line to Mercurial. First, thanks a lot for your great and impressive work :-) [...cut the announce... ] As we discussed, I have added Migration to Mercurial presentation we planned together in the Education Project ClassRoom agenda : http://wiki.services.openoffice.org/wiki/Education_ClassRoom/Agenda Please verify nothing is wrong, and thanks again for your participation ! Eric P.S. for Björn : a student from UTBM (Mathieu Paret, on CC) is currently working on the Education Project wiki page improvement, and we'll modernize a bit soon. If you want to discuss more about this topic, we can meet us on IRC ( #education.openoffice.org ) - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: [...] As shown, theres a way to do that. However, this local repository now contains multiple heads. Do NOT DARE to hg push --force these multiple heads to an outgoing repository or the wrath of RelEng will be upon you. You have been warned(*) ;-) Best Regards, Bjoern (*) At least twice, as the docs say this pretty clearly at: http://wiki.services.openoffice.org/wiki/MercurialCws#Publishing_changes Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Bjoern, thanks, this is looking way better and is much more usable. Regarding your idea with reorganizing the pages. I like that :-). Maybe we could just forward the old pages to the new ones (only the OOo and Mercurial one, no need to bother with rest). Regards, Heiner bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Tue, 27 Oct 2009 04:42:37 -0400 T. J. Frazier tjfraz...@cfl.rr.com wrote: Jens-Heiner Rechtien wrote: Migration to Mercurial == [snip...] Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Bj__rn has done a beautiful job of adding a TOC for the Mercurial pages. Yeah, sorry. I could not keep my hands of it ;-) (and I really just found a template to copy'n paste) The one problem I see is, will potential users be able to find it? Please think about where developers would look for this info, then add links there. I added one on the main wiki page. As of now it is linked from: - Main Page - Main Page - I want to be an OpenOffice.org developer - Main Page - Build Environment Effort - Main Page - Building Guide - Category:Mercurial - Category:SCM - Category:Development (Entry Page only) - Category:CWSTooling (were relevant) - I did not add Category:Build System and Category:Quality Assurance to not dilute them. Anything missing? Actually I think in the long run (in 6 month, after migration), it would not need to be on the Main Page anymore as current devs would know about it and newcomers will find it in the I want to be ... and Building Guide Pages. But now, its great to have it on the frontpage. Thanks for adding it! Best Regards, Bjoern Michaelsen P.S.: I was wondering if it would be a good idea to move the pages to subpages matching their current title. Of course one would keep the redirects from the historic titles to keep the links from the Mailing Lists working. OOo and Mercurial - Mercurial/Getting Started MercurialCws - Mercurial/CWS MercurialTipsAndTricks - Mercurial/TipsAndTricks MercurialMigration - Mercurial/Migration Opinions? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Announcement: Migration to Mercurial
Hi Bjoern, let's see if there are accidental new heads on the outgoing repository. No need to have a hook for something that never happens anyway. Best regards, Heiner bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On Tue, 27 Oct 2009 14:22:31 +0100 Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: Actually, I'm thinking about a hook which will prevent the creation of new heads on the outgoing repositories. Not yet implemented, though. This time, unlike last time, I am against such a hook. ;-) If somebody creates multiple heads on an outgoing repo, no harm was done to the master. This is different than with SVN. However, it has to be clear that such a repo will never be integrated unless all heads are merged. Still, having such repos on outgoing might be of value for experimental minibranches, where one is not certain if they might get integrated one day. When those are on outgoing repos: - They are on backup as long as it is uncertain if they will make it to the master. - They can be easily merged into real cws for integration once they seem fit for it. - They can be simply deleted with the repo if they prove faulty. Nothing of value will be lost. If you want to make absolutely clear that a cws wont be integrated when its repo has multiple heads, I would propose to add another Test to EIS showing this nifty stopsign and scary red boxes, if the cws repo has multiple heads. Best Regards, Bjoern Michaelsen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Announcement: Migration to Mercurial
Migration to Mercurial == OpenOffice.org developers, here - as promised - some information about the migration of the DEV300 code line to Mercurial. The next milestone DEV300 m63 will be the last milestone published via SVN. Newer milestone will only be available from the Mercurial repository (http://hg.services.openoffice.org/DEV300). The SVN server will still be available for some time to come. Please continue your work on your existing SVN hosted child workspaces as usual. You don't need to migrate your CWS immediately. You are only required to migrate your CWS if you need to update it to DEV300 m64 or later. Please see the migration guide for details. From now on, new child workspaces should be Mercurial hosted. You will still be able to create a new DEV300 m63 based SVN hosted child workspace, but this just means unnecessary migration work later. Please don't hesitate to contact me per email or IRC if you have questions. My IRC nick is 'blauwal'. Documentation: -- Main entry point: http://wiki.services.openoffice.org/wiki/Mercurial Setting up Mercurial: http://wiki.services.openoffice.org/wiki/Setting_up_Mercurial Basic hg usage: http://wiki.services.openoffice.org/wiki/OOo_and_Mercurial CWS handling: http://wiki.services.openoffice.org/wiki/MercurialCws Migrating child workspaces to Mercurial: http://wiki.services.openoffice.org/wiki/MercurialMigration If you find errors in the documentation, not just technical errors but also embarrassing spelling and grammar mistakes, please feel free to correct them. It's a Wiki after all. Regards, Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Announcement: OpenOffice.org development switches to Mercurial as SCM
ANNOUNCEMENT OpenOffice.org developers, I'm very pleased to announce, that after five months of piloting, implementation and and testing, we are finally ready to switch OpenOffice.org development to Mercurial (hg) as our SCM (Source Code Management) tool. Mercurial is a modern and flexible distributed SCM tool with the fast and convenient merging capability which is so required for OOo development. We have chosen Mercurial out of the three major open source DSCM tools available (Git, Bazaar and Mercurial) because we believe that its combination of ease of use, flexibility and performance fits best with the overall OOo needs. We are well aware that a slightly different emphasis on the selection criteria might well have led to a choice of Git or Bazaar, which are both very capable DSCMs as well. Details: We'll switch the DEV300 development code line first, the OOO320 (OpenOffice.org 3.2 release code line) will follow later. We certainly don't want to interfere with the OOo 3.2 release. The DEV300 switch will happen around the 26th of October. The current DEV300 hg mirror repository on hg.services.openoffice.org will be elevated to *the* reference repository, where release engineering pushes released milestones. Simultaneously release engineering will stop to commit new milestones to the current Subversion (svn) trunk. Please stay tuned! During the course of the next two weeks I'll make a number of announcements regarding the switch to Mercurial: - where to find documentation - which will be the last svn based milestone - conversion of child workspaces to hg - conventions which we will use Regards Heiner -- Jens-Heiner Rechtien OpenOffice.org release engineer h...@openoffice.org jens-heiner.recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] should we drop gcc3 support ?
Hi Christian, Christian Lohmaier wrote: Hi *, On Wed, Sep 30, 2009 at 8:45 PM, Jens-Heiner Rechtien jens-heiner.recht...@sun.com wrote: there is not yet a need to drop gcc-3.4 support I think, the usual compile problems happen with gcc-3.3 or older versions. GCC made a major (and very necessary) parser update from 3.3 to 3.4 and should have bumped up the major version at that time. We have discussed dropping gcc-3.3 support for quite some time now, but we refrained from officially obsoleting it because OS/2 and MACOSX 10.3 support still depend on gcc-3.3, Aqua-OOo is not supported on Mac OS X 10.3 - at least I don't know anyone who ever did an aqua build that would run on 10.3. So dropping gcc-3.3 would only affect X11-MacOSX. Is that one still relevant at all? Does it still work? Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [porting-dev] MinGW port build guide
Hi Takashi, the OpenOffice.org build guide in the Wiki is licensed under PDL, you can do with it pretty much what you want as long as the resulting document stays under PDL and it's clear where it did come from and what your modification are. Of course, IANAL. The exact terms can be found here: http://www.openoffice.org/licenses/PDL.html As for the format: you could use the Sun WikiPublisher extension, to be found here: http://extensions.services.openoffice.org/project/wikipublisher Pure HTML as exported from Writer(web) is not that convenient in a Wiki. Regards, Heiner Takashi Ono wrote: Hi all, OOo is now can be built with MinGW compiler and I wish build guide for it can be added to OOo-Wiki. I have already made a draft by copying existing Windows build guide and edited it with OOo-writer(web) as I am not accustomed to MediaWiki nor Wiki updating. I would like to get experts' comment how should I proceed. Is it OK to disclose my draft calling for comment, from Licensing point of view? Best Regards, Takashi Ono (t...@openoffice.org) - To unsubscribe, e-mail: dev-unsubscr...@porting.openoffice.org For additional commands, e-mail: dev-h...@porting.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] should we drop gcc3 support ?
Hi, there is not yet a need to drop gcc-3.4 support I think, the usual compile problems happen with gcc-3.3 or older versions. GCC made a major (and very necessary) parser update from 3.3 to 3.4 and should have bumped up the major version at that time. We have discussed dropping gcc-3.3 support for quite some time now, but we refrained from officially obsoleting it because OS/2 and MACOSX 10.3 support still depend on gcc-3.3, at least according to this list: http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers The deal up to now was, that for active development we don't care much about testing buildability with the stoneage gcc-3.3 versions but would accept patches from the port-maintainers to re-enable building with it. It was also understood that we wouldn't make sweeping changes to accommodate gcc-3.3 anymore. Certainly a gcc-3.3 build failure is *no* reason for a Prio 1 task. Regarding gcc-3.4: it seems that older *BSD still rely on gcc-3.4 support, but I don't know if this is still correct and if they can't upgrade to something a bit more recent. My suggestion: - declare gcc-3.3 as not longer supported, patches aren't any longer accepted - declare gcc-3.4 as obsolete, patches will be accepted up to including OOO330. Build breakers can't be flagged as Prio 1, fixes will have to come from the port maintainers using this obsolete version as most developers will not have a way to fix or even to verify the build problem. Comments? I would especially like to hear from the port maintainers. Regards, Heiner Martin Hollmichel wrote: Hi, obviously OOo doesn't compile any longer with gcc3, see http://qa.openoffice.org/issues/show_bug.cgi?id=95511, should we now officially drop gcc3 ? Martin - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] should we drop gcc3 support ?
Hi Yuri, thanks for the update! Bye Heiner Yuri Dario wrote: Hi, We have discussed dropping gcc-3.3 support for quite some time now, but we refrained from officially obsoleting it because OS/2 and MACOSX 10.3 support still depend on gcc-3.3, at least according to this list: http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers thanks for reminding me :-) With OOo 3.x, I moved to gcc 4.3.2; it works well, except for optimizer: code must be compiled with -O1 because O2/O3 causes OOo crashes (at least in earlier 3.x builds, it is a lot of time that I did not recheck). Bye, Yuri Dario /* * OS/2 open source software * http://web.os2power.com/yuri * http://www.netlabs.org */ - To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: [tools-dev] Line-endings in source files
Hi, Christian Lohmaier wrote: Hi *, it seems to me that lately a huge amount of lineend-changes did occur. Maybe it is just a bad impression because many of the cws I had a look at lately did cause so many unrelated changes, but still: *Please* take care of lineendings before you commit. especially: please don't create files with mixed lineendings. I can only emphasize how important this is. Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Mercurial-Implementation: OOo domain developer public keys
Hi OOo Mercurial users, OOo domain developers public keys = The SVN public keys of all OOo domain developers can now be used to r/w access the outgoing mercurial repositories on hg.services.openoffice.org via SSH (ssh://h...@hg.services.openoffice.org/cws/*). It's no longer necessary to be part of the Mercurial Pilot (which has been concluded weeks ago anyway) or to contact RE if you want to try out a Mercurial based CWS. There are still some caveats with Mercurial based child workspaces as long as we still use SVN for tracking our code lines: * Your changesets will loose their identity during integration. This might create problems if you cross merged changesets between several CWSs. * Integration into SVN will lump all changeset of your CWS into one single changeset. The single changeset commit during integration will contain of course only a single commit log. We lump together all commit logs and authors of your changesets together via scripting and attach that to the commit. Alternatively REs will accept a detailed commit log supplied by you. The * Be careful with renaming files. If you do a lot of renaming you'll most probable cause a lot of stress on the integrator. Remember, the RE integrate your CWS via diff and patch. Also, all restrictions of SVN regarding the renaming of files/directories still apply. If you plan to do a lot of renaming please do it on a SVN based repository. Or better, if possible, wait for the final switch to hg. * Tinderboxes, buildbots etc are currently adapted to Mercurial, some things might not yet work. Please contact me if you have problems, suggestions etc. Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Mercurial-Implementation: automatic generation of outgoing repositories
Hi OOo Mercurial users, Automatic creation of outgoing repositories = The mechanism for the server side creation of the outgoing CWS repositories on hg.services.openoffice.org is in now place. An outgoing repository is automatically created for every CWS which is: a) flagged for Mercurial use b) in state new or later (but not for planned) It's no longer necessary to request Mercurial based CWSs per email. Any newly created mercurial based CWS should appear in this list no later than about two hours after the creation of the CWS: http://hg.services.openoffice.org/hg Fresh outgoing repositories will contain every milestone up to the creation milestone of the CWS, this ensures minimal network transfers consistent with the prevention of unnecessary heads. If the outgoing respository for your CWS is not properly created please notify me. Flag your CWS as mercurial (hg) based = It's possible to flag your CWS as hg based by editing the SCM entry in EIS. Starting with DEV300 m57 cws create accepts a new option --hg: $ cws create --hg DEV300 cwsname This will create a CWS with name cwsname in EIS with is by default flagged for Mercurial usage. Also it doesn't create these superfluous branches in SVN anymore. Please don't use this switch for OOO310 childworkspaces. Setting the current milestone of a CWS == Starting with DEV300 m57 the cws tool knows a new command: $ cws setcurrent -m milestone Use this to set the correct current milestone in EIS. You'll need this for hg based child workspaces because there is no wrapper (yet) to do this after a pull/merge. I'm currently thinking about how to set the current milestone automatically, but nothing is in place yet. You can set the master code line with this command as well, please use this prudently. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Important Process for Mercurial Users
Hi Jan, Jan Holesovsky wrote: Hi Heiner, On Wednesday 26 August 2009, Jens-Heiner Rechtien wrote: Everyone using a mercurial based CWS MUST enter the new milestone in EIS manually after rebasing the CWS to a new milestone using mercurial commandline or gui tools. Cannot this be automated? With git, all you'd need is to have a post-update hook on the server that does 'git describe' (finds the most recent tag that is reachable from a commit) on the CWS, and just gives the tag to the EIS. I suppose the same must be achievable with Mercurial, right? Yes, something like that is possible with hg. Great! But it's somewhat wrong also because in most cases it's more relevant what's in your local working repository and that might be much more current than what you have in the outgoing rep. I don't think it is wrong. In your local repository, you don't care about the milestone at all, it is important for the outside world only. From the other mail: - 8 - Thus in order to not break processes which depend on the correct milestone version information in EIS like buildbots or automated tests do for example a developer MUST update milestone information in EIS manually after using mercurial tools to update the source code to the new milestone. - 8 - The buildbots and the automated tests will never get what you have locally, unless you push that. So from my understanding, the information in the EIS should track what is published (pushed) = post-update hook is what we want. So the whole notion of the current milestone is somewhat unclear in a DSCM scenario. No, the notion of the current milestone is perfectly defined - the most recent tag that is reachable from the commit. What is somewhat unclear in the DSCM scenario is the definition of Child workspace :-) - is the CWS what is on the server, or each and every clone out there? Is every clone the one CWS, or is it several CWSes? ;-) Heretic idea comes to my mind - what about to discard the 'current milestone' info from EIS completely, and update buildbots/automated tests/etc. to count the 'current milestone' themselves using the Mercurial equivalent of 'git describe'? Then we never can be wrong, and the info can never be outdated/out of sync. Haven't thought finally about it. There will be at least a command line method to update the milestone. The rebasing using the Mercurial tools only is a great leap ahead [thanks for that!], let's not make a step back by introducing commands that are not really necessary... I'll keep that in mind. Some great suggestions here, I'll have a look at them! Regards, Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?
Hi Thorsten, Thorsten Behrens wrote: [Cc to tinderbox removed] Frank Schönheit - Sun Microsystems Germany wrote: As an additional note, it has been suggested to not commit the boost*.tar.gz to boost/download, but make it a pre-requisite which needs to be downloaded before building. This would (for 1.39) save 50M in the repository for every version ever committed there. Opinions on this plan are also welcome. Hi Frank, hm - in the light of heavy-weight commits like the .sdf one, ain't this just a micro-optimisation? Unless such stuff gets downloaded automagically, it's a big nuisance in the already-full-of-nuisances ooo build experience. Or invent a nice solution that does auto-downloads, and switch a few other huge external libs to that (like icu). ;) Actually, I would love that. Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: [tools-tinderbox] Moving to bost 1.3?
Hi Rene, Rene Engelhard wrote: Hi, On Wed, Aug 19, 2009 at 04:53:28PM +0200, Jens-Heiner Rechtien wrote: Or invent a nice solution that does auto-downloads, and switch a few other huge external libs to that (like icu). ;) That would be a problem for some builders unless you don't download it when the file is there... For example, for Debian requiring any form of net access on a build is a no-go (and for some libs we have to use the internal versions, and be it sometime, in emergency) And please also think on people bulding somewhere without net access.. Any such mechanism must be well thought out to prevent being a nuisance. It needs some kind of caching mechanism. Also the downloaded tarballs shouldn't get in the way of a dmake clean or something. Stuff to be downloaded needs a place where it's guaranteed to be available etc etc. Lots of details to be taken care of. Heiner - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Mercurial Pilot Feedback, Results
Hi Rene, please see my comments inline, Rene Engelhard wrote: Jens-Heiner Rechtien wrote: Scalability: - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. If that was true, please tell me why it also was that slow on my MacBook 2Ghz, 1GB RAM with (quite) fast disk, not an old like my Mac mini G4 with 512M RAM? But I told you that at that time, too - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. You didn't read what I wrote. How please is http://packages.debian.org/lenny/mercurial not using native libs? (See the libc6 dependency and the .sos). You shouldn't think that only you have problems here and there :-) This bullet point was about an observation by Mikhail, and we think we have tracked it down to this problem. Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some Not difficult if you ignore problems ;-( I certainly do not ignore problems. I may come to different conclusions at that time, but I do not ignore them. I even blogged about it at that time. Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Mercurial Pilot Feedback, Results
OOo developers, last week I asked the participants of the Mercurial pilot for feedback. Most have responded and I think we are now able to wrap up the pilot and come to a conclusion. Over the last eight weeks 21 child workspaces have been created and worked on, three of them went the full way until being integrated back into the main code line. You can find an overview here: http://hg.services.openoffice.org/hg The responses covered a whole range of topics, which I try to break down in the following: Functionality: == - most importantly, no participant complained about missing functionality. - one participant mentioned that he's more comfortable with the git feature set, but added that he's also way more experienced with git. - at least one participant was positively surprised by some unexpected but very useful functionality, for example the powerful template engine. Disclaimer: that would be me ... Scalability: - overall perceived good performance, some were even quite enthusiastic about it (SVN users are easy to please ...). - there were three mentions of sub-par performance which all have been investigated shortly: - unexpected slow clone times on a very old machine with slow disks and little memory: this machine was probably simply underpowered for use with Mercurial, which is somewhat memory intensive due to the implementation in python. Also there was a misunderstanding about when hg uses hard links as an optimization. - unexpected slow update of the working tree: caused by using the pure python replacements instead of the hg native shared libs. This should be avoided by any project of the size of OOo. - very slow push to outgoing rep. via async DSL after pull/merging the DEV300_m51 milestone: caused by an over sized changeset in DEV300_m51, which moved 40% or so of our tree to another place. Very nice test for a worst case behavior. Emphasizes the need of server side copies for creating the outgoing repositories. - storage efficiency in the case of renamed large files is worse than what is possible with git. Ease of handling/Learning curve: - got a lot of positive feedback here and one neutral (like git better but don't know yet enough about hg to judge it fair) - a complete and working infrastructure (build bots, opengrok, required changes to build.pl, a hg plugin which deals with EIS and many other tools) need to be in place before we could start with production use. Conclusion: === The purpose of the pilot was to find out if there are any important aspects which render Mercurial unusable as SCM for OOo. We found that there are none. This doesn't mean that Mercurial couldn't use some improvements here and there, but all-in-all the majority of the pilot participants is pleased with its functionality, scalability and especially the ease of handling. With an overall positive outcome of the pilot we move over to next phase: the implementation of a full scale migration to Mercurial. I'll keep you posted about the details. Thanks: === I would like to thank all the pilot participants for their work and their valuable discussions and insights. Regards, Heiner -- Jens-Heiner Rechtien h...@openoffice.org recht...@sun.com OpenOffice.org release engineer - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] How to kill your CWS with svn rebase
Hi, please see my comments inline. Mathias Bauer wrote: Moin, rumours are that some CWS have not survived a rebase with svn (at least they weren't very useful afterwards) and in some cases the reason was that files added on the master between the old and the new revision for the CWS didn't make it into the merged CWS. I was successful ;-) in reproducing this behavior and at least in my case the reason was as simple as easily avoidable: I wanted to rebase a CWS from DEV300_m49 to DEV300_m53 and due to the huge amount and size of downloaded files my internet connection broke before the cws rebase -m step finished. So I called svn revert to start anew and then successfully got a merged CWS that I happily committed. The shock came when the build broke due to missing files. What had happened? The problem was that I didn't call svn clean after svn revert and so all files that had been added previously (in the failed merge) still remained in my source tree, but not under version control (svn status would have shown them with a ? in front). The following merge caused by the successful cws rebase was not able to add some of the new files as they were already there, and so they did not enter my workspace and wheren't committed to my CWS. I wonder why I never got the slightest warning, let alone an error message, but anyway, I think the lesson learned is: Never forget to call svn clean after svn revert. Just one comment here: It's svn-clean, a script, written with a hyphen in the middle which can be used to remove untracked files. svn clean ist a shortcut for svn cleanup, a svn commando to clean broken locks from the working tree after an interrupted write operation on the tree. So the sequence is: cd working space svn revert -R . svn-clean The script can be found in most SVN installations. I hope this will save others the time I have lost now (roughly a full day to assemble the patch for my cws so that I can start from m53 again). The good thing is that now the CWS is hosted with Mercurial. :-) Regards, Mathias Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws rebase failed
Hi Max, Maximilian Odendahl wrote: Hi, SVN 1.5.4 is OK. so any idea why new files were not added during rebase? -Max I think we finally found out why the new files were not added during rebase, many thanks to Mathias Bauer who pointed this out to me. The one way to cause this to happen is the following: 1) Try an rebase (cws rebase -m), this failed or was interrupted for one reason or another 2) Do an svn revert -R . to get rid of all the already merged stuff. 3) Do cws rebase -m again, worked this time. 4) Do a cws rebase -C and suddenly you realize that many new files were not added during rebase. What went wrong? If you do a svn status after doing the revert (step 2) you'll notice a number of files marked with an ?, untracked files. Every *new* file which has been merged up to the breakage in 1) will be among them. This is because svn marks them only as untracked and does not delete them in the revert, this is because it can't know where they did come from in the first place - it could be manually crafted files from the developer which she/he just had added, or it could come from a merge with subsequent add. In the former case deleting the file could have serious consequences and cause unhappy faces. SVN goes the safe way here and doesn't delete the files. If you do now a new merge nothing will happen to these files - after all they are already in you working tree ... I guess you can see where this is going ... So the moral of the story: - if you do a revert, than do it right. - never ever merge into an unclean working tree. cd workspace svn revert -R . svn-clean svn status - to make sure that your tree is really clean svn-clean is a script which will delete all untracked files (object files included) in your working tree. It comes with your SVN distribution. Does this sequence of events match your experience? Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] Please read: DSCMs, Mercurial Pilot and Performance
Hi developers, you might have notice, that pulling/merging/pushing a hg based CWS might be quite slow if the CWS was based on a pre-m51 milestone and you did pull a m51 or later milestone into the CWS. The effect is big enough to desire an explanation: In DEV300_m51 the CWS l10ncleanup04 has been integrated. In this CWS all the sdf files from all over the place have been move into a single module (top-level directory) called l10n. Now the sdf-files are a significant part of the overall OOo source tree (886 MB from a 2.0 GB total). This move of the sdf files also involved an additional change of format which prevented a simple use of svn move, the end effect being that the content was copied. This is not that tragic on a centralized system (server disk space being cheap) but is very suboptimal in a DSCM setting. Copying/Deleting/Adding the files prevented the svn-hg converter to recognize that something has been moved and be efficient about it, the old and the new files are unrelated as far as the SCM is concerned. The whole changeset, converted to hg, blew up the OOo hg repository (store only) from 1.1 GB to 1.3 GB, or nearly 20%. Thus we have now a single changeset in our OOo hg repository which represents nearly 20% of the size of the repository, the other 80% being the 262000 changesets which cover the trunk history of OOo since 2001. If you pull/push that changeset over the line it *will* take some time. Please bear that in mind if you judge the performance characteristics of hg. Developers, please: if you make big changes like this, use svn move or it's equivalent to move the files, regardless if it's in SVN or later in a DSCM. We don't want to have hundred's of megabytes dead weights in a repository which every one needs to copy/clone many times. I hastily add that I don't blame the author of the CWS for doing this, he hadn't much choice due to the (required) format change. But often we do have a choice, please keep this in mind. Thanks for your consideration Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws rebase failed
Hi Max, Maximilian Odendahl wrote: Hi, SVN 1.5.4 is OK. so any idea why new files were not added during rebase? Sorry, no. Without a log it's hard to guess what went wrong there. Heiner -Max - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws rebase failed
Hi Max Maximilian Odendahl wrote: Hi, looks like svn 1.6.x doesn't play nice with cws.pl, got a bug or two for this lately. Now I'm wondering myself if it's required to make cws.pl cope with all the 1.6 stuff, or is it good enough to check for 1.5.[56] - which are known to work - As I wrote earlier, I'm using 1.5.4, is this known not to work? As mentioned already, this site http://wiki.services.openoffice.org/wiki/SVNMigration is saying 1.5.4 is fine. SVN 1.5.4 is OK. It does create a bit to much merge-info's in the tree but we'll delete that anyway on integration. If you find the time to update to 1.5.5 or 1.5.6 it might be worthwhile because will be somewhat faster and slightly more correct that 1.5.4. Heiner - EIS database was updated with a rebase to m47 instead of m52, can someone fix that please? I guess this has nothing to do with svn? -Max - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws rebase failed
Hi, looks like svn 1.6.x doesn't play nice with cws.pl, got a bug or two for this lately. Now I'm wondering myself if it's required to make cws.pl cope with all the 1.6 stuff, or is it good enough to check for 1.5.[56] - which are known to work - in cws.pl knowing that we'll get rid of this tool by September or so. I rather don't wont to pour much effort in a lost case but on the other hand I can see the pain ... Opinions? Heiner Maximilian Odendahl wrote: Hi, I wanted to rebase my cws notes9 to m52, but it failed miserably. - EIS database was updated with a rebase to m47 instead of m52, can someone fix that please? - it seems that I'm missing all new files added somewhere along the line, e.g. all the patches for redland, new containers and new files for the bubblechart did not make its way into my cws during rebase. I can see them inside my rebase directory, but svn status gives a question mark. Shouldn't they all be added automatically to my cws during rebase? How can I fix this? Thanks, Max - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] [ClassRoom] Log available : introduction to git tool
Gi Eric, eric.bachard wrote: Hi, FYI, we had a nice ClassRoom, about git introduction, made by Jérémie Laval (from UTBM). As usual the log is available at : http://wiki.services.openoffice.org/wiki/Education_ClassRoom/Previous_Logs/git Thanks again to Jérémie and the attendees ! Regards, Eric Bachard P.S. : the choice of explain git tool has been proposed long time ago by Jérémie, and is completely orthogonal to the current choice to use mercurial. Last but not least, we'd be happy to have a ClassRoom about mercurial. Heiner, do you read me ? :-) Yup, have read this :-) We can setup a mercurial classroom as well, after I'm back from vacation (July, 6th). Let's say at sometime in mid July? Tschues, Heiner -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] [ClassRoom] Log available : introduction to git tool
Hi Malte, Malte Timmermann wrote: Jens-Heiner Rechtien wrote, On 06/12/09 15:33: Gi Eric, eric.bachard wrote: Hi, FYI, we had a nice ClassRoom, about git introduction, made by Jérémie Laval (from UTBM). As usual the log is available at : http://wiki.services.openoffice.org/wiki/Education_ClassRoom/Previous_Logs/git Thanks again to Jérémie and the attendees ! Regards, Eric Bachard P.S. : the choice of explain git tool has been proposed long time ago by Jérémie, and is completely orthogonal to the current choice to use mercurial. Last but not least, we'd be happy to have a ClassRoom about mercurial. Heiner, do you read me ? :-) Yup, have read this :-) We can setup a mercurial classroom as well, after I'm back from vacation (July, 6th). Let's say at sometime in mid July? Well - maybe we can use that classroom as a kick-off for using mercurial only then? ;) well, everyone can participate in the Mercurial pilot But we won't be ready for general Mercurial only usage in mid of July, there are a lot of bells and whistles missing and there is also the matter of vacation ... The current plan is to move to hg only at some time in September, hopefully early enough to not interfere with the 3.2 release. Heiner Malte. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Open Office on HP UX
Hi Alex, the last official HPUX port of the OOo source code has gone stale about a decade ago or so. The more or less official list of maintained ports http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers doesn't mention HPUX. It might be possible that someone has a version hidden in the closet but I doubt it. Most of the OOo stuff shouldn't be to difficult to port but there is at least one thing which is quite involved: creating the UNO bridge (it needs to now a lot about compiler internals and the ABI). Heiner alexandre@bull.net wrote: I'm using UNO SDK and Open Office to create and read word documents from an application. My OS needs to be HP UX. I need some help about this unix. Has someone compiled Open Office succesfully on HP UX? If not, do you know if it is possible to use UNO SDK with a light version of Open Office wich could be compiled on HP UX? Perhaps is it possible to extract specifics librairies from open office to write and read a document? Thanks a lot for your help. Alex - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws sync m38 problems.
Jürgen, thanks for pointing this out. The problem is caused by SVN fooling up on resurrected items. I found this in the change log for SVN 1.5.5 * fixed: broken merge if target's history includes resurrections (r34385, -93) Heiner PS: svn 1.5.5 fixes a number of svn:mergeinfo related problems. RE is currently contemplating an client/server upgrade, 1.5.5 will probably not be mandatory though. Alternative would be to wait for 1.6.x which seems to have a warning mechanism for the infamous tree conflicts (aka I lost my changes after moving a file) Heiner Juergen Schmidt wrote: Kohei Yoshida wrote: On Mon, 2009-01-05 at 10:52 -0500, Kohei Yoshida wrote: I'm now checking out the cws once again to do a fresh rebase, to see if that works. And this worked! Still not sure what the problem was that prevented the rebase in the first place. Kohei i had the same problem. Updated svx/uiconfig/layouts and got the problem again. After a second look i noticed that it is now not svx/uiconfig/layout/delzip but sw/uiconfig/layout/delzip Please note the little difference between svx and sw and update both ;-) Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] cws sync m38 problems.
Hi, the best way to resolve this problem (if you haven't change anything in that area): cd svx/uiconfig/ rm -rf layout svn update (which checks ouut the stuff again). This works because there was no real change to this files, they just got accidentally deleted and readded. Some very strange things seem to go on with the working copy there. I'm beginning to positively hate certain SVN features. Heiner eric b wrote: Hello Kohei, Le 5 janv. 09 à 16:17, Kohei Yoshida a écrit : On Tue, 2008-12-23 at 15:14 +, Caolán McNamara wrote: i.e. [...cut...] svn: File '/cws/WORKSPACE/svx/uiconfig/layout/delzip' is out of date cws: ERROR: The subversion command line client failed with exit status '1' FAILURE: cws aborted. Ok. Now I'm getting this while rebasing kohei02 cws to m38. The funny thing is, I've successfully rebased several other CWSes to m38 and this is the first time I've got this problem. I had it 3 times, and had to work on that the week end. Fortunaly, Christian Lohmaier (alias cloph on IRC ) saved me. Any known workaround on this? As Caolan already said, running 'svn up' does not seem to fix it. Same issue, for 2 cws's. I don't have the solution, since I had to rebase manually, but don't remove the faulty module, else, the resync will not work for him (see my recent commits on CIA and you'll understand what will happen ;-) So I'm sorry, I prefer not give you a bad advice, but I'd be glad to read how to solve that too. Maybe better wait .. Regards, Eric -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Build problems with updated cws 0dff05
Hi Regina, the target for copying the templates is a bit to broad, it copies the .svn directories to the output tree. The second time you try this it may fail due to lacking write permissions One fast way to solve the problem is to simply remove the complete output tree wntsmc12.pro and rebuild or just the offending .svn directories in wntmsci12.pro/misc/openoffice/misc/msi_templates Heiner Regina Henschel wrote: Hi all, I had build cws odff05 as soon as it was on subversion. It build without problems and I could provide some patches. Then I have updated my local copy of cws odff05 using SVN update to the actual version as Eike told me. But now I don't get it build. I have used the same configure commands as before. It breaks with the error message: Building module instsetoo_native /cygdrive/c/SoftwareArchiv2/odff05/instsetoo_native/inc_openoffice/windows/msi_languages - /cygdrive/c/SoftwareArchiv2/odff05/instsetoo_native/util - mkdir.exe -p ../wntmsci12.pro/misc/openoffice/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/ooolangpack/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/ure/msi_templates mkdir.exe -p ../wntmsci12.pro/misc/sdkoo/msi_templates C:/cygwin/bin/cp.exe -ua ../inc_openoffice/windows/msi_templates ../wntmsci12.pro/misc/openoffice C:/cygwin/bin/cp: cannot create regular file `../wntmsci12.pro/misc/openoffice/msi_templates/.svn/entries': Permission denied C:/cygwin/bin/cp: cannot create regular file `../wntmsci12.pro/misc/openoffice/msi_templates/Binary/.svn/entries': Permission denied dmake: Error code 1, while making 'hack_msitemplates' ERROR: Error 65280 occurred while making /cygdrive/c/SoftwareArchiv2/odff05/instsetoo_native/util rmdir /cygdrive/c/Temp/2244 What to do? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org -- Jens-Heiner Rechtien recht...@sun.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Moving files in a Subversion CWS
Hi, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. Doing the restructuring in a big CWS which needs many month to complete won't do it, I completely agree here. I think I remember having read something about a warning system someone devised but I just can't find the reference, Have to look harder. Heiner Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, So, back to good old manual merging: Remember which files you moved in your CWS, and after every rebase, check whether they miss any changes to the original files. Sigh. With the additional hurdle that nobody will warn you about the lost changes. If the compiler finds them, that's fine, but if you just lose a small bug fix, then may not notice this at all. However, what worries me deeply is the [not] true data loss scenario upon svn merge --reintegrate described at http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.moves . A disaster waiting to happen, I would say. Or am I missing something? I tend to agree here. Just recently asked Heiner about this, and in my opinion, both scenarios effectively mean we should completely ban svn move, as it has a pretty large potential to silently destroy our code base. Which is a pity, as this is *the* feature of SVN which made it worth suffering the additional complexity introduced with it. Ciao Frank -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Moving files in a Subversion CWS
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: Jens-Heiner Rechtien wrote: Hi, I wouldn't call for a complete ban but it looks like one has to be extra careful. Restructuring should be done in CWS which lives only a very short time. Best, say, opened on one milestone and integrated in the next (as first CWS) this would minimize the potential for data loss. As first CWS? Wouldnt that doom any changes from other CWS on the moved files because the file is already deleted when they are itegrated. *Confused* I thought _last_ CWS would be the safest ... That's not a problem because changes to no longer exiting files will trigger warnings. Heiner Still data loss is possible even in this scenario, which IMHO is very scary. I would feel much more comfortable, if a naked move wouldnt be possible. As an (ugly, very ugly) workaround for now, we might need a command in the cws tool that registers the moved files by their old name (the name it is known as on the master) somewhere. This could be either in a svn property (on trunk??) or in a administrative file somewhere. It should at least be noted, if changes to a file are wandering to /dev/null. Have Fun, Björn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Please do not use Subversion-1.5.1, update to 1.5.4
Hi, Subversion-1.5.1 has a bug which can lead to a scenario where subsequent rebases can undo each other, see issue: http://so-web.germany.sun.com/iBIS/servlet/edit.ControlPanel?tid=i96877 Please upgrade your client to the latest SVN version which is 1.5.4. It should be faster as well. Thank you Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] cancel [EMAIL PROTECTED]
This message was cancelled from within Mozilla. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Please do not use Subversion-1.5.1, update to 1.5.4
[Reposted due to wrong link] Hi, Subversion-1.5.1 has a bug which can lead to a scenario where subsequent rebases can undo each other, see issue: http://qa.openoffice.org/issues/show_bug.cgi?id=96877 Please upgrade your client to the latest SVN version which is 1.5.4. It should be faster as well. Thank you Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update of the SVN server to 1.5.4
Hi, the server upgrade to SVN 1.5.4 is completed. Have a nice weekend Heiner Jens-Heiner Rechtien wrote: To be more precise: Friday, Nov 28th, 19:00 CET (GMT+1) Thanks, heiner Jens-Heiner Rechtien wrote: Hi, on Friday evening (19:00) I plan to update the SVN server on svn.services.openoffice.org to version 1.5.4. Please avoid having open svn connections then. Thank you, Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Update of the SVN server to 1.5.4
Hi, on Friday evening (19:00) I plan to update the SVN server on svn.services.openoffice.org to version 1.5.4. Please avoid having open svn connections then. Thank you, Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Update of the SVN server to 1.5.4
To be more precise: Friday, Nov 28th, 19:00 CET (GMT+1) Thanks, heiner Jens-Heiner Rechtien wrote: Hi, on Friday evening (19:00) I plan to update the SVN server on svn.services.openoffice.org to version 1.5.4. Please avoid having open svn connections then. Thank you, Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN and lineends
Hi, Eike Rathke wrote: Hi Frank, On Tuesday, 2008-10-28 10:57:39 +0100, Frank Schönheit wrote: modifying a .cxx file on Windows, and committing it to SVN, followed by a svn diff -r PREV file, shows me that *the complete* file changed with the commit. Doing a svn diff -r PREV -x --ignore-eol-style file shows me only the changes which I just did. This makes me wonder, because so far, with CVS, we did not have that problem. Even a Lf-only source when edited in MS-Dev did not change line ends, AFAIK. What does cause this change? We use a hacked CVS client inside the Hamburg environment. It kills any CR in a non binary file no matter what. Conclusion: We have a problem with our line endings - we certainly do *not* want to have a thousands-line-change-set for every file we modify/commit on Windows, do we? Shouldn't we set to svn:eol-style property to a reasonable value (native, probably) for all our source files, globally? Probably not, see my previous mail I sent just a minute ago. Eike Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN and lineends
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi, modifying a .cxx file on Windows, and committing it to SVN, followed by a svn diff -r PREV file, shows me that *the complete* file changed with the commit. Doing a svn diff -r PREV -x --ignore-eol-style file shows me only the changes which I just did. Conclusion: We have a problem with our line endings - we certainly do *not* want to have a thousands-line-change-set for every file we modify/commit on Windows, do we? Shouldn't we set to svn:eol-style property to a reasonable value (native, probably) for all our source files, globally? Will also not really help in all cases. If you check out under Unix (or cygwin) and commit on Windows you get the same problem, which is probably a common scenario. Unfortunately not everyone uses an able editor which detects the line-style and conserves it on Windows. I've thought a while about setting eol-style native during the migration, but the best practices recommended to not set a eol-style to prevent garbling of not correctly flagged binaries (I'm sure we've got a few). This doesn't prevent us to do it now, of course. We would need to prepare a list of files types which we consider sources ... Let me hear your thoughts. Should we go to svn:eol-style native? For which file types? Or should we stay with Unix and require that people use editors which preserve the line end conventions? Is that even possible for the more popular editors (I use vim, so I wouldn't know). Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] application/octet-stream files in SVN repository
Stephan Bergmann wrote: svn propget svn:mime-type --depth files svn://svn.services.openoffice.org/ooo/trunk/[EMAIL PROTECTED] shows that all of STLport-4.0.patch STLport-4.5-0119.patch STLport-4.5.patch dos_lineends.patch win32_custom.sh win32_sdk.sh are classified as application/octet-stream (and so, e.g., svn diff on them will not report anything useful). All of them consistently use LF line ends, except for dos_lineends.path, which consistently uses CRLF line ends. Why are all those files, erroneously in my opinion, classified as application/octet-stream? Either these files were flagged as binary files in CVS or the Subversion import file type detection heuristic didn't work, so SVN choosed the save way (import the file as binary). The mime type can be changed, text would be best for the patches and in addition the svn:eolstyle should be set to CRLF. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Removing a module
Stephan Bergmann wrote: In http://qa.openoffice.org/issues/show_bug.cgi?id=92875 remove jut it had been intended to remove the jut CVS module (back then; resp. now the corresponding SVN directory), but for whatever reason that step has been forgotten when fixing and integrating the corresponding CWS http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb93. I guess it is easy to just remove the SVN jut directory on DEV300 through a follow-up issue now (and I will file such an issue for me), but I am wondering whether further steps are necessary when removing such a module: - Are any adaptations to any CWS or build tools necessary? Just a mail to RE to that jut will be removed with CWS xxx should suffice. - Should jut be removed from the code module list at http://qa.openoffice.org/issue_handling/submission_gateway.html, or kept there for historic reference and in case somebody wants to file an issue against an old version of jut? Good question. I makes sense to keep it there for a while, but it's hard to determine when this while should end :) Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [allsvn] r262317 - tags/DEV300_m33/vcl/source/gdi
Yup, Thorsten got the price for being the first developer to commit on a tag. Please clean up this mess. I'm still pondering the question if it's a good idea to prevent people doing such commits. I'm normally not a friend of overly strict access controls as they tend to get in the way later. But, well, ... Heiner Stephan Bergmann wrote: Thorsten, all, I assume the below commits to tags/DEV300_m33 are in error, and should instead have gone to some cws? -Stephan On 10/20/08 13:59, [EMAIL PROTECTED] wrote: Author: thb Date: Mon Oct 20 11:58:48 2008 New Revision: 262317 Log: #i95197# Fixes valgrind warnings by shuffling code behind the place where stream errors are checked. Modified: tags/DEV300_m33/vcl/source/gdi/cvtsvm.cxx tags/DEV300_m33/vcl/source/gdi/impgraph.cxx [...] On 10/20/08 14:45, [EMAIL PROTECTED] wrote: Author: thb Date: Mon Oct 20 12:44:25 2008 New Revision: 262319 Log: #i95209# Made vcl/test/canvasbitmaptest unit test work again; fixed all bugs that test turned up subsequently Modified: tags/DEV300_m33/vcl/source/helper/canvasbitmap.cxx tags/DEV300_m33/vcl/source/helper/canvastools.cxx tags/DEV300_m33/vcl/test/canvasbitmaptest.cxx tags/DEV300_m33/vcl/test/makefile.mk tags/DEV300_m33/vcl/unx/source/gdi/salbmp.cxx [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Subversion precommit hook
Hi Bjoern,
there was no need for crucifying yourself, server side we are python
only. Actually we have no perl bindings installed.
I think we need to be a bit carefull with pre-commit hooks. Other than
post-commit hooks they do influence the user experience of SVN, so
they have to be fast. Well, we've got a very fast server so probably
this is not really a problem.
I somehow don't like tying SCM functionality to commit messages, but
that's may be just me.
And should we enforce policy (like tabs vs spaces etc) via the SCM tool?
Heiner
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
Hi list,
since we now have subversion, we might as well use the new features it
provides. I wrote a precommit hook on the weekend that does some
precommit sanity checks:
- It rejects commits changing files in a cws and outside of it (thus
hopefully preventing some accidental commits to a master
- It checks all *.{cxx|c|hxx|h} files for correct indentation (no tab
indentation on added/changed lines)
- Adding a new module has to be properly announced in the commit message
- Adding a new toplevel dir in a module has to be properly announced in
the commit message (this hopefully prevents accidental commit of
output trees)
- Never allows changes/deleting of tagged versions
I crucified myself to write the hook in perl because I thought it to be
the preferred language for releng stuff (I would have preferred python
myself).
All checks can be disabled with adding special strings to the commit
message.
Im looking forward to comments, ideas and additions. Is it a good idea
to use such a precommit hook? Whats relengs position on this?
Have Fun,
Björn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote: On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 -1 Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Moin Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, On 10/16/08 11:00, Malte Timmermann wrote: In short: Can we please add the platform-dependent output tree names as svn:ignore property to all modules? +1 +1 -1 I tried to explain why I think the property-approach is better, please also elaborate why you think it isn't. Just saying no without explaining why has a small taste of ... dictatorship. (And the only your argument I saw so far, on the Wiki page, is it's clumsy, which isn't really convincing.) Well, this +1 or -1 one in s a kind of vote and you normally don't have to explain your votes. Note that I didn't say We will not do this, I'm the maintainer of this stuff, basta! :-) Just a vote. But if you insist: we've got 191 top level directories in Openoffice.org and they are multiplying like rabbits. We've got, uhm let me see common common.pro unxlngi6 unxlngi6.pro unxlngx6 unxlngx6.pro unxols4 unxsols4.pro unxsolu4 unxsolu4.pro unxsoli4 unxsoli4.pro wntmsci12 wntmsci12.pro unxmacx unxmacxi.pro unxubit8 unxubti8.pro and let's not forget all the platforms which might be build by someone somewhere: unxaixp unxbsda unxbsdi2 unxbsdi unxbsds unxfbsdi unxfbsd unxfbsdx unxhpgr unxhpxr unxirgm unxirxm3 unxirxm unxlnga unxlngm68k unxlngmips unxlngp unxlngppc4 unxlngppc64 unxlngppc unxlngr unxlngs3904 unxlngs390x unxlngs unxlnxi unxmacxi unxmacxp unxsogi unxsogs hopefully I've not forgotten something, These are roughly 50 platforms times 191 top level dirs, about 9550 entries to maintain. That I call clumsy. Since most of the platforms are only interesting to a few people I feel that having this in the so called global ignore list might not be unreasonable. As for I can't use the platform names in the ignore list readily: Well this is a good(TM) thing. You should not use this names, they are reserved for the build process. If you insist on using them, well there is always the --no-ignore switch to svn add, or you just explicitly add a path with this name. Once a path is under version control the ignore list has no effects anyway. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] SVN-ignored files
Hi, just a little correction ... [...] So, I still think putting the stuff into SVN is better ... (Hey, what did we do the migration for if we don't use all the cool new SVN features?) ... at least for the *most common* platforms - what the *#+%$# is unxhpxr? And how many people will ever encounter it in real life, compared with unxlngi6, unxmacxi, and wntmsci12? I guess OpenOffice.org on HP-UX on a MIPS architecture. And, no I will not discriminate against less known platforms, so a partial list can't be an option. :-) Of course, it's not MIPS but PA-RISC ... [...] Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi, there seems to be an agreement that VCS keywords do not make any sense anymore and should be removed. Hamburg RE will take care of this. The tabs converted to spaces issue seems somewhat more controversial. At least we have to move it out of the migration phase. I've played with the idea of a pre-commit formatting check and it's clear that a little thought has to go in this. Removing the tabs out of POSIX style makefiles might not be a good idea :) Heiner Caolán McNamara wrote: On Mon, 2008-10-06 at 09:20 +0200, Stephan Bergmann wrote: Regarding the tab conversion, I guess such a one-time conversion won't help much unless we could ensure that no new tabs get introduced with new commits. I've long stuck /* vi:set tabstop=4 shiftwidth=4 expandtab: */ at the bottom of the .?xx files that I own in OOo, perhaps something like that plus the emacs equivalent could be mass stuffed into the header region to aid not putting them into .?xx files in the first place And subversion (like cvs) has a precommit hook that can e.g. reject files with tabs in them. e.g. http://wordaligned.org/articles/a-subversion-pre-commit-hook C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: +1 for the proposal +1 Is this something which can/should be done by release engineering, for instance with the switch from m32 to m33, globally? Yes, this can (and should) be done by RE, if we decide drop the VCS keywords. Most probably not m33, but at some time in the near future. Another huge change which could be done in the same milestone is to convert tabs to 4 spaces, something I know Kendy and some others are advocating. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, Yes, this can (and should) be done by RE, if we decide drop the VCS keywords. Most probably not m33, but at some time in the near future. would be good. Another huge change which could be done in the same milestone is to convert tabs to 4 spaces, something I know Kendy and some others are advocating. Uhm - but this will *certainly* give *a lot* of resync conflicts, won't it? As much as I am for having spaces instead of tabs, the trouble we would get with such a global conversion is not worth it, IMO. 'svn merge -x -b' is your friend ... Could be done, and the earlier the better I guess. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Frank Schönheit - Sun Microsystems Germany wrote: Hi Heiner, 'svn merge -x -b' is your friend ... You mean ... I really should go reading this Handbuch? :) Could be done, and the earlier the better I guess. As long as we still have CVS-based CWS'es, which need to be migrated ... not sure. Finally, migration will probably usually happen by create a CWS in SVN, based on the latest milestone, and *patch* in the changes of the CVS-CWS. In this case, svn merge is of no help. Instead, it would require people to create the SVN-CVS on an pre-tab-replaced-by-spaces-milestone, then apply the patches, then lift the SVN-CWS to a post-tab-replaced-by-spaces-milestone. Not a good workflow, IMO. So, if we really want to do this replacement, I would do this only when we can really rely on the power of svn merge being available in all cases. The trick would be to migrate CVS stuff to a SVN based branch @m32 and then rebase with svn merge to something newer ... = problem solved. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] VCS Keywords in License Headers
Hi +1 for the proposal Heiner Stephan Bergmann wrote: After the switch to Subversion, the license headers in all the OOo source files (taken from the templates http://www.openoffice.org/dev_docs/source/templates/code and http://www.openoffice.org/dev_docs/source/templates/makefile) still contain $RCSfile$ and $Revision$ keywords with old values copied over from CVS during the initial migration to Subversion. (The Subversion property svn:keywords, to expand such keywords, seems to not be set for any files in the Subversion repository. Also, the $RCSfile$ keyword seems to be completely unknown to Subversion.) Those old values are at best unnecessary clutter, and at worst will cause confusion. Maybe we should completely drop those keywords from the license headers in the OOo source files (and from the templates, and maybe also address http://www.openoffice.org/issues/show_bug.cgi?id=94480 while we are at it). Anybody? -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] ANNOUNCEMENT: OpenOffice.org migrates to Subversion
ANNOUNCEMENT: OpenOffice.org migrates to Subversion === The OOo subversion source code repository is now write enabled for all domain developers, thus we are officially migrated to Subversion. The details of the migration can be found here: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion Please note that old code lines up to the OOo 3.0 (including upcoming OOo-3.0.x microreleases) are still maintained with CVS. Also nothing has changed for OOo web content developers. The OOo web presence stays with CVS for now. Write access to the repository is organized via SSH public/private key pairs. If your public key is not yet migrated or you are a developer who used until now a shared tunnel to the CVS server, please have a look at these instructions: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#SSH_Setup Please allow a work day or two for your key to be enabled. If your key still doesn't work then, please contact me via email: [EMAIL PROTECTED] or IRC (nick: blauwal). With the migration we have updated our CWS-Tooling to cope with Subversion. There might still be bugs lurking there, so if you have trouble, please try to use the latest version: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#CWS_tooling Any problem reports, corrections and suggestions are welcome! Have fun Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OpenOffice.org subversion repository R/W enabled on Tuesday
Hi, just a little status update: We plan to write enable the subversion based OOo repository on Tuesday if nothing to serious shows up until then. There will be a separate announcement on the developer mailing list when this happens. Actually the repository is already write enabled for those with already migrated SSH-Keys, but I would like to ask you to refrain from committing to the repository until the announcement. If you find that your key does not work on Tuesday, please check if the issue with your public key has been added to the dependency list of issue #94002 (http://www.openoffice.org/issues/show_bug.cgi?id=94002). If your issue is not on the dependency list, please add your issue to #94002 and allow for two work days or so for your key to be added to the repository access list. If after two work days your key still isn't enabled, please contact me per email or IRC and I'll check out what went wrong. Thanks, Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] [tools-dev] Migration to Subversion
MIGRATION TO SUBVERSION === The migrated OpenOffice.org SVN repository is now available via svn://svn.services.openoffice.org/ooo (read/only) or http://svn.services.openoffice.org/ooo (read/only) or svn+ssh://[EMAIL PROTECTED]/ooo (read/write) Please do refrain from committing to this repository for now (most ssh public keys aren't in place yet anyway) until RE announces the DEV300 m32 milestone with additional instructions. What you can do already with the repository: - test checkouts with the r/o access methods and all svn operations with the exception of commits - test if I got everything which is needed to build a DEV300 m31 milestone is included in the repository - build the DEV300 m31 milestone, please tell me if you found problems - start svnsync if you plan to have a local mirror (instructions on how to setup a mirror can be found here: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion#Create_a_OOo_repository_mirror Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Migration to Subversion
MIGRATION TO SUBVERSION === this week we will migrate the OOo-3.1 development line from CVS to Subversion. The base for the migration is milestone DEV300 m31, milestone m32 will already be done with Subversion as SCM. Please note that the OOo-3.0 development line stays with CVS (at least for now), thus the Openoffice.org 3.0 release is not affected at all. The migration will take about a week. Please find the details here: http://wiki.services.openoffice.org/wiki/OOo_and_Subversion Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OOo SVN migration
Hi, last weekend I managed to hurt myself with the kick starter of a bike and as a result I'm out of office for probably a week. This means that the Subversion migration will probably be delayed for a few days. Sorry for that. I keep you posted about when exactly we will do the migration. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [tools-dev] Re: [council-esc] Re: [tools-dev] OOo SCM project
Hi Stephan, the integration of a CWSs will usually happen in a single step, so it's principally not possible to attach single file commit messages to the changed files. But we can have a kind of Changlog attached to the integration revision with the logs of every commit together with the files names (paths). I'm not sure if people will really want this, but if we have the need it can be done. As for the integration of CWS which were started in CVS, if it really bothers you that the comments are not migrated I can implement something along the above mentioned line. I would need a script which extracts the comments from CVS, collect them in a file and attach this file as integration comment. I guess I need two days or so for scripting and it might slightly delay the integration of your CWS. Is this OK for you? Heiner Stephan Bergmann wrote: On 08/28/08 16:01, Jörg Jahnke wrote: Hi, Jens-Heiner Rechtien schrieb: Martin Hollmichel wrote: Jens-Heiner Rechtien wrote: Hi Martin, since almost all OOO300 CWSs (for the RC) will be integrated into DEV300 as well it makes sense to have most of them already integrated into DEV300 before starting the migration. Also there are some quite huge CWSs currently in the queue which will go into DEV300 today or in the next few days. The current plan is to have all the cws for 3.0 rc ready this week (today or tomorrow). Currently it looks like that DEV300 m31 (the next DEV300 milestone) could be a good basis for migration. yes, but I think we should coordinate and announce this on [EMAIL PROTECTED] Ok. So are there objections against starting the migration directly after DEV300 m31 gets finished? Otherwise we (Hamburg RE) would start at that time. I should add that ideally any CWSs with greater changes that are finished already should make it into m31 to avoid unncessary work. There is http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fsb93 which touches quite a number of files and should go into QA tomorrow. Not sure whether it is worth waiting for it, though---those who have to do the actual migration work may have an opinion here. (However, what would disappoint me somewhat is if the CWS's carefully written CVS commit comments were effectively lost, for example in case the CWS is not integrated into the final CVS HEAD revision but only into some SVN revision other than the initial one---that the corresponding SVN revision contains changes for which commit comments can be found by looking at a specific CWS branch tag in the corresponding CVS file log is so much more obscure than if the commit comments can be found by looking at the last HEAD entry in the corresponding CVS file log.) -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: [tools-dev] Re: [council-esc] Re: [tools-dev] OOo SCM project
Martin Hollmichel wrote: Jens-Heiner Rechtien wrote: Hi Martin, since almost all OOO300 CWSs (for the RC) will be integrated into DEV300 as well it makes sense to have most of them already integrated into DEV300 before starting the migration. Also there are some quite huge CWSs currently in the queue which will go into DEV300 today or in the next few days. The current plan is to have all the cws for 3.0 rc ready this week (today or tomorrow). Currently it looks like that DEV300 m31 (the next DEV300 milestone) could be a good basis for migration. yes, but I think we should coordinate and announce this on [EMAIL PROTECTED] Ok. I would suggest that we wait until DEV300 m31 is done and finished and then start the migration. If all goes well this could be next Monday and DEV300 m32 would already be on Subversion (expected about a week later). I think we could also have the necessary documentation in place when DEV300 m32 is published. how many days of SCM outage are you calculating for the migration ? Will there be the possibility to work still on open cws during the migration ? Will there be an outtage for CVS or will just be the committing to HEAD be forbidden ? There will be no outage for CVS at all (one of the major reasons for going with the trunk only approach). Just release engineering will refrain from integration on trunk (HEAD) during migration, no one else should be committing there anyway (the exception being new modules which will be handled separately). The OOO300 code line is not affected at all. I would reconsider the plan if someone steps up with a CWS nominated for DEV300 m32 with hundreds of changed files. In this case it would make sense to throw in another CVS based milestone, just to save ourselves a bit of work. What are developers required to do with their open cws during the migration ? During migration? Nothing special, developers can just work on them as usual. When they are done with a CWS, we'll ask the developer to resync their CWS to the latest CVS milestone. We (that is Release Engineering) will create a patch from the CVS branch and apply it either directly to the latest SVN milestone (thus integrate it) or create a (CWS)-branch on the first SVN milestone for further resyncing with the latest SVN milestone. The first option is of course for nominated CWSs without to many conflicts, the second one for complicated CWSs or ones where the developer wants to resume developing via SVN. I guess we'll need a hand here and there from developers but it shouldn't be that bad. Please note that we have a soft dependency on the RC. Since CWSs which are meant for OOO300 can only be opened in CVS, we'll need to manually merge then into SVN for DEV300. The simple double integration trick we usually use to propagate the fixes between different masters doesn't work in this case. Will not be a problem for a few small CWSs and because the majority of the CWSs is already integrated I do not worry to much about then. Heiner Martin Martin Hollmichel wrote: Jörg Jahnke wrote: Hi, due to the trunk-only migration mentioned below, we do no longer have a dependency on the first release candidate of OOo 3.0, which is done on the OOO300 branch. At the same time, Heiner is ready to start the migration. So do we want to start the migration now i.e. prior to the RC? from my point of we don't need to wait for the release candidate to proceed with the migration as we decided to go with the trunk migration only (see http://wiki.services.openoffice.org/wiki/Scm_migration_scope). If nobody objects I would ask you to provide a concrete plan for the migration starting asap. Regards, Jörg Martin Jens-Heiner Rechtien schrieb: Hi, Jens-Heiner Rechtien wrote: Hi Guido, the migration is going nicely along. We do plan to migrate after the 3.0 RC. - We've got a box, a Sun Fire 4150 (8 cores, 64 GB RAM, no less). The URL will be svn.services.openoffice.org. An updated test repository will be on that machine RSN. - We'll use Subversion 1.5.1, that is with the build in merge tracking - The ESC council decided after some debate about the migration scope, aka how much history do we want (http://wiki.services.openoffice.org/wiki/Scm_migration_scope) We will go along with option c) trunk only, this will also help with later DSCM options. Some asked, so I probably should explain it in a bit more detail what we mean with trunk only migration: - only history on the main development line (trunk) will be migrated, thus no branches and tags - we'll migrate only files which are still active (nothing from the CVS Attic directories) - binary files will be pruned to the last version - Localization files (*.sdf) will be pruned to the last version Existing branches will be maintained in CVS. This includes the OOO300 branch, on which OpenOffice.org 3.0 will be released. Heiner
Re: [dev] Re: [tools-dev] Re: [council-esc] Re: [tools-dev] OOo SCM project
Stephan Bergmann wrote: On 08/27/08 16:00, Jens-Heiner Rechtien wrote: Please note that we have a soft dependency on the RC. Since CWSs which are meant for OOO300 can only be opened in CVS, we'll need to manually merge then into SVN for DEV300. The simple double integration trick we usually use to propagate the fixes between different masters doesn't work in this case. Will not be a problem for a few small CWSs and because the majority of the CWSs is already integrated I do not worry to much about then. Just wondering: Will CWSs targeting OOo 3.0.1 be handled on CVS branch OOO300 (and thus have to be copied manually to SVN in order to be included in OOo 3.1)? OOo-3.0.1 will be handled on OOO300 (or maybe something like OOA300 or so) and thus in CVS for now. But, at some later stage, maybe around end of the year the OOO branch will be moved to a standalone branch to SVN so that we can switch CVS r/o Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] At the end of the OpenSolaris 2008.05 adventure tour...
Hi Ulf, Ulf Wendel wrote: Moin Christian! Christian Lohmaier schrieb: On Thu, Aug 21, 2008 at 7:09 PM, Ulf Wendel [EMAIL PROTECTED] wrote: (Those who missed a few mail: I did try on purpose to compile OOo 3.0 M28 on OpenSolaris 2008.05 although its not a supported/recommended development platform ) At the end of the OpenSolaris 2008.05 adventure tour is JDK 1.5. OpenOffice requires JDK 1.5. OpenSolaris 2008.05 comes with JDK 1.6. I tried compiling OpenOffice 3.0 M28 against JDK 1.6 . I was not too successfull. But hey, OOo does not promise to compile with JDK 1.6 - no deal! AFAIK only hsqldb module had problems with JDK 1.6 hsqldb did build just fine. My trouble was always on jni.h and libawt* - I still believe the JDK 1.6 package smells or my installation was (repeatably) broken. But anyway, I spend so much time on it and I think I should try Solaris 10 instead to get any Solaris box working. The problem with jdk-1.6 and hsqldb (caused by bumping up the jdbc-level in 1.6) has been fixed some time ago, nice to see that the fix worked for you. The last time I've seen jni.h related problems were when the gcj (the gcc java compiler) variant from jni.h was accidentally included instead of the one from the JDK. Maybe you've a similar problem? The virtual machine still exists, I might try again later... OpenSolaris 2008.05 does not offer JDK 1.5 packages. You may try to install a JDK using a download package from java.sun.com. However, the Solaris packages of JDK 1.5 are build against Motif 2.1. And there is no Motif package for OpenSolaris 2008.05. As far as I understood it, the lawyers are working to make the two worlds compatible :(. IIRC you can tell java not to use any motif stuff/operate in some kind of headless mode as well. -Djava.awt.headless=true might be worth a try. Hmm, ah, no, the virtual machine is already zipped and archived... maybe in a week... In general it looks promising but I'm afraid I don't have much more time to play with it. Thanks! Ulf - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Compile error: external/common/apache-ant[...] not found @ OpenSolaris snv 95
PROTECTED] [2] http://opensolaris.org/jive/thread.jspa?threadID=69228tstart=120 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Compile error: external/common/apache-ant[...] not found @ OpenSolaris snv 95
Hi Ulf, Ulf Wendel wrote: Moin Heiner! Jens-Heiner Rechtien schrieb: - we had a former version of OOo on Solaris Sparc which was buildable with gcc but this port hasn't been maintained for a long time. Currently you'll need SunStudio (8, 10-12 or Sun Studio Express) to build OOo on Solaris. The configure script hasn't been updated in a while as you found out ... sorry for that. Its likely that GCC works fine on OpenSolaris and x86. Its just that you might not want to use the OpenSolaris SUNWgcc package but compile GCC yourself. I'll try GCC once I get OOo to build with the Sun compilers. Building OOo on Solaris with gcc is a bit more involved than it might seem on the first glance. GCC itself is a fine compiler and works great on Solaris but there are a few assumptions in the OOo code that assume that on Solaris SunStudio is used for building. Especially the bridge needs to be adapted for each compiler/platform combination, because it requires intimate knowledge about object layout, calling conventions and the throwing and catching of exceptions. The bridge glues the generic UNO API to the (mostly) C++ based OOo implementation. Parts of it are implemented in assembler. - support for building jdk-1.6 has been recently added and might not work perfectly yet. They've changed the place where some libraries live (for instance the libmawt.so over which you stumbled). Since we need to access these libraries directly some changes to JDKLIB and JDKLIBS environment variables might be necessary. Maybe not perfect but, for example, hsql compiles just fine with the defaultOpenSolaris Java 1.6 packages. That's pretty cool. JDKLIB, JDKLIBS ... aha... I'll try to find a human Java-FAQ to navigate me through the 1.6 waters... These are environment variables which are set in the SolarisEnv.sh script generated by the configure process, so they are specific to OOo. through. Please do file a few bugs for the problems you found, I do plan to update the Solaris build stuff in the hopefully not so long future. Will do once I've fiddled out some instructions for building on OpenSolaris x86. I'm doing a lot of try error at the moment. Ulf PS: SuSE 11 - all fine on x86, x86_64 as long as you stay away from non-Sun Java. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Problems with system vs. OOo libstdc++.so.6 mismatch on Linux
Pavel, Kurt got the task to switch to gcc-4.2.3 before the final. In principe this is easy but ... the major issue with that is to upgrade all our build machines and still be able to do the old build. With that gcc-4.2.3 will come a new libstdc++ ... problem solved :) Heiner PS: We might as well switch to gcc-4.2.4, but probably not to the gcc-4.3.x series. Pavel Janík wrote: Hi, It's not magic at all. It comes from the used compiler. Always been so. And the compiler version is documented here: http://wiki.services.openoffice.org/wiki/Compiler_versions_used_by_port_maintainers_and_release_engineers Heiner, yes. This is the current status quo. And sb wants to change it... I do not agree with the change. -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] linux environement fo official Open Office 2.4 builds
Hi, The Sun OOo 2.4 x86 build is done vs. Linux libc-2.2.4 libraries and headers so it will run on practically on every not to old Linux system - the base line system is practically from the stone age. To state the version of every tool used would take pages, suffice to say that we use a patched version of gcc-3.4.1. Heiner Michael Strobel wrote: Hi, Which linux distro is used for the official Open Office 2.4 builds and the exact versions of the tools? The requirements on http://tools.openoffice.org/dev_docs/build_linux.html are a bit vague in some cases. Regards, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] building ooo failed with sun studio 12
Hi,
this exact problem is not exactly new and got already forgotten twice
because we (well I) were to lazy to write an issue. Please write me (hr)
an issue, and I'll include a fix in my next CWS.
Here is a possible way to fix the problem.
--- _stdio_file.hFri Sep 7 13:33:27 2007
+++ _stdio_file.h Mon Sep 10 17:55:16 2007
@@ -92,7 +92,7 @@
typedef unsigned char* _File_ptr_type;
#endif
-inline int _FILE_fd(const FILE __f) { return __f._file; }
+inline int _FILE_fd(const FILE __f) { return
fileno(__CONST_CAST(FILE*,__f)); }
inline char* _FILE_I_begin(const FILE __f) { return (char*) __f._base; }
inline char* _FILE_I_next(const FILE __f) { return (char*) __f._ptr; }
inline char* _FILE_I_end(const FILE __f)
Heiner
PS: Gerard, from there on it will be hopefully a bit easier to build.
You've got more than your fair share of pitfalls to stumble upon.
Laurent Godard wrote:
Hi Cyrille, Hi Caolan, Hi Gerard
Thanks guys for your help
It would appear the issue is in accessing the member directly rather
than using the fileno macro, which has been introduced if I understand
correctly to circumvent some restrictions in the descriptor count or
something to that effect. A search on stlport solaris fileno will
show reports around that issue, and though the problem is probably
addressed in the stlport headers from the compiler, the ones from OOo
don't have that fix. A likely solution is to replace the call
generating that direct access with something using fileno (thanks to
Caolan who encountered the problem too for his help in finding the
source of it).
Gerard if a patch can be applied, please open an issue or send it to me
i'll do it so that next time, there won't be any problem building OOo on
solaris
Thanks again, and Gerard, Courage ! ;)
Laurent
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] building OOO on solaris 10 x86
Hi Gérard, I'm wondering which version of Solaris x86 you are using? All my versions of Solaris (Solaris 8, Solaris 9, OpenSolaris Develepor Edition 09/07) know about the -P switch of /usr/ccs/bin/as. It just preprocesses the file before assembling. You could replace interlck_x86.s with a preprocessed file and remove -P from AFLAGS in solenv/inc/unxsoli4.mk Heiner Gérard Henry wrote: hello all, i'm trying to compile OOO on solaris machines. Firstly, as i'm new to this process, i got OOG680_m5, but what's the difference with SRC680_m233? I dowloaded these files: ncftpget ftp://ftp.free.fr/mirrors/ftp.openoffice.org/stable/2.3.0/OOo_2.3.0_src_*.tar.bz2 After setting paths and some variables, i did configure: caiman-henry% ./configure --disable-mozilla --with-jdk-home=/usr/jdk/latest --with-mingwin=no --with-gnu-patch=/usr/bin/gpatch --with-gnu-cp=/opt/csw/bin/gcp CPPFLAGS=-I/opt/csw/include CC=cc CXX=CC | tee CONFIG.LOG then dmake ended with this error: caiman-henry% dmake ... adjustvisibility -p ../../unxsoli4.pro/slo/file_url.o if ( -e ../../unxsoli4.pro/slo/file_url.o ) touch ../../unxsoli4.pro/slo/file_url.obj tr -d \015 asm/interlck_x86.s ../../unxsoli4.pro/misc/interlck_x86.s /usr/ccs/bin/as -P -o ../../unxsoli4.pro/slo/interlck.o ../../unxsoli4.pro/misc/interlck_x86.s /usr/ccs/bin/as: unrecognized option `-P' dmake: Error code 1, while making '../../unxsoli4.pro/slo/interlck.o' ---* tg_merge.mk *--- ERROR: Error 65280 occurred while making /home/henry/ooo/OOG680_m5/sal/osl/unx dmake: Error code 1, while making 'build_instsetoo_native' I'm using SunStudio 12. Anybody can help, thanks in advance, gerard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] building OOO on solaris 10 x86
Hi, looks like the top level makefile is broken for Solaris (looks like it wants a gmake). Please place gmake in PATH before /usr/ccs/bin/make (can be found in /usr/sfw/bin nowadays) Heiner Gérard Henry wrote: Jens-Heiner Rechtien wrote: Hi Gérard, I'm wondering which version of Solaris x86 you are using? All my you're right, as is broken on my machine, an old modification. Now it's ok for that, but another error: caiman-henry% dmake clean rm -rf */unxsoli4.pro rm -rf solver/*/unxsoli4.pro echo cleaning up dmake... cleaning up dmake... make -C dmake clean Usage : make [ -f makefile ][ -K statefile ]... [ -d ][ -dd ][ -D ][ -DD ] [ -e ][ -i ][ -k ][ -n ][ -p ][ -P ][ -q ][ -r ][ -s ][ -S ][ -t ] [ -u ][ -w ][ -V ][ target... ][ macro=value... ][ macro +=value... ] make: Fatal error: Unknown option `-C' caiman-henry% which make /usr/ccs/bin/make -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] $Author$
Stephan Bergmann wrote: over at [EMAIL PROTECTED], Ariel Constenla-Haile wrote: Hi Frank, Frank Schönheit - Sun Microsystems Germany escribió: Hi Ariel, FIRST of all, I would like to thank the one who wrote the code of the GUI examples on the new SDK (OpenOffice.org_2.3_SDK/examples/DevelopersGuide/GUI): it answers some questions I had for a long time! Thanks hr (I don't know your real name!)! Hehe. hr (Jens-Heiner Rechtien) is a release engineer, who integrated the child workspace where this was introduced. While he, as all our release engineers, surely deserves thanks for the work he does, in this particular case please direct your thank to Jürgen Schmidt (jsc, also to be seen in the CVS history). As I never use CVS for OOo, I just took for granted that the author of the *.java source file was the one indicated there, so here I go again: A reason to drop at least the $Author$ field from the legal headers, to avoid confusion? (I wonder, anyway, why RCSs are designed and used in a way where the RCS modifies the stored content---expanding $...$ fields---, as that cannot work in general.) Yes, yes please let's do this. And while we are at it, let's remove the other $keywords$ as well. They really do make merges more complicated, without adding much of a value. But don't take this too seriously... :) Oh, I take this very serious :) Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: [qa-dev] Can we do more regression testing?
Jörg Jahnke wrote: Hi, the reason why the Wiki page speaks of mandatory tests I have mentioned in a previous mail: Jörg Jahnke schrieb: The problem with such tests not being mandatory is that, sooner or later, some tests would break. That again would lead to a state where the user of the tests could not be sure whether a broken test-case means that he introduced a bug or whether he just encountered an old problem that broke the test-cases before. He would have to start a tedious search to find out the cause of the problem - just like the testers have to do nowadays. And then people would simply not use the tests because the efforts are too high... Ause just informed me about another solution that might remove the need to have the test run on every CWS i.e. we wouldn't need to have the tests mandatory. His idea is to run the tests on the Master Workspace prior to announcing the CWS as ready for CWS use. If a test fails then this would result in a P1 issue that has to be fixed before the MWS can be used by everyone. Very similar to how we handle it for the Smoketest on the MWS nowadays. That's not the same (not even similar). The smoketest is also done on every CWS and it's mandatory. This ensures that it works in all cases with the exception of the rare cases where 1) either a platform specific problem appears and this platform was not tested or 2) the integration of multiple CWSs exposed to a problem which was not there in the respective CWSs. Additionally the list of tests to run would be checked in to CVS, so that we could disable a tests for every user on a given milestone if a fix cannot be done in time. That way a developer could get an _optional_ means at hand of doing regression tests, with no obligation to always run these tests. If the developer feels that he should run the tests, then he could do so and invest the (machine) time. If he thinks that the tests will be no additional help, he just does not run them. Of course the question then is how often such a regression happens. If we have to expect to have half a dozen P1 bugs each milestone due to the mass of regressions, then the mandatory for every CWS seems the better solution to me. But if we expect to have such a P1 bug from the automatic tests only once every 2 or 3 milestones (or hopefully even less often), then this seems an acceptable way to me. Does that make sense? Well, this moves the burden of hunting down which of the 40 or so simultaneously integrated CWSs is responsible for the regression down on RE, usually even with a considerable time pressure (you don't want to know how many times Kurt and I have been asked when m212 will be ready). That's absolutely not the idea behind all this. We know that the cost of a bug is smallest if found as early as possible. The best thing is if the responsible developer finds it. The developer usually has an immediate idea where to look if something happens and there is no need for having the considerable overhead of filing and tracking a specific bug. One of the better way of ensuring that as many bugs can be found as early as possible are regression test. For this to work well four things need to be ensured: 0) The regression test must be reasonable. This means it must be easy to start and must finish in an acceptable time. After it's finished it must be immediately clear if it was successful or if it failed. 1) If the regression test fails than only a change in the latest development (read CWS) can be responsible for triggering it, otherwise we'll place to much burden on the developer (look at the current situation with assertions). This means, of course, that the main code line has to be clean with respect to the regression test all the time. 2) To fulfill the condition mentioned in 1) (main code line always clean) no CWS with a regression regarding these tests can ever be integrated. It's of course allowed to temporarily disable certain tests (if they need to be rewritten etc) with a CWS, but then they will be disabled in the main code line as well. 3) The only way to fulfill 2) is to make the regression test mandatory on a CWS. RE will do the same tests on the MWS as well. But this is only for catching the issues arising due to simultaneous integration and to have a fallback for the odd cases (like regressions which only happen on a single platform which was not tested etc). I will vote strongly against moving the whole responsibility of ensuring that the regression tests still do work on RE where it will lie if the tests are optional on a CWS. The reason is that RE usually has no immediate idea why something goes wrong, thus RE would have to initiate a full bug search, file and handling cycle. This could delay the publishing of a milestone quite a bit. It's also nearly as costly as the current situation, where QA does initiate the issue cycle. If we want to make regression tests a working tool we have to share responsibility:
Re: [dev] How to check whether nas is working?
Christian Lohmaier wrote: Repost and x-post to [EMAIL PROTECTED] it was suggested on IRC that the code that interacts with nas is in vcl and thus the folks dealing with vcl might know how to use OOO with nas... Maybe #i75734# - utilities: security issues fixed in nas 1.8b refreshed somebodies memories... History: http://www.mail-archive.com/dev@qa.openoffice.org/msg03794.html http://www.mail-archive.com/dev@openoffice.org/msg06134.html Hi again... (again nobody replied :-((() AFAIK, NAS is definitely on the short list of the to be eliminated parts. It has to be checked if there are, well, unexpected dependencies in the code base and than it will take a source code janitor to removed it from the code. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] .Doc importer performance
Gregoire Gentil wrote: Hello, When I big import a Microsoft Word .doc document with the Sun binaries ooo 2.1, the document opens in 20s. When I import it with my own compilation of ooo (Gentoo, gcc 4.1, a set of coherent/optimized flags), it takes more then two minutes. Can anyone tell me if there is any specific optimization of the importer in the Sun binaries and how to reproduce them? The optimization flags for our (Sun) build can be found in solenv/inc/unxlngi6.mk. The flags for the doc importer are the same as for the rest of the build (sometimes someone uses local flags via ENVCFLAGS, please check the makefile.mk's of of the import code) Maybe gcc-4.1 mis-optimizes something? Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Thorsten Behrens wrote: Caolan McNamara [EMAIL PROTECTED] writes: On Fri, 2007-02-02 at 14:18 +0100, Pavel Janík wrote: What about making binfilter SO only module? ;-) -1 Unfortunately .sdw etc documents exist and are a fact of life, we do still need to import them. e.g. my performance review still comes in .sdw format, we wouldn't want to drop importing that :-) Hm - hard to estimate how many of those binary documents are still in active use. And it would be interesting if they are kept just because of laziness, or for good reasons (I clearly suspect the former). Laziness is a good reason. No one is going over back up tapes just for converting old documents ... as long as it is reasonably safe to assume it's still safe to open the old documents. Active use is a misleading term here. I still want to be able to look into - let's say - old exchanges with the tax authorities but I wouldn't ever want to change these documents. Be able to do that without fiddling around with an old version of OpenOffice.org is a major convenience. At any rate, binfilter is a huge, tangled mess (yes, more so than the average OOo module), and maintaining/building/shipping it benefits only those tiny fraction of users with sd?-documents. *If* we want to start reducing build time/reduce developer load/free resources for other tasks, then reducing code size is clearly top on the list - and binfilter would be a huge blob we could drop in one go. There are at least three possible ways to do this gracefully: a) drop binfilter for the next major release, telling users to convert their documents using OOo2.x. Can even implement a tiny filter replacement, that says so in a message box. Before we drop our own legacy filters (which would be a major inconvenience for lazy long time office users) we should think hard about obsolete 3rd party filters which could be removed without alienating our own user base. b) move _all_ modules below binfilter into that module, possibly after stripping them to the necessary minimum. Build it once, and tuck it into a safe place (comes close to a, but is smaller integrates with OOo3). Unrealistic, because rebuilding the binfilters might be necessary for all kind of reasons: compiler changes, base line changes, bug fixes, new platforms etc. Over long it would be part of the regular build again, now only bigger than ever before. c) have a webservice at services.openoffice.org, that runs OOo2.x, and gets accessed from the sd?-filter of OOo3 A webservice for confidential documents? Not a good idea ... Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compile error on Solaris 10
Hi, Joe Reid wrote: I am attempting to build Openoffice with all debug symbols and am getting an compiler/include file error: -- = Building project python = /jreid/OOO/OOC680_m7/python dmake: Executing shell macro: +-which cc dmake: Executing shell macro: pwd dmake: Executing shell macro: pwd dmake: Executing shell macro: pwd - mkdir ./unxsols4/misc/build/Python-2.3.4/ mkdir: Failed to make directory unxsols4/misc/build/Python-2.3.4/; File exists dmake: Executing shell macro: pwd cd ./unxsols4/misc/build/Python-2.3.4/ gmake -j1 ; gmake install ; chmod -R g+w /jreid/OOO/OOC680_m7/python/unxsols4/misc/build/python-inst touch so_built_so_python /opt/SUNWspro/bin/cc -c -DNDEBUG -O -I. -I./Include -KPIC -DPy_BUILD_CORE -o Modules/python.o Modules/python.c ./Include/Python.h, line 21: #error: limits.h is required by std C -- why isn't HAVE_LIMITS_H defined? cc: acomp failed for Modules/python.c gmake: *** [Modules/python.o] Error 2 -- Any pointers at all would be helpful. Which compiler do you use? SunStudio 11? It looks like the Python autoconf configuration for your compiler/OS combination doesn't work. I had no problem with SunStudio 8/Solaris 8. A quick workaround would be to modify Python.h to include limits.h unconditionally. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] External header guards
Thorsten Behrens wrote: Hi Kendy, you wrote: I hate them that much that I am willing to do a script that would do the removal ;-) What is the platform/compiler that probably needs this, please? Any volunteer to do a comparison of the with and without compilation times? That would be msvc 7.1 Go ahead with the script (I'd take that anyway, once we switch to 8.0) - I can do the timings. Please remember to do the timings against remote volumes. Thanks Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] In the Works: New OOo C++ Coding Standards
Stephan Bergmann wrote: Jens-Heiner Rechtien wrote: Jan Holesovsky wrote: Hi Thorsten, On Monday 18 December 2006 11:46, Thorsten Behrens wrote: Aah. Let me rephrase. Are -you- really sure the external include guard optimization provides enough benefit on all the compilers we are using to make it worthwhile to degrade readability by adding noise? Ie. is this a modest gain in machine time compared to a perhaps much costlier loss of human time? Can you provide some numbers to support this optimization or should we perhaps be conservative and not use it? ;-) ok, seems we've deadlocked here. ;-) Point is, the vast majority of the code uses that idiom as of today, and I'm reluctant to advice people of the contrary (as long as there are build time degradations on at least one prominent platform, at least when building on a network volume). Rather sooner than later, all used compilers will perform this optimization by themselves, and I'd say let's add the rule then. I'm relatively indifferent about this, though - if people think it's ok to start removing external header guards right now (because it will take years to clean them up anyway), I'd be fine with that, too. I hate them that much that I am willing to do a script that would do the removal ;-) What is the platform/compiler that probably needs this, please? Any volunteer to do a comparison of the with and without compilation times? AFAIK GCC and SunStudio know about the include guard optimization and do not need this. These platforms also do have no problem with caching a few files even if they are served from a remote volume, so it hardly wouldn't matter anyway. The one remaining compiler is Microsoft Visual Studio. There are varying reports if this compiler has a build-in include guard optimization or not. The acid test would be a build on Windows vs. a remote Samba or NFS volume (some people have such a setup). If the compile speed drops no more than - say - 5 to 10% we IMHO could do away with these ugly things. Heiner As I said before on this thread, makedepend (or whatever the tool is called exactly) did not implement the include guard optimization when I last checked a couple of years ago. (And makedepend is called before the compiler, on all platforms.) But the call for makedepend has been changed :-) We create now dependencies for all *.cxx in a directory in one step. Resulted in a huge speedup, especially on Windows :-) In this mode every header is only parsed once so it shouldn't make much of a difference. Would still need to be tested, of course. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Bounty for performance improvements
Hi Michael, With UTF2 you mean Uno Threading Framework 2? I can see how it helps the performance if we reduce mutex locking (especially Solar-Mutex, of course) but naively I would assume that reference counter as programming concept are mostly independent from that effort? Does UTF2 significantly reduce the amount of reference counter usage? How? Heiner Leibowitz, Michael wrote: Actually, yes. I'm glad to hear that we have a better implementation. If we can avoid locking as much as possible. UTF2 should help in this regard. -- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 3:39 AM To: dev@openoffice.org Subject: Re: [dev] Bounty for performance improvements Hi Michael, slightly off topic, but speaking of performance improvements: Didn't these numbers about the expense of the reference counters on older Intel processors (pre Hyperthreading, say Pentium III) come initially form you? I changed the implementation of the reference counters in m191 so on older processors should we see 5-6 percent improvements on the more notorious docs while hopefully not damaging the performance for current CPU's. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Bounty for performance improvements
Hi Thorsten, Thorsten Behrens wrote: Jens-Heiner Rechtien [EMAIL PROTECTED] writes: With UTF2 you mean Uno Threading Framework 2? I can see how it helps the performance if we reduce mutex locking (especially Solar-Mutex, of course) but naively I would assume that reference counter as programming concept are mostly independent from that effort? Does UTF2 significantly reduce the amount of reference counter usage? How? Not per se. And apart from that, the ref counting in _itself_ is indeed not addressed by UTF2. But the number of _atomic_ operations could be significantly reduced - a plain, non-locking integer operation should be fast everywhere. Well, but any reference counter increase/decrease still needs to be atomic as long as they are not thread local? How can we replace them with plain integer operations? Locking in the narrow context of the x86-reference counter discussion referred to the lock prefix of the xadd statement which locks the bus (so that the memory location in question can't be changed by another processor or by other means like DMA). It's not a locking operation in the sense of the synchronization primitive Lock, it's just the way x86 systems implements atomic integer operations. Whether we should go down that road (i.e. distinguishing between thread-safe and thread-unsafe ref counting all over the place) is a different question though... I really doubt that it's worth the trouble. We are talking about 1% gain for a potential hazardous change in case someone didn't get it right. The one expensive case (old Intel single processor systems where the lock prefix seems to be very expensive and is completely unneeded for reference counters) is taken care for. Eliminating unneeded reference counting itself is a worthy goal, as the improvements with the empty string showed. Heiner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Bounty for performance improvements
Hi Michael, slightly off topic, but speaking of performance improvements: Didn't these numbers about the expense of the reference counters on older Intel processors (pre Hyperthreading, say Pentium III) come initially form you? I changed the implementation of the reference counters in m191 so on older processors should we see 5-6 percent improvements on the more notorious docs while hopefully not damaging the performance for current CPU's. Heiner Leibowitz, Michael wrote: It's very easy to measure how long it takes to open a file. You can use the UNO API and gettimeofday. If just want something quick and dirty, you can just use RTL_LOGFILE. However, figuring out what is a typical document is not. For our performance profiling, we have a collection of about 100 documents culled from inside of Intel. This is an imperfect sample, and we've never felt comfortable with a particular set of documents as being representative. BTW, I'd also like to plug i#53055 at this time for speeding .doc imports (it even saves memory) -- Michael Leibowitz Software Engineer, Channel Platform Solutions Group Intel Corporation michael.leibowitz at intel.com +1 503 264 7621 -Original Message- From: Utomo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 8:07 PM To: dev@openoffice.org Subject: RE: [dev] Bounty for performance improvements Thanks for the suggestions. My original idea was. To make Ooo faster opening the Microsoft Office files. (but without adding memory usage by OOo) Especially for user with old computer, such as PIII with around 128 memory (which now mostly suffer from the huge memory usage by Ooo, and they feel very long time opening the Microsoft office files). I hear many PIII user complain about this, and this make them stop using Ooo. And I think it need to be improved, so it can make them happy and use Ooo. (I will provide some test file when the bounty start.) Example: Original Ooo without patch open the file in 60 second Ooo with patch open the file in 30 second In My opinion this is a 50% Improvements. But sometimes it is not easy to measure how long opening a files is. ( I think judges will help decide it) What do you think ? Best Regards, Utomo -Original Message- From: Andrew Douglas Pitonyak [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 10:35 AM To: dev@openoffice.org Subject: Re: [dev] Bounty for performance improvements Utomo wrote: I am waiting and open for suggestions. Is there somebody can help me to determine how is the performance improvements measured ? Utomo I have a few comments: Performance should be quantified and explained by the submitter. In other words, the submitter should indicate how to test and demonstrate a speed improvement. Memory and runtime both sounds like improvements to me. Broader impact should carry more weight. For example, a 100% improvement in sort speed is probably not as important as a 10% improvement in screen redraw time because the screen is almost always updated. By the same token, a 10% improvement in screen redraw may also beat a 20% improvement in macro run-time. I would probably use imprecise statements as those, and then after some prioritizing, leave the final decision to public voting if it is not obvious as to the final winner, or simply decide up front, that public voting will be done. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as ready for CWS usage?
Hi, Martin Hollmichel wrote: From technical perspective there seem to be no difference between milestone and step anymore, There was never a technical difference. It was just about the time Hamburg RE will hold a milestone which is absolutely meaningless for OOo which is why it was dropped. There was a time when a milestone could be incompatible and a step not, but this distinction is meaningless as well nowadays. I'm just for increasing the milestone number, but if a majority wants an indicator if a milestone is meant as an emergency fix we should call them m181fix or even m181fix1 or something. Heiner Martin Pavel Janík wrote: From: Martin Hollmichel [EMAIL PROTECTED] Date: Wed, 02 Aug 2006 15:51:44 +0200 Issues should always be fixed on the next milestones, I agree with this. But an idea: in the past we have seen several step milestones as well. So if the issue is critical enough, can't we just make *new* (next) step milestone with only the critical fix added and make it available faster than usual? This can fix the We have to wait a week for fixed milestone reply. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re-opening a milestone that has been announced as ready for CWS usage?
Hi,
regarding position _B) below: one should point out that the milestone
will be delayed for more than 2-3 days in case something is wrong with
the milestone. Creating a CWS, fixing the bug, rebuilding, repackaging,
doing again the automated tests can possibly delay the milestone by a
week or even more.
Another thing is what criteria do we establish for a bug which is severe
enough to stop a milestone? Certainly not the ones we do for for major
and minor releases, this is just a development milestone after all. But
what is a bad milestone for - say - using the writer in a meaningful way
can be a perfect milestone to base a new calc CWS on if it contains
urgent needed new stuff.
Any criteria for such milestone stopper bug will be necessarily
subjective in a way, at least everything short of saying that all
automated tests must be successful. The latter criteria would be a nice
one if it wouldn't take days to ensure this, I think we would become to
inflexible if we adopt that.
I would plead for keeping the current way to release development
milestones, that is, do the smoketest and than announce it. Maybe we
should enhance it with a milestone is really really bad, please don't
use, QA will not accept anything which is based on this notification
mechanism.
+1 for _A)
Heiner
Jörg Jahnke wrote:
Hi,
the P1 issue i67982, that was found on the milestone m179 of SRC680,
brought up the question whether there might be cases when it is useful
to re-open a milestone that has already been announced as ready for CWS
usage, in order to integrate a P1 bugfix. As this matter does not only
affect a few guys at Sun, I am trying to start this discussion again
here on the OOo list.
I will try to summarize some of the points which were already brought up
in the recent discussion (ruthlessly copying pasting from other
people's emails ;-)). Please excuse if this mail gets quite long
thereby. In replying it might be useful to keep only the part which seem
relevant to you.
_A) Reasons to always fix the issues on the next milestone_
After a milestone is announced on [EMAIL PROTECTED],
developers nearly immediately start working on that milestone, they
create childworkspaces or resync their existing CWS against it. For
doing so they rely on having the cvs tags fixed.
What could be a reason to re-open an existing milestone?
1) A milestone could pass smoketest but nevertheless contain issues
rendering it useless for parts of the stake holders. Example: current
issue i67982 causing writer to crash on red linig or tables, build
issues making a milestone totally unusable (build breaks) for OOo
community developers.
2) A milestone could contain code integrated 'by accident' which is not
allowed to be in the code line. For example license protected code not
allowed to be distributed.
Ad 1) Developer perspective: for those not already working on that
milestone it makes no difference, whether to wait for a rebuild or for a
new milestone. For those who are already working on that milestone a
re-open would cause additional trouble if they need to get the new fix.
Getting it from a new milestone would be standard task with normal
tooling support ('cwsresync'). Getting it from the same milestone
requires manual work (throw away your solver, get the new one, rebuild
if necessary).
QA perspective: for serious QA you cannot accept that milestone as base
for any CWS. No one knows by sure in what state such a CWS would be:
does it already contain the late fix, or not? Of course you would gain a
testable master milestone, but what is the difference in waiting for a
rebuild of milestone x and waiting for milestone x+1 containg just that
one fix? Technically you would win nothing.
So, to summarize: no benefit for developers, more work to do for some
developers, no real benefit for QA - no solution at all. Scenario 1
does not need re-opening an existing milestone.
Ad 2) Allthough we did not have this situation yet, there may be cases
where we are required to undo master commits regardless from all
negative consequences.
What would be consequences of fixing bugs on existing milestone (in
contrast to doing them ASAP for the next build)?
- More work for developers (see above).
- Unambiguity about the state of such a milestone and derived work. We
have no versioning withing milestones, no one could tell whether
something based on a redone milestone is done before or after that fix
(see 'QA perspective' above).
- Unambiguity about when a milestone is really ready for use. At the
moment everyone can rely on the announce mails. If we start redoing
milestones, when should a developer be shure a milestone is good? I f.e.
would stop creating CWSs against the latest milestone, I would take the
one before, just to be shure I do not have to redo my work.
- Another question that comes up: what kind of P1 tasks is severe enough
to redo a build? Who decides about that?
What would
Re: [dev] workspace handling
Hi Caolan, you are not alone with this, check for instance encupfix01, soldep1, perftest03, hr33 and a few others. QA was very busy with OOo-2.0.3, so I think that's understandable. As for the approved but not yet nominated CWSs, that's mostly due to warnings01 which just due to sheer size hold up everything for a few weeks. BTW, it helps if you prod MH a bit if a CWSs is approved but not nominated :-) Heiner Caolan McNamara wrote: I'm a little worried about how long it's taking my workspaces to go anywhere, and I'm wondering if this is normal both for external and internal workspaces, i.e. today is Jul 3 and I've 4 unintegrated workspaces which are out my hands. xalanupgrade ready for qa since May 5 = 59 days unchanged fpicker6 ready for qa since May 24 = 40 days unchanged targetedaot approved since Jun 12 = 21 days unchanged bfsixtyfour approved since Jun 15 = 18 days unchanged And interestingly, since some of those workspaces were created, I've just realized that according to http://ooomisc.services.openoffice.org/pub/OpenOffice.org/cws/upload/readme.txt the cws upload site has moved, and the original installsets for some of these workspaces have apparently disappeared in the meanwhile :-( C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] CWS warnings01 Integrated
Hi Christian, you are a little to fast ... integration was still under way at 12:00 am CEST :-). It's no wonder your build broke. Heiner Stephan Bergmann wrote: Christian Lohmaier wrote: Hi Stephan, On Tue, Jun 20, 2006 at 10:28:51AM +0200, Stephan Bergmann wrote: almost a year ago, I announced that we started a project to get the OOo (C/C++) code base warning-free, see http://www.openoffice.org/servlets/ReadMsg?list=devmsgNo=14653. Today, I can announce that a large part of this project (CWS warnings01) is right now being integrated into SRC680m173. Hmm - I fear you need to masterfix to allow building with gpc. Making: ../unxlngi6.pro/slo/gpc.obj cc1: warnings being treated as errors gpc.c: In function ‘gpc_polygon_clip’: gpc.c:1130: warning: ‘tl’ may be used uninitialized in this function gpc.c:1130: warning: ‘tr’ may be used uninitialized in this function gpc.c:1130: warning: ‘bl’ may be used uninitialized in this function gpc.c:1130: warning: ‘br’ may be used uninitialized in this function gpc.c:1129: warning: ‘contributing’ may be used uninitialized in this function gpc.c:1131: warning: ‘dy’ may be used uninitialized in this function gpc.c:1131: warning: ‘yt’ may be used uninitialized in this function dmake: Error code 1, while making '../unxlngi6.pro/slo/gpc.obj' ERROR: Error 65280 occurred while making /home/cloph/compile/shadow/external/gpcdmake: Error code 1, while making 'instsetoo_native/prj/build_instsetoo_native''---* tg_merge.mk *---' http://go-oo.org/tinderbox/warnings01/status.html This is strange, as external/gpc/makefile.mk:1.3.18.1 contains EXTERNAL_WARNINGS_NOT_ERRORS=TRUE, which should cause warnings not to be treated as errors when building gpc. Can you make sure that you have got the correct version of makefile.mk, and if yes provide me with a few more log lines before the error occurs (I were not able to extract that from the above tinderbox link, but am not really familiar with tinderbox). -Stephan - I just yesterday stumbled upon the that for unxlngi6[.pro], we only concentrated on GCC 3.4.1, while other GCC versions produce slightly different warnings (that will break the build now on those GCC versions), see http://www.openoffice.org/issues/show_bug.cgi?id=66577. Could be related to that one. Is Sun building with gpc at all? [...] ciao Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
Hi,
between SRC680 m164 and SRC680 m170 some important performance
improvements have been integrated, most notably is the empty string no
longer reference counted. This has significantly reduced the number of
reference counter calls. I redid the measurement to see if there is
still a significant impact of the lock prefix on the overall performance.
$ time ./soffice numbers_large.ods
With lock, w/o lock, w/o lock but with check for SMP
31.566 31.142 30.762
32.515 30.909 30.807
32.247 30.515 31.413
31.695 30.594 30.812
32.008 30.449 30.924
-- -- --
Mean 32.006 30.722 30.944
Std 0.349 0.263 0.241
The gain for old machines is now some 3.3% (column 1 and 3), the penalty
for new machines because of the additional check (column 2 and 3) can be
estimated to be somewhere around 0.7%. I no longer think that the gain
on older machines warrants the penalty on modern systems.
BTW column 1 and 2 are directly comparable to the columns below, a 23%
improvement from m164 to m170, wow!
On another note: Inlining on Solaris Sparc machines saves only about 10%
per call to the reference counter. The overall influence of inlining on
the performance is thus probably not measurable on this platform.
Heiner
Jens-Heiner Rechtien wrote:
Hi,
I did some measurements with a copy of SRC680 m164 and one of the more
pathological calc documents, and found that the lock prefix indeed
imposes a significant overhead of about 8% on a non HT 1.8 GHz Pentium IV.
(The tests included starting StarOffice, loading the document and
closing the application as soon as the document is loaded).
$ time ./soffice numbers_large.ods
With lock: w/o lock
user time: 41.474s38.379s
user time: 41.611s38.676s
user time: 41.796s38.397s
user time: 41.623s38.412s
user time: 41.696s38.742s
mean: 41.64s 38.52s
Comparing the wall clock times showed essentially the same value of 8%
overhead for the lock case.
Heiner
Stephan Bergmann wrote:
Hi all,
Someone recently mentioned that
osl_increment/decrementInterlockedCount would show up as top scorers
with certain profiling tools (vtune?). That got me thinking. On both
Linux x86 and Windows x86, those functions are implemented in
assembler, effectively consisting of a LOCK-prefixed XADD. Now, I
thought that, at least on a uniprocessor machine, the LOCK would
probably not be that expensive, but that the profiling tool in
question might be confused by it and present bogus results.
However, the following little program on Linux x86 (where incLocked is
a copy of osl_incrementInterlockedCount, and incUnlocked is the same,
without the LOCK prefix) told a different story:
// lock.c
#include stdio.h
int incLocked(int * p) {
int n;
__asm__ __volatile__ (
movl $1, %0\n\t
lock\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
return n;
}
int incUnlocked(int * p) {
int n;
__asm__ __volatile__ (
movl $1, %0\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
return n;
}
int main(int argc, char ** argv) {
int i;
int n = 0;
if (argv[1][0] == 'l') {
puts(locked version);
for (i = 0; i 1; ++i) {
incLocked(n);
}
} else {
puts(unlocked version);
for (i = 0; i 1; ++i) {
incUnlocked(n);
}
}
return 0;
}
m1 cat /proc/cpuinfo
processor : 0
model name: Intel(R) Pentium(R) 4 CPU 1.80GHz
...
m1 time ./lock l
locked version
11.868u 0.000s 0:12.19 97.2% 0+0k 0+0io 0pf+0w
m1 time ./lock u
unlocked version
1.516u 0.000s 0:01.57 96.1% 0+0k 0+0io 0pf+0w
m2 cat /proc/cpuinfo
processor : 0
model name: AMD Opteron(tm) Processor 242
processor : 1
model name: AMD Opteron(tm) Processor 242
...
m2 time ./lock l
locked version
1.863u 0.000s 0:01.86 100.0% 0+0k 0+0io 0pf+0w
m2 time ./lock u
unlocked version
0.886u 0.000s 0:00.89 98.8% 0+0k 0+0io 0pf+0w
So, depending on CPU type, the version with LOCK is 2--8 times slower
than the version without LOCK. Would be interesting to see whether
this has any actual impact on overall OOo performance. (But first,
I'm off on vacation...)
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
Hi,
I've done some additional very simple minded measurements to estimate
the effects of inling the reference counters and the potential overhead
for checking if we are on a SMP system. I got the following numbers:
I: inlining
NOI:no-inlining
SMPC: SMP check
NOSMPC: no SMP check
Times are in seconds.
NOI/NOSMPC, I/NOSMPC, NOI/SMPC, I/SMPC
P-IV 1800 (single)7.634 6.892 1.796 0.784
Xeon 3.06GHz (multi) 6.504.07 6.674.11
Conclusions: Checking for SMP costs about 1% (4.11s vs. 4.07s)
additionally on multi-processor machines, and yields about 880% speed
improvement on older non-HT/non-multiprocessor systems. Inlining is
significant, too. The effect of inlining dwarfs the penalty for checking
for SMP on modern multi-processor systems.
The measurements were done with the simple benchmark attached, they are
of course no substitute for doing some real profiling with the office code.
Heiner
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
CFLAGS= -I. -fPIC -O2 -Wall -DINLINE -DCHECKSMP
#CFLAGS= -I. -fPIC -O2 -Wall -DINLINE
#CFLAGS= -I. -fPIC -O2 -Wall -DCHECKSMP
#CFLAGS= -I. -fPIC -O2 -Wall
intrlock: intrlock.o libsal.so
$(CC) $(CFLAGS) -o intrlock $ -L. -lsal
libsal.so: sal.o
$(CC) -shared -o libsal.so $
clean:
rm *.o libsal.so intrlock
all: intrlock libsal.so
extern int is_smp;
#if defined(INLINE)
#if defined(CHECKSMP)
inline int incrementInterlockedCount(int *p) {
int n;
if ( is_smp ) {
__asm__ __volatile__ (
movl $1, %0\n\t
lock\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
}
else {
__asm__ __volatile__ (
movl $1, %0\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
}
return n;
}
#else /* !CHECKSMP */
inline int incrementInterlockedCount(int *p) {
int n;
__asm__ __volatile__ (
movl $1, %0\n\t
lock\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
return n;
}
#endif /* !CHECKSMP */
#else /* INLINE */
int incrementInterlockedCount(int *p);
#endif /* INLINE */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Completely lost in the building process...
Hi, Alexandre Laforest wrote: Hi all, I'm starting to research OpenOffice.org possibilities and I admit being stuck in the build process. I need to build with Windows 2000 Pro (no comments please, ;-)), but I thought using Cygwin was mandatory (is it?). Moreover, I must build in a VMWare image since I cannot get a VS .NET 2003 licence for my office workstation. Thus, I have followed the instructions I found at: http://tools.openoffice.org/dev_docs/build_windows_tcsh.html#BuildingaFullBuildofOpenOffice, but got stuck at the /Generating the Build Environment and Build Tools /step: I can not seem to get the 'configure' script to work from a command-line. Either DOS or Cygwin. Here's what I've got: - Windows 2000 Pro SP4 - Visual Studio .NET 2003 - gcc 3.3.1 - j2sdk1.4.2_11 - Cygwin Consequently, a couple of questions puzzle me: 1. Is it possible to build OOo in a VMWare environment?? Yes. I don't know if someone recently did such a build, but it used to work. It won't help the compile time, though :-) 2. Does the source code need to be in the same drive (partition) as Cygwin and the compilers? No. But plan for a lot of disk space for the source tree. The generated binaries take up a lot of space. 3. Can you actually use multiple drives? Depends. Splitting up the source tree over multiple drives is not really recommended. 4. Am I on the right track or completely lost? The track is still in sight :-) 5. Could someone point a proper 'how-to' if the one I've been using is not right? Some additional notes are here: http://wiki.services.openoffice.org/wiki/Windows -- Jens-Heiner Rechtien OpenOffice.org Release Engineer Technical Lead Release Enginering, StarOffice [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
Thorsten Behrens wrote: Jens-Heiner Rechtien [EMAIL PROTECTED] writes: BTW, on newer processors (P4, Xeon etc) the lock prefix shouldn't be that expensive, because if the target memory of the instruction is cacheable the CPU will not assert the Lock# signal (which locks the bus) but only lock the affected cache line. Wasn't Stephan's original measurement based on a P4 (model name: Intel(R) Pentium(R) 4 CPU 1.80GHz), with a factor-eight slowdown? I think that Intel changed the behavior with the introduction of HT in Pentium 4, so Stefans machine is still one which locks the whole bus. Could be wrong here, though. So, how to go forward from here? Is anybody trying out/profiling the proposed changes (switch on multi-coreness, inlining)? I volunteer for that, but I got two projects to finish before that, so it could take a little time. Heiner -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
Hi Ross, thanks for your numbers. So it looks like the lock prefix inside the reference counters will have on older processors - exactly where it's not needed at all - an impact which dwarfs even the costs for not inlining the reference counter. I'll have a look at it. Heiner Ross Johnson wrote: On Mon, 2006-04-24 at 16:19 +0200, Jens-Heiner Rechtien wrote: Ross Johnson wrote: The timings for the Interlocked routine calling and for the inlined non- locked asm using MSVC 6 were almost identical, whereas the inlined locked asm was much slower. The same tests using GCC showed the Interlocked calls to be similar to the slower locked asm from either GCC or MSVC. The inlined non-locked asm for MSVC and GCC were very similar. GCC may have been a little faster, reflecting that gcc can optimise the inlined asm by substituting registers. Your measurements seem to suggest that Microsoft uses a conditional approach in the non-inlined version of the Interlocked[In|De]crement routines, without lock prefix for older processors/single processor systems. The additional check penalizes newer HT/multicore/multiprocessor systems, if it matters at all needs to be measured. I checked my notes and there isn't actually much difference between MSVC and GCC when calling the Interlocked routines - they are both faster than results using the locked prefix. So it isn't the compiler but the dll itself that appears to conditionally switch. I had also completely forgotten that I emulate xchg using cmpxchg to avoid the mandatory buss lock on that instruction. The following results are for an application that performs saturated pthreads reader-writer lock operations using pthreads-win32, which uses xchg and cmpxchg inline assembler in the underlying mutex and semaphore routines. It's not important, but these times are total milliseconds for 5 threads to perform 1,000,000 access operations each (about 50,000 writes and 950,000 reads each). On a 2.4GHz i686 single-core, single processor. --- inlined inlined call PTW32 xchg XCHGInterlockedExchange ... GCC 641 1687765 VC6.0 844 1750891 --- As you say below, the XCHG instruction always locks the buss, so I emulate the XCHG instruction using the CMPXCHG instruction. The times for the emulated xchg (inlined PTW32 xchg in the table) and the real XCHG instruction (inlined XCHG) are shown above. The InterlockedExchange call timings suggest that it also uses cmpxchg instead of xchg, and that it doesn't use the lock prefix. Even though the time spent in the xchg operation is a small proportion of the whole application, the difference in overall run time with and without the lock prefix (first two result columns) is 2 to 2.5 times. AFAIK, the xchg etc instructions are atomic without the lock prefix on the single (non-hyperthreaded (TM)) processor system that I'm still using. The Intel manuals states that xchg implicitly behaves as if it had a lock prefix. Yes. See above. BTW, on newer processors (P4, Xeon etc) the lock prefix shouldn't be that expensive, because if the target memory of the instruction is cacheable the CPU will not assert the Lock# signal (which locks the bus) but only lock the affected cache line. Otherwise, for some very specific multithreaded applications, a single processor can still beat two processors working together. :o) Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jens-Heiner Rechtien [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] x86 osl/interlck.h performance
Hi,
I did some measurements with a copy of SRC680 m164 and one of the more
pathological calc documents, and found that the lock prefix indeed
imposes a significant overhead of about 8% on a non HT 1.8 GHz Pentium IV.
(The tests included starting StarOffice, loading the document and
closing the application as soon as the document is loaded).
$ time ./soffice numbers_large.ods
With lock: w/o lock
user time: 41.474s38.379s
user time: 41.611s38.676s
user time: 41.796s38.397s
user time: 41.623s38.412s
user time: 41.696s38.742s
mean: 41.64s 38.52s
Comparing the wall clock times showed essentially the same value of 8%
overhead for the lock case.
Heiner
Stephan Bergmann wrote:
Hi all,
Someone recently mentioned that osl_increment/decrementInterlockedCount
would show up as top scorers with certain profiling tools (vtune?). That
got me thinking. On both Linux x86 and Windows x86, those functions are
implemented in assembler, effectively consisting of a LOCK-prefixed
XADD. Now, I thought that, at least on a uniprocessor machine, the LOCK
would probably not be that expensive, but that the profiling tool in
question might be confused by it and present bogus results.
However, the following little program on Linux x86 (where incLocked is a
copy of osl_incrementInterlockedCount, and incUnlocked is the same,
without the LOCK prefix) told a different story:
// lock.c
#include stdio.h
int incLocked(int * p) {
int n;
__asm__ __volatile__ (
movl $1, %0\n\t
lock\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
return n;
}
int incUnlocked(int * p) {
int n;
__asm__ __volatile__ (
movl $1, %0\n\t
xaddl %0, %2\n\t
incl %0 :
=r (n), =m (*p) :
m (*p) :
memory);
return n;
}
int main(int argc, char ** argv) {
int i;
int n = 0;
if (argv[1][0] == 'l') {
puts(locked version);
for (i = 0; i 1; ++i) {
incLocked(n);
}
} else {
puts(unlocked version);
for (i = 0; i 1; ++i) {
incUnlocked(n);
}
}
return 0;
}
m1 cat /proc/cpuinfo
processor : 0
model name: Intel(R) Pentium(R) 4 CPU 1.80GHz
...
m1 time ./lock l
locked version
11.868u 0.000s 0:12.19 97.2% 0+0k 0+0io 0pf+0w
m1 time ./lock u
unlocked version
1.516u 0.000s 0:01.57 96.1% 0+0k 0+0io 0pf+0w
m2 cat /proc/cpuinfo
processor : 0
model name: AMD Opteron(tm) Processor 242
processor : 1
model name: AMD Opteron(tm) Processor 242
...
m2 time ./lock l
locked version
1.863u 0.000s 0:01.86 100.0% 0+0k 0+0io 0pf+0w
m2 time ./lock u
unlocked version
0.886u 0.000s 0:00.89 98.8% 0+0k 0+0io 0pf+0w
So, depending on CPU type, the version with LOCK is 2--8 times slower
than the version without LOCK. Would be interesting to see whether this
has any actual impact on overall OOo performance. (But first, I'm off
on vacation...)
-Stephan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jens-Heiner Rechtien
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
