Re: [Libreoffice] LibreOffice config migration
Hi, Am 14.10.2010 07:51, schrieb Mechtilde: please don't take any user information from older version without any agreemaent of the user I second this. If you do so you haven't the possibilityy to start *office with a new user directory e.g in case you destroy something yourself. Correct. Config migration is not sometimes not very reliable and you may end up with a broken config. Best way to get around this is to remove config dir. But normally the people who give support only know about the *current* config dir - so if there are some legacy directories, these will not be removed and break the config at the next start. André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice config migration
Hello please don't take any user information from older version without any agreemaent of the user If you do so you haven't the possibilityy to start *office with a new user directory e.g in case you destroy something yourself. If you don't want a dialog then create a user directory with the defaut setting as you do it on a mschine where this *office is installed the first time Kind regards Mechtilde Am 13.10.2010 22:58, schrieb Noel Power: On Tue, 2010-10-12 at 15:07 +0100, Michael Meeks wrote: Would it be possible to add a non-modal / floating / dialog to prompt users to migrate / import their macros from an old version if it hasn't been previously imported, and we know that they have really been editing / changing their macros ? a reasonably rare case I suspect. I don't exactly get what you mean, the migration purely takes place first time libreoffice is run ( e.g. your config profile doesn't exist and you have no macros ) so I dont understand the 'previously imported' bit Later on if you want to suck in macros from somewhere else I guess that's a different story, there already exists some ( poor ) import capability from the IDE ( we could definitely improve that if necessary ) Anyway I pushed the change to Setup.xcu to add Openoffice.org 3.x as a supported versio to migrate data from. If there are any objections let me know and of course I can back that out Noel -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Improving the build experience in rawbuild
Hi Christian, CC'ing the list as you apparently forgot to Reply All. On Thu, 2010-10-14 at 00:44 +0200, Christian Lohmaier wrote: The current build procedure described on the wiki and TDF website builds in build/libreoffice*. In order to change that, I'ld like to do the following: * Change the rawbuild/configure.in to have the defaults matching the options defined in distros-config/LibreOfficeLinux.conf.in What about Mac? What about Windows? Hum... You're right! Any better idea to have something smooth very everyone? * Hack bin/g to have bin/g clone download all the repos at the appropriate place and create the rawbuild folder. I don't understand this part. Why would you need to hack this when rawbuild folder is generated now already? The point is to generate it sooner: it is now generated by download which is generated by the build/autogen.sh. The idea here is to have a simple process to build in rawbuild instead of build/libreoffice* I'd like to be able to do rm -rf build and run make again, without re-downloading stuff again (ideally stuff downloaded using different scripts should end up in different directories, but not below build) I'd like to have one build-directory for the core office, I don't mind whether that would be build/rawbuild or different, it just should be named the same when the tree is updated. The downloaded stuffs are currently in the src folder of the build repository and are added to the gitignore files: you can currently run a rm -rf build safely :) If the dev builds are happening in rawbuild, it'll be more complicated as rawbuild is a lot of symlinks to the clone folder. but I agree that something like make clean (properly working) would be needed. I'd like to be able to git diff in the build-directory. That's why building in the current rawbuild is interesting: we could use bin/g tool to create the patches and/or commit directly instead of some black magick to move the changes from build/libreoffice* into rawbuild. And of course I'd like to be the version for Mac that way as well as a Linux version. Indeed... If that is what you propose, then sorry for not being able to parse your message. If your proposal differs significantly, I'd be happy if you could explain in more detail. The main problem I have with building in rawbuild is that one needs to input a lot of arguments to the configure depending on his OS / Distro. These infos are all in the distros-config folder of the build repository: it would be nice to be able to reuse them when running the rawbuild/autogen.sh I hope to have explained my thoughts a bit better. -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH]Remove death code and comments
Hi Gil! Reviewed, pushed. Thanks, KAMI 2010-10-14 02:09 keltezéssel, Gil Forcada írta: patch that removes death code and comments on writer/sw/source signature.asc Description: OpenPGP digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] C{,PP}FLAGS ignored in sal
On Thu, 2010-10-14 at 08:37 +0200, Thomas Klausner wrote: On Wed, Oct 13, 2010 at 05:25:59PM +0200, Thomas Klausner wrote: I don't see my CFLAGS nor CPPFLAGS, which would make it find boost, in the gcc arguments. How can I make them used in this part of the build? I don't think we have any proper support to pass CFLAGS and CPPFLAGS down to everything correctly. You can try using ARCH_FLAGS as a route to pass extra flags down to the final compiler line. Ok, if that question is too detailed... I haven't yet understood how to start parts of the build, I'm always running autogenmake from toplevel. E.g.: Yeah, the current story is roughly that, taking the current documented make route, that there is a build wrapper around the core build stuff. The toplevel ./autogen.sh sets up the inner build, and some other foo. Where is the build executable I'm supposed to run when a build is interrupted? So, if you open another shell (to keep this simple) and cd build/build/libreoffice-3.2.99.2 source *Env.Set.sh alias|grep build= build is an alias to a build.pl in solenv and go to the broken module, say sw cd sw build Do I need to set some environment variables before running it? Yeah, the somethingEnv.Set.sh, e.g. LinuxX86-64Env.Set.sh for me, in the root of the libreoffice-3.2.99.2 build dir What are the files used by dmake to find out what to do? all those makefile.mk files (How) Can I run dmake manually? In which directory? Does it need environment variables set as well? yeah, build calls dmake in each dir, so again lets take sw, and say that the breakage is in sw/source/filter/ww8 cd sw/source/filter/ww8 dmake Anything else I should know about building? The current documented libreoffice build route is one where the different split git repos live in build/clone, they are all symlinked to build/rawbuild and the toplevel build/Makefile rsyncs rawbuild into build/build/libreoffice-3.2.99.2 and runs the inner configure in there, sources the EnvSet.sh file and runs the build alias in there. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice config migration
Mechtilde wrote: please don't take any user information from older version without any agreemaent of the user If you do so you haven't the possibilityy to start *office with a new user directory e.g in case you destroy something yourself. If you don't want a dialog then create a user directory with the defaut setting as you do it on a mschine where this *office is installed the first time Hi Mechtilde, all, well, this is surely not an easy decision to make - but there's definitely a way to have LibO use a clean user dir, if you need it: -env:UserInstallation=file:///path/to/config So if we can agree that migrating user configuration is a sensible thing for the majority of the users, we should default to that - and fix all bugs that make this experience a bad one (including a prune of the 2.x migration from known-bad things - I need your help here, Mechtilde, you have a fancy ooo2 dir, with stuff I don't have). Having less options, and not hiding a sensible feature like config migration away in a menu, is generally a good thing, I guess. Cheers, -- Thorsten pgppU2D5U27sZ.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error Building, vcl segmentation fault
Hi Rene, On Wed, 2010-10-13 at 19:54 +0200, Rene Engelhard wrote: On Tue, Oct 12, 2010 at 12:13:15PM +0200, Lubos Lunak wrote: On Tuesday 12 of October 2010, Michael Meeks wrote: Having said that - it looks like this may be some horrendous compatibility problem between the internal stlport and the system version - but we'll need to chase that down. Possibly we simply can't use our own stlport if we link KDE, unclear - Lubos: thoughts ? I don't see the point of using stlport if the system is capable of building KDE, in which case I'd expect the compiler to provide an adequate STL implementation itself. ABI compatibility to OOo C++ extensions is one. (Though happily only for i386 on Linux) Nasty - so we could be in the position of choosing between KDE integration, and extension/plugin compatibility ? Lets hope Caolan's iostream fix hides the problem for now ;-) Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error Building, vcl segmentation fault
On Thu, 2010-10-14 at 10:04 +0100, Michael Meeks wrote: Nasty - so we could be in the position of choosing between KDE integration, and extension/plugin compatibility ? If there *is* something in the KDE headers which replies on the native STL which is triggering this, which I'm not utterly convinced by yet, but if that's the problem then we can put #include preextstl.h and preextstl.h before and after the kde header include lines and the same sort of -Dsomething and ext_std:: we're using for graphite, etc. Perhaps adding some more stuff to those, depending on what from the KDE headers might be using STL. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error Building, vcl segmentation fault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 14/10/2010 11:04, Michael Meeks wrote: ABI compatibility to OOo C++ extensions is one. (Though happily only for i386 on Linux) Nasty - so we could be in the position of choosing between KDE integration, and extension/plugin compatibility ? We use in openSUSE a workaround that solves this incompatibility for a theoretical 99% of extensions. We build OOo against system STL implementation, but we provide the stlport library built externally for extensions that link with stlport. I investigated the headers of OOo SDK and found only very rare cases when this could actually be not working. Cheers F. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky2y90ACgkQu9a1imXPdA+q6gCeKsRWILjrby/Bl3h4YteE1xPj AzgAmwROWuMvd/+ibBI9JqvvfzR9k1uN =64m8 -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] running 'build' ...
On Thu, Oct 14, 2010 at 4:19 AM, Michael Meeks michael.me...@novell.com wrote: Hi Thomas, On Thu, 2010-10-14 at 08:37 +0200, Thomas Klausner wrote: Where is the build executable I'm supposed to run when a build is interrupted ? Ah - good point :-) I'll update the build script to print a more useful message in a bit, but first: Do I need to set some environment variables before running it? Yes - you need to: cd build/libreoffice* source Linux*Set.sh cd directory-that-failed build # it is a shell alias What are the files used by dmake to find out what to do? 'build' is a perl-script, that parses prj/build.lst to work out what can be built, and how much parallelism the code can cope with. (How) Can I run dmake manually? In which directory? Does it need environment variables set as well? yes, and yes - dmake gets all it needs from sourcing that (huge) environment script; so just run it: dmake There are some useful flags to dmake and build - the most important are: verbose=1 # let me see the compile lines debug=true # enable assertions and debugging symbols -P10 # do 10 builds in parallel ;-) Anything else I should know about building? Not really, great questions :-) ATB, Michael. PS. Spaetz any chance you could add these to the wiki somewhere ? :-) It's been there already: http://wiki.documentfoundation.org/Development#The_Build_Failed..._What_can_I_do_.3F -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] The Windows installer
I see that it's an installer that includes all the languages but i wonder if it is really necessary and if the languages are the only cause. Well, there certainly isn't hundreds (or even tens) of megabytes of new code, as far as I know, so yes, it must be the languages. Even if the installed size is about 500 MB, isn't the installer too big? I wonder what's the planned direction about it. The plan is what the community consensus is. (Or what somebody is brave enough to just do, or is told to do.) Feel free to provide explicit suggestions how to package LibreOffice for Windows, and take part in discussion in the relevant forum. (This list? Or a Document Foundation list, or audio/IRC meeting? I don't know.) Of course, this is supposed to be a meritocracy, I think, so if you have actual experience in building and packaging OOo or LO installers, that gives you more clout. To me were more smart the go-oo approach: an english installer + the interested language pack. Sorry, but I think that is against the Document Foundation's Next Decade Manifesto, which says: WE REJECT: [...] the creeping domination of computer desktops by a single language forcing people to learn a foreign language before they can express themselves electronically OK, so if an *installer* could be multi-lingual even if it installs just the English UI, what you say could be a viable approach. Currently that is not possible, as far as I know, but it should be possible to do it that way using some amount of work on the Perl code that directs the installer generation. Something to discuss, sure. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Filters - Remove unnecessary #ifdef PCH comments
Hi Graeme, On Wed, 2010-10-13 at 23:31 +0100, jgraeme wrote: Patch to remove unused #ifdef PCH and comments, Wonderful - thanks :-) [ wonder why they were still there ] Pushed, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Script used to change the product codes
Hi Fridrich, On Wed, 2010-10-13 at 16:12 -0600, Fridrich Strba wrote: I run the script on the relevant code*.txt files in instsetoo_native and I reverted all stuff that concerns BrOffice back, since its product code was distinct from OOo product code. IMHO - we just want to bin that different broffice product - with the new splash / about / shell branding work - we should be collapsed into a single product, that is branded correctly per-locale. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] unable to create 'refs/heads/master.lock' in libs-extern-sys
On Wed, 2010-10-13 at 20:49 +0100, Caolán McNamara wrote: fatal: unable to create 'refs/heads/master.lock': File exists fatal: The remote end hung up unexpectedly This is cleared now, dunno if someone helped out, or if the lock got deleted automatically after some timeout. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] NEEDINFO in the FreeDesktop bugzilla
Hi, The Novell Bugzilla has a nice feature I am missing in the FreeDesktop bugzilla - the NEEDINFO state, and its straightforward handling. This is for the bugs that are waiting for input, mostly from the initial reporter. Nevertheless, we have the possibility to use the NEEDINFO keyword. In addition to that, I think Whiteboard looks suitable for the address of the supposed info provider - how does that sound to you? I mean, when the bug description is incomplete, you would set: - 8 - Whiteboard: addr...@of.the.info.provider Keywords: NEEDINFO Addition Comments: Please provide the missing strace, and also the exact steps to reproduce, etc. - 8 - When the info is provided, you'd reset Whiteboard and remove NEEDINFO from Keywords. If OK [ie. nobody vetoes the use of Whiteboard for the info provider address ;-)], I'll hack a GreaseMonkey script that will ease the NEEDINFO setting/showing/resetting. [BTW - there is one more nice Keyword, 'patch' - for bugs with a patch attached.] Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Fix RTF export incorrect output with nested tables
Hi Miklos, On Thu, 2010-10-14 at 12:58 +0200, Miklos Vajna wrote: Hi Cedric, See attached patch, it fixes exporting the http://cgit.freedesktop.org/~vmiklos/ooo-gsoc/tree/writer/hallenverzeichnis_2003.odt?h=ooo-test-files test file - before the fix, only the first column was visible in Word. OK to push? I'ld say yes: the patch looks fine... thought I haven't built it ;) Push it and we'll bother you if there's something wrong with it. Regards -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] running 'build' ...
PS. Spaetz any chance you could add these to the wiki somewhere ? :-) http://wiki.documentfoundation.org/Development#What_else_to_know_about_the_build_system.3F Aye captain! ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice config migration
André Schnabel wrote: well, this is surely not an easy decision to make - but there's definitely a way to have LibO use a clean user dir, if you need it: -env:UserInstallation=file:///path/to/config and this will prevent, that LibO will migrate any old userconfig when this path is used the first time? Heh, good point - you're, as always, right. :) So we indeed need a way to prevent LibO from doing migration on first start - just pushed a fix for that: export SAL_DISABLE_USERMIGRATION=1; soffice ... gives you a virgin user installation (subsequent runs will not require that env var, as the migration is flagged as done). Having a migration wizard, that also permits selecting the actual source config, and/or selecting only subsets of the config, would be cool indeed, but I think that's something orthogonal to this question. Cheers, -- Thorsten pgpnR7oEEqgx4.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] NEEDINFO in the FreeDesktop bugzilla
Jan Holesovsky wrote: On 2010-10-14 at 13:17 +0200, Jan Holesovsky wrote: - 8 - Whiteboard: addr...@of.the.info.provider Whiteboard: infoprovider:addr...@of.the.info.provider might be actually better; no strong opinion though ;-) Yes, I like that better - there may be other content in whiteboard. Cheers, -- Thorsten pgp0Aq27OPRU1.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Error Building, vcl segmentation fault
On Wed, 2010-10-13 at 22:30 +0200, julien wrote: Thread 1 (Thread 0xb7d276d0 (LWP 15195)): #0 0xb68061db in _STL::locale::locale() () from /usr/lib/libstlport_gcc.so.4.6 #1 0xb67d1414 in _STL::ios_base::ios_base() () from /usr/lib/libstlport_gcc.so.4.6 #2 0xb67e3a41 in _STL::ios_base::_S_initialize() () from /usr/lib/libstlport_gcc.so.4.6 #3 0xb67e3f17 in _STL::ios_base::Init::Init() () from /usr/lib/libstlport_gcc.so.4.6 #4 0xb64d755e in global constructors keyed to debugplotter.cxx () from /home/serval/libreoffice-source/build/build/libreoffice-3.2.99.2/solver/330/unxlngi6.pro/lib/libbasegfxli.so Well, I succeeded in moving the crash until later on :-). I've committed another micro optimization which'll likely have the effect of moving the crash slightly further along again. We're at least immeasurably slightly improving our start up time :-) You need to find out why your libraries are apparently getting linked against, or resolved against /usr/lib/libstlport_gcc.so.4.6 as opposed to the one in the solver/unxlngi6.pro/lib dir C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] LO: Linux distro specific packages vs. universal build
Hi, I think about what package names and paths use for the openSUSE LibreOffice packages. I wonder how they should conflict with the universal Linux Libre Office build and what they should share with it. I think that there are three main things: 1. installation root path: + /opt/libreoffice3 - used by the universal linux build by default + /usr/lib(64)/libreoffice - proposed path for distro-specific build 2. user configuration: + ~/.libreoffice/3 - used by the universal linux build + ~/.libreoffice/3-distro - proposed alternative distro-specific path, e.g. ~/.libreoffice/3-suse I tried to use the same directory but the other build did not start because incompatible berkley DB, see the attached screenshot 3. package names: + libreoffice-ure, libreoffice3*, libobasis3.3* - used by the universal Linux build + libreoffice* - preferred distro-specific package name The universal and distro-specific packages can be installed in parallel because they use different paths. The only problem is the same name for the libreoffice-ure package. I suggest to rename it to libreoffice3-ure in the universal linux build. What do you think? Best Regards, Petr attachment: db-error.png___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO: Linux distro specific packages vs. universal build
Hi, On Thu, Oct 14, 2010 at 04:45:57PM +0200, Petr Mladek wrote: I think about what package names and paths use for the openSUSE LibreOffice packages. I wonder how they should conflict with the universal Linux Libre Office build and what they should share with it. I think that there are three main things: 1. installation root path: + /opt/libreoffice3 - used by the universal linux build by default Well, I don't see why we should keep that version here too but I can live with it being there. + /usr/lib(64)/libreoffice - proposed path for distro-specific build OK. 2. user configuration: + ~/.libreoffice/3 - used by the universal linux build + ~/.libreoffice/3-distro - proposed alternative distro-specific path, e.g. ~/.libreoffice/3-suse I tried to use the same directory but the other build did not start because incompatible berkley DB, see the attached screenshot I'd use the same user directory, personally. We use the same bdb as universal/vanilla anyways. 3. package names: + libreoffice-ure, libreoffice3*, libobasis3.3* - used by the universal Linux build + libreoffice* - preferred distro-specific package name Jup. The universal and distro-specific packages can be installed in parallel because they use different paths. The only problem is the same name for the libreoffice-ure package. I suggest to rename it to libreoffice3-ure in the universal linux build. We use simply ure in Debian. Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LO: Linux distro specific packages vs. universal build
Hi, On Thu, Oct 14, 2010 at 08:55:40AM -0600, Fridrich Strba wrote: On Thu, 2010-10-14 at 16:45 +0200, Petr Mladek wrote: 2. user configuration: + ~/.libreoffice/3 - used by the universal linux build + ~/.libreoffice/3-distro - proposed alternative distro-specific path, e.g. ~/.libreoffice/3-suse I tried to use the same directory but the other build did not start because incompatible berkley DB, see the attached screenshot Ok, when we were distributing GoOo as OpenOffice_org, we were using ~/.ooo3, why not to use something like ~/.libo3 ? Other, long-run task could be to use sqlite3 instead of Oracle-owned berkeley db :) I never liked .ooo3 (and never used it either, but just took OOos default - .openoffice.org/3) Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Slowness on UNC path
- camille moulin camille.mou...@free.fr a écrit : - Michael Meeks michael.me...@novell.com a écrit : [...] It would be just great (if you can reproduce this) I can reproduce this no problem Strangely, since I install windbg files now open normally, but closing still takes 30 seconds. - to attach a debugger to soffice in this 20 second window I'll try to do that (never done that before, so it might take me a while) following http://wiki.services.openoffice.org/wiki/Windows_Debugging - abort it, and see what back-trace we get; that'd be most helpful. Here is what I did: -Launch OOo -Launch Windbg -Open my file in OOo -In Winddbg File Attach to process 652 Soffice.bin -In Winddbg : Debug Go -In OOo : File Close -In Winddbg : Debug Break -In Winddbg : kv The result is below. Please tell me if I should do something differently. Best, Camille Microsoft (R) Windows Debugger Version 6.12.0002.633 X86 Copyright (c) Microsoft Corporation. All rights reserved. *** wait with pending attach Symbol search path is: *** Invalid *** * Symbol loading may be unreliable without a symbol search path. * * Use .symfix to have the debugger choose a symbol path. * * After setting your symbol path, use .reload to refresh symbol locations. * Executable search path is: ModLoad: 0040 00ecd000 C:\Program Files\OpenOffice.org 3\program\soffice.bin ModLoad: 7c90 7c9b2000 C:\WINDOWS\system32\ntdll.dll ModLoad: 7c80 7c8f6000 C:\WINDOWS\system32\kernel32.dll ModLoad: 1000 101af000 C:\Program Files\OpenOffice.org 3\URE\bin\sal3.dll ModLoad: 0025 00269000 C:\Program Files\OpenOffice.org 3\URE\bin\uwinapi.dll ModLoad: 7e41 7e4a1000 C:\WINDOWS\system32\USER32.dll ModLoad: 77f1 77f59000 C:\WINDOWS\system32\GDI32.dll ModLoad: 77dd 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll ModLoad: 77e7 77f03000 C:\WINDOWS\system32\RPCRT4.dll ModLoad: 77fe 77ff1000 C:\WINDOWS\system32\Secur32.dll ModLoad: 77c0 77c08000 C:\WINDOWS\system32\VERSION.dll ModLoad: 7852 785c3000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_d495ac4e\MSVCR90.dll ModLoad: 77f6 77fd6000 C:\WINDOWS\system32\SHLWAPI.dll ModLoad: 77c1 77c68000 C:\WINDOWS\system32\msvcrt.dll ModLoad: 71ad 71ad9000 C:\WINDOWS\system32\WSOCK32.dll ModLoad: 71ab 71ac7000 C:\WINDOWS\system32\WS2_32.dll ModLoad: 71aa 71aa8000 C:\WINDOWS\system32\WS2HELP.dll ModLoad: 774e 7761d000 C:\WINDOWS\system32\ole32.dll ModLoad: 71b2 71b32000 C:\WINDOWS\system32\MPR.dll ModLoad: 0028 002d9000 C:\Program Files\OpenOffice.org 3\program\sofficeapp.dll ModLoad: 002f 003eb000 C:\Program Files\OpenOffice.org 3\program\comphelp4MSC.dll ModLoad: 0186 018cd000 C:\Program Files\OpenOffice.org 3\URE\bin\cppuhelper3MSC.dll ModLoad: 018e 018e8000 C:\Program Files\OpenOffice.org 3\URE\bin\salhelper3MSC.dll ModLoad: 0190 01927000 C:\Program Files\OpenOffice.org 3\URE\bin\cppu3.dll ModLoad: 0194 019d7000 C:\Program Files\OpenOffice.org 3\URE\bin\stlport_vc7145.dll ModLoad: 019f 01a4b000 C:\Program Files\OpenOffice.org 3\program\ucbhelper4MSC.dll ModLoad: 01a6 01a7b000 C:\Program Files\OpenOffice.org 3\program\vos3MSC.dll ModLoad: 01a9 01a99000 C:\Program Files\OpenOffice.org 3\program\i18nisolang1MSC.dll ModLoad: 01ab 01db8000 C:\Program Files\OpenOffice.org 3\program\sfxmi.dll ModLoad: 01dd 01ea4000 C:\Program Files\OpenOffice.org 3\program\fwemi.dll ModLoad: 01ec 01f1a000 C:\Program Files\OpenOffice.org 3\program\fwimi.dll ModLoad: 01f3 01fa5000 C:\Program Files\OpenOffice.org 3\program\utlmi.dll ModLoad: 01fc 0203c000 C:\Program Files\OpenOffice.org 3\program\tlmi.dll ModLoad: 0205 020e3000 C:\Program Files\OpenOffice.org 3\program\basegfxmi.dll ModLoad: 7c9c 7d1d7000 C:\WINDOWS\system32\SHELL32.dll ModLoad: 0210 023fa000 C:\Program Files\OpenOffice.org 3\program\vclmi.dll ModLoad: 0241 02452000 C:\Program Files\OpenOffice.org 3\program\sotmi.dll ModLoad: 0247 0247b000 C:\Program Files\OpenOffice.org 3\program\i18npapermi.dll ModLoad: 0249 024a6000 C:\Program Files\OpenOffice.org 3\program\i18nutilMSC.dll ModLoad: 024c 025ac000 C:\Program Files\OpenOffice.org 3\program\icuuc40.dll ModLoad: 025c 03307000 C:\Program Files\OpenOffice.org 3\program\icudt40.dll ModLoad: 4ec5 4edfb000 C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.6001.22319_x-ww_f0b4c2df\gdiplus.dll ModLoad: 7638 76385000 C:\WINDOWS\system32\MSIMG32.dll ModLoad: 7300 73026000 C:\WINDOWS\system32\WINSPOOL.DRV ModLoad: 7639 763ad000 C:\WINDOWS\system32\IMM32.dll ModLoad: 0332 03517000 C:\Program
Re: [Libreoffice] LO: Linux distro specific packages vs. universal build
On Thu, 2010-10-14 at 16:45 +0200, Petr Mladek wrote: Hi, I think about what package names and paths use for the openSUSE LibreOffice packages. I wonder how they should conflict with the universal Linux Libre Office build and what they should share with it. + /usr/lib(64)/libreoffice - proposed path for distro-specific build Yup, works for me. 2. user configuration: + ~/.libreoffice/3 - used by the universal linux build + ~/.libreoffice/3-distro - proposed alternative distro-specific path, e.g. ~/.libreoffice/3-suse I tried to use the same directory but the other build did not start because incompatible berkley DB, see the attached screenshot I thought that problem has been sort of fixed at some stage to ignore/overwrite those databases when they couldn't be opened (#i107440), *shrug*, if not, then sure, the above works for me. We got something similar with dual boot guys with different versions of the same distro, so maybe best to somehow version that name using the version of db that OOo is built against :-) 3. package names: The only problem is the same name for the libreoffice-ure package. I suggest to rename it to libreoffice3-ure in the universal linux build. Yeah, this has been something a problem in the past. That works for me. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] cppcheck fixes under libs-core
- unopage.cxx and unoshap2.cxx: remove redundant null checks for pointers that
have already been checked for null value
- odma_datasupplier.cxx: fix memory leak if NODMQueryExecute returns with
error
Harri
diff --git a/svx/source/unodraw/unopage.cxx b/svx/source/unodraw/unopage.cxx
index 4504c99..e4f9abb 100644
--- a/svx/source/unodraw/unopage.cxx
+++ b/svx/source/unodraw/unopage.cxx
@@ -330,8 +330,7 @@ void SAL_CALL SvxDrawPage::add( const uno::Reference drawing::XShape xShape
if(pObj == NULL)
return;
-if(pShape)
-pShape-Create( pObj, this );
+pShape-Create( pObj, this );
if( mpModel )
mpModel-SetChanged();
diff --git a/svx/source/unodraw/unoshap2.cxx b/svx/source/unodraw/unoshap2.cxx
index b0c48b7..10fd236 100644
--- a/svx/source/unodraw/unoshap2.cxx
+++ b/svx/source/unodraw/unoshap2.cxx
@@ -249,8 +249,7 @@ void SAL_CALL SvxShapeGroup::add( const uno::Reference drawing::XShape xShap
// Establish connection between new SdrObject and its wrapper before
// inserting the new shape into the group. There a new wrapper
// would be created when this connection would not already exist.
-if(pShape)
-pShape-Create( pSdrShape, mxPage.get() );
+pShape-Create( pSdrShape, mxPage.get() );
if( mpModel )
mpModel-SetChanged();
diff --git a/ucb/source/ucp/odma/odma_datasupplier.cxx b/ucb/source/ucp/odma/odma_datasupplier.cxx
index 86d1326..8225175 100644
--- a/ucb/source/ucp/odma/odma_datasupplier.cxx
+++ b/ucb/source/ucp/odma/odma_datasupplier.cxx
@@ -288,8 +288,11 @@ sal_Bool DataSupplier::getResult( sal_uInt32 nIndex )
DWORD dwFlags = ODM_SPECIFIC;
odm = NODMQueryExecute(ContentProvider::getHandle(), sQuery,dwFlags, lpszDMSList, pQueryId );
-if(odm != ODM_SUCCESS)
+if(odm != ODM_SUCCESS) {
+delete[] pQueryId;
+delete[] lpszDMSList;
return sal_False;
+}
sal_uInt16 nCount = 10;
sal_uInt16 nMaxCount = 10;
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] cppcheck fixes under libs-core
Hi Harri, On Thu, 2010-10-14 at 19:01 +0300, Harri Pitkänen wrote: - unopage.cxx and unoshap2.cxx: remove redundant null checks for pointers that have already been checked for null value - odma_datasupplier.cxx: fix memory leak if NODMQueryExecute returns with error Nice looking fixes - cleaning things up :-) thanks for that ! Pushed, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] comment translation
hi' Libre Office mailing list,
I've looked through the calc's chart2 source and translated and spell
corrected a few
comments in the view code
in the ChartItemPool I've added the use of SAL_N_ELEMENTS(array) too
greetings
René Kjellerup
(aka Katana Steel)
--
-- as life grows older, I gain experience.
diff --git a/chart2/source/view/main/ChartItemPool.cxx
b/chart2/source/view/main/ChartItemPool.cxx
index face424..f3b6205 100644
--- a/chart2/source/view/main/ChartItemPool.cxx
+++ b/chart2/source/view/main/ChartItemPool.cxx
@@ -131,11 +131,11 @@ ChartItemPool::ChartItemPool():
ppPoolDefaults[SCHATTR_STYLE_LINES- SCHATTR_START] = new SfxBoolItem
(SCHATTR_STYLE_LINES, 0);
ppPoolDefaults[SCHATTR_STYLE_PERCENT - SCHATTR_START] = new SfxBoolItem
(SCHATTR_STYLE_PERCENT, 0);
ppPoolDefaults[SCHATTR_STYLE_STACKED - SCHATTR_START] = new SfxBoolItem
(SCHATTR_STYLE_STACKED, 0);
-ppPoolDefaults[SCHATTR_STYLE_SPLINES - SCHATTR_START] = new SfxInt32Item
(SCHATTR_STYLE_SPLINES, 0); //Bug: war Bool! -Fileformat testen (betrifft nur
5er)
+ppPoolDefaults[SCHATTR_STYLE_SPLINES - SCHATTR_START] = new
SfxInt32Item (SCHATTR_STYLE_SPLINES, 0); //Bug: was Bool! test -Fileformat
(touches only 5's)
ppPoolDefaults[SCHATTR_STYLE_SYMBOL - SCHATTR_START] = new SfxInt32Item
(SCHATTR_STYLE_SYMBOL, 0);
ppPoolDefaults[SCHATTR_STYLE_SHAPE- SCHATTR_START] = new SfxInt32Item
(SCHATTR_STYLE_SHAPE, 0);
-ppPoolDefaults[SCHATTR_AXIS-
SCHATTR_START] = new SfxInt32Item(SCHATTR_AXIS,2); //2 = Y-Achse!!!
+ppPoolDefaults[SCHATTR_AXIS-
SCHATTR_START] = new SfxInt32Item(SCHATTR_AXIS,2); //2 = Y-Axis!!!
ppPoolDefaults[SCHATTR_AXIS_AUTO_MIN - SCHATTR_START] = new
SfxBoolItem(SCHATTR_AXIS_AUTO_MIN);
ppPoolDefaults[SCHATTR_AXIS_MIN-
SCHATTR_START] = new SvxDoubleItem(0.0, SCHATTR_AXIS_MIN);
@@ -201,7 +201,7 @@ ChartItemPool::ChartItemPool():
pItemInfos = new SfxItemInfo[SCHATTR_END - SCHATTR_START + 1];
USHORT i;
-for( i = SCHATTR_START; i = SCHATTR_END; i++ )
+for( i = SCHATTR_START; i = SAL_N_ELEMENTS(pItemInfos); i++ )
{
pItemInfos[i - SCHATTR_START]._nSID = 0;
pItemInfos[i - SCHATTR_START]._nFlags = SFX_ITEM_POOLABLE;
@@ -229,7 +229,7 @@ ChartItemPool::~ChartItemPool()
delete[] pItemInfos;
-const USHORT nMax = SCHATTR_END - SCHATTR_START + 1;
+const USHORT nMax = SAL_N_ELEMENTS(ppPoolDefaults);
for( USHORT i=0; inMax; ++i )
{
SetRefCount(*ppPoolDefaults[i], 0);
diff --git a/chart2/source/view/main/ChartView.cxx
b/chart2/source/view/main/ChartView.cxx
index 3a55690..c44b819 100644
--- a/chart2/source/view/main/ChartView.cxx
+++ b/chart2/source/view/main/ChartView.cxx
@@ -621,7 +621,7 @@ void
SeriesPlotterContainer::initializeCooSysAndSeriesPlotter(
const uno::Reference frame::XModel xChartModel )
{
// get model series from model
-sal_Int32 nDiagramIndex = 0;//todo if more than one diagam is supported
+sal_Int32 nDiagramIndex = 0;//todo if more than one diagram is supported
uno::Reference XDiagram xDiagram( ChartModelHelper::findDiagram(
xChartModel ) );
if( !xDiagram.is())
return;
@@ -699,7 +699,7 @@ void
SeriesPlotterContainer::initializeCooSysAndSeriesPlotter(
if(pVCooSys)
pVCooSys-addMinimumAndMaximumSupplier(pPlotter);
-// add series to plotter and thus prepare him for
providing minimum and maximum values
+// add series to plotter and thus prepare him(it) for
providing minimum and maximum values
uno::Reference XDataSeriesContainer xDataSeriesContainer(
xChartType, uno::UNO_QUERY );
OSL_ASSERT( xDataSeriesContainer.is());
if( !xDataSeriesContainer.is() )
@@ -860,7 +860,7 @@ void SeriesPlotterContainer::setScalesFromCooSysToPlotter()
void SeriesPlotterContainer::setNumberFormatsFromAxes()
{
-//set numberfarmats to plotter to enable them to display the data labels
in the numberfromat of teh axis
+//set numberformats to plotter to enable them to display the data labels
in the numberformat of the axis
::std::vector VSeriesPlotter* ::const_iterator aPlotterIter =
m_aSeriesPlotterList.begin();
const ::std::vector VSeriesPlotter* ::const_iterator aPlotterEnd =
m_aSeriesPlotterList.end();
@@ -1851,7 +1851,7 @@ sal_Int32 lcl_getExplicitNumberFormatKeyForAxis(
if( nDimensionIndex == 1 )
{
-//only take those series into accoutn that are
attached to this axis
+//only take those series into account that are
attached to this axis
sal_Int32 nAttachedAxisIndex =
DataSeriesHelper::getAttachedAxisIndex(xDataSeries);
[Libreoffice] User mailing list
Hi, Message for Dev. Please have a look at users list. http://the-document-foundation.969070.n3.nabble.com/OFFSET-function-don-t-works-tp1700974p1700974.html Thanks for your great work. Gérard -- View this message in context: http://the-document-foundation.969070.n3.nabble.com/User-mailing-list-tp1702874p1702874.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] code cleanup 4
git diff attached. contributed under the LGPLv3+ Jacopo Nespolo nespoloj_patch4 Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] SAL_N_ELEMENTS changes for libs-core
Hi Kayo, On Thu, 2010-10-14 at 09:18 -0700, Kayo Hamid wrote: SAL_N_ELEMENTS changes for libs-core A really nice cleanup, carefully done :-) thank you ! Pushed, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Improving the build experience in rawbuild
Hi guys, On Thu, 2010-10-14 at 09:31 +0200, Cedric Bosdonnat wrote: * Change the rawbuild/configure.in to have the defaults matching the options defined in distros-config/LibreOfficeLinux.conf.in What about Mac? What about Windows? Hum... You're right! Any better idea to have something smooth very everyone? Soo ... I think we can cope with a slightly different flow for mac and windows (at some level this is inevitable). * personally I'd love to get rid of 'build' - it just adds confusion, and possible loss in my view. Can we not make 'unpack' do one of two things: On Windows [ and Mac? ] * create 'rawbuild' and rsync it as/when necessary to 'build' On Linux * create 'build' as a set of symlinks (a-la-rawbuild) And then continue almost as normal ? The point is to generate it sooner: it is now generated by download which is generated by the build/autogen.sh. The idea here is to have a simple process to build in rawbuild instead of build/libreoffice* We could do it as part of download I guess. I'd like to be able to do rm -rf build and run make again, without re-downloading stuff again (ideally stuff downloaded using different Right - hopefully the symlinks make that possible, without making it dangerous. Having said that hopefully we could get used to using make clean instead - which is the normal way for most autotools packages. And of course I'd like to be the version for Mac that way as well as a Linux version. I guess if macs have symlinks, this would work well too (?) though clearly it would be even more ideal not to have symlinks - but to build each module into a different OUTPATH, or just rely on 'make clean' to cleanup the pieces in the tree. So - why should we not switch the default build to happen inside a 'rawbuild' like directory ? Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Enable Microsoft Visual C++ 10 compiler
Hi all, I have been using LO compiled with Visual C++ 10 to do my homework for more than a week now so I will assume that I can merging some patches :) This first patch is very simple, it just enables the compiler and puts it at the very end of the list, so it will only try to compile it with Visual C++ 10 if it doesn't find anything else installed. So I think it's safe to apply. Note: The build will not go very far until the other patches are merged. -- Jesús Corrius je...@softcatala.org Document Foundation founding member Skype: jcorrius | Twitter: @jcorrius 0001-Enable-Microsoft-Visual-C-10-compiler-in-the-build-s.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] spaces in directory with another file open
Does anyone else use KDE? It doesn't matter if I use the LibreOffice file dialogs, it doesn't like spaces in the directory name. It ONLY happens if a document is already open. LibreOffice 3.3.0 OOO330m9 (Build:1) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Enable Microsoft Visual C++ 10 compiler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks, pushed F. On 15/10/2010 01:45, Jesús Corrius wrote: Hi all, I have been using LO compiled with Visual C++ 10 to do my homework for more than a week now so I will assume that I can merging some patches :) This first patch is very simple, it just enables the compiler and puts it at the very end of the list, so it will only try to compile it with Visual C++ 10 if it doesn't find anything else installed. So I think it's safe to apply. Note: The build will not go very far until the other patches are merged. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky3n30ACgkQu9a1imXPdA/djACffrV1/ZGk5wCqsKFdGX4BZTtv jtEAnj9cRUMxDDsTBwETJ/JgDWc6flae =Q4qt -END PGP SIGNATURE- ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH 1/3] Translate German comments in ure/xml2cmp
Signed-off-by: Laurent Charrière lcharri...@gmail.com
---
xml2cmp/source/support/list.hxx |4 ++--
xml2cmp/source/xcd/cr_index.cxx |2 +-
xml2cmp/source/xcd/main.cxx |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xml2cmp/source/support/list.hxx b/xml2cmp/source/support/list.hxx
index 7678752..6de123e 100644
--- a/xml2cmp/source/support/list.hxx
+++ b/xml2cmp/source/support/list.hxx
@@ -165,7 +165,7 @@ template class XX
void
ListXX::checkSize(unsigned newLength)
{
- // neuen Platzbedarf pruefen:
+ // test new size requirement:
unsigned newSpace = space();
if (newLength newSpace)
{
@@ -184,7 +184,7 @@ ListXX::checkSize(unsigned newLength)
}
}
- // Veraenderung ?:
+ // change?
if (newSpace != space())
alloc(newSpace,true);
}
diff --git a/xml2cmp/source/xcd/cr_index.cxx b/xml2cmp/source/xcd/cr_index.cxx
index f4f0d28..aef1432 100644
--- a/xml2cmp/source/xcd/cr_index.cxx
+++ b/xml2cmp/source/xcd/cr_index.cxx
@@ -241,7 +241,7 @@ Index::WriteHeap( std::ostream o_rOut,
-/**�bersicht der Struktur
+/**Structure overview
MODULEDESCRIPTION
{
diff --git a/xml2cmp/source/xcd/main.cxx b/xml2cmp/source/xcd/main.cxx
index c40e09f..7e13807 100644
--- a/xml2cmp/source/xcd/main.cxx
+++ b/xml2cmp/source/xcd/main.cxx
@@ -128,7 +128,7 @@ Do_SingleFileCommandLine(const CommandLine i_rCommandLine)
int
Do_IndexCommandLine(const CommandLine i_rCommandLine)
{
-// Parsen files:
+// Parse files:
ListSimstr aFiles;
Index aIndex( i_rCommandLine.OutputDirectory(),
i_rCommandLine.IdlRootPath(),
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH 2/3] Delete commented out code in ure/xml2cmp
Signed-off-by: Laurent Charrière lcharri...@gmail.com
---
xml2cmp/source/finder/dependy.cxx |1 -
xml2cmp/source/xcd/main.cxx |1 -
xml2cmp/source/xcd/parse.cxx |4
3 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/xml2cmp/source/finder/dependy.cxx
b/xml2cmp/source/finder/dependy.cxx
index 4daca23..1b34b56 100644
--- a/xml2cmp/source/finder/dependy.cxx
+++ b/xml2cmp/source/finder/dependy.cxx
@@ -104,7 +104,6 @@ DependencyFinder::FindNeededServices( StringVector
o_rLibraries,
aResult_Libraries.erase( aResult_Libraries.begin(),
aResult_Libraries.end() );
aResult_Services.erase( aResult_Services.begin(), aResult_Services.end() );
-// const ServiceInfo rSInfo = (*itService).second-FirstImplementation();
Add2Result( *(*itService).second );
for ( std::set Simstr ::const_iterator il = aResult_Libraries.begin();
diff --git a/xml2cmp/source/xcd/main.cxx b/xml2cmp/source/xcd/main.cxx
index 7e13807..377cd9a 100644
--- a/xml2cmp/source/xcd/main.cxx
+++ b/xml2cmp/source/xcd/main.cxx
@@ -213,7 +213,6 @@ Create_TypeInfo( const char *
o_sOutputFile,
if ( 0 == strcmp(pHeapTop-Key(), pLastHeapTop-Key()) )
continue;
delete pLastHeapTop;
-// pLastHeapTop = 0;
}
pLastHeapTop = pHeapTop;
diff --git a/xml2cmp/source/xcd/parse.cxx b/xml2cmp/source/xcd/parse.cxx
index 906b407..20198cf 100644
--- a/xml2cmp/source/xcd/parse.cxx
+++ b/xml2cmp/source/xcd/parse.cxx
@@ -442,10 +442,6 @@ X2CParser::SyntaxError( const char * i_sText )
void
X2CParser::TestCurChar()
{
-// if (*text == '\0')
-// SyntaxError(unexpected end of file);
-// else
-
if (*text == '\n')
nFileLine++;
}
--
1.7.1
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
