Re: [Libreoffice] RFC: Idea for fuzz-testing filters

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 o

Re: [Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc

> 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? Some of them are red for weeks. Is just bluntly reverting the right way to

[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just too much for gcc

I reverted c9f9b6723b40279716b1e34c1441a33e60cceb58. e36f591dfeb89fded172f4770157bc6cb6dc7454. because oox/source/drawingml/customshapepresets.cxx, a 4MB source, made gcc blow-up both on Mac and on Gentoo The compiler churned on it for 20 minutes or consumming huge amount of memory ( as in

Re: [Libreoffice] patch for scan-diialog

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+/

Re: [Libreoffice] build breaker 04688482241aa28b40f3ba911a4c9acab87b5d56

Noel, decided to plain revert the commit instead... so 5ab0fe797013bab66f5bbc30ec490da3bee662ce was not pushed. On Wed, Oct 5, 2011 at 5:30 PM, Norbert Thiebaud wrote: > 5ab0fe797013bab66f5bbc30ec490da3bee662ce is meant to fix > 04688482241aa28b40f3ba911a4c9acab87b5d56 > > aside for the missing i

[Libreoffice] build breaker 04688482241aa28b40f3ba911a4c9acab87b5d56

5ab0fe797013bab66f5bbc30ec490da3bee662ce is meant to fix 04688482241aa28b40f3ba911a4c9acab87b5d56 aside for the missing include and other joy. it was missing a define in offapi/.../form/FormComponentType.idl I added the needed constant, but Noel, can you please fill-up the comment for that consta

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Lubos Lunak wrote: > On Wednesday 05 of October 2011, Noel Grandin wrote: > > Yeah, the results are clunky. > > I think it might make sense to include the machine translated comments, but > mark them as such and still keep the original intact. > Which will clutter the code even more. What's the

[Libreoffice] [PATCH] filter: PDF Export UI "page range" autofocus

When the user selects "Pages" radio button in the Range section, it is very reasonable to expect that she would now want to specify the range. Thus moving the focus automatically to the page range edit box would save the user a mouse click.a Code is contributed under the LGPLv3+ / MPL. Signed-off

[Libreoffice] How to get my checkout in sink with OpenGrok?

I am working in master. I did ./g pull -r. But sw/source/core/inc/UndoTable.hxx:186 still has: SwUndoSaveSections * pDelSects; It should be as Opengrok says: boost :: scoped_ptr

Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes

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

[Libreoffice] patch for scan-diialog

Hi, 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. -- Greetings, Rob Snelders _

Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes

Dnia 2011-10-05, śro o godzinie 17:35 +0200, Lubos Lunak pisze: > On Wednesday 05 of October 2011, Jan Holesovsky wrote: > > Hi Maciej, > > > > On 2011-10-05 at 10:39 +0200, Maciej Rumianowski wrote: > > > There was a lot of WW8Bytes( SV_DECL_VARARR ) which was partly replaced > > > with ww::bytes.

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Hi, I had a quick look at the attachment and I fear that the comments that are really quick and easy to translate (like "siehe oben" -> "see above") are translated correctly by the software and those which make translating a pain are left as they are. At the moment I translate comments as I com

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

On the topic of machine translation of German comments in LibreOffice source code ... On Wed, 2011-10-05 at 17:25 +0200, Lubos Lunak wrote: > On Wednesday 05 of October 2011, Noel Grandin wrote: > > Yeah, the results are clunky. > > I think it might make sense to include the machine translated c

[Libreoffice] [PUSHED] Re: [PATCH] fix for bug fdo#41478: [UI] Add protect sheet command to sheet tab popup menu

Hi Olivier, On 2011-10-05 at 11:43 -0300, Olivier Hallot wrote: > The following patch fixes bug fdo#41478, enhancement to add the > command "Protect Sheet..." to the sheet context menu. Thank you a lot, pushed! :-) Regards, Kendy ___ LibreOffice mail

Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes

On Wednesday 05 of October 2011, Jan Holesovsky wrote: > Hi Maciej, > > On 2011-10-05 at 10:39 +0200, Maciej Rumianowski wrote: > > There was a lot of WW8Bytes( SV_DECL_VARARR ) which was partly replaced > > with ww::bytes. This set of patches totally migrates code to ww::bytes. > > Very nice, than

Re: [Libreoffice] whoops! [was: ODBC handles, a quibble]

Whoops. As soon as I saw this come back to me, I realized that I had written the exact opposite of the truth. On Wed, 2011-10-05 at 11:09 -0400, Terrence Enger wrote: > For comparison, I tried inserting a value with too much > precision into a TIMESTAMP(4) field in PostgreSQL. The > resul

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

On Wednesday 05 of October 2011, Noel Grandin wrote: > Hi > > Michael Meeks wrote: > > I suspect that some of the comments will not produce good results at all, > > and of course some of our comments are really rather bogus and > > un-necessary. Also - it may loose the distinction between carefully

Re: [Libreoffice] ODBC handles, a quibble

On Wed, 2011-10-05 at 13:31 +0100, Caolán McNamara wrote: > > I pushed my patch, mostly because its the simplest, and Lionel can > double-check it later at his leisure. I agree. > > > (*) Both patches discard milliseconds. I *guess* this is > > the right thing to do, but would welcome othe

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Hi Michael Meeks wrote: > I suspect that some of the comments will not produce good results at all, and > of course some of our comments are > really rather bogus and un-necessary. Also - it may loose the distinction > between carefully translated and cleaned up > files and those with machine tr

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

At 5:39am -0400 Wed, 05 Oct 2011, Stephan Bergmann wrote: Unfortunately, there's no good unit tests for this code. Blame it on me for taking the all too easy road out and committing the fix without doing the boring ^H^H^H joyful work of adding a test for it first. There's no blame,[1] only hope

Re: [Libreoffice] [PATCH] Replace WW8Bytes with ww::bytes

Hi Maciej, On 2011-10-05 at 10:39 +0200, Maciej Rumianowski wrote: > There was a lot of WW8Bytes( SV_DECL_VARARR ) which was partly replaced > with ww::bytes. This set of patches totally migrates code to ww::bytes. Very nice, thank you! :-) Before pushing, I wonder - ww::bytes is std::vector; i

[Libreoffice] [PATCH] fix for bug fdo#41478: [UI] Add protect sheet command to sheet tab popup menu

Hi The following patch fixes bug fdo#41478, enhancement to add the command "Protect Sheet..." to the sheet context menu. Kind regards -- Olivier Hallot Founder and Steering Commitee Member The Document Foundation From bb0a1760a07e6f79670fd0794e4fabca362e2008 Mon Sep 17 00:00:00 2001 From: Olivier

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Hi Noel, On Wed, 2011-10-05 at 15:12 +0200, Noel Grandin wrote: > I'm trying to write a machine translation program for the remaining > german comments in the source code (using google-translate to do the > heavy lifting). Well - it's an idea that has been raised before. > Is this accept

Re: [Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Hi, A few comments inline below. At 15:12 5-10-2011, Noel Grandin wrote: Hi I'm trying to write a machine translation program for the remaining german comments in the source code (using google-translate to do the heavy lifting). Is this acceptable? I'm not a german speaker, so I won't be a

[Libreoffice] [PUSHED] Re: [PATCH] simplify IsEmpty() logic in autodoc

Hi Kevin, On 2011-10-04 at 19:02 -0400, Kevin Hunter wrote: > A simple driveby patch that makes use of the standard library. Nice catch! :-) Pushed. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedeskt

[Libreoffice] [EASY HACKS] machine translation of remaining german comments acceptable?

Hi I'm trying to write a machine translation program for the remaining german comments in the source code (using google-translate to do the heavy lifting). Is this acceptable? I'm not a german speaker, so I won't be able to vet the resulting translation for accuracy, but I've done this before f

Re: [Libreoffice] RFC: Idea for fuzz-testing filters

On Wed, 2011-10-05 at 18:25 +0530, Marc-André Laverdière wrote: > Hi everyone, > > Before I start writing code, I wanted to get the input of more > experienced developers. > > Why bother about this? Why not use what's available out there? Well... > - Fuzzgrind isn't well documented and won't wor

[Libreoffice] [PUSHED][PATCH] Refactoring for WMF Loading

On Tue, 2011-10-04 at 14:04 +0530, Marc-André Laverdière wrote: > Based on Caolan's comments, here's another attempt at doing things right. > > I'm unable to test right now (some symlink problem)... please don't push > right away :) This looks right to me, pushed now, thanks for this. Only micro

[Libreoffice] RFC: Idea for fuzz-testing filters

Hi everyone, Before I start writing code, I wanted to get the input of more experienced developers. Why bother about this? Why not use what's available out there? Well... - Fuzzgrind isn't well documented and won't work out of the box, - zzuf has too many bells and whistles, and won't guarantee

Re: [Libreoffice] ODBC handles, a quibble

On Tue, 2011-10-04 at 12:27 -0400, Terrence Enger wrote: > (*) Caolán's patch fixes also > ODatabaseMetaDataResultSet::getTimestamp. (Hunh? > Why does the diff say that the changed line is in > ODatabaseMetaDataResultSet::getShort? ... > I still think the changed function is getTim

Re: [Libreoffice] OOo CWSes

On 05.10.2011 12:23, Michael Meeks wrote: > Hi Michael. > > On Tue, 2011-10-04 at 11:55 +0200, Michael Stahl wrote: >> is there a plan to integrate the outstanding OOo CWSes into LibO? > > We are considering how best to do this. >> - calc67 >> - calc68 > > As a general rule we're ve

Re: [Libreoffice] OOo CWSes

Hi Michael. On Tue, 2011-10-04 at 11:55 +0200, Michael Stahl wrote: > is there a plan to integrate the outstanding OOo CWSes into LibO? We are considering how best to do this. > over at ApacheOOo, the following CWSes with a 3.4 target have been > integrated on top of that: So -

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

On 10/05/2011 09:13 AM, Kevin Hunter wrote: At 2:58am -0400 Wed, 05 Oct 2011, Stephan Bergmann wrote: On 10/04/2011 11:01 PM, Kevin Hunter wrote: Here is a second patch that compiles, /should/ respond to what you just confirmed was the original intent, but is untested. (It was a random drive by

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

At 4:46am -0400 Wed, 05 Oct 2011, Michael Meeks wrote: On Wed, 2011-10-05 at 03:11 -0400, Kevin Hunter wrote: Heh, yeah, awhile ago. Had a whole discussion with the Meeks. :-) Goodness; yes - that thread is still on my festering and ever growing list of things to do ;-) If I remember you wan

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

