Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes
On 10/05/2011 10:11 PM, Michael Stahl wrote:
On 05.10.2011 22:02, Maciej Rumianowski wrote:
Dnia 2011-10-05, śro o godzinie 17:35 +0200, Lubos Lunak pisze:
On Wednesday 05 of October 2011, Jan Holesovsky wrote:
That would allow you to convert the pO->GetData() to something like
po->data(), instead of&(*pO)[0] (and similar) used on many places...
That same would be allowed by
class bytes : public std::vector
{
public:
const sal_uInt8* data() const { return&front(); }
...
So if it is desired solution I can modify Patches?
why not just use "&po->front()" directly instead, that's nicer than
&(*po)[0] and no need to introduce a class just for this IMHO.
&v[0] has become something of a standard idiom, I'd say. So, personal
taste mostly.
Btw, &v[0] (as well as &v.front()) are only valid if !v.empty() -- but
(without checking it in detail right now) I guess the patch already
takes account of that, Maciej?
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] Refactoring for WMF Loading
On 10/05/2011 03:03 PM, Caolán McNamara wrote:
Only micro-nit is can leave an argument unnamed rather than self-assign
it to avoid an unused parameter warnings, e.g.
void foo(int a, int, int c)
{
}
rather than
void foo(int a, int b, int c)
{
b = b;
}
See also
.
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
On Thu, Oct 6, 2011 at 1:01 AM, Tor Lillqvist wrote: >> because oox/source/drawingml/customshapepresets.cxx, a 4MB source, >> made gcc blow-up both on Mac and on Gentoo > > The horror! The horror! > > Seriously, is it really that awful if a few tinderboxes are red for > some days? That particular one get Linux and Mac to die due to a gcc abend...it is not like it is missing an include of some strategically placed #ifdef > Some of them are red for weeks. And that is very bad... hopefully with mingw the tinderbox iteration time will be in part with other platform and in the 15-20 minutes range. the current windows tinderbox itarate at best in 10 hours or so. it makes it completely unpractical to monitor's one's commit and to identify which commit is responsible of a breakage. > Is just bluntly reverting > the right way to solve problems? If it is, will have to remember that. that particular revert was not 'blunt'. that particular commit did not just make the build failed, it made the box that tried to build fail or at least suffer badly. on Mac, thanks to the fact that gcc ran as a 32 bit process it died before doing much damage to the rest of the system. on my linux, it was happily consuming 7+GB of memory by the time I manually kicked it...a commit that break the build is one thing, one that essentially DOS the tinderboxes are another. Many times, whenever I can, I try to fix the problematic commit rather than reverting. and the work is not lost... it is right there in git. if you find of a way to make it work, please, by all means do so. but to answer your more general question: yes red tinderboxes are bad, very bad. because it has a run-away effect: When master is broken, you can't check your work properly, so you increase the odd of yourself pushing a broken commit leading to an even more broken master; In the mean time tinderbox are not able to produce daily build... which means that QA cannot do their part to find bug early. Yep it is that bad on windows... and yeah we haven't been able to produce a daily build for it in weeks... but that is no reason to make that the 'standard'. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
The only solutions I see are: 1) Either we should get some really really bad-ass Windows tinderbox, *and* make it use ccache (i.e. investigate whether kendy's port of an old ccache version really works correctly, or re-port a current ccache to support MSVC). 2) Or, we should have our developers mainly work on the "difficult" platforms, i.e. Windows, and to some extent MacOSX, so that they notice themselves when code they are writing will cause problems on these platforms. Only people mainly doing distro packaging would continue to work on Linux. Obviously "we" (for some value of "us") can't enforce that on volunteers, only bosses can on their paid developers ;) 3) Or, we should jump to 4.0 directly, and support only cross-compilation to Windows. (Yes, that means a lot of work needs to be done to avoid too many regressions in the form of missing features.) Obviously I am not really expecting you to take alternative 2 seriously. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
Hi, I would also vote for not reverting stuff (at least not before we try fix it first), when only some of the tinderboxes fail due low system resources. I will try to split the offending source file to few smaller files, similar to what we do for some non-generated CXX sources, and push again. One thing I noticed. It might be useful to run tinderboxes without gcc optimization (ie. with -O0). It makes huge difference in compile time - more than 10 times faster on my system and could make the tinderbox turnaround much faster. customshapepreset.cxx compiled with -O2 real4m22.910s user4m13.794s sys 0m9.996s customshapepreset.cxx compiled with -O0 real0m25.427s user0m25.242s sys 0m1.035s Cheers Radek On Thu, 2011-10-06 at 11:18 +0300, Tor Lillqvist wrote: > The only solutions I see are: > > 1) Either we should get some really really bad-ass Windows tinderbox, > *and* make it use ccache (i.e. investigate whether kendy's port of an > old ccache version really works correctly, or re-port a current ccache > to support MSVC). > > 2) Or, we should have our developers mainly work on the "difficult" > platforms, i.e. Windows, and to some extent MacOSX, so that they > notice themselves when code they are writing will cause problems on > these platforms. Only people mainly doing distro packaging would > continue to work on Linux. Obviously "we" (for some value of "us") > can't enforce that on volunteers, only bosses can on their paid > developers ;) > > 3) Or, we should jump to 4.0 directly, and support only > cross-compilation to Windows. (Yes, that means a lot of work needs to > be done to avoid too many regressions in the form of missing > features.) > > Obviously I am not really expecting you to take alternative 2 seriously. > > --tml -- Radek Doulík Novell, Inc. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
Hi Tor, all, On Thu, 6 Oct 2011 09:01:06 +0300 Tor Lillqvist wrote: > Seriously, is it really that awful if a few tinderboxes are red for > some days? Yes, it is. Reasons follow below. > Some of them are red for weeks. IMHO we should do something about that too. > Is just bluntly reverting the right way to solve problems? If it is, > will have to remember that. At least for "breaks all platforms, cant possibly be right"-commits it is. If that happens the commiter/pusher did not do his due diligence and shouldnt complain. As a rule of thumb I personally expect every push to be tested on one platform at least(*). If it obviously was not, I have no qualms against a revert -- actually I would expect others to do the same (unfortunately some commits can even be fixed by that because of interdependencies with other changes). Reasons why tinderboxes red for a week are bad: - Whatever we had in people trying their first build this week are gone and will likely never come back. - It makes certain work almost impossible. I asked Fridrich about testing feature/kill-set_soenv on cygwin, but that has to wait until the one commit in the month where the windoze tinderbox is green again. - We do not get any early warnings by people testing nightlys as there are none. - While the tinderboxes are red for sustained periods of time, we are flying blind. Commits breaking things additionally in interesting new ways sneaks in and pile up shadowed by the first breaker. - Sustained "tinderbox is red"-periods are blackboxes for "git bisect". - There is a moral hazard: When you get twenty tinderbox breaker mails a day you just ignore them (or procmail them with the same result). Also newcomers (without procmail rules) who finally got their first commit in are scared away from the project, because these mails are telling them they either got it wrong (which is what a first commiter would suspect) or others around him are careless are not encouraging at all. - A break on master causes lots of duplication of work as many people are working on a fix and once they push their fixes likely conflict and cause even more trouble. The most recent example is almost poetry: A commit pushes an unbalanced ifdef in scp2: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=5bd2890a56125d391b42f34d51e2e0c57b0a80b0 this of course breaks the build for everyone. Lots of people get hit by it and start debugging and searching for the problem -- among them Caolan and I. Caolan pushes his fix first: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=a2623000c16d9f02bb945559a91d5bd76651772a I too fix the issue (as I pulled two commits before Caolans fix), test it and pull -r/push it back: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=d2f633c5464fd4339e9e804c97596a78bfa58e62 Note that the rebase silently resolved the conflict: "Remove one #endif? Roger, Wilco." Now two #endifs got removed and master is broken _again_ until: http://cgit.freedesktop.org/libreoffice/core/commit/scp2/source/ooo/file_library_ooo.scp?id=e944e135bc157d092532fff0829390fa7d4fa958 which also collided midair _again_ with the same fix from Fridrich (which he had to throw away, because I was faster this time). As result master was broken for half a day, lots of useless communication on IRC about it and lots of wasted resources. Now this might seem like a rare example but it likely isnt: - A lot of fixes can be mutually exclusive and still apply be without conflict -- it does not need the poetry of applying the exact same fix twice for that. - Even if the fixes collide on rebase, the additional work and wasted time is already gone. With a project this size and these numbers of commits this is bound to happen again and again rather sooner than later. This ain't Kansas anymore, Toto. I dont want to single anyone out here, this can (and will, given some time) happen to anyone with our current setup. But please, please be aware of the consequences until we have a better one. Finally: This is a prime selling point why gerrit with tinderboxes testing commits _before_ they hit master is a Good Thing(tm), but I think this point is painfully obvious now, isnt it? Best, Bjoern (*) Do I do that for a those mythological "cant possibly break anything"-commit right now? No, not a build from scratch for every one of them as chances are good that somebody else pushes while I build and I would need to rebase again anyway. But if I botch such a commit I expect the exact blunt reversal you talk about if I am to slow to react in fixing it myself. My little broken commit can possibly be more important than the health of master for everyone. -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/m
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
2011/10/6 Radek Doulík : > Hi, > > I would also vote for not reverting stuff (at least not before we try > fix it first), when only some of the tinderboxes fail due low system > resources. my mac as 32 GB of memory and a dual quad core... the linux box as 8GB and a signle quad... 'low system ressource' is _not_ the problem here. most likely a gcc corner-case... > > I will try to split the offending source file to few smaller files, > similar to what we do for some non-generated CXX sources, and push > again. > > One thing I noticed. It might be useful to run tinderboxes without gcc > optimization (ie. with -O0). It makes huge difference in compile time - > more than 10 times faster on my system and could make the tinderbox > turnaround much faster. Yes, but the generated daily build would be less usefull that way and possibly hide optimisation-induced bug until the last minute. > > customshapepreset.cxx compiled with -O2 > real 4m22.910s > user 4m13.794s > sys 0m9.996s The mac version did not finished it died afeter 20+minutes The linux one I killed after the gcc process went up to 7+GB of ram used and the machine was becoming unresponsive (swapping like hell) > > customshapepreset.cxx compiled with -O0 > real 0m25.427s > user 0m25.242s > sys 0m1.035s > note : if for that/these source -O is not necessary or useful then you can tell the build to do a NOOPT compile. see sd/Library_sd.mk for an example. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
On Thu, 2011-10-06 at 04:13 -0500, Norbert Thiebaud wrote: > > One thing I noticed. It might be useful to run tinderboxes without gcc > > optimization (ie. with -O0). It makes huge difference in compile time - > > more than 10 times faster on my system and could make the tinderbox > > turnaround much faster. > > Yes, but the generated daily build would be less usefull that way and > possibly hide optimisation-induced bug until the last minute. I thought the point of tinderboxes was to check quickly whether the tree is buildable and report failure if not. I would consider differences between whether an optimized or a non-optimized compilation would complete to be compiler bug and ignore these. IMO, I would prefer quicker turnarounds. Even more when the turnaround can be in order of 10 hours. OTOH, we would need first to see how much would -O0 save for the whole build. Cheers Radek ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Undoing basis/brand split in 3.5
On 09/20/2011 03:11 PM, Stephan Bergmann wrote: As recently announced on #libreoffice-dev, I consider undoing the basis/brand layer split. Historically, this was introduced at Sun to make it possible for various products (plain OpenOffice.org, Brasilian BrOffice re-branding, Sun's proprietary StarOffice, ...) to share code that is only built, packaged (into platform specific package formats like rpm, deb), and quality-checked once. With LibO today, there is no real need for that split any longer, so it only complicates our code base. I would undo it in incremental steps directly on master (unless I hit temporary problems that cannot be worked around easily and that force me on a branch of my own). One consequence would be that the 3.5 package and file system layout would differ rather substantially from the 3.4 one (so that, e.g., using some form of delta packages to upgrade from 3.4 to 3.5 would not be a good idea, if anybody wanted to do something like that anyway). (There is also a URE/rest split, which I will not touch for now. At least Debian seems to be interested in having a stand alone URE on top of which sits a LibO alongside potentially more apps.) So, if you see any issue with this, please make yourself heard. So that the following quote from #libreoffice-dev does not get lost: "Oct 05 14:03:57 heads up: I notice that bin/distro-install-file-lists intimately knows which files are found where within an installation; much of that changes now that I reunite basis and brand layer (but changes will come in piecemeal); is it OK if I leave that file as is for now, and each distro revisits it once the basis layer is gone?" -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] development summary: year 2011, week 39
Hi,
this time a brief summary of what happened during the 39th week in 2011
on LibreOffice repositories and the living branches:
+ master:LO-3.5 development
+ libreoffice-3-3: fixes for LO-3.3.5 bug fix release
+ no changes on that branch
+ libreoffice-3-4: fixes for LO-3.4.4 bug fix release
There are two logs for each branch:
+ bugfixes--week--.txt lists all commits that
reference a proper
bug id from a variety of trackers, i.e. #i... referring to the
OpenOffice
issuezilla, fdo# to freedesktop, rhbz# to RedHat bugzilla
+ commit-log--week--.txt lists all relevant commits
on the actual
source repositories
Many thanks to all contributors - you make all the difference!
Best Regards,
Petr
PS: It seems that Thorsten incremented the week number too fast last two weeks
:-)
So, in fact:
+ "Development summary: week 38 of 2011" described the calendar week 37
+ "Development summary: week 39 of 2011" described the calendar week 38
+ extensions
+ libreoffice doesn't build with poppler-0.17.3 (rhbz#735182) [Caolán McNamara]
+ writer
+ comment added (fdo#39510) [Bjoern Michaelsen]
+ crash on closing document with footnotes (fdo#39510, lp#854626) [Bjoern Michaelsen]
+ core
+ - Need more room for localized string (fdo#41393) [Olivier Hallot]
+ - Need more room for localized string (III) (fdo#41396) [Olivier Hallot]
+ generate valid xhtml export by using xml:lang, see also (fdo#40373) [Regina Henschel]
+ honour minimum word hyphenation length (fdo#41083) [Caolán McNamara]
+ hyphenation properties without handle ids not honoured (fdo#41128) [Caolán McNamara]
+ bootstrap
+ make configure check for cpp/poppler-version.h [Rene Engelhard]
+ extensions
+ build without glib poppler bindings [Luboš Luňák]
+ libreoffice doesn't build with poppler-0.17.3 (rhbz#735182) [Caolán McNamara]
+ this is merge of f6f8f67460bba296c49f794d14621b7313df4f7d. [Tomáš Chvátal]
+ libs-gui
+ fix crash when changing screen resolution [Radek Doulik]
+ writer
+ comment added (fdo#39510) [Bjoern Michaelsen]
+ crash on closing document with footnotes (fdo#39510, lp#854626) [Bjoern Michaelsen]
+ binfilter
+ byteString->rtl::OStringBuffer [Caolán McNamara]
+ callcatcher: SwCache::Flush unused [Caolán McNamara]
+ callcatcher: newly unused code [Caolán McNamara]
+ callcatcher: newly unused methods [Caolán McNamara]
+ callgrind: remove newly unused code [Caolán McNamara]
+ class TypedStrCollection is not really used, so I'm deleting it. [Joseph Powers]
+ cleanup class ScChartListenerCollection [Joseph Powers]
+ cleanup class ScDBDocFunc a little [Joseph Powers]
+ ditch W4W filter support [Caolán McNamara]
+ ditch out of date debugging stuff [Caolán McNamara]
+ initial .gitignore [Stephan Bergmann]
+ mirror changes in here [Caolán McNamara]
+ more DBG_BF_ASSERT cleanup [Joseph Powers]
+ more DBG_BF_ASSERT cleanup in bf_sw [Joseph Powers]
+ more DBG_BF_ASSERT cleanup in bf_sw classes [Joseph Powers]
+ object is unused [Caolán McNamara]
+ remove DBG_BF_ASSERT [Joseph Powers]
+ remove class ScOutlineDocFunc [Joseph Powers]
+ remove one of the two editsh.hxx files [Joseph Powers]
+ remove some unused code. [Joseph Powers]
+ remove the last of the easy DBG_BF_ASSERT()s in bf_sw [Joseph Powers]
+ removed uses of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *(). [Stephan Bergmann]
+ some more cleanup [Joseph Powers]
+ some more warning cleanup (Mac OS X). [Stephan Bergmann]
+ some more warning cleanup. [Stephan Bergmann]
+ some simple DBG_BF_ASSERT() cleanup [Joseph Powers]
+ the whole SwPamRanges stuff is read only so dump it [Joseph Powers]
+ waE: ditch unused args [Caolán McNamara]
+ waE: unused variables [Caolán McNamara]
+ waE: various windows warnings [Caolán McNamara]
+ core
+ - Need more room for localized string (fdo#41393) [Olivier Hallot]
+ - Need more room for localized string (III) (fdo#41396) [Olivier Hallot]
+ -fthreadsafe-statics uses a single lock on Mac OS X and thus leads to deadlock. [Stephan Bergmann]
+ <= for extra safely I suppose [Caolán McNamara]
+ adapt make dev-install to unotest changes [Markus Mohrhard]
+ adapt to the new way of passing dash-arrays from libvisio, still need to adapt libwpg [Fridrich Štrba]
+ add "Manage Names..." entry to Name Box/ScPosWnd [Markus Mohrhard]
+ add --with-system-libcmis [Rene Engelhard]
+ add GetParentDialog to VCL's Window, and remove DLGWIN & cut/paste [Michael Meeks]
+ add MinGW debugging hints. [Jan Holesovsky]
+ add MinGW handling to linkoo. [Jan Holesovsky]
+ add bestreversemap [Tor Lillqvist]
+ add dependencies for vba unit test [Markus Mohrhard]
+ add extension support to gbuild for creating .oxt files [Matúš Kukan]
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
2011/10/6 Radek Doulík : > On Thu, 2011-10-06 at 04:13 -0500, Norbert Thiebaud wrote: >> > One thing I noticed. It might be useful to run tinderboxes without gcc >> > optimization (ie. with -O0). It makes huge difference in compile time - >> > more than 10 times faster on my system and could make the tinderbox >> > turnaround much faster. >> >> Yes, but the generated daily build would be less usefull that way and >> possibly hide optimisation-induced bug until the last minute. > > I thought the point of tinderboxes was to check quickly whether the tree > is buildable and report failure if not. I would consider differences > between whether an optimized or a non-optimized compilation would > complete to be compiler bug and ignore these. IMO, I would prefer > quicker turnarounds. Even more when the turnaround can be in order of 10 > hours. > > OTOH, we would need first to see how much would -O0 save for the whole > build. I'll give it a shot... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
2011/10/6 Norbert Thiebaud : > 2011/10/6 Radek Doulík : >> >> OTOH, we would need first to see how much would -O0 save for the whole >> build. > > I'll give it a shot... Not that I expect it to make a big difference... since most of the compiles are ccached... Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
Hi Tor, On Thu, 6 Oct 2011 11:18:24 +0300 Tor Lillqvist wrote: > The only solutions I see are: > > 1) Either we should get some really really bad-ass Windows tinderbox, > *and* make it use ccache (i.e. investigate whether kendy's port of an > old ccache version really works correctly, or re-port a current ccache > to support MSVC). 1a) Or we use gerrit to coordinate tinderboxes, so that the moderately bad-add Windows tinderbox only tests stuff that succeeded on a fast Linux tinderbox. After all, quite a lot of stuff will break on both platforms and there is no use in testing on a slow one what has already failed on a fast one. > Obviously "we" (for some value of "us") can't enforce that on > volunteers, only bosses can on their paid developers ;) Just an additional note: In general, I fully expect volunteers to fix breakers they introduced on _any_ platform. That is the only way it can work sensibly. However with our current setup that is more than volunteers can do, which is why we need to change the situation. To get volunteers to fix breakers they introduced, we need to make sure it is a rare occurrence with clearly assigned responsibility. Mailing 200 people "one of you broke master on Windows" isnt helping anyone. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] fdo#41187: "Grid display" settings in Writer does not apply correctly to Page Preview
Hi all,
On fdo#41187
https://bugs.freedesktop.org/show_bug.cgi?id=41187
the reporter suggests that "Print grid" should be ignored unless "Display grid"
is checked.
I am wondering if an easy trick that making "Print grid" checked/unchecked
once "Display grid" checked/unchecked, as attached, has the similar effect
enough as making "Print grid" possible only when "Display grid" is checked.
And yes, it does change the current behavior of Writer, so it would be nice
to hear your opinions about this idea.
Cheers,
-- Takeshi Abe
>From be57f6b9b3485087c4a69538843aa199032f7e8d Mon Sep 17 00:00:00 2001
From: Takeshi Abe
Date: Thu, 6 Oct 2011 20:15:19 +0900
Subject: [PATCH] fdo#41187
making "Prind grid" possible only when "Display grid" checked
---
sw/source/ui/misc/pggrid.cxx |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/sw/source/ui/misc/pggrid.cxx b/sw/source/ui/misc/pggrid.cxx
index 7d315d8..1507b94 100644
--- a/sw/source/ui/misc/pggrid.cxx
+++ b/sw/source/ui/misc/pggrid.cxx
@@ -518,7 +518,9 @@ IMPL_LINK(SwTextGridPage, GridTypeHdl, RadioButton*, pButton)
IMPL_LINK(SwTextGridPage, DisplayGridHdl, CheckBox*, EMPTYARG)
{
-aPrintCB.Enable(aDisplayCB.IsChecked());
+sal_Bool bChecked = aDisplayCB.IsChecked();
+aPrintCB.Enable(bChecked);
+aPrintCB.Check(bChecked);
return 0;
}
--
1.7.6.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
2011/10/6 Norbert Thiebaud : > 2011/10/6 Norbert Thiebaud : >> 2011/10/6 Radek Doulík : >>> >>> OTOH, we would need first to see how much would -O0 save for the whole >>> build. >> >> I'll give it a shot... > > Not that I expect it to make a big difference... since most of the > compiles are ccached... As I suspected. changing to -O0 yield no significant difference on a 'cache hot' tinderbox. But on Windows that may be worth it, since it does not use ccache. Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
Hi Bjoern, On 2011-10-06 at 10:58 +0200, Bjoern Michaelsen wrote: > Also newcomers (without procmail rules) who finally got their first > commit in are scared away from the project, because these mails are > telling them they either got it wrong (which is what a first commiter > would suspect) or others around him are careless are not encouraging > at all. Just a small correction, we are mailing people pushing the commits, not the authors, so this is fine. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc (rant inside)
On Thu, 06 Oct 2011 13:42:52 +0200
Jan Holesovsky wrote:
> On 2011-10-06 at 10:58 +0200, Bjoern Michaelsen wrote:
>
> > Also newcomers (without procmail rules) who finally got their
> > first commit in are scared away from the project, because these
> > mails are telling them they either got it wrong (which is what a
> > first commiter would suspect) or others around him are careless are
> > not encouraging at all.
>
> Just a small correction, we are mailing people pushing the commits,
> not the authors, so this is fine.
Thanks for the correction, but I dont think it changes much about my
point: Newcomers are already reluctant to get commit access ("Oh, I
rather just send patches until I feel more at home" is heard quite
often) and getting the full nine yards on their first selfpushed commit
isnt encouraging either.
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
On Thu, 2011-10-06 at 06:30 -0500, Norbert Thiebaud wrote: > 2011/10/6 Norbert Thiebaud : > > 2011/10/6 Norbert Thiebaud : > >> 2011/10/6 Radek Doulík : > >>> > >>> OTOH, we would need first to see how much would -O0 save for the whole > >>> build. > >> > >> I'll give it a shot... > > > > Not that I expect it to make a big difference... since most of the > > compiles are ccached... > > As I suspected. changing to -O0 yield no significant difference on a > 'cache hot' tinderbox. > > But on Windows that may be worth it, since it does not use ccache. OK, I have meanwhile split the big .cxx file into 6 smaller ones and pushed. Largest file has around 750k, so hopefully it should not choke tinderboxes anymore. Cheers Radek ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
(from location) hi, donwloaded and installed master-2011-10-03_13.33.17_li etc x86 this morning. On starting, error as per subject. Regards, Cor ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
2011/10/6 Radek Doulík : > On Thu, 2011-10-06 at 06:30 -0500, Norbert Thiebaud wrote: >> 2011/10/6 Norbert Thiebaud : >> > 2011/10/6 Norbert Thiebaud : >> >> 2011/10/6 Radek Doulík : >> >>> >> >>> OTOH, we would need first to see how much would -O0 save for the whole >> >>> build. >> >> >> >> I'll give it a shot... >> > >> > Not that I expect it to make a big difference... since most of the >> > compiles are ccached... >> >> As I suspected. changing to -O0 yield no significant difference on a >> 'cache hot' tinderbox. >> >> But on Windows that may be worth it, since it does not use ccache. > > OK, I have meanwhile split the big .cxx file into 6 smaller ones and > pushed. Largest file has around 750k, so hopefully it should not choke > tinderboxes anymore. well they seems to go in a loop, most likely due to a bug in gbuild that send the make in a endless look when one try to compile a file that does not exist... are you sure of commit d05649c43b41c20a15677982e0942be8ac796753 ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Build breaks in libcmis
> On Sun, 2011-10-02 at 23:23 +0200, Regina Henschel wrote: > > I've cloned and build from master today and it breaks in libcmis. Error > > messages in build_error.log cited below. > > There are still some build problems on windows with libcmis as it's the > first 3rd party library to be gbuildified. Please add --disable-cmis to > the configure options to skip it while we still have the problems. Using --without-cmis I get build breaks in ucb (on linux). I have tried both --with-system-libcmis and --without-system-libcmis. The help string indicates CMIS is experimental and can be disabled but it appears this is not the case. Can someone fix the the build scripts so that it is possible to disable CMIS? (I take it that a conditional needs to be put into ucb/prj/build.lst?) Neil Leathers (For reference: Compiling: ucb/source/ucp/cmis/cmis_provider.cxx In file included from /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_provider.cxx:33: /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:39:39: error: libcmis/session-factory.hxx: No such file or directory In file included from /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_provider.cxx:33: /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:70: error: ‘libcmis’ has not been declared /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:70: error: ISO C++ forbids declaration of ‘Session’ with no type /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:70: error: expected ‘;’ before ‘*’ token /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:71: error: ‘libcmis’ has not been declared /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:71: error: ISO C++ forbids declaration of ‘CmisObjectPtr’ with no type /media/libreoffice/libo/ucb/source/ucp/cmis/cmis_content.hxx:71: error: expected ‘;’ before ‘m_pObject’ dmake: Error code 1, while making '../../../unxlngx6.pro/slo/cmis_provider.obj' ) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
On Thu, 2011-10-06 at 14:12 +0200, Cor Nouws wrote: > donwloaded and installed master-2011-10-03_13.33.17_li etc x86 this morning. What fun :-) is there an 'oosplash' binary in the program/ directory ? my build puts one there. Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
On Thu, 2011-10-06 at 07:36 -0500, Norbert Thiebaud wrote: > 2011/10/6 Radek Doulík : > > On Thu, 2011-10-06 at 06:30 -0500, Norbert Thiebaud wrote: > >> 2011/10/6 Norbert Thiebaud : > >> > 2011/10/6 Norbert Thiebaud : > >> >> 2011/10/6 Radek Doulík : > >> >>> > >> >>> OTOH, we would need first to see how much would -O0 save for the whole > >> >>> build. > >> >> > >> >> I'll give it a shot... > >> > > >> > Not that I expect it to make a big difference... since most of the > >> > compiles are ccached... > >> > >> As I suspected. changing to -O0 yield no significant difference on a > >> 'cache hot' tinderbox. > >> > >> But on Windows that may be worth it, since it does not use ccache. > > > > OK, I have meanwhile split the big .cxx file into 6 smaller ones and > > pushed. Largest file has around 750k, so hopefully it should not choke > > tinderboxes anymore. > > well they seems to go in a loop, most likely due to a bug in gbuild > that send the make in a endless look when one try to compile a file > that does not exist... > are you sure of commit > d05649c43b41c20a15677982e0942be8ac796753 ? Sorry, should be fixed now. (the .mk file, not the gbuild) Cheers Radek ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
> What fun :-) is there an 'oosplash' binary in the program/ directory ? > my build puts one there. ls oo* No such file or folder... Ciao- Cor ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] oox/source/drawingml/customshapepresets.cxx - generated code ...
Hi Radek,
First: I love the feature - this should improve interop. really nicely,
and great to have it in-place :-)
On Thu, 2011-10-06 at 15:12 +0200, Radek Doulík wrote:
> Sorry, should be fixed now. (the .mk file, not the gbuild)
in general though, I'm not that happy to see >4Mb of generated .cxx
(that apparently builds a similar size of .o) checked into git :-)
-particularly- because I think we can do rather better if we tweak the
generation perl script.
The problem with 'just tweak it then' is that each time we check in
another different 4Mb of auto-generated code we bloat our git repo. I
appreciate it's harder to gbuild the intermediate.
it seems it might be nicer to build tables that we interpret with code
at run-time; rather than building code that embodies the data,
potentially:
{
Any aAny ((sal_Int32) 25000);
aAdjSequence [0].Value = aAny;
}
{
Any aAny ((sal_Int32) 48123);
aAdjSequence [3].Value = aAny;
}
is much smaller as an C array of values, and similarly the sequence
construction:
Sequence< OUString > aStringSequence (61);
aStringSequence[0] = CREATE_OUSTRING ("min(width,height)");
aStringSequence[1] = CREATE_OUSTRING ("5*height/?0 ");
aStringSequence[2] = CREATE_OUSTRING ("if(0-$1 ,0,if(?1 -$1 ,
$1 ,?1 ))");
I'd like to think the compiler would evaporate all of this down to
something tiny ;-) but reading the generated assembler I'm not so
convinced ;-)
Of course, that would trade-off size for speed of initialization -
particularly if we can avoid init'ing all the custom shape presets onto
the heap before using only a subset of them (?).
How hard would it be to make the auto-generation part of the build, and
to remove the generated cxx ?
Anyhow - don't let that put a damper on the achievement, the end user
result really looks rather sexy :-) [ any chance you could add this at:
http://wiki.documentfoundation.org/ReleaseNotes/3.5 with before/ after
screenshots ].
Thanks !
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx - generated code ...
Hi Michael, On Thu, 2011-10-06 at 14:57 +0100, Michael Meeks wrote: > How hard would it be to make the auto-generation part of the build, and > to remove the generated cxx ? it not possible as the cxx code is generated by impress itself, running debug build. If I change it to run the perl scripts at build time, we will need a log file containing all the code in the git, and the log file is even bigger. What would help is to rewrite the debug dumper in the customshapeproperties.cxx to generate some simpler (ie. no UNO API involved) structures and add few methods generating UNO properties from them at runtime. I plan to do that, but later in the game, when I fix the remaining issues - or at least the worst of them. It's in the master only now, so hopefully not a big deal until we will get close to the next release. OTOH, it is quite isolated part, so if there's someone who volunteer to improve the generation meanwhile, I can point to the important pieces to change. It will mostly mean changing the dumper code to more specialized one - aware of possible structure of the properties - and generating simple structures containing the data. Plus adding the code for loading the simple data and outputting UNO data at runtime. Cheers Radek ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH], VALGRIND=memcheck => sc unit test discovered bug
btw, in case people don't know you can
export VALGRIND=memcheck
make -sr
and the unit tests are run under valgrind then
e.g. the sc unit test has the attached valgrind.log bug in it, I've
attached a probable fix.
2f632a0b39e6ae6518131ef6d100831c69c2f68f is another bug found through
valgrind on the unit tests.
C.
==18095== Conditional jump or move depends on uninitialised value(s)
==18095==at 0x1080841A: ScDBQueryDataIterator::DataAccessInternal::getCurrent(ScDBQueryDataIterator::Value&) (dociter.cxx:585)
==18095==by 0x108087F6: ScDBQueryDataIterator::DataAccessInternal::getFirst(ScDBQueryDataIterator::Value&) (dociter.cxx:648)
==18095==by 0x108094B3: ScDBQueryDataIterator::GetFirst(ScDBQueryDataIterator::Value&) (dociter.cxx:925)
==18095==by 0x10A281D6: ScInterpreter::ScDBCount() (interpr1.cxx:6509)
==18095==by 0x10A5B9C6: ScInterpreter::Interpret() (interpr4.cxx:3934)
==18095==by 0x107CC9C7: ScFormulaCell::InterpretTail(ScFormulaCell::ScInterpretTailParameter) (cell.cxx:1563)
==18095==by 0x107CBABA: ScFormulaCell::Interpret() (cell.cxx:1290)
==18095==by 0x107CE500: ScFormulaCell::MaybeInterpret() (cell.cxx:2025)
==18095==by 0x107D59E1: ScFormulaCell::GetErrCode() (cell2.cxx:733)
==18095==by 0x109A9BA7: ScCellFormat::GetString(ScBaseCell*, unsigned long, String&, Color**, SvNumberFormatter&, unsigned char, unsigned char, ScForceTextFmt) (cellform.cxx:124)
==18095==by 0x1083BCDC: ScDocument::GetCellScriptType(ScBaseCell*, unsigned long) (documen6.cxx:147)
==18095==by 0x1083BE72: ScDocument::GetScriptType(short, int, short, ScBaseCell*) (documen6.cxx:182)
==18095==by 0x107E919F: ScColumn::HasEditCells(int, int, int&) const (column.cxx:2137)
==18095==by 0x107EF11B: ScColumn::GetOptimalHeight(int, int, unsigned short*, OutputDevice*, double, double, Fraction const&, Fraction const&, bool, unsigned short, int) (column2.cxx:745)
diff --git a/sc/source/core/data/dociter.cxx b/sc/source/core/data/dociter.cxx
index 76a254f..bc9689b 100644
--- a/sc/source/core/data/dociter.cxx
+++ b/sc/source/core/data/dociter.cxx
@@ -517,7 +517,8 @@ SCSIZE ScDBQueryDataIterator::SearchColEntryIndex(ScDocument& rDoc, SCTAB nTab,
ScDBQueryDataIterator::DataAccessInternal::DataAccessInternal(const ScDBQueryDataIterator* pParent, ScDBQueryParamInternal* pParam, ScDocument* pDoc) :
DataAccess(pParent),
mpParam(pParam),
-mpDoc(pDoc)
+mpDoc(pDoc),
+bCalcAsShown( pDoc->GetDocOptions().IsCalcAsShown() )
{
nCol = mpParam->mnField;
nRow = mpParam->nRow1;
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH], VALGRIND=memcheck => sc unit test discovered bug
Hello Caolan, 2011/10/6 Caolán McNamara > btw, in case people don't know you can > export VALGRIND=memcheck > make -sr > and the unit tests are run under valgrind then > > e.g. the sc unit test has the attached valgrind.log bug in it, I've > attached a probable fix. > You can blame me, I know it and I saw the problem in one of my ouputs but wrote it on my todo list because I was debugging a crash in the basic support. I'll have a look at the patch later. Thanks a lot for reminding me again that i should not put such things on my TODO list Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
On Thu, 2011-10-06 at 15:47 +0200, Cor Nouws wrote: > > What fun :-) is there an 'oosplash' binary in the program/ directory ? > > my build puts one there. > > ls oo* > No such file or folder... Fun - what is in there ? can you attach a file-list; /bin/ls -R output of the top-level directory would be great, or rpm -qlp foo.rpm for each rpm perhaps too. Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH], VALGRIND=memcheck => sc unit test discovered bug
On Thu, 2011-10-06 at 16:58 +0200, Markus Mohrhard wrote: > Hello Caolan, > > 2011/10/6 Caolán McNamara > btw, in case people don't know you can > export VALGRIND=memcheck > make -sr > and the unit tests are run under valgrind then > > e.g. the sc unit test has the attached valgrind.log bug in it, > I've > attached a probable fix. > > You can blame me, I know it and I saw the problem in one of my ouputs > but wrote it on my todo list because I was debugging a crash in the > basic support. Heh. Don't over-blame yourself for something you are not responsible. ;-) That's my code, so it's not yours to take heat for. (Besides I don't believe in blame-fest. We help each other out.) > I'll have a look at the patch later. The patch is perfectly fine. You have my blessing. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
Cor Nouws wrote (06-10-11 15:47) What fun :-) is there an 'oosplash' binary in the program/ directory ? my build puts one there. ls oo* No such file or folder... of course copying from an other installation makes the office run... Now some more fun :-D I installed as followes: - unpacked and ran dpkg-deb in a tmp folder - moved the whole opt to ~/ - changed bootstraprc: ~/LibreOffice/master20111003/lo-dev/program$ emacs bootstraprc $SYSUSERCONFIG/libreoffice/35master111003 (what I always do with test builds) ... however, the program insists on starting with the user profile from /home/cono/.libreoffice/3 and not from /home/cono/.config/libreoffice/35master111003 what is what I expect from my builds from last month ... bug report? -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] [PUSHED], VALGRIND=memcheck => sc unit test discovered bug
Pushed to master. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] masterbuild 2011-10-03.. Linux x86: oosplash not found
Michael Meeks wrote (06-10-11 17:02) On Thu, 2011-10-06 at 15:47 +0200, Cor Nouws wrote: What fun :-) is there an 'oosplash' binary in the program/ directory ? my build puts one there. ls oo* No such file or folder... Fun - what is in there ? can you attach a file-list; /bin/ls -R output of the top-level directory would be great, ~/LibreOffice/master20111003$ ls lo-dev/program/ > ~/master20111003_program_listing.txt is attached (mind! I did copy oosplash to it) or rpm -qlp foo.rpm for each rpm perhaps too. all debs here ;-) -- - Cor - http://nl.libreoffice.org about.png basprovlo.uno.so bootstraprc bootstraprc~ canvasfactory.uno.so cmdmail.uno.so components configmgr.uno.so defaults dlgprovlo.uno.so expwrap.uno.so fastsax.uno.so fpicker.uno.so fps_gnome.uno.so fps_office.uno.so fsstorage.uno.so fundamentalrc gdbtrace greprefs hatchwindowfactory.uno.so i18npool.uno.so i18nsearch.uno.so intro.png kdebe1.uno.so libabplo.so libacclo.so libadabasuilo.so libanalysislo.so libanimcorelo.so libavmediagst.so libavmedialo.so libbasctllo.so libbasebmplo.so libbasegfxlo.so libbf_frmlo.so libbf_golo.so libbf_migratefilterlo.so libbf_ofalo.so libbf_sblo.so libbf_schlo.so libbf_sclo.so libbf_sdlo.so libbf_smlo.so libbf_solo.so libbf_svtlo.so libbf_svxlo.so libbf_swlo.so libbf_wrapperlo.so libbf_xolo.so libbiblo.so libbindetlo.so libcached1.so libcalclo.so libcanvastoolslo.so libchartcontrollerlo.so libchartmodello.so libcharttoolslo.so libchartviewlo.so libcollator_data.so libcommunilo.so libcomphelpgcc3.so libcppcanvaslo.so libctllo.so libcuilo.so libcurl.so.4 libdatelo.so libdb-4.7.so libdbalo.so libdbaselo.so libdbaxmllo.so libdbmmlo.so libdbplo.so libdbpool2.so libdbtoolslo.so libdbulo.so libdeploymentgui.so libdeployment.so libdict_ja.so libdict_zh.so libdrawinglayerlo.so libeditenglo.so libegilo.so libembobj.so libemboleobj.so libemelo.so libepblo.so libepglo.so libepplo.so libepslo.so libeptlo.so liberalo.so libetilo.so libevtattlo.so libexplo.so libfileacc.so libfilelo.so libfilterconfiglo.so libflashlo.so libflatlo.so libforlo.so libforuilo.so libfreebl3.so libfrmlo.so libfwelo.so libfwilo.so libfwklo.so libfwllo.so libfwmlo.so libguesslanglo.so libhelplinkerlo.so libhsqldb.so libhwplo.so libhyphenlo.so libi18nisolang1gcc3.so libi18npaperlo.so libi18nutilgcc3.so libicdlo.so libicglo.so libicudata.so.44 libicudata.so.44.2 libicui18n.so.44 libicui18n.so.44.2 libicule.so.44 libicule.so.44.2 libicuuc.so.44 libicuuc.so.44.2 libidxlo.so libimelo.so libindex_data.so libipblo.so libipdlo.so libipslo.so libiptlo.so libipxlo.so libiralo.so libitglo.so libitilo.so libjdbclo.so libkab1.so libkabdrv1.so libldap50.so liblegacy_binfilterslo.so liblnglo.so liblnthlo.so liblocaledata_en.so liblocaledata_es.so liblocaledata_euro.so liblocaledata_others.so liblpsolve55.so liblwpftlo.so libmcnttype.so libmozabdrvlo.so libmozjs.so libmozz.so libmsgbaseutil.so libmswordlo.so libmsworkslo.so libmysqllo.so libneon.so libnpsoplugin.so libnspr4.so libnss3.so libnssckbi.so libnssdbm3.so libnssutil3.so libodbclo.so libodfflatxmllo.so liboffacclo.so libofficebeanlo.so libooxlo.so libpackage2.so libpcrlo.so libpdffilterlo.so libplacewarelo.so libplc4.so libplds4.so libpllo.so libprldap50.so libprotocolhandlerlo.so libraptor.so.1 librasqal.so.1 librdf.so.0 librecentfile.so libreslo.so librptlo.so librptuilo.so librptxmllo.so libsaxlo.so libsblo.so libscdlo.so libscfiltlo.so libsclo.so libscnlo.so libscriptframe.so libscuilo.so libsdbc2.so libsdbtlo.so libsddlo.so libsdfiltlo.so libsdlo.so libsduilo.so libsfxlo.so libsimplecmlo.so libsmdlo.so libsmime3.so libsmlo.so libsofficeapp.so libsoftokn3.so libsolverlo.so libsotlo.so libspalo.so libspelllo.so libspllo.so libsqlite3.so libsrtrs1.so libssl3.so libstslo.so libsvgfilterlo.so libsvllo.so libsvtlo.so libsvxlo.so libswdlo.so libswlo.so libswuilo.so libt602filterlo.so libtextconv_dict.so libtextconversiondlgslo.so libtklo.so libtllo.so libtvhlp1.so libucb1.so libucbhelper4gcc3.so libucpchelp1.so libucpdav1.so libucpfile1.so libucpftp1.so libucphier1.so libucppkg1.so libunopkgapp.so libunordflo.so libunoxmllo.so libupdchklo.so libutllo.so libuuilo.so libvcllo.so libvclplug_genlo.so libvclplug_gtklo.so libvclplug_kdelo.so libvclplug_svplo.so libwpftlo.so libwpgimportlo.so libwriterfilterlo.so libxcrlo.so libxmlfalo.so libxmlfdlo.so libxmlsecurity.so libxmxlo.so libxoflo.so libxolo.so libxpcom_compat.so libxpcom_core.so libxpcom.so libxsec_fw.so libxsec_xmlsec.so libxsltdlglo.so libxsltfilterlo.so libxslt.so.1 libxstor.so localebe1.uno.so migrationoo2.uno.so migrationoo3.uno.so OGLTrans.uno.so oosplash pagein-calc pagein-common pagein-draw pagein-impress pagein-writer passwordcontainer.uno.so python redirectrc sbase scalc sdraw services.rdb setuprc shell simplecanvas.uno.so simpress slideshow.uno.so smath soffice soffice.bin sofficerc spadmin stringresourcelo.uno.so swriter syssh.uno.so testtool testtoolrc ucpexpand1.uno.so ucpgvfs1.uno.so ucptdoc1.uno.s
Re: [Libreoffice] patch for scan-diialog
Here is the patch.
M.V.G.
Rob Snelders
On 06-10-11 01:28, Miklos Vajna wrote:
On Wed, Oct 05, 2011 at 09:57:43PM +0200, Rob Snelders
wrote:
I created a patch for the scan-dialog for Linux. It allows to scan a
image directly from the scan-dialog without needing to select first the
dialog and then the "request"-menuitem.
The patch is submitted under the LGPLv3+/MPL-licence.
Forgot to attach the patch?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
>From 2e6180eb49ec4886550ea105cf7149d6ff307c3e Mon Sep 17 00:00:00 2001
From: Rob Snelders
Date: Wed, 5 Oct 2011 21:52:08 +0200
Subject: [PATCH] Added a scan-button to the SaneDlg
---
extensions/source/scanner/sanedlg.cxx | 12 +++-
extensions/source/scanner/sanedlg.hrc |1 +
extensions/source/scanner/sanedlg.hxx |4
extensions/source/scanner/sanedlg.src |7 +++
extensions/source/scanner/scanner.hxx |2 +-
extensions/source/scanner/scanunx.cxx |7 ++-
extensions/source/scanner/scanwin.cxx |2 +-
offapi/com/sun/star/scanner/XScannerManager.idl |5 +++--
sd/source/ui/view/drviews8.cxx |2 +-
sw/source/ui/uiview/uivwimp.cxx |6 --
10 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/extensions/source/scanner/sanedlg.cxx b/extensions/source/scanner/sanedlg.cxx
index 39b8862..2e55050 100644
--- a/extensions/source/scanner/sanedlg.cxx
+++ b/extensions/source/scanner/sanedlg.cxx
@@ -58,6 +58,7 @@ SaneDlg::SaneDlg( Window* pParent, Sane& rSane ) :
maCancelButton( this, SaneResId( RID_SCAN_CANCEL ) ),
maDeviceInfoButton( this, SaneResId( RID_DEVICEINFO_BTN ) ),
maPreviewButton( this, SaneResId( RID_PREVIEW_BTN ) ),
+maScanButton( this, SaneResId( RID_SCAN_BTN ) ),
maButtonOption( this, SaneResId( RID_SCAN_BUTTON_OPTION_BTN ) ),
maOptionsTxt( this, SaneResId( RID_SCAN_OPTION_TXT ) ),
maOptionTitle( this, SaneResId( RID_SCAN_OPTIONTITLE_TXT ) ),
@@ -88,6 +89,7 @@ SaneDlg::SaneDlg( Window* pParent, Sane& rSane ) :
maOptionBox( this, SaneResId( RID_SCAN_OPTION_BOX ) ),
mpRange( 0 )
{
+doScan = sal_False;
if( Sane::IsSane() )
{
InitDevices(); // opens first sane device
@@ -97,6 +99,7 @@ SaneDlg::SaneDlg( Window* pParent, Sane& rSane ) :
maDeviceInfoButton.SetClickHdl( LINK( this, SaneDlg, ClickBtnHdl ) );
maPreviewButton.SetClickHdl( LINK( this, SaneDlg, ClickBtnHdl ) );
+maScanButton.SetClickHdl( LINK( this, SaneDlg, ClickBtnHdl ) );
maButtonOption.SetClickHdl( LINK( this, SaneDlg, ClickBtnHdl ) );
maDeviceBox.SetSelectHdl( LINK( this, SaneDlg, SelectHdl ) );
maOptionBox.SetSelectHdl( LINK( this, SaneDlg, OptionsBoxSelectHdl ) );
@@ -476,13 +479,15 @@ IMPL_LINK( SaneDlg, ClickBtnHdl, Button*, pButton )
ReloadSaneOptionsHdl( NULL );
}
}
-if( pButton == &maOKButton )
+if( pButton == &maOKButton || pButton == &maScanButton )
{
double fRes = (double)maReslBox.GetValue();
SetAdjustedNumericalValue( "resolution", fRes );
UpdateScanArea( sal_True );
SaveState();
EndDialog( mrSane.IsOpen() ? 1 : 0 );
+if (pButton == &maScanButton)
+doScan = sal_True;
}
else if( pButton == &maCancelButton )
{
@@ -1376,4 +1381,9 @@ sal_Bool SaneDlg::SetAdjustedNumericalValue(
return sal_True;
}
+sal_Bool SaneDlg::getDoScan()
+{
+return doScan;
+}
+
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/extensions/source/scanner/sanedlg.hrc b/extensions/source/scanner/sanedlg.hrc
index ca89312..1e468c9 100644
--- a/extensions/source/scanner/sanedlg.hrc
+++ b/extensions/source/scanner/sanedlg.hrc
@@ -62,6 +62,7 @@
#define RID_SCAN_BITMAP_MINUS 32
#define RID_SCAN_ADVANCED_BOX 33
#define RID_SCAN_ADVANCED_TXT 34
+#define RID_SCAN_BTN 35
#define RID_SANE_DEVICEINFO_TXT 1001
#define RID_SANE_SCANERROR_TXT 1002
diff --git a/extensions/source/scanner/sanedlg.hxx b/extensions/source/scanner/sanedlg.hxx
index c3f72ea..a008655 100644
--- a/extensions/source/scanner/sanedlg.hxx
+++ b/extensions/source/scanner/sanedlg.hxx
@@ -65,6 +65,7 @@ private:
CancelButtonmaCancelButton;
PushButton maDeviceInfoButton;
PushButton maPreviewButton;
+PushButton maScanButton;
PushButton maButtonOption;
FixedText maOptionsTxt;
@@ -107,6 +108,8 @@ private:
double* mpRange;
double mfMin, mfMax;
+sal_BooldoScan;
+
DECL_LINK( ClickBtnHdl, Button* );
DECL_LINK( SelectHdl, ListBox* );
DECL_LINK( ModifyHdl, Edit* );
@@ -145,6 +148,7 @@ public:
~SaneDlg();
virtual short
[Libreoffice] --with-alloc setting
In running through my build settings I was trying to decide which value to use for --with-alloc=???. There isn't a specific recommendation on http://wiki.documentfoundation.org/Development/How_to_build/Configure_options and the only other documentation I can find is that values other than "system" cause problems when testing. Currently it defaults to "internal" perhaps this should be changed to default to "system". If there is a good reason why "internal" is better then it should be documented on the wiki page. Or the trade offs and recommendations should be documented on the wiki. Neil Leathers ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] ODF plugfest Gouda, Netherlands, November 17, 18
Hi, I've seen an invitation for that ODF plugfest. Anyone planning to be there? Because of the distance, I could attend easily. At least partly. However, because of the content, others might be more in place there.. Cheers, -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx - generated code ...
Hi Radek, On Thu, 2011-10-06 at 16:16 +0200, Radek Doulík wrote: > it not possible as the cxx code is generated by impress itself, running > debug build. Ah - fair enough, I was missing this piece :-) while no doubt possible with experience from our nice unit-testing goodness, it does stick rather an arrow in the eye of the idea ;-) Thanks, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] minutes of tech. steering call ...
+ Present: + Thorsten, Andras, Michael M, Stephan, Tor, Rainer, Mitch, Norbert, Kendy, Michael S, Bjoern, Caolan, Petr + Completed + add ABI related re-factoring plans to wiki [ on going / indeterminate ] at: http://wiki.documentfoundation.org/Development/LibreOffice4 + update openSymbol with version gap & checks (done by Julien Nabet) + hide virus/trojan warnings with XOR mangling for unit tests (Caolan) + add C++ cross-compile ABI change issue to release 4 wiki page (Kendy) + download page recommends stale version (Thorsten) + Pending Action Items + default to TM safe (non-TDF) branding (Thorsten) + enable on-line updates for QA in cross-compiled dalies ... (Kendy) + publicise our list of ODF proposals / extensions [ in progress] (Thorsten) * Agenda items + pending action items + Andras's new MSI packaging approach (Andras/Tor) + motivation - make Windows installer simpler + existing install process has two->three steps, pre-installer, setup.exe, MSI and is not localizeable + hack week: created multi-language single MSI for installation + why not use it before ? no MSI install at all before (Tor) + should not be an issue anymore + the setup.exe level - could pass params to setup installer + old switches can be mapped to std. msiexec switches AA: + add l10n improvements to 3.5 release notes (Andras) AA: + adding l10n code is currently done by pair of VB Scripts would need to grok & port these to a better tool. (Andras) AA: + default to Andras' new MSI building method when this is documented (Andras) + release mgmt bits (Petr) + nothing much new happening, 3.4.4 RC1 freeze is one week after the conference + few more most annoying bugs to be looked at + looking forward to discussing 3.5 schedule at conference + introduction (Michael Stahl) + at Sun/Oracle for four years, part of writer + framework team + experience of RDF meta-data (not in such a useful state yet sadly - no copy/paste support of that), writer undo/redo, removed old/obsolete/duplicated stuff, document properties re-implementation, redland module, lots of bug fixes, gbuild on OS/X + Solaris etc. + great to have Michael on board at RedHat, plan to poke at the area of change-tracking, and other issues in writer. + ESC composition - update it in Paris ? + QA update (Rainer) + business as usual + concern wrt. lots of bugs untouched for months 2.3k waiting for review + bug report assistant + few issues being kindly unwound by Loic + but getting more reports since it was created + missing operating-system detection, + way better overall for end users. + need better co-ordination with the ~10 active QA guys. AA: + come up with a list of QA heros for next meeting (Rainer) + gbuild multi-repo support (Bjoern) + quests through every source root for object files + avoiding symlinks etc. + obsolete and potentially already broken, remove it ? + general agreement AA: + add potential removal of two-layer LibO to plan (Bjoern) http://wiki.documentfoundation.org/Development/LibreOffice4 -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --with-alloc setting
Hi Neil, On Thu, 2011-10-06 at 13:45 -0300, Neil Leathers wrote: > In running through my build settings I was trying to decide which > value to use for --with-alloc=???. Wow - that's a blast from the past. Intel did some work to enable tcmalloc to be used - one of those micro-optimisations that people hope will make things faster and often do - but only linearly. > Currently it defaults to "internal" perhaps this should be changed to > default to "system". If there is a good reason why "internal" is > better then it should be documented on the wiki page. Or the trade > offs and recommendations should be documented on the wiki. Right - so, we should do some performance tests of characteristic documents with the internal vs. system allocator. AFAIR the system allocator is rather good on Linux, and terrible on Windows ;-) so possibly we should have a platform-dependent default. As for the tcmalloc and abcmalloc options I'd be inclined to strip them out as cruft we can live without these days. Is that reasonable ? I'd just do 3x timing runs for startup / document load / exit for some reasonably large .doc, .ppt, and .xls [ chosen for their faster, non-XML impls. by the way ]. if you use: export RTL_LOGFILE=/tmp/startup.nopid and remove that before running, you -should- get some nice timestamps in it that can be used to test. It'd be wonderful to have some new research in that area to build better decisions on. Thanks :-) Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] installation fails because of missing MSVCR90.dll
Hi all, I've finished 'make build' on WinXP. Now I have installed administrative with 'setup.exe -a' with the setup.exe from instsetoo_native/.../install/en-US. It unpacked the files without problems, but when I try to run soffice.exe I get an error about missing MSVCR90.dll. Other versions with administrative installation does not have this problem. Do I miss something after 'make build'? Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Hi Regina, On Thu, Oct 6, 2011 at 7:53 PM, Regina Henschel wrote: > Hi all, > > I've finished 'make build' on WinXP. Now I have installed administrative > with 'setup.exe -a' with the setup.exe from > instsetoo_native/.../install/en-US. It unpacked the files without problems, > but when I try to run soffice.exe I get an error about missing MSVCR90.dll. > > Other versions with administrative installation does not have this problem. > > Do I miss something after 'make build'? What version of the compiler are you using for the build? If it's Visual Studio 2008 the C runtime libraries version 90 are installed with the compiler and it would be very strange that it doesn't find them... In any case, can you post the output of the error that you can find in "Administrative Tools" -> "Event Viewer" -> "Applications"? That output can probably give us more hints about the problem. Thanks and regards, -- Jesús Corrius Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --with-alloc setting
> AFAIR the system allocator is rather good on Linux, and terrible on Windows > ;-) And bestest of all it is on Gentoo!!! --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Hi Jesús, Jesús Corrius schrieb: Hi Regina, On Thu, Oct 6, 2011 at 7:53 PM, Regina Henschel wrote: Hi all, I've finished 'make build' on WinXP. Now I have installed administrative with 'setup.exe -a' with the setup.exe from instsetoo_native/.../install/en-US. It unpacked the files without problems, but when I try to run soffice.exe I get an error about missing MSVCR90.dll. Other versions with administrative installation does not have this problem. Do I miss something after 'make build'? What version of the compiler are you using for the build? If it's Visual Studio 2008 the C runtime libraries version 90 are installed with the compiler and it would be very strange that it doesn't find them... It is Visual Studio 2008 Express. It is the first time I get this error. In any case, can you post the output of the error that you can find in "Administrative Tools" -> "Event Viewer" -> "Applications"? That output can probably give us more hints about the problem. Windows Installer-Transaktion wird gestartet: C:\git\LO35OKT\instsetoo_native\wntmsci12.pro\LibreOffice_Dev\native\install\en-US\libodev35.msi. Clientprozess-ID: 8132. Windows Installer-Transaktion wird beendet: C:\git\LO35OKT\instsetoo_native\wntmsci12.pro\LibreOffice_Dev\native\install\en-US\libodev35.msi. Clientprozess-ID: 8132. Product: LibO-dev 3.5 -- Installation operation completed successfully. Das Produkt wurde durch Windows Installer installiert. Produktname: LibO-dev 3.5. Produktversion: 3.5.0. Produktsprache: 1033. Erfolg- bzw. Fehlerstatus der Installation: 0. Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Could it be that we don't get any manifest into the executables, or something? That was broken at some stage after the gbuildification of desktop. Myself, I haven't had a successful build of master in a month. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] Remove code related to previously disabled HTML 3.2 export
Again one small patch to simplify HTML export code.
This patch is licensed under LGPLv3+/MPL. This will also hold for all
future patches I submit to this list, unless I state otherwise.
Harri>From 425bd69f8968101a84ec510b1e880fa4b2c51244 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Harri=20Pitk=C3=A4nen?=
Date: Thu, 6 Oct 2011 20:58:11 +0300
Subject: [PATCH] Remove code related to previously disabled HTML 3.2 export
---
cui/source/tabpages/page.cxx | 11 ++-
svtools/inc/svtools/htmlcfg.hxx |1 -
sw/source/filter/html/wrthtml.cxx |7 ++-
sw/source/ui/shells/textsh.cxx|5 +
4 files changed, 5 insertions(+), 19 deletions(-)
diff --git a/cui/source/tabpages/page.cxx b/cui/source/tabpages/page.cxx
index 59977eb..fe0af32 100644
--- a/cui/source/tabpages/page.cxx
+++ b/cui/source/tabpages/page.cxx
@@ -89,9 +89,6 @@ public:
/** Returns the HTML export mode, as read from the configuration. */
inline sal_Int32GetExportMode() const { return mnExpMode; }
-/** Returns true, if the current HTML export mode is set to HTML 3.2. */
-inline bool IsExportModeHTML32() const { return mnExpMode == 0; } // 0 == HTML_CFG_HTML32, see offmgr/htmlcfg.hxx
-
virtual voidCommit();
virtual void Notify( const com::sun::star::uno::Sequence< rtl::OUString >& _rPropertyNames);
@@ -310,10 +307,6 @@ SvxPageDescPage::SvxPageDescPage( Window* pParent, const SfxItemSet& rAttr ) :
0 != (pItem = pShell->GetItem(SID_HTML_MODE
bWeb = 0 != (((const SfxUInt16Item*)pItem)->GetValue() & HTMLMODE_ON);
-// #109989# get the HTML export setting from configuration.
-// !! This is a hack, see comments in SvxHtmlExportModeConfigItem_Impl class above.
-bool bHTML32 = SvxHtmlExportModeConfigItem_Impl().IsExportModeHTML32();
-
// fill text flow listbox with valid entries
aTextFlowBox.InsertEntryValue( CUI_RESSTR( RID_SVXSTR_PAGEDIR_LTR_HORI ), FRMDIR_HORI_LEFT_TOP );
if( bCTL )
@@ -328,8 +321,8 @@ SvxPageDescPage::SvxPageDescPage( Window* pParent, const SfxItemSet& rAttr ) :
}
}
-// #109989# show the text direction box in Writer/Web too, but only, if HTML export mode is not HTML3.2.
-if( !(bWeb && bHTML32) && (bCJK || bCTL) &&
+// #109989# show the text direction box in Writer/Web too
+if( (bCJK || bCTL) &&
SFX_ITEM_UNKNOWN < rAttr.GetItemState(GetWhich( SID_ATTR_FRAMEDIRECTION )))
{
aTextFlowLbl.Show();
diff --git a/svtools/inc/svtools/htmlcfg.hxx b/svtools/inc/svtools/htmlcfg.hxx
index e73a385..9b35b7b 100644
--- a/svtools/inc/svtools/htmlcfg.hxx
+++ b/svtools/inc/svtools/htmlcfg.hxx
@@ -38,7 +38,6 @@
// !!!be aware!!!: the following defines are _not_ used as values in the configuration file
// this is because of compatibility reasons
-#define HTML_CFG_HTML32 0 // Html 3.2
#define HTML_CFG_MSIE 1 // Internet Explorer
#define HTML_CFG_WRITER 2 // Writer
#define HTML_CFG_NS40 3 // Netscape 4.0
diff --git a/sw/source/filter/html/wrthtml.cxx b/sw/source/filter/html/wrthtml.cxx
index 4a7cd31..ddc377f 100644
--- a/sw/source/filter/html/wrthtml.cxx
+++ b/sw/source/filter/html/wrthtml.cxx
@@ -162,8 +162,7 @@ sal_uLong SwHTMLWriter::WriteStream()
if( HTML_CFG_NS40==nExportMode )
nHTMLMode |= HTMLMODE_BORDER_NONE;
-if( HTML_CFG_HTML32!=nExportMode )
-nHTMLMode |= HTMLMODE_FONT_GENERIC;
+nHTMLMode |= HTMLMODE_FONT_GENERIC;
if( HTML_CFG_NS40==nExportMode )
nHTMLMode |= HTMLMODE_NO_CONTROL_CENTERING;
@@ -906,9 +905,7 @@ const SwPageDesc *SwHTMLWriter::MakeHeader( sal_uInt16 &rHeaderAttrs )
{
rtl::OStringBuffer sOut;
sOut.append(OOO_STRING_SVTOOLS_HTML_doctype).append(' ')
-.append(HTML_CFG_HTML32==nExportMode ?
-OOO_STRING_SVTOOLS_HTML_doctype32 :
-OOO_STRING_SVTOOLS_HTML_doctype40);
+.append(OOO_STRING_SVTOOLS_HTML_doctype40);
HTMLOutFuncs::Out_AsciiTag( Strm(), sOut.makeStringAndClear().getStr() );
// baue den Vorspann
diff --git a/sw/source/ui/shells/textsh.cxx b/sw/source/ui/shells/textsh.cxx
index e46d7d3..5835e5c 100644
--- a/sw/source/ui/shells/textsh.cxx
+++ b/sw/source/ui/shells/textsh.cxx
@@ -515,10 +515,7 @@ void SwTextShell::ExecInsert(SfxRequest &rReq)
{
SvxHtmlOptions& rHtmlOpt = SvxHtmlOptions::Get();
sal_uInt16 nExport = rHtmlOpt.GetExportMode();
-if( HTML_CFG_MSIE == nExport ||
-HTML_CFG_HTML32 == nExport ||
-HTML_CFG_MSIE == nExport ||
-HTML_CFG_HTML32 == nExport )
+if( HTML_CFG_MSIE == nExport )
{
bSingleCol = sal_True;
}
--
1.7.6.3
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Questions about push access
Hello, let me ask a few questions. 1. I've performed my first push today and received this message: 2011/10/6 > Your mail to 'Libreoffice-commits' with the subject > > .: tools/source > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: I've canceled posting foolishly. I was not supposed to do that, was I? And is it possible not to receive such mailings? 2. What changes should I avoid in my commits? I mean, what changes are unwanted, needless, etc. Thanks. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
2011/10/6 Tor Lillqvist : > Could it be that we don't get any manifest into the executables, or > something? That was broken at some stage after the gbuildification of > desktop. Myself, I haven't had a successful build of master in a > month. It's very possible, yes. Regina, this log is about the installation. Do you also have another error log in the "Event Viewer" that is produced when you launch soffice.exe? It probably mentions manifests and MSVCR90 Also you can use the tool mt.exe to check the manifest. The syntax is something like: $ mt.exe -inputresource:soffice.exe -out:soffice.manifest (mt.exe should be located in C:\Program Files\Microsoft SDKs\Windows\v6.1\bin or a similar location) Thanks again :) -- Jesús Corrius Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] dmake/win95: deprecated directory ?
hello, I found a directory that seems to be deprecated since win95 is not supported anymore. There is another directory: dmake/winnt which seems to be more or less the clone of dmake/win95. Since I am not able to compile under windows, -hence not able to check what I would break - I mention it here, if someone wants to clean this directory and its dependencies... or move them to dmake/winnt if still needed. regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] scope of variable reduction, cppcheck-error free build and new bugs
Hello, since I had free time, I have taken over to eliminate the "scope reduction" warning from cppcheck in order to reduce the noise by checks. This has been done almost successfully, about 10 such warnings are still available due to #ifdefn or macros. This also allowed me to reduce other warnings (like hiding of var) and to find some errors introduced by recent changes. Every change has been checked and done "manually", finding also some false positives (and one false negative). I have tested several clean build with different options, discovering so some too hard scope reduction (some #ifdefn masking some if statement). But I guess there are - sadly - some configurations where I did not notice that I broke something. (Murphy's Law lurks somewhere near us). So my apologies in advance. I will push it during the week-end, once I am finished with rebasing and after a last clean build. If some build option is broken, just revert the concerned commit: they are on purpose small and isolated. The log indicates the top directory and when possible the file where (the) change(s) has been done. Regards Pierre-André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Remove code related to previously disabled HTML 3.2 export
Hi Harri, On Thu, 2011-10-06 at 21:34 +0300, Harri Pitkänen wrote: > Again one small patch to simplify HTML export code. Thanks ! :-) nice to clean that up. > This patch is licensed under LGPLv3+/MPL. This will also hold for all > future patches I submit to this list, unless I state otherwise. Lovely, thanks for the link in the Developers wiki page too :-) All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about push access
Hi Ivan, On Thu, 2011-10-06 at 22:22 +0400, Ivan Timofeev wrote: > 1. I've performed my first push today and received this message: Heh ;-) we get to add each committer to the commiters list manually - that is something I ought to do I guess, but Thorsten tends to do idly when the bounces happen. > I've canceled posting foolishly. I was not supposed to do that, was I? > And is it possible not to receive such mailings? No problem cancelling it, we can read the git log -u much more easily these days. > 2. What changes should I avoid in my commits? I mean, what changes are > unwanted, needless, etc. Clearly running indent gratuitously on the code, while it may improve it, makes the diff very hard to read ;-) beyond that - code cleanup, porting, easy hacks - anything non-controversial should go straight into master. Anything you're not sure - just ask on the list :-) If you're hacking a module substantially, it makes sense to dung out un-necessary cruft, vertical line wasteage, over-verbose comments that reduce readability are all fair game I think. Excited to see what you'll work on :-) All the best, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Hi, Jesús Corrius schrieb: 2011/10/6 Tor Lillqvist: Could it be that we don't get any manifest into the executables, or something? That was broken at some stage after the gbuildification of desktop. Myself, I haven't had a successful build of master in a month. It's very possible, yes. Regina, this log is about the installation. Do you also have another error log in the "Event Viewer" that is produced when you launch soffice.exe? It probably mentions manifests and MSVCR90 In 'System' is the content of the popup Anwendungspopup: soffice.exe - Komponente nicht gefunden: Die Anwendung konnte nicht gestartet werden, weil MSVCR90.dll nicht gefunden wurde. Neuinstallation der Anwendung könnte das Problem beheben. No other entries. Also you can use the tool mt.exe to check the manifest. The syntax is something like: $ mt.exe -inputresource:soffice.exe -out:soffice.manifest (mt.exe should be located in C:\Program Files\Microsoft SDKs\Windows\v6.1\bin or a similar location) mt.exe : general error c101008c: Failed to read the manifest from the resource of file "soffice.exe". Der angegebene Ressourcentyp wurde nicht in der Image-Datei gefunden. I'm not sure that I call it right. I'm in Cygwin and set source, change to the folder with soffice.exe and call mt.exe -inputresource:soffice.exe -out:soffice.manifest I get the same error with mt.exe -inputresource:soffice.exe -out:soffice.bin.manifest Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Hi Regina, > mt.exe : general error c101008c: Failed to read the manifest from the > resource of file "soffice.exe". Der angegebene Ressourcentyp wurde nicht in > der Image-Datei gefunden. > > I'm not sure that I call it right. I'm in Cygwin and set source, change to > the folder with soffice.exe and call You did it right. Everything points to the problem Tor mentioned. Although it should be possible to fix the the generated binaries and run the build (embedding manifests to the executables by hand), in my opinion it is way too much work and not productive at all. So I wouldn't do it without a good reason. I would like to be able to help you more here, but I guess the answer has to be "the Windows build is broken, someone has to fix it, and then you should rebuild". Maybe you are interested at poking at the makefiles and try to fix this problem yourself? :) -- Jesús Corrius Document Foundation founding member Mobile: +34 661 11 38 26 Skype: jcorrius | Twitter: @jcorrius ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] installation fails because of missing MSVCR90.dll
Hi Jesús, Jesús Corrius schrieb: [..] I would like to be able to help you more here, but I guess the answer has to be "the Windows build is broken, someone has to fix it, and then you should rebuild". Maybe you are interested at poking at the makefiles and try to fix this problem yourself? :) I'm not able to do it. Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [RFC] hard dependencies on 3rd party libraries
Hi, I was lately wondering why all the new features / dependencies are handled as required unconditionaly. Would it not be possible to add specific with/without switches for features that require 3rd party libs? Like cups/cmis/visio/wpd/... so users could choose which features they really want in during the compile, making the build smaller if they want to. I am not saying that we are to backport all the switches right away, but with disappearance of --with-cmis it occured to me that we add even new libraries as hard dependencies. I also know that you can say that we can unbundle this on runtime, but then again I am gentoo dev so we need this kind of optionality on build time, and I bet we are not the only ones. Of course all the switches would be in enabled state by default. If you are afraid of breakages that would not be noticed i can quite ensure you that I am capable of running tests for on/off for each swich weekly. Cheers Tom ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] --with-alloc setting
On Thu, 6 Oct 2011 21:14:41 +0300 Tor Lillqvist wrote: > > AFAIR the system allocator is rather good on Linux, and terrible on > > Windows ;-) > > And bestest of all it is on Gentoo!!! And more fun there with -funroll-loops too!!1!! SCNR. Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] Replace WW8Bytes with ww::bytes
Hi Maciej,
On 2011-10-05 at 22:02 +0200, Maciej Rumianowski wrote:
> > That same would be allowed by
> > class bytes : public std::vector
> > {
> > public:
> > const sal_uInt8* data() const { return &front(); }
> > ...
> So if it is desired solution I can modify Patches?
No need to, I took this approach
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f1eda55a0670cd571d676b46d2ac19fe86d51a3f
and modified your patches myself. I've pushed them under your name, as
all I did was a sed :-)
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6cdc31837c73accca69ed9b1702e269f50c96bff
http://cgit.freedesktop.org/libreoffice/core/commit/?id=37836e3ba37c1ff7c303047a418dcbc3ef390afe
http://cgit.freedesktop.org/libreoffice/core/commit/?id=bcf7d383578a00b961a0484534d810202cf57852
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d052ac384fbb476fe4525ab2d123d79b1158acb4
Thank you a lot,
Kendy
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED] Re: [PATCH] fdo#41187: "Grid display" settings in Writer does not apply correctly to Page Preview
Hi Takeshi, On 2011-10-06 at 20:25 +0900, Takeshi Abe wrote: > On fdo#41187 > https://bugs.freedesktop.org/show_bug.cgi?id=41187 > the reporter suggests that "Print grid" should be ignored unless "Display > grid" > is checked. > I am wondering if an easy trick that making "Print grid" checked/unchecked > once "Display grid" checked/unchecked, as attached, has the similar effect > enough as making "Print grid" possible only when "Display grid" is checked. > And yes, it does change the current behavior of Writer, so it would be nice > to hear your opinions about this idea. Thank you for that, pushed! :-) Cannot judge myself, as this is affecting the CTL case only (right?), instead adding the UX guys should they have any input on this. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc
At 6:28am -0400 Thu, 06 Oct 2011, Norbert Thiebaud wrote: 2011/10/6 Norbert Thiebaud: I'll give it a shot... Not that I expect it to make a big difference... since most of the compiles are ccached... As an nth data point on the matter, I've been using ccache for awhile, and my builds take longer. Anecdotally (because I'm not focused on ccache specifically), I turned it off the other day, and my builds reduced from about 2 hours to 1h15m.* For reference, my ccache size is 8G, but only 1.8 G has been used. My hits at about 12,000 are about half of my misses. Cheers, Kevin * Both of those numbers are _very_ rough averages (created from memory of my "alias make='time make'" output), my builds compile in the background, at nice +19, on a puny dual-core 4G machine with a latent rotating HDD. The majority of my builds are "./g pull -r; make" used for testing. The less rough average is the "make distclean; ./g pull -r; make" workflow, which reduced a 3h30m compile to about 2h05m on the same hardware. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc
Wow, I really missed the 'big debate' :) Anyways, here are some things that went on my mind going through the list: - IIRC, some projects have build farms available... why is it we're not using theirs to supplement ours? I see here that GCC is willing to help any free software project: http://gcc.gnu.org/wiki/CompileFarm - Can we have distributed builds in non-Linux systems? If so, I think it wouldn't be so hard to make the tinderboxes help each other in building things - I agree that an email to 200 people is not super interesting. I think we should run git bisect to try building for every commit until we hit one that breaks, or build on each commit. However, that is not so great if we have commits for which the thing is fixed in the next commit. I am not expecting everyone to be comfortable with git rebase to the point of merging commits all the time. But if we put such a policy in place, it would help people learn very very fast :) - Can we have some intermediary branch then? Or some 'proofed' branch? If we build after each commit, the CI service can push that commit that is OK to the 'proofed' branch, and then only those commits would be tested with others. A failed commit would mean an email to the author and/or commiter. Only after the commit is fixed will it reach 'proofed'. And we could build nightly from 'proofed'. - I don't think we can expect developers to run a build before each push, especially not with all the debug options enabled and the like. This would massively slow them down IMHO. We have a relatively high rate of commits. It does happen from time to time that a commits comes in just after you do your ./g pull -r ; make. So you have to repeat the process, and that isn't so nice. Now, if I have to build something a gazillion times slower before I can push, will I _ever_ be able to push? I'm not asking rhetorically by the way. Just my 2 paise :) Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 10/07/2011 09:30 AM, Kevin Hunter wrote: > At 6:28am -0400 Thu, 06 Oct 2011, Norbert Thiebaud wrote: >> 2011/10/6 Norbert Thiebaud: >>> I'll give it a shot... >> >> Not that I expect it to make a big difference... since most of the >> compiles are ccached... > > As an nth data point on the matter, I've been using ccache for awhile, > and my builds take longer. Anecdotally (because I'm not focused on > ccache specifically), I turned it off the other day, and my builds > reduced from about 2 hours to 1h15m.* For reference, my ccache size is > 8G, but only 1.8 G has been used. My hits at about 12,000 are about > half of my misses. > > Cheers, > > Kevin > > * Both of those numbers are _very_ rough averages (created from memory > of my "alias make='time make'" output), my builds compile in the > background, at nice +19, on a puny dual-core 4G machine with a latent > rotating HDD. The majority of my builds are "./g pull -r; make" used > for testing. The less rough average is the "make distclean; ./g pull > -r; make" workflow, which reduced a 3h30m compile to about 2h05m on the > same hardware. > ___ > 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] RFC: Idea for fuzz-testing filters
Thanks for your feedback. I would really really like #1, but I'm not knowledgeable enough right now to do that. If (God willing), I'm starting that PhD soon, I might just be able to do that blindfolded a year from now :) For #2, I would like to have a tool generate the format handled by reading our source code. That would give something like 90% of the spec generated for us. Then we can fill in the blanks. I'm guessing I could do that in 2-3 more years of PhD than #1 ;) As for #3, I haven't had good experience with zzuf. I used the integrated option from CERT, only to have a few results in the log file and no fuzzed file to repeat the test with. I also used zzuf to generate test cases for the wmf filters, put the results in indeterminate, and then export the VALGRIND variable and run make -sr. Once that was done, I just had to read the report file for valgrind errors. Not automated, but 'good enough'. Problem is that it would saturate the disks pretty fast... so the end-result is that I was spending more time babysitting The Monster (the computer which was doing all those computations) than improving stuff. Not ideal. And I'm talking about >30 Gb disk space filled up! And my personal beef with zzuf is that the bytes are fuzzed randomly, which means that you never know if that length field at offset 0xABCDEF was even touched. Running the whole of LO on a test case is going to take an enormous amount of time. There is also the risk of having false positives for things that would be slow to open (you have to set a time out, after which it will kill the process). I think we could have some zzuf going, because the probabilistic thing could help find the kind of bugs that would be otherwise too expensive to find deterministically (100 Kb file means a lot of combinations). Maybe my suggestion could be used to generate a lot of seeds for zzuf. It would guarantee that the specific byte was tampered with... I'm not thrilled with the idea of so much process creation and overhead (think Valgrind) for running a somewhat short test over and over again. Marc-André Laverdière Software Security Scientist Innovation Labs, Tata Consultancy Services Hyderabad, India On 10/06/2011 12:01 PM, Huzaifa Sidhpurwala wrote: > On 10/05/2011 06:41 PM, Caolán McNamara wrote: >> caolanm->huzaifas: any advice ? > > Nice to see the work you have been doing here! > > To share some opinion about the my work which lead me to the discovery > of CVE-2011-2713. > > 1. There is no right or wrong approach here. A good approach would be > the one which covers all the possible code paths or maximum possible > ones in this case. > > 2. Ideally Peachfuzz or any other intelligent fuzzers (ones available > freely or custom ones) would be the best way to find flaws. But i will > have to agree with you, the specs are too big in this case and the time > taken to translate them into a fuzzer format is formidable. > > 3. I was pointed at [1] by Caolan. How do you run these files through > libreoffice after generating these test cases?. zzuf could actually > create the test cases, run libreoffice, destroy them and cycle through > this process as many times as you want. Saving on hard disk space? :) > > ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] libreoffice-3-4 Scottish Gaelic (gd) UI
Hi, Scottish Gaelic was added to Pootle not long ago, but the translator, Michael Bauer, have done a fantastic job and this language now is at 90% completition level. It may reach 100% soon. Michael Bauer asked, if we could include gd into LibreOffice 3.4.4. All it takes is add gd to solenv/inc/langlist.mk, because all other pieces are already in the source. Of course I need to add gd directory to the translations repo, but I don't want to attach that patch. :) Thanks, Andras 0001-add-Scottish-Gaelic-gd-UI-support.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about push access
Hi Ivan, Michael, On 2011-10-06 at 20:08 +0100, Michael Meeks wrote: > > 1. I've performed my first push today and received this message: > > Heh ;-) we get to add each committer to the commiters list manually - > that is something I ought to do I guess, but Thorsten tends to do idly > when the bounces happen. Based on this, I've changed the rule there so that any new committer should be allowed to post without need of further tweaking of the settings. > > 2. What changes should I avoid in my commits? I mean, what changes are > > unwanted, needless, etc. > > Clearly running indent gratuitously on the code, while it may improve > it, makes the diff very hard to read ;-) beyond that - code cleanup, > porting, easy hacks - anything non-controversial should go straight into > master. Anything you're not sure - just ask on the list :-) > > If you're hacking a module substantially, it makes sense to dung out > un-necessary cruft, vertical line wasteage, over-verbose comments that > reduce readability are all fair game I think. Also, don't be shy to push for other people that send patches to the mailing list! :-) It is trivial - when you see a patch on the mailing list that is correct, and you think it should go in, just save it (eg. as the_patch.patch), and do: # apply the patch (it applies including setting the right committer name # and the commit message) git am the_patch.patch # check that everything applied well git log -p # check that it builds / does the work # and finally git push # then send a reply to the mailing list that you pushed the patch; add # [PUSHED] to the subject of the mail And that's it :-) You need to do more when the patch sent to the mailing list is not produced using 'git format-patch' - in that case you have to set the committer name using --author switch of the git commit command. All the best, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Questions about push access
On 10/06/2011 08:22 PM, Ivan Timofeev wrote: 2. What changes should I avoid in my commits? I mean, what changes are unwanted, needless, etc. One thing to watch out for is to avoid pushing accidental merge commits. (It does happen, and is harmless, but also easily avoided.) That is, if you cannot push because someone else already pushed something newer, do a "git pull --rebase" before your next push attempt, so that your local changes are shuffled around to the branch head and git does not need to create a merge commit. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
