Re: [Libreoffice] STAR_RESOURCEPATH env variable
On Thu, 18 Nov 2010 19:50:01 +, Michael Meeks wrote: > This is used by 'ooenv': > > export STAR_RESOURCEPATH=`pwd`/../basis-link/program/resource Ooops, thanks for the pointer. I am glad I asked before removing seemingly obsolete code pieces. Perhaps I should insert a code comment explaining where it is still used :). Sebastian pgp5OQ5BzJzgb.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] feature/rip-build-repo - branch for removal of the need of the 'build' repo
On Fri, 19 Nov 2010 04:18:46 +0100, Jan Holesovsky wrote: > Hi, > > In case you are interested to try to build without the 'build' repo (the > rawbuild/ way), you can try to get the feature/rip-build-repo branch > which I hope is going to become the 'official' way of building soon ;-) > > git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo > cd libo/ > git checkout -b rip-build-repo origin/rip-build-repo > > ./autogen.sh [flags that you normally use in rawbuild/] > ./g clone BTW, this doesn't work right yet ? Or is it some git failure ./g clone = artwork = Initialized empty Git repository in /media/lo/artwork/.git/ fatal: The remote end hung up unexpectedly ./g: line 202: cd: /media/lo/clone/artwork: No such file or directory pgp8BCBd1GN4u.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] feature/rip-build-repo - branch for removal of the need of the 'build' repo
On Fri, 19 Nov 2010 04:18:46 +0100, Jan Holesovsky wrote: > In case you are interested to try to build without the 'build' repo (the > rawbuild/ way), you can try to get the feature/rip-build-repo branch > which I hope is going to become the 'official' way of building soon ;-) Very cool, I look forward to switching to this very soon, to get one canonical way of building. Personally, I would be very much in favor of doing ./g clone and ./download automatically if they haven't been done, as part of the make. This is the sequence that I intuitively (naively?) expect to work: ./autogen ./make ./make check ./make install We can always have a --disable-downloads switch that one can turn on if he wants a true ofline mode. Sebastian P.S. I don't like to clutter top-level dirs and would be in favor of keeping it as bin/g, but that's a minor issue. pgplR4MviFsbn.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] crash report and Oracle url
Hi, Yesterday I got the crash report in LibO after a test of docking the navigator on the right edge of the LibO window. It contained a link to the privacy policy of Oracle. I did not sent the crash report because it was no clear for me who is the recipient of this crash report. Best regards JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] make help typo fix
On Thu, 2010-11-18 at 21:58 -0500, Kevin Hunter wrote: > Hullo List, > > My girlfriend sat down as I was finishing some code reading, and noted > from my adjacent terminal window that, "For a detail-oriented computer > person, you sure can't spell." :-) Pretty innocuous fix. Pushed. P.S. Who can spell these days? I sure can't. ;-) Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] feature/rip-build-repo - branch for removal of the need of the 'build' repo
Hi, In case you are interested to try to build without the 'build' repo (the rawbuild/ way), you can try to get the feature/rip-build-repo branch which I hope is going to become the 'official' way of building soon ;-) git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo cd libo/ git checkout -b rip-build-repo origin/rip-build-repo ./autogen.sh [flags that you normally use in rawbuild/] ./g clone ./download make make dev-install [./g is there in toplevel, but can be in bin/, I am not sure what is more convenient for you?] How does it look like? The repos are again in a clone/ subdir, but this time, they are linked to the bootstrap toplevel (libo/ in the example above), so you 'feel' like having everything at hand. 'g' works both on bootstrap and the repos in clone/, so you don't need to do "git something && g something" any more, one "g something" is enough. It is not ready for integration yet, TODOs: - ./autogen.sh should work without params for most uses (ie. default to the same values as ./autogen.sh in the build repo does) - this means tweaking the default values according to the distro-config/LibreOffice*.conf.in - ./g clone should be called in ./download, when necessary Let me know if you actually prefer to have it integrated ~now, it should not interfere with the build/ repo in general, and would allow/pressure others to help me fix the above mentioned TODOs :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] make help typo fix
Hullo List, My girlfriend sat down as I was finishing some code reading, and noted from my adjacent terminal window that, "For a detail-oriented computer person, you sure can't spell." Patch attached. Kevin 0001-Spelling-error-fix.patch.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Proposal: Enhancements in Easy_Hacks Wiki Page
Hi Sebastien, On 2010-11-14 at 00:50 -0800, Sebastien Delvaux wrote: > Hey everyone, i already sent an email when after i saw this one, i > "speak" c#, html, basic, applescript and a bit of javascript, There is an Easy Hack that would use your JavaScript skills, and would help a lot :-) http://wiki.documentfoundation.org/Development/Easy_Hacks&setlang=en#GreaseMonkey_script_to_show_a_NEEDINFO_status_in_bugzilla Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] just find all .sdf files and do not use GNU find arguments
Hi Robert, On 2010-11-13 at 19:00 +0100, Robert Nagy wrote: > -for sdf_file in `find $TOOLSDIR/src $DEB_GSIDIR $TOOLSDIR/po $SRCDIR_PIECE > -path $TOOLSDIR/src/clone -prune -o -name "*.sdf"` ; do > +for sdf_file in `find $TOOLSDIR/src $DEB_GSIDIR $TOOLSDIR/po $SRCDIR_PIECE > -path $TOOLSDIR/src/clone -name "*.sdf"` ; do I am afraid this is not equivalent :-( The "-path -prune" means "ignore the complete structure". Unfortunately, I don't know what is the portable way to achieve that (other than find ... | while read P ; do ... ; done, or something). Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
Hi Wol, On 2010-11-18 at 11:29 +, Wols Lists wrote: > > So, I think that it should default to -O2 on a normal build, and to > > -O0 when using --enable-symbols. Don't see the point of using > > optimizations when building a version for debugging purposes. > > What if it's the optimisation that introduces the bug? We've had such already, and when debugging that, the use of the configure switches is the smallest problem you have ;-) - you have to do much more magic to be able to isolate the problem (eg. compile part of the file with -O0 and the other part with -O), instead of relying on the configure switches. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Problem if switching on --with-lang=all
Hi, On Thu, 18 Nov 2010 20:09:21 -0400, "werner" wrote: > When I switch on --with-lang=all , then a previously successful build stops, > with the following error message: > in sysui/util/unxlngi6.pro/misc is produced a /sysui/dummy/localize.sdf with > size =0, and checksize.pl stops the compilation saying thefile is 'damaged' > > This have to be corrected - otherwhise, how to produce the language files ? It sounds the same as http://lists.freedesktop.org/archives/libreoffice/2010-October/001268.html So it might be a FAQ, good to add its entry, say, on http://wiki.documentfoundation.org/Development/How_to_build/localized Cheers, -- Takeshi Abe > > wl > --- > Professional hosting for everyone - http://www.host.ru > ___ > 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] [PATCH] writer, #i66304#
Hi Andras, On 2010-11-15 at 00:04 +0100, Andras Timar wrote: > The attached patch allows localizers to translate the string "My > AutoText" which comes from mytexts.bau. > It has been unresolved since 2006: > http://qa.openoffice.org/issues/show_bug.cgi?id=66304 > There is a thread about this issue on [libreoffice-l10n] and I would > not mind, if the patch could be added to libreoffice-3-3 branch, too. > It adds only one string, and if it was not translated by some language > teams, that would not be a regression. Agreed, pushed to the libreoffice-3-3 branch [with slight modifications, hopefully I did not break the patch with them ;-)] Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Contributing test cases
On Thu, Nov 18, 2010 at 11:58:29AM +, Caolán McNamara wrote: > 1) basic cppunit tests take place during the build, keep us honest and > basic functionality working at all times. Have a few of these at the > moment. > 2) smoketest run at the end of the build, at least by the buildbots to > make sure that works. This needs a little bit more love, at the moment > I've some enthusiasm that I may have found some of problems that makes > it die horribly at exit time for some people. > 3) a bit optional module/repo filled with masses of test cases with a > simple "make" target that gets run at release time and/or whenever qa > folk want to test the build. Hi, Is 3) about cppunit as well? If yes, what about just having 3) in the tree as well, and then it could be invoked with a 'make check' or similar that would run all those tests. I'm asking because I guess the more complex to run it, the fewer people will actually try it out at all. pgppBqGNMeWzF.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git server-side hooks
On Thu, Nov 18, 2010 at 04:52:56PM +0100, Jan Holesovsky wrote: > Sorry for that, I did not see all the consequences :-( > > It really sounds as reverting is the safer choice - Miklos, can you > please do that? I just did so in the libreoffice-3-3 branch. If it's urgent, I can cherry-pick it manually to master before you would merge it anyway. > [For me, the best would be a 'read my mind' kind of pull - if you pull, > and have just few commits up to 2-3 days old, and no merge commit among > them, it would do 'pull -r', otherwise 'pull --no-rebase' :-) I'll try > to improve the merge hook warning that way, so that it warns only in the > cases where 'pull -r' is really the better choice; currently it shouts > too often.] What about just not shouting in case you are on a feature branch? Then the only false positive will be when you merge OOo tags, but you know what you're doing and that's rare. pgpoaY22rW33A.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git server-side hooks
On Thu, Nov 18, 2010 at 08:28:36AM -0500, Kohei Yoshida wrote: > Also, I have no doubt that some of us will start using feature branches > to share development with others, and if my understanding is correct > (which it may not be) rebasing locally and pushing to the remote feature > branch when it's not fastforward would screw up the other person's > branch state... Or is my understanding not correct? No, that's correct, I did not think about feature branches are used by multiple developers as well. Let's just not rebase anything that has been pushed already. pgp9z5OwQ6XCh.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Problem if switching on --with-lang=all
When I switch on --with-lang=all , then a previously successful build stops, with the following error message: in sysui/util/unxlngi6.pro/misc is produced a /sysui/dummy/localize.sdf with size =0, and checksize.pl stops the compilation saying thefile is 'damaged' This have to be corrected - otherwhise, how to produce the language files ? wl --- Professional hosting for everyone - http://www.host.ru ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] EasyHack: svtools/ RTL macro conversion
Hullo List, An easy hack for RTL conversion strings, against svtools/ . Cheers, Kevin 0001-EasyHack-RTL_CONST-macro-from-createFromAscii.patch.bz Description: application/bzip ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Easy hack: removed commented-out code
Hullo List, Another easy hack of cluttering comments removal. Kevin 0001-Remove-some-commented-out-code-we-have-Git.patch.xz Description: application/xz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] RTL easy hack, look over please
Hi List, Here's an RTL easy hack, that affects a macro. I believe it okay because it affects strings created like this: string = "prefix" "Something else"; but through a macro. Please look over. Cheers, Kevin 0001-EasyHack-RTL_CONST-macro-from-createFromAscii.patch.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] tools/ RTL easy hack
Hiya List, Here's an RTL easy hack for tools/ . Kevin 0001-Easy-Hack-RTL_CONST-macro-from-createFromAscii.patch.gz Description: GNU Zip compressed data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Fwd: Re: cppcheck : snprintf size is out of bounds
Le 17/11/2010 22:46, Julien Nabet a écrit : Le 17/11/2010 22:19, Caolán McNamara a écrit : On Wed, 2010-11-17 at 21:50 +0100, julien wrote: There's no more cppcheck errors if if i change the line : const sal_uInt32 nBezString = 1024; into this : sal_uInt32 nBezString = 1024; Before i create a tracker for cppcheck guy, i'd like to know what you think about it ? Yeah, that basically confirms it for me. C. I created the ticket 2210 for this bug. I noticed that sal_uInt32 is defined in sal/inc/sal/types.h and that it depended of preprocessor, perhaps it's the pb. I attached this remark in the tracker. Julien. The bug on cppcheck has been fixed : https://github.com/danmar/cppcheck/commit/66c2825b2309d21474b22eb4e73e75a4b4ee150f Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter RTL easy hack
On Thu, 2010-11-18 at 16:24 -0500, Kevin Hunter wrote: > (What're your rough-'n'ready measurements?) A 17 character string, iterating 5120 times on createFromAscii vs the other replacement just timed with gettimeofday. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] use dbglevel=1 for --enable-debug builds?
On Thu, 2010-11-18 at 13:01 +0100, David Tardon wrote: > Hi all, > > currently, configuring with --enable-debug means that dbglevel is set to > 2 > If we used dbglevel=1 as default, only assertions would be enabled and > the output would be much more manageable (practically nonexistent in > most cases, from my experience). My hope is that more devs would just be > configuring with --enable-debug and using/fixing assertions. Yeah, that sound reasonable to me. Having the default "debug" build tuned to level 1, and then we can treat any output as "a bug which should be fixed". C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter RTL easy hack
At 3:18pm -0500 Thu, 18 Nov 2010, Caolán Mcnamara wrote:
As an aside, for the empty OUString::createFromAscii("") case its
probably best just to swap with OUString(), so I did that for the
two cases.
Doh! Totally forgot about those. I even /searched/ for, and found 'em,
but got distracted at the wrong moment. *This* is why it's a group
effort, right? ;-) Thanks for catching those.
We'd probably get the biggest outcome from these efforts (approx
2-3% fast string construction time from my rough and ready
measurements) by converting the lower level most used stuff in e.g.
tools and svtools.
That's what I was figuring, and I realized that no one had yet tackled
binfilter. (What're your rough-'n'ready measurements?)
On this note, is there any plan of attack in terms of decoupling
components and thinking at a higher-level in terms algorithms and data
storage/manipulation?
Thanks,
Kevin
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Perl Installer: Remove commented out code.
On Wed, 2010-11-10 at 21:36 -0600, Jordan Ayers wrote: > Removing some of the commented out code from the installer's windows code. Looks ok to me, no functionality changes as far as I can see, so even though I'm not under windows I pushed this. Thanks for this. BTW, the installer is pig slow, if you're able to e.g. profile it to determine what's the slowest step and/or speed it up a little that'd be much appreciated I bet. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] binfilter RTL easy hack
On Thu, 2010-11-18 at 10:42 -0500, Kevin Hunter wrote:
> Hullo List,
>
> This rather large commit should take care of all non-commented versions
> of the RTL_CONST macro easy hack in binfilter/ .
Looks good, pushed. Thanks for this.
As an aside, for the empty OUString::createFromAscii("") case its
probably best just to swap with OUString(), so I did that for the two
cases.
We'd probably get the biggest outcome from these efforts (approx 2-3%
fast string construction time from my rough and ready measurements) by
converting the lower level most used stuff in e.g. tools and svtools.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] More clean code at writer [source/core/{docnode, draw, edit}]
Hello, sending this for review. I think that cleaniness is better than the previous. revol_ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] setting ulimit before running soffice
At 3:49am -0500 Thu, 18 Nov 2010, Sebastian Spaeth wrote: On Wed, 17 Nov 2010 14:01:18 -0500, Kevin Hunter wrote: I suppose it's an Ubuntu thing then. I've used ulimit files minimally in my career thus far. I suppose I'll get some practice this go round ... mmh, works fine in Ubuntu for me (as nonroot) Heh, alright. PEBCAK then. :-) Either way, I'll learn more about it! Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)
On Thu, 2010-11-18 at 09:30 +, Caolán McNamara wrote: > > See also scratch/writer/gdbinit-cbosdo in build.git. :) > > Without checking myself, are those pu macros horrifically slow or > speedy ? I vaguely recall trying something like that before, and got > whacked by astonishingly slow output. With the new python / gdb stuff it could be that we could add some hooks for printing our funky types that would actually execute quickly and be helpful :-) I'll add an 'easy' hack for this tomorrow :-) 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] libreoffice Uebersetzung
Hi guys, On Thu, 2010-11-18 at 00:28 -0300, wer...@guyane.yi.org wrote: > Hallo :-) It's great to see you getting helped out by our German speaking community. But in general it allows more people to benfit from the replies to your questions (and to help you out) if you use English (no matter how bad). Anyhow - great to have you involved ! :-) All the best, 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] STAR_RESOURCEPATH env variable
On Thu, 2010-11-18 at 15:32 +0100, Sebastian Spaeth wrote: > in /libs-gui/tools/source/rc/resmgr.cxx we load resource files either > from "$OOO_BASE_DIR/program/resource" or from the path specified in the > env variable STAR_RESOURCEPATH. Is it save to assume that this is a > historical leftover that I can delete? This is used by 'ooenv': export STAR_RESOURCEPATH=`pwd`/../basis-link/program/resource to locate resource files when all the relevant libraries are 'linkoo'd into various random places no-where near the rest of the tree. Of course, we could/should probably use a better environment variable name to point to the installation base path instead (that would be more generic than just for resources), but ... it is used. 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] libreoffice Install -- weitere Probleme
On Thu, Nov 18, 2010 at 03:37:25PM -0400, werner wrote: > *** ES MUSS MOEGLICH SEIN, ALLES IN EINEN ORDNER zBsp ./pkg zu > installieren, exakt so wie es spaeter auf dem Rechner des benutzers > von / aus gesehen sein soll (also inkl. prefix und inkl ooInBase) > *** Das ist möglich. Wird von allen möhglichen Distros gemacht. Und da ist dann auch das openclipart-Problem nonexistent. Sie wollen einfach nur trollen oder sind merkbefreit. *plonk* Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] libreoffice install Problem
Hi, On Thu, Nov 18, 2010 at 03:22:15PM -0400, werner wrote: > Bei der Installation besteht ferner noch folgendes Problem: > > 1) Bei bin/ooinstall X fehlt Hinzufuegung derooInBase = > /usr/lib/ooo-3.3 vor X !!! Falsch. Das geht über --with-oodirname, und das enthält die ganzen Verzeichnisse. Dann macht libreoffice-builds bin/ooinstall das richtige. > 2) Bei bin/ooinstall X fehlen die Programme in /usr/bin , zBsp > soffice3.3 , oowriter3.3 usw soffice3.3 macht auch keinen Sinn, und oowriter *wird* installiert wenn Sie libreoffice's bin/ooinstall benutzen. Wenn Sie ne 3.3 dahinter wollen benutzen Sie bitte die entsprechende option. (--with-binsuffix) > ./pkg/usr/bin/oowriter3.3 > ./pkg/usr/bin/soffice3.3 > ... > ./pkg/usr/lib/ooo-3.3/program/... > ./pkg/usr/lib/ooo-3.3/share/... > ./pkg/usr/lib/ooo-3.3/basis3.3/... > ./pkg/usr/lib/ooo-3.3/ure/... > ... > ./pkg/usr/share/applications/... > ./pkg/usr/share/mime/... > ... > > Das funktioniert alles ueberhaupt nicht. Falsch. Sie kriegen es nicht hin. > Normal ist fuer obiges: ./configure --prefix=/usr Korrekt, *das* tut nicht (--prefix wird komplett ignoriert). Hat aber auch keiner behauptet. > Wenn man nach dem compilen aufruft: bin/ooinstall /.../.pkg , > dann wird einfach alles in .pkg OHNE der ooInBase kopiert, also > findet man dann dort: > > ./pkg/program/... > ./pkg/share/... > ./pkg/basis3.3/... > > Das ist falsch, in ./pkg muss alles so sein wie spaeter im System, > also MIT ooInBase. Ausserdem fehlen die Dann schauen sie sich mal bitte an, wie man das richtig macht, danke. > Bitte reparieren ! Bitte konstruktiv sein und nicht trollen. Und evtl. einfach mal beitragen, umso schneller funktioniert es für Sie. > Ansonsten ist bin/ooinstall ganz nutzlos ! das solenv/bin/ooinstall ist IMHO momentan nutzlos, ja, man benutzt ja auch libreoffice-builds make install (was dessen bin/ooinstall aufruft). UND DAS TUT. Und nochmal: ENGLISCH. Und bitte keine CCs an mich, ich lese die Liste, danke. Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] libreoffice Install -- weitere Probleme
Weitere Probleme: / Die Installation von clipart erfolgt ins lfnd System. Das ist falsch. Sie muss auch nach prefix = DESTDIR (= /usr zBsp) innerhalb .pkg erfolgen , damit es mit gepackt wird. / In ...basis3.3/program sind alle links zu libs .so ZUM ABSOLUTEN PATHS DES (ZUFAELLIGEN) ORDNERS DES RECHNERS WO compiliert wurde, nicht zu ./pkg /usr /$ooInBase . Diese links sind dann auf jedem Rechner wo installiert wird, nutzlos. / In ... basis3.3/sdk/bin die Programme sind nicht executable (chmod +x wurde nicht gemacht) Das Install-Programm muss genau getestet werden ! *** ES MUSS MOEGLICH SEIN, ALLES IN EINEN ORDNER zBsp ./pkg zu installieren, exakt so wie es spaeter auf dem Rechner des benutzers von / aus gesehen sein soll (also inkl. prefix und inkl ooInBase) *** wl --- Professional hosting for everyone - http://www.host.ru ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] libreoffice install Problem
Bei der Installation besteht ferner noch folgendes Problem: 1) Bei bin/ooinstall X fehlt Hinzufuegung derooInBase = /usr/lib/ooo-3.3 vor X !!! 2) Bei bin/ooinstall X fehlen die Programme in /usr/bin , zBsp soffice3.3 , oowriter3.3 usw Bsp. : Um hinterher ein .tgz , .rpm , .deb Paket zu bilden, will man im Ordner ./pkg alles so haben, wie es im System sein soll, MIT ooInBase: ./pkg/usr/bin/oowriter3.3 ./pkg/usr/bin/soffice3.3 ... ./pkg/usr/lib/ooo-3.3/program/... ./pkg/usr/lib/ooo-3.3/share/... ./pkg/usr/lib/ooo-3.3/basis3.3/... ./pkg/usr/lib/ooo-3.3/ure/... ... ./pkg/usr/share/applications/... ./pkg/usr/share/mime/... ... Das funktioniert alles ueberhaupt nicht. Normal ist fuer obiges: ./configure --prefix=/usr Wenn man nach dem compilen aufruft: bin/ooinstall /.../.pkg , dann wird einfach alles in .pkg OHNE der ooInBase kopiert, also findet man dann dort: ./pkg/program/... ./pkg/share/... ./pkg/basis3.3/... Das ist falsch, in ./pkg muss alles so sein wie spaeter im System, also MIT ooInBase. Ausserdem fehlen die ./pkg/usr/bin/oowriter3.3 ./pkg/usr/bin/soffice3.3 und ./pkg/usr/share/applications/... ./pkg/usr/share/mime/... ganz. Bitte reparieren ! NACH DEM AUFRUF VON bin/ooinstall /.../.pkg MUSS ALLES SO SEIN WIE NACH DER INSTALLATION IN / , ALSO WIE BEI make DESTDIR=./pkg -i install, also muss in ./pkg der --prefix=/usr UND die ooInBase mit drin sein. Ansonsten ist bin/ooinstall ganz nutzlos ! Werner Landgraf Linux SYS --- Professional hosting for everyone - http://www.host.ru ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] libreoffice installieren, Problem
OK nach langem Rumprobieren hab ich jetzt rausgefunden, dass die Option --with-ct2n und nicht --with-numbertext dafuer abgeschaltet werden muss. Jetzt gibt es andere Probleme bei der Installierung. Bei mir ist inkscape nicht installiert, da stuerzt die Erstellung von clipart ab. Die Abhaengigkeit von inkscape sollte daher rausgenommen werden, inkscape ist sowieso total bescheuert. Ich will in eine Ordner ./pkg installieren. Das funktioniert ueberhaupt nicht !!! Normal geht das mit DESTDIR=pkg make -i install oder make DESTDIR=./pkg -i install . Ihr Installer macht dann ein Punkt dahinter also ...pkg/./... und bricht dann ab weil so base3.3.desktop nicht gefunden wird. Bitte korrigieren das Pfadname richtig gebildet wird. Aber auch mit dem absoluten Pfad angegeben, geht es mit bin/ooinstall -l ...pkg nicht. Es wird nun teilweise in irgendeinen Ordner ./pkg installiert, der aber am angegebenen Ort nichtist. Ein Teil, mindestens clipart, wird direkt ins lfnd. System installiert, also nach /usr/share/openclipart . Das ist alles Muell. Machen Sie das mal richtig. Ich packe viele Programme fuer die SYS Distro ftp://ftp5.gwdg.de/pub/linux/install/sys Es sollte unbedingt auch die Moeglichkeit bestehen, daß man das modular uebersetzt. Also von Haus aus sollte in den Modulen, in denen das Programm als .tar.gz kommt, individuelles configure und make-File sein, ggf durch den Installer anfangs upgedated, sodaß man sie einzeln uebersetzen kann. Werner Landgraf --- Professional hosting for everyone - http://www.host.ru ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] binfilter RTL easy hack
Hullo List, This rather large commit should take care of all non-commented versions of the RTL_CONST macro easy hack in binfilter/ . Cheers, Kevin 0001-EasyHack-RTL-macro-from-createFromAscii.patch.bz Description: application/bzip ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] use dbglevel=1 for --enable-debug builds?
On Thu, 2010-11-18 at 13:01 +0100, David Tardon wrote: > Opinions? I've trained myself to ignore all those messages coming from DBG_* OSL_* and almost always insert my own debug messages. So, to me less of those messages the better. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] More patches for Base
On Fri, 2010-11-12 at 20:03 +, Wols Lists wrote: > But anyways, here's the first two patches again - the new 1 is the old 6 > with "Dimensions" fixed, 5 is unchanged. Final results look good, tweaked "dimension parent window" to just "parent window dimension" which reads better and fits what the code is doing and pushed these. Thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about Timers
On Thu, 2010-11-18 at 13:54 +, Caolán McNamara wrote: > On Thu, 2010-11-18 at 08:05 -0500, Kohei Yoshida wrote: > > On Thu, 2010-11-18 at 09:14 +, Caolán McNamara wrote: > > > If you look at calc I think it has > > > a timer which is launched off when calc is first started, and then > > > that > > > timer never ends, even when calc is actually closed down :-) > > > > Hmm... Not Good. Which timer in calc is doing this? > > See sc/ui/app/scmod.cxx and aIdleTimer. IIRC aIdleTimer is started on > first load of a calc document and will never end. Might have to double > check that, been a while since I looked at them. Yup, it's still there, along with the spell check timer (aSpellTimer). They keep restarting themselves every time the timer hits. Hmm... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git server-side hooks
Hi Kohei, Miklos, On 2010-11-18 at 08:28 -0500, Kohei Yoshida wrote: > > > And continuously pulling from the master branch is very common when you > > > are in a long-term feature branch, and messing up the branch history is > > > the last thing you want to see happen while the branch is still being > > > worked on. > > > > That was added by me. I asked on this list and it was supposed to be a > > good idea: > > > > http://lists.freedesktop.org/archives/libreoffice/2010-October/000470.html > > > > It's commit 7f24ede9ec00fea0482abc74a131d41c5578a915 in build.git. If > > the consensus is that this is just annoying, I can revert it, sure. > > IMNSO this is not just annoying, but plain dangerous, because mis-use of > rebasing may end up removing your local changes (or remote changes). > Now that we promote the concept of feature branches, I hope we can > revert this. Sorry for that, I did not see all the consequences :-( It really sounds as reverting is the safer choice - Miklos, can you please do that? We do not have to be concerned about the merge commits that much any more, because we will always have those with the merges from OpenOffice.org [and have to get used to them ;-)], so few 'git pull's when 'git pull -r' might have been used will not be that much a problem. [For me, the best would be a 'read my mind' kind of pull - if you pull, and have just few commits up to 2-3 days old, and no merge commit among them, it would do 'pull -r', otherwise 'pull --no-rebase' :-) I'll try to improve the merge hook warning that way, so that it warns only in the cases where 'pull -r' is really the better choice; currently it shouts too often.] Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: RTL_CONST patch: binfilter
On Wed, 2010-11-17 at 16:57 -0500, Kevin Hunter wrote: > Hullo List, > > A quick two-line patch against binfilter. Yup, looks good, pushed. Thanks for this. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] minor fixes for Base
On Thu, 2010-11-18 at 13:19 +, Wols Lists wrote: > Cheers, > Wol Thanks for these, looks good, pushed now. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Clean code at writer (core/{access, attr, bastyp, crsr, doc})
Ok, thanks for your review, I'll remember them the next cleanup revol_ I pushed it with several changes: * reverted several comments that remain valid after the removals * reverted one removed vim modeline * removed issue numbers only related to the removed code. Nonexistent code doesn't need comments .-) * removed all refs to old bug tracker (Bug: -- I don't remember ever seeing this form before...) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] STAR_RESOURCEPATH env variable
On Thu, 2010-11-18 at 15:32 +0100, Sebastian Spaeth wrote: > in /libs-gui/tools/source/rc/resmgr.cxx we load resource files either > from "$OOO_BASE_DIR/program/resource" or from the path specified in the > env variable STAR_RESOURCEPATH. Is it save to assume that this is a > historical leftover that I can delete? I'd like to hold onto it, Its handy for unit tests where the configuration stuff isn't available and the .res files aren't in their final deployed dirs. If you're looking for stuff to delete I suggest having a look at callcatcher :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] STAR_RESOURCEPATH env variable
in /libs-gui/tools/source/rc/resmgr.cxx we load resource files either
from "$OOO_BASE_DIR/program/resource" or from the path specified in the
env variable STAR_RESOURCEPATH. Is it save to assume that this is a
historical leftover that I can delete?
Sebastian
209 RTL_CONSTASCII_USTRINGPARAM("$OOO_BASE_DIR/program/resource"));
210 rtl::Bootstrap::expandMacros(uri);
211 aDirs.push_back(uri);
212
213 // 2. in STAR_RESOURCEPATH
214 const sal_Char* pEnv = getenv( "STAR_RESOURCEPATH" );
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about Timers
On Thu, 2010-11-18 at 08:05 -0500, Kohei Yoshida wrote: > On Thu, 2010-11-18 at 09:14 +, Caolán McNamara wrote: > > If you look at calc I think it has > > a timer which is launched off when calc is first started, and then > > that > > timer never ends, even when calc is actually closed down :-) > > Hmm... Not Good. Which timer in calc is doing this? See sc/ui/app/scmod.cxx and aIdleTimer. IIRC aIdleTimer is started on first load of a calc document and will never end. Might have to double check that, been a while since I looked at them. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: [PATCH 02/12] RTL_CONSTASCII_USTRINGPARAM in components cui options
As I assume you're using a regex, you might consider catching this by
doing the search and replace in series. Here's an example:
1. Catch the 'OUString +?= ...createFromAscii...' case and replace with
'OUString var( RTL...)'
search: OUString\s*\w+\s*\+?=\s*\S*createFromAscii\(\s*"([^"]*)"\s*\)
replace: $1 $2( RTL_CONSTASCII_USTRINGPARAM( "$4" ))
2. Then go back for a second pass with something like this:
search: ::createFromAscii\(\s*"([^"]*)"\s*\)
replace: $1 $2( RTL_CONSTASCII_USTRINGPARAM( "$4" ))
The solution isn't perfect, as it still misses certain edge cases, but
should at least help a little bit.
Cheers,
Kevin
At 3:51pm -0500 Wed, 17 Nov 2010, Pierre-André Jacquod wrote:
Sharp eyes.. Just to keep you trainded..:-(
No really sorry, Despite reviewing diff, I did not catch this one.
Will take more care
On 11/17/2010 05:18 PM, Caolán McNamara wrote:
On Tue, 2010-11-16 at 22:39 +0100, Pierre-André Jacquod wrote:
On 11/16/2010 10:37 PM, Pierre-André Jacquod wrote:
Hello,
being off for some days, here the collection of patches I produced in
between.
Mostly good, but careful here, see...
-aAutoStr += ::rtl::OUString::createFromAscii( " (" );
+aAutoStr += ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("(") );
you changed the string by accident from a bracket with a preceding space
to one with no preceding space, clearly what's between "" has to remain
the same :-). Fixed that typo and the rest looks good, pushed.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git server-side hooks
On Thu, 2010-11-18 at 10:30 +0100, Miklos Vajna wrote: > On Wed, Nov 17, 2010 at 08:28:36PM -0500, Kohei Yoshida > wrote: > > 3) When creating a feature branch, by default, the autosetuprebase > > option is set to true, which forces rebase when pulling from the master > > branch even without the -r switch. You need to manually specify > > --no-rebase to disable rebase. > > > > I'm very concerned about this, because with this setting, pulling from > > the master into a feature branch, and push to the remote feature branch > > fails (because you rebased). Worse, when pushing to the remote fails, > > git tells you to pull from the remote feature branch, but when you do > > that, you lose the merging of the master you just did (bad). > > > > And continuously pulling from the master branch is very common when you > > are in a long-term feature branch, and messing up the branch history is > > the last thing you want to see happen while the branch is still being > > worked on. > > That was added by me. I asked on this list and it was supposed to be a > good idea: > > http://lists.freedesktop.org/archives/libreoffice/2010-October/000470.html > > It's commit 7f24ede9ec00fea0482abc74a131d41c5578a915 in build.git. If > the consensus is that this is just annoying, I can revert it, sure. IMNSO this is not just annoying, but plain dangerous, because mis-use of rebasing may end up removing your local changes (or remote changes). Now that we promote the concept of feature branches, I hope we can revert this. Also, I have no doubt that some of us will start using feature branches to share development with others, and if my understanding is correct (which it may not be) rebasing locally and pushing to the remote feature branch when it's not fastforward would screw up the other person's branch state... Or is my understanding not correct? > > The current workaround is to directly edit the .git/config file to > > manually remove autosetuprebase=true from every feature branch you have, > > but I wouldn't necessarily call it intuitive... > > Actually you need to remove autosetuprebase from every repo, and 'rebase > = true' from each feature branch. OK... Thanks for pointing this out. Either way, I hope someone who is a git expert can outline the correct way of merging from master into a feature branch. I still don't understand what exactly 'rebase' does (I do only know it vaguely) in the context of git (especially when pushing to remote), so I may end up rebasing again when I shouldn't be. Thanks, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] minor fixes for Base
Cheers,
Wol
>From 63291f58afa08fadd35f736b6ade308b9d85d66e Mon Sep 17 00:00:00 2001
From: Wol
Date: Thu, 18 Nov 2010 13:17:46 +
Subject: [PATCH] Comment fixes - dead code and spelling mistakes
---
dbaccess/source/ui/control/ColumnControlWindow.cxx |2 --
dbaccess/source/ui/control/FieldDescControl.cxx|8 +++-
dbaccess/source/ui/control/dbtreelistbox.cxx |6 +++---
dbaccess/source/ui/control/marktree.cxx|8
dbaccess/source/ui/control/tabletree.cxx |4 ++--
5 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/dbaccess/source/ui/control/ColumnControlWindow.cxx
b/dbaccess/source/ui/control/ColumnControlWindow.cxx
index 8dc0b41..5786aa2 100644
--- a/dbaccess/source/ui/control/ColumnControlWindow.cxx
+++ b/dbaccess/source/ui/control/ColumnControlWindow.cxx
@@ -73,7 +73,6 @@ void OColumnControlWindow::ActivateAggregate( EControlType
eType )
{
case tpFormat:
case tpDefault:
-// case tpAutoIncrement:
case tpColumnName:
break;
default:
@@ -87,7 +86,6 @@ void OColumnControlWindow::DeactivateAggregate( EControlType
eType )
{
case tpFormat:
case tpDefault:
-// case tpAutoIncrement:
case tpColumnName:
break;
default:
diff --git a/dbaccess/source/ui/control/FieldDescControl.cxx
b/dbaccess/source/ui/control/FieldDescControl.cxx
index a7fa752..f85af16 100644
--- a/dbaccess/source/ui/control/FieldDescControl.cxx
+++ b/dbaccess/source/ui/control/FieldDescControl.cxx
@@ -410,7 +410,6 @@ void OFieldDescControl::CheckScrollBars()
{
m_pVertScroll->Show();
m_pVertScroll->SetRangeMax(nActive - nLastVisible);
-// m_pVertScroll->SetThumbPos(0);
m_pVertScroll->SetPosSizePixel( Point(nNewHWidth, 0),
Size(nVScrollWidth, szOverallSize.Height()) );
}
@@ -425,7 +424,6 @@ void OFieldDescControl::CheckScrollBars()
{
m_pHorzScroll->Show();
m_pHorzScroll->SetRangeMax((lMaxXPosition - lMaxXAvailable +
HSCROLL_STEP - 1 )/HSCROLL_STEP);
-// m_pHorzScroll->SetThumbPos(0);
m_pHorzScroll->SetPosSizePixel( Point(0, nNewVHeight),
Size(bNeedVScrollBar ? nNewHWidth : szOverallSize.Width(), nHScrollHeight) );
}
@@ -516,7 +514,7 @@ sal_Int32 OFieldDescControl::GetMaxControlHeight() const
const Size aTemp(
ppAggregates[i]->GetOptimalSize(WINDOWSIZE_PREFERRED) );
if ( aTemp.Height() > aHeight.Height() )
aHeight.Height() = aTemp.Height();
-} // if ( ppAggregates[i] )
+}
}
return aHeight.Height();
@@ -1194,7 +1192,7 @@ void OFieldDescControl::SetPosSize( Control** ppControl,
long nRow, sal_uInt16 n
case 4:
aSize.Width() = CONTROL_WIDTH_4;
break;
-} // switch( nCol )
+}
}
@@ -1710,7 +1708,7 @@ void OFieldDescControl::SaveData( OFieldDescription*
pFieldDescr )
catch(const Exception&)
{
}
-} // if ( sDefault.getLength() )
+}
else
pFieldDescr->SetControlDefault(Any());
diff --git a/dbaccess/source/ui/control/dbtreelistbox.cxx
b/dbaccess/source/ui/control/dbtreelistbox.cxx
index 1ddba15..8251442 100644
--- a/dbaccess/source/ui/control/dbtreelistbox.cxx
+++ b/dbaccess/source/ui/control/dbtreelistbox.cxx
@@ -515,7 +515,7 @@ namespace
{
lcl_adjustMenuItemIDs( *pPopup, _rCommandController );
continue;
-} // if ( pPopup )
+}
const USHORT nCommandId = _rCommandController.registerCommandURL(
aCommand );
_rMenu.InsertItem( nCommandId, _rMenu.GetItemText( nId ),
_rMenu.GetItemImage( nId ),
@@ -551,7 +551,7 @@ namespace
{
lcl_insertMenuItemImages( *pPopup, _rCommandController );
continue;
-} // if ( pPopup )
+}
if ( xFrame.is() )
_rMenu.SetItemImage(nId,framework::GetImageFromURL(xFrame,aCommand,FALSE));
@@ -692,7 +692,7 @@ PopupMenu* DBTreeListBox::CreateContextMenu( void )
// the interceptors only know command URLs, but our menus primarily
work
// with IDs -> we need to translate the commands to IDs
lcl_adjustMenuItemIDs( *pModifiedMenu,
m_pContextMenuProvider->getCommandController() );
-} // if ( bModifiedMenu )
+}
return pContextMenu.release();
}
diff --git a/dbaccess/source/ui/control/marktree.cxx
b/dbaccess/source/ui/control/marktree.cxx
index bca4ebe..e001a60 100644
--- a/dbaccess/source/ui/control/marktree.cxx
+++ b/dbaccess/source/ui/control/marktree.cxx
@@ -152,8 +152,8 @@ SvButtonState
OMarkableTreeListBox::implDetermineState(SvLBoxEntry* _pEntry)
// we did not finish the loop because at least one of the children is
in tristate
eState = SV_BUTTON_TRISTATE;
-// but this means that we d
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
Hi *, On Thu, Nov 18, 2010 at 12:50 PM, Caolán McNamara wrote: > > I agree with Dave really. I get confused about them, I don't think > people are using --enable-dbgutil anyway, and I always perceive it as > some infrastructure handy under windows to get a console that > warnings/asserts can get logged to. FYI: http://wiki.services.openoffice.org/wiki/Non_Product_Build http://wiki.services.openoffice.org/wiki/Build_Environment_Effort/DBGUTIL and this mini-table: http://wiki.services.openoffice.org/wiki/Debug_Levels ciao Christian ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about Timers
On Thu, 2010-11-18 at 09:14 +, Caolán McNamara wrote: > If you look at calc I think it has > a timer which is launched off when calc is first started, and then > that > timer never ends, even when calc is actually closed down :-) Hmm... Not Good. Which timer in calc is doing this? -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] use dbglevel=1 for --enable-debug builds?
On Thu, 18 Nov 2010 13:01:42 +0100, David Tardon wrote: 1) > one would just run build -- dbglevel=2 in the desired module similarly > as one runs build -- debug=true today. 2) > As an alternative, we could add optional level argument to > --enable-debug or add another option, say, --enable-assertions, that > would do the same thing as --enable-debug and export dbglevel=1 in > addition. 2) is more complicated, but also more discoverable and explicitely documented. I dislike secret ENVVARIABLE incarnations that enable things and not easily discoverable without trawling through READMEs. So: --enable-debug=2 (with 1 being the default) or --enable-assertions (==--enable-debug=1) would be my preferred choice. Sebastian pgpPBkfWTofTh.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] use dbglevel=1 for --enable-debug builds?
Hi all, currently, configuring with --enable-debug means that dbglevel is set to 2, which in turns means that OSL_DEBUG_LEVEL is set to 2. This enables all the OSL_ debugging stuff there is (well, maybe there is some really rare stuff that is only enabled for OSL_DEBUG_LEVEL > 2, but I don't know about any), which spews unbelievable amount of stuff on stdout. If we used dbglevel=1 as default, only assertions would be enabled and the output would be much more manageable (practically nonexistent in most cases, from my experience). My hope is that more devs would just be configuring with --enable-debug and using/fixing assertions. The full debug build would still be easily available: one would just run build -- dbglevel=2 in the desired module similarly as one runs build -- debug=true today. >From impl. standpoint: AFAIK this would require one-line change in solenv/inc/settins.mk . As an alternative, we could add optional level argument to --enable-debug or add another option, say, --enable-assertions, that would do the same thing as --enable-debug and export dbglevel=1 in addition. Both would require change to configure.in and set_soenv.in (to export proper dbglevel). I would accept either of these two, but IMHO it is complicating things too much. Opinions? D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Contributing test cases
On Thu, 2010-11-18 at 12:16 +0100, Gioele Barabucci wrote: > Hello, > > in order to report a subtle bug [1], I had to create a minimal failing > test case document. > > Is there a way to contribute this kind of testcases, and assertions on > which results one should expect, to a testsuite so that future changes > to the LibreOffice code can be tested against these well-known bugs? We really should try and organize this alright. I know there are some adhoc collections of documents here and there, e.g.scratch/sc-vba, but we need to get something organized and better automated IMO. What I'd like to see, and I'm still working on a few pieces, is to get basic cppunit build-time tests for the major apps together, e.g. a basic calc one is working under Linux and I've added another super-basic one I haven't enabled yet for starmath. As part of those tests I think I'd like to have a least one load/save for each file format, maybe, depends on the practicability of that. First though I need to get the smoketest reliable on windows at least. > In my case I'd need to describe something like «type this, type that, > apply this style; save; in the resulting XML file there should not be a > space between this element and this other element». Something like that might be suitable for a build-time cppunit test. But either way we definitely should have slower automated tests that run separately. I feel the "testtool" thing is a bit of a disaster really, needs too much continual poking and adding timeouts etc to keep it going. There other random grabbags of stuff in qadevOOO, then there's the subsequent tests etc. What I think I'd like to see is 1) basic cppunit tests take place during the build, keep us honest and basic functionality working at all times. Have a few of these at the moment. 2) smoketest run at the end of the build, at least by the buildbots to make sure that works. This needs a little bit more love, at the moment I've some enthusiasm that I may have found some of problems that makes it die horribly at exit time for some people. 3) a bit optional module/repo filled with masses of test cases with a simple "make" target that gets run at release time and/or whenever qa folk want to test the build. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On Thu, 2010-11-18 at 03:19 -0700, Tor Lillqvist wrote: > On a related note, what is your take on --enable-dbgutil vs. > --enable-debug? Are they designed to do clearly separate things? Do > people in general understand the difference? If either answer is no, > should these two concepts be merged? I agree with Dave really. I get confused about them, I don't think people are using --enable-dbgutil anyway, and I always perceive it as some infrastructure handy under windows to get a console that warnings/asserts can get logged to. I don't think I've ever done an enable-dbgutil build. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
> * insert arbitrary debugging code that is only present in 'special' > builds: #ifdef DBG_UTIL and #if OSL_DEBUG_LEVEL > n Unfortunately, I think those have been mixed up in the past occasionally. When I recently tried a build with --enable-dbgutil but not --enable-debug, I came across a handful of places where some variables or class member was defined inside #if OSL_DEBUG_LEVEL > n but then those variables or class members were used inside #ifdef DBG_UTIL code, or in some DBG_whatever macro which amounts to the same. > I'm fully for discarding the old DBG_* tools entirely. I probably agree. The reason why I wanted to build with --enable-dbgutil was that I was trying to track down what I suspected was heap corruption, on Windows, and using --enable-dbgutil makes the built binaries use the so-called debugging runtime that does (as far as I know) more heap correctness checking. But unfortunately that build didn't turn out usable anyway, it crashed on startup, and I didn't have time to dig into it more. But anyway, I wonder, if we drop --enable-dbgutil, should then --enable-debug (or building individual modules with debug=true) cause the debugging runtime to be used? Will it cause horrible crashes if some DLLs use the debugging runtime and some not? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On 17/11/10 18:50, Santiago Bosio wrote: > Hi! > > When LibO is built using --enable-symbols, it still uses -O2 > optimizations, making hard to debug execution with GDB. > > So, I think that it should default to -O2 on a normal build, and to > -O0 when using --enable-symbols. Don't see the point of using > optimizations when building a version for debugging purposes. What if it's the optimisation that introduces the bug? Completely different product (MS VB :-) but I know of a very nasty bug that only crops up in compiled mode - you prove the code is correct in interpreted mode, compile it, and the executable fails ... Cheers, Wol ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On Thu, Nov 18, 2010 at 12:13:36PM +0100, David Tardon wrote: > On Thu, Nov 18, 2010 at 03:19:39AM -0700, Tor Lillqvist wrote: > > On a related note, what is your take on --enable-dbgutil vs. > > --enable-debug? Are they designed to do clearly separate things? > > IMHO no. Both allow to: > * use assertions > * insert arbitrary debugging code that is only present in 'special' > builds: #ifdef DBG_UTIL and #if OSL_DEBUG_LEVEL > n > * track object lifetime: that's what all these DBG_CHKTHIS, DBG_CHKOBJ, > DBG_NAME etc. in vcl, sfx2, svtools and maybe in a few other places > are for. OSL's counterpart is osl::DebugBase, that is AFAIK only used > at a few places in sd. I should add that osl::DebugBase's impl. was broken for at least a year and noone noticed .-) D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On Wed, Nov 17, 2010 at 03:50:33PM -0300, Santiago Bosio wrote: > Hi! > > When LibO is built using --enable-symbols, it still uses -O2 > optimizations, making hard to debug execution with GDB. > You can export nopt=true before building to turn optimizations off. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Contributing test cases
Hello, in order to report a subtle bug [1], I had to create a minimal failing test case document. Is there a way to contribute this kind of testcases, and assertions on which results one should expect, to a testsuite so that future changes to the LibreOffice code can be tested against these well-known bugs? In my case I'd need to describe something like «type this, type that, apply this style; save; in the resulting XML file there should not be a space between this element and this other element». Regards, [1] https://bugs.freedesktop.org/show_bug.cgi?id=31707 -- Gioele Barabucci ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On Thu, Nov 18, 2010 at 03:19:39AM -0700, Tor Lillqvist wrote: > On a related note, what is your take on --enable-dbgutil vs. --enable-debug? > Are they designed to do clearly separate things? IMHO no. Both allow to: * use assertions * insert arbitrary debugging code that is only present in 'special' builds: #ifdef DBG_UTIL and #if OSL_DEBUG_LEVEL > n * track object lifetime: that's what all these DBG_CHKTHIS, DBG_CHKOBJ, DBG_NAME etc. in vcl, sfx2, svtools and maybe in a few other places are for. OSL's counterpart is osl::DebugBase, that is AFAIK only used at a few places in sd. (And we have valgrind for that anyway, don't we?) * profile code (isn't there enough profilers available?) > Do people in general understand the difference? IMHO the main difference is that DBG_ family is older and bound to VCL (it has that configuration dialog that can be started by Ctrl+Shift+Alt+D in non-pro build ... but hardly anyone would know what to do with it anyway .-) > If either answer is no, should these two concepts be merged? I'm fully for discarding the old DBG_* tools entirely. D. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] libreoffice Uebersetzung
Hello, On Thu, 2010-11-18 at 07:29 -0300, wer...@guyane.yi.org wrote: > Das ist alles Muell. Machen Sie das mal richtig. As I love to be (certain) user-friendly, the obvious answer here is: "patches welcome" or in de-DE "mitmachen oder Klappe halten". Alles Gute F. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] libreoffice Uebersetzung
On Thu, Nov 18, 2010 at 07:29:20AM -0300, wer...@guyane.yi.org wrote: > Bei mir ist inkscape nicht installiert, da stuerzt die Erstellung > von clipart ab. Die Abhaengigkeit von inkscape sollte daher > rausgenommen werden, inkscape ist sowieso total bescheuert. Ahja. (Im übrigen kann man die Funktion nicht aufrufen, wie das auch viele tun). > oder make DESTDIR=./pkg -i install . Ihr Installer macht dann ein > Punkt dahinter also ...pkg/./... und bricht dann ab weil so base3.3.desktop > nicht gefunden wird. Bitte korrigieren das Pfadname richtig gebildet wird. Nein, Benutzen Sie nen absoluten Pfad. > angegebenen Ort nichtist. Ein Teil, mindestens clipart, wird direkt ins lfnd. > System installiert, also nach /usr/share/openclipart . .. Wenn man das einschaltet.. Tue ich z.B. nicht und mache das selbst. > Das ist alles Muell. Machen Sie das mal richtig. Ah. Trolling. Hätte ich mir doch direkt denken können. > Ich packe viele Programme fuer die SYS Distro > > ftp://ftp5.gwdg.de/pub/linux/install/sys *gähn*. Und ich für Debian. So what? Manchmal braucht man patches. Und es wäre sicherlich hilfreich wenn Sie miithelfen würden. Offensichtlichwerweise tut make install für uns alle. > Es sollte unbedingt auch die Moeglichkeit bestehen, daß man das modular > uebersetzt. > Also von Haus aus sollte in den Modulen, in denen das Programm als .tar.gz > kommt, > individuelles configure und make-File sein, ggf durch den Installer anfangs > upgedated, > sodaß man sie einzeln uebersetzen kann. Das ist Ziel irgendwann, ja. Momentan gibts leider noch Altlasten aus OOo-Zeit. Und Sie schreiben weiterthin in der falschen Sprache... (Und zu förmlich, das hier ist OSS, also eigentlich "Du"). Grüße/Regards, René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] libreoffice Uebersetzung
OK nach langem Rumprobieren hab ich jetzt rausgefunden, dass die Option --with-ct2n und nicht --with-numbertext dafuer abgeschaltet werden muss. Jetzt gibt es andere Probleme bei der Installierung. Bei mir ist inkscape nicht installiert, da stuerzt die Erstellung von clipart ab. Die Abhaengigkeit von inkscape sollte daher rausgenommen werden, inkscape ist sowieso total bescheuert. Ich will in eine Ordner ./pkg installieren. Das funktioniert ueberhaupt nicht !!! Normal geht das mit DESTDIR=pkg make -i install oder make DESTDIR=./pkg -i install . Ihr Installer macht dann ein Punkt dahinter also ...pkg/./... und bricht dann ab weil so base3.3.desktop nicht gefunden wird. Bitte korrigieren das Pfadname richtig gebildet wird. Aber auch mit dem absoluten Pfad angegeben, geht es mit bin/ooinstall -l ...pkg nicht. Es wird nun teilweise in irgendeinen Ordner ./pkg installiert, der aber am angegebenen Ort nichtist. Ein Teil, mindestens clipart, wird direkt ins lfnd. System installiert, also nach /usr/share/openclipart . Das ist alles Muell. Machen Sie das mal richtig. Ich packe viele Programme fuer die SYS Distro ftp://ftp5.gwdg.de/pub/linux/install/sys Es sollte unbedingt auch die Moeglichkeit bestehen, daß man das modular uebersetzt. Also von Haus aus sollte in den Modulen, in denen das Programm als .tar.gz kommt, individuelles configure und make-File sein, ggf durch den Installer anfangs upgedated, sodaß man sie einzeln uebersetzen kann. Werner Landgraf On 18/Nov/2010 04:44 Rene Engelhard wrote .. > Hallo, > > On Thu, Nov 18, 2010 at 12:28:27AM -0300, wer...@guyane.yi.org wrote: > > Das Installieren geht ueberhaupt nicht > > > > Ich habe das im Oo support Forum gepostet, aber es kam keine brauchbare > > Antwort. > > > > http://user.services.openoffice.org/en/forum/viewtopic.php?f=16&t=35931 > > > > Bitte um Ueberpruefung/ Dasmake Skript funktioniert halt nicht richtig. > > Doch, tut. Nur haben Sue die extensions, die da erwartet wirst nicht gebaut. > Wenn > man solche supertollen > extra features enabled.. Ich würde die Option einfach abschalten. > > > / Aber auch das globale Programm sollte, statt/ausser mit bin/ooinstaller , > > auch > mit make destdir=X install installierbar sein. Dabei ist die Option > destdir=... > besonders wichtig. So dass man das Ganze in einen Ordner installieren kann. > Naemlich > man will sich dann selbst Verschiedenes in einzelne Pakete unterteilen (zBsp > jede > Sprache als einzelnes Paket) > > Tut. Und genauso wird es auch von den distros gemacht (auch mit der > Unterteilung) > > > > > / Normalerweise laden die Packer zu uebersetzende Programme .tar.bz2 selbst > > down, > ebenso ggf. zusaetzliche Programme. Es gibt zwar eine Option in configure fuer > den ordner wo die source-Programme sind ... die funktioniert jedoch nicht. Und > bei jeder (nach Fehler) wiederholten Uebersetzung, wird alles nochmal neu > downgeladen > ... > > Falsch. Wenn Du den ./download-Schritt meinst > > > Das sollte unbedingt funktionierend gemacht werden. Dabei sollten auch die > > Source-Programme > im Original bleiben -- nicht mit langen Nummern versehen werden.BITTE > ALLES > UNNUETZ KOMPLIZIERTE VERMEIDEN. Die Packer uebersetzen / packen sehr viele > Programme, > wen da jedes Extrawuerste oder individuelle Prozedur zum Uebersetzen / linken > hat, > wird man wahnsinnig. dasSchema configure - make - make destdir=PKGDIR install > sollte immer moeglich sein. > > Und geht auch. Und Sie machen es sich selbsr kompliziert(er). > > Und vielleicht sollten sie auf einer internationalen Liste auch nicht auf > Deutsch > schreiben sondern auf Englisch. Und sinnvoll Ihre Zeilen umbrechen. > > Grüße/Regards, > > René ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Disable GCC optimizations when building with --enable-symbols
On a related note, what is your take on --enable-dbgutil vs. --enable-debug? Are they designed to do clearly separate things? Do people in general understand the difference? If either answer is no, should these two concepts be merged? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)
On Thu, 2010-11-18 at 09:30 +, Caolán McNamara wrote: > On Thu, 2010-11-18 at 00:17 +0100, Miklos Vajna wrote: > > On Wed, Nov 17, 2010 at 04:44:19PM +, Caolán McNamara > > wrote: > > > print dbg_dump(string) [...] > Without checking myself, are those pu macros horrifically slow or > speedy ? horrifically slow ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)
On Thu, Nov 18, 2010 at 09:30:54AM +, Caolán McNamara wrote: > Without checking myself, are those pu macros horrifically slow or > speedy ? I vaguely recall trying something like that before, and got > whacked by astonishingly slow output. They are quiet slow for me, so I just use OSL_TRACE() most of the time. I never checked if it's only me, though. pgpnyPdAwJhne.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Re: [PATCH 11/12] RTL_CONSTASCII_USTRINGPARAM components - zipapi
On Wed, 2010-11-17 at 21:58 +0100, Pierre-André Jacquod wrote: > Hello, > I saw it too, this allow me to rize a question. My firt though was to > remove this one - since commentted out - but I left it there not knowing > if this was a way to handle this here.? > > For my taste, I would have remove it. -> Debug it at home, not on public > branch... Your input? Yeah. Though for perfection I'd like to see a cppunit test that gets build and executed at runtime to always test whatever that wants to test. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Examing unicode strings in gdb (while debugging LibO)
On Thu, 2010-11-18 at 00:17 +0100, Miklos Vajna wrote: > On Wed, Nov 17, 2010 at 04:44:19PM +, Caolán McNamara > wrote: > > print dbg_dump(string) > > > > should (in theory) generally work with rtl::OUString,rtl::OString,String > > and ByteString, etc. > > See also scratch/writer/gdbinit-cbosdo in build.git. :) Without checking myself, are those pu macros horrifically slow or speedy ? I vaguely recall trying something like that before, and got whacked by astonishingly slow output. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Git server-side hooks
On Wed, Nov 17, 2010 at 08:28:36PM -0500, Kohei Yoshida wrote: > 3) When creating a feature branch, by default, the autosetuprebase > option is set to true, which forces rebase when pulling from the master > branch even without the -r switch. You need to manually specify > --no-rebase to disable rebase. > > I'm very concerned about this, because with this setting, pulling from > the master into a feature branch, and push to the remote feature branch > fails (because you rebased). Worse, when pushing to the remote fails, > git tells you to pull from the remote feature branch, but when you do > that, you lose the merging of the master you just did (bad). > > And continuously pulling from the master branch is very common when you > are in a long-term feature branch, and messing up the branch history is > the last thing you want to see happen while the branch is still being > worked on. That was added by me. I asked on this list and it was supposed to be a good idea: http://lists.freedesktop.org/archives/libreoffice/2010-October/000470.html It's commit 7f24ede9ec00fea0482abc74a131d41c5578a915 in build.git. If the consensus is that this is just annoying, I can revert it, sure. > The current workaround is to directly edit the .git/config file to > manually remove autosetuprebase=true from every feature branch you have, > but I wouldn't necessarily call it intuitive... Actually you need to remove autosetuprebase from every repo, and 'rebase = true' from each feature branch. pgp84zXlDrwvW.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Tango icon theme leftovers
Hi all, this is a list of 412 icons that are in the tango theme, but not in the default_images theme. Some of the are obvious High contrast icons that can be killed. But what about others? Should I delete those? (I kept the .xcb.bz2 and .svg as source files in the tango theme). See the full list of files below. Permission to kill, or should they be examined in more detail first? (On the other hand we have 3766 files more in default_images than we have in the tango theme.) ./dbaccess/res/bookmarkcontainer_sx.png ./dbaccess/res/bookmark_sx.png ./dbaccess/res/db_deleted.png ./dbaccess/res/db_modified.png ./dbaccess/res/db_new.png ./dbaccess/res/docedit_sc.png ./dbaccess/res/docopen_sc.png ./dbaccess/res/formnew_sc.png ./dbaccess/res/lc010.png ./dbaccess/res/lc011.png ./dbaccess/res/lc012.png ./dbaccess/res/lc013.png ./dbaccess/res/lc014.png ./dbaccess/res/lc021.png ./dbaccess/res/lc023.png ./dbaccess/res/lc05621.png ./dbaccess/res/lc09.png ./dbaccess/res/lc12252.png ./dbaccess/res/linkdrop_sc.png ./dbaccess/res/linkedit_sc.png ./dbaccess/res/linknew_sc.png ./dbaccess/res/querydrop_sc.png ./dbaccess/res/queryeditdesign_sc.png ./dbaccess/res/queryeditsql_sc.png ./dbaccess/res/querynewdesign_sc.png ./dbaccess/res/querynewsql_sc.png ./dbaccess/res/rename_sc.png ./dbaccess/res/sc010.png ./dbaccess/res/sc011.png ./dbaccess/res/sc012.png ./dbaccess/res/sc013.png ./dbaccess/res/sc014.png ./dbaccess/res/sc021.png ./dbaccess/res/sc023.png ./dbaccess/res/sc05621.png ./dbaccess/res/sc09.png ./dbaccess/res/sc12252.png ./dbaccess/res/tabledrop_sc.png ./dbaccess/res/tableedit_sc.png ./dbaccess/res/tablenew_sc.png ./lc10713.png ./res/commandimagelist/ar/lc_underlinedouble.png ./res/commandimagelist/ar/sc_underlinedouble.png ./res/commandimagelist/lc_adddirect32.png ./res/commandimagelist/lc_fontcolor-alt.png ./res/commandimagelist/lc_graphicdraft.png ./res/commandimagelist/lc_insertapplet.png ./res/commandimagelist/sc_graphicdraft.png ./res/commandimagelist/sc_insertapplet.png ./res/hldocntp.xcf ./res/hldoctp.xcf ./res/im30819.png ./res/lc05303.png ./res/lc05501.png ./res/lc05502.png ./res/lc0.png ./res/lc05556.png ./res/lc10107.png ./res/lc10113.png ./res/lc10243.png ./res/lc10375.png ./res/lc10376.png ./res/lc10863.png ./res/lc10864.png ./res/lc10865.png ./res/lc10866.png ./res/lc10867.png ./res/lc10868.png ./res/lc10869.png ./res/lc10907.png ./res/lc10908.png ./res/lc10937.png ./res/lc12201.png ./res/lc12203.png ./res/lc12231.png ./res/lc12235.png ./res/lc12236.png ./res/lc12237.png ./res/lc12238.png ./res/lo03123.png ./res/lo03126.png ./res/lo03127.png ./res/lo03129.png ./res/lo03130.png ./res/lo03139.png ./res/lo03144.png ./res/lo03162.png ./res/lo03163.png ./res/lo03216.png ./res/lo03226.png ./res/lo03227.png ./res/lo03228.png ./res/lo03242.png ./res/sc05303.png ./res/sc06694.png ./res/sc10108.png ./res/sc10113.png ./res/sc10116.png ./res/sc10375.png ./res/sc10376.png ./res/sc10907.png ./res/sc10908.png ./res/sc10937.png ./res/sc12201.png ./res/sc12203.png ./res/sc12231.png ./res/sc12235.png ./res/sc12236.png ./res/sc12237.png ./res/sc12238.png ./res/sch06694.png ./res/sco206.png ./res/so03123.png ./res/so03126.png ./res/so03127.png ./res/so03129.png ./res/so03130.png ./res/so03139.png ./res/so03144.png ./res/so03162.png ./res/so03163.png ./res/so03216.png ./res/so03226.png ./res/so03227.png ./res/so03228.png ./res/so03242.png ./sc10713.png ./sch ./sch/res ./sch/res/lc10242.png ./sch/res/lc30514.png ./sch/res/lc30528.png ./sch/res/lc30529.png ./sch/res/lc30530.png ./sch/res/lc30531.png ./sch/res/lc30532.png ./sch/res/lc30533.png ./sch/res/lc30534.png ./sch/res/lc30535.png ./sch/res/lc30536.png ./sch/res/lc30539.png ./sch/res/lc30586.png ./sch/res/sc10242.png ./sch/res/sc30514.png ./sch/res/sc30528.png ./sch/res/sc30529.png ./sch/res/sc30530.png ./sch/res/sc30531.png ./sch/res/sc30532.png ./sch/res/sc30533.png ./sch/res/sc30534.png ./sch/res/sc30535.png ./sch/res/sc30536.png ./sch/res/sc30539.png ./sch/res/sc30586.png ./sd/res/apply.png ./sd/res/extras.png ./sd/res/fadeout.png ./sd/res/imagelst/lc05928.png ./sd/res/imagelst/lc10245.png ./sd/res/imagelst/lc10299.png ./sd/res/imagelst/lc27008.png ./sd/res/imagelst/lc27014.png ./sd/res/imagelst/lc27015.png ./sd/res/imagelst/lc27017.png ./sd/res/imagelst/lc27019.png ./sd/res/imagelst/lc27022.png ./sd/res/imagelst/lc27028.png ./sd/res/imagelst/lc27031.png ./sd/res/imagelst/lc27032.png ./sd/res/imagelst/lc27036.png ./sd/res/imagelst/lc27037.png ./sd/res/imagelst/lc27046.png ./sd/res/imagelst/lc27051.png ./sd/res/imagelst/lc27054.png ./sd/res/imagelst/lc27055.png ./sd/res/imagelst/lc27056.png ./sd/res/imagelst/lc27057.png ./sd/res/imagelst/lc27058.png ./sd/res/imagelst/lc27059.png ./sd/res/imagelst/lc27060.png ./sd/res/imagelst/lc27062.png ./sd/res/imagelst/lc27063.png ./sd/res/imagelst/lc27064.png ./sd/res/imagelst/lc27085.png ./sd/res/imagelst/lc27090.png ./sd/res/imagelst/lc27091.png ./sd/res/imagelst/lc27095.png ./sd/res/imagelst/lc27098.png ./sd/res/imagelst/lc2709
Re: [Libreoffice] Questions about Timers
On Wed, 2010-11-17 at 23:13 +0100, Julien Nabet wrote: > Hello, > > In the easy hacks, could it be possible to have more information on what > to do with timers ? > For example : > - what's a "leaked timer", is it the same as "permanent timer" that i > read on this http://qa.openoffice.org/issues/show_bug.cgi?id=106485 ? > - how to find a leaked timer ? In vcl/source/app/timer.cxx stick a printf and gdb breakpoint at Timer::Timeout. Run the app, e.g. starmath, draw, impress, etc. Now, there's absolutely nothing wrong with timeouts. What's wrong is a timeout that gets triggered for some condition and then never ends, doing nothing at each timeout. > - how to correct them ? (must we delete them or change them ?) Generally change them to come to a halt when whatever they want to do is complete, and restart them if that condition arises again. > For example, the timer mpOnlineSpellingTimer that we can find in these > files : > impress/sd/inc/drawdoc.hxx > impress/sd/source/core/drawdoc4.cxx > impress/sd/source/core/drawdoc.cxx > > Is this timer ok ? Is there something we can improve/optimize in it ? This depends, and I think I made some modifications to that specific one to fix it. What would happen is that changing/adding text would trigger the spell checking time out, which was good, but when the spellcheck was complete the timer would continue to timeout, wake up the processor, find out that nothing new had been changed to spellcheck, go back and snooze for a while, wake up, etc. So right fix was to end the timer when the spellcheck was complete and launch a new one when text was modified again. Draw/Impress has a timer which unloads some resources after some time, that's ok, it gets fired one and then goes away. I think the spellchecking timers in sd and impress are good and eventually stop when they're finished. calc and writer on the other hand are still problematic, maybe quite hard to fix. If you look at calc I think it has a timer which is launched off when calc is first started, and then that timer never ends, even when calc is actually closed down :-) C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] What are these /*N*/ comments?
On Wed, 2010-11-17 at 18:12 -0500, Kevin Hunter wrote:
> Hullo List,
>
> Is there a reason for lines that look like this?
>
> [...]
> /*N*/ String aGraphicId( rGraphicId );
> /*N*/ BfGraphicObject aGrfObject( ByteString( aGraphicId,
> RTL_TEXTENCODING_ASCII_US ) );
> /*N*/
> /*N*/ maTmp.EnableKillingFile();
> /*N*/
> /*N*/ if( aGrfObject.GetType() != GRAPHIC_NONE )
> /*N*/ {
> [...]
>
> The code is compiled, but what was the initial reason to have them in there?
To continue to be able to import/export the older native binary format,
which was closely connected to the old internal layout and structure of
the apps, but to allow decoupling of the apps from the older formats the
decision was made to create the binfilter as effectively copies of the
old sw/sd/starmath/sc apps, except stripped down to the bare minimum to
import and export the binary file formats and convert to/from the XML
file format.
So those /*N*/ comments mean something like "I think this is Necessary"
while there will be other places with e.g. /*?*/ meaning "Dunno, maybe
necessary"
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] setting ulimit before running soffice
On Wed, 17 Nov 2010 14:01:18 -0500, Kevin Hunter wrote: > At 11:07am -0500 Wed, 17 Nov 2010, Caolán McNamara wrote: > > Nah, I don't run as root ulimit -c unlimited works fine. I'd guess > > that there some hard limits set that ordinary users aren't allowed > > to override set for you. > I suppose it's an Ubuntu thing then. I've used ulimit files > minimally in my career thus far. I suppose I'll get some practice this > go round ... mmh, works fine in Ubuntu for me (as nonroot) Sebastian pgpsZfRMdAEvz.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] Clean code at writer (core/{access, attr, bastyp, crsr, doc})
On Thu, 2010-11-18 at 08:24 +0100, David Tardon wrote: > * removed all refs to old bug tracker (Bug: -- I don't remember > ever seeing this form before...) FWIW bug numbers fall into three major patterns IIRC. XX internal StarDivision bugtracker bXX Sun bugtracker I think iX Public Issuezilla C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