Hi Kevin, On Wed, 2011-10-05 at 03:11 -0400, Kevin Hunter wrote: > > (I assume you already stated somewhere what license your > > contributions are under, even though that's not explicitly listed at .. > Heh, yeah, awhile ago. Had a whole discussion with the Meeks. :-) Goodness; yes - t

Re: [Libreoffice] gbuild hack

On Tue, 04 Oct 2011 19:52:31 +0200 Michael Stahl wrote: > it seems like you want $(gb_Helper_OUTDIRLIBDIR). ... which wasnt there yet when kendy first asked ;) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list

Re: [Libreoffice] Removal of rtl::O[U]String[Buffer]::operator sal_{char|Unicode} const *()

On 09/27/2011 09:00 PM, Stephan Bergmann wrote: Hi all, As has recently been discussed on #libreoffice-dev, its probably a good idea to remove the rather unhelpful conversion operators rtl::OString::operator sal_Char const * () rtl::OStringBuffer::operator sal_Char const * () rtl::OUString::ope

Re: [Libreoffice] libCMIS breakages ???

On Wed, 2011-10-05 at 06:58 +0200, Fridrich Strba wrote: > Hello, good people, > > I am just wondering why the libcmis module cannot for the time being be > using the "old" way of building as many of the C++ libraries in our tree > do. In any case, there is no solution for Windows yet with the > g

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

At 2:58am -0400 Wed, 05 Oct 2011, Stephan Bergmann wrote: On 10/04/2011 11:01 PM, Kevin Hunter wrote: Here is a second patch that compiles, /should/ respond to what you just confirmed was the original intent, but is untested. (It was a random drive by patching.) Specifically, I suppose it's obvi

Re: [Libreoffice] [PATCH] [PUSHED] .: stoc/source

At 2:58am -0400 Wed, 05 Oct 2011, Stephan Bergmann wrote: On 10/04/2011 11:01 PM, Kevin Hunter wrote: Here is a second patch that compiles, /should/ respond to what you just confirmed was the original intent, but is untested. (It was a random drive by patching.) Specifically, I suppose it's obvi