date:20110627

Hello,

2011/6/27 Markus Mohrhard markus.mohrh...@googlemail.com:
 Hello,

 this patch fixes the problem that we are unable to save a password protected
 file without a password. The problem is that we don't clear the old
 encryption data and copy them from the old ItemSet. We merge two ItemSets
 there, and the information about encryption should always come from the
 ItemSet filled during the file dialog.

 I think we should include this patch in the 3-4 branch. I think this patch
 only applies to 3-4 but not to master, so if this patch is accepted I'll
 write a second one for master and push it.


It's not clear to me why the functionality works in 3.3. Encryption
data is not cleared there, too.

Best regards,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] [PUSHED:master] Fix for Bug 37484 - On any animation change, current position in list is lost

2011-06-27 Thread Radek Doulík

Hi Luke,

thanks for the fix! Pushed.

Cheers
Radek

On Sun, 2011-06-26 at 22:23 +1200, Luke Symes wrote:
 Hi Radek,
 
 On Sat, Jun 25, 2011 at 3:47 AM, Radek Doulik r...@novell.com wrote:
 I run into a crash on startup in that part. I quickly fixed
 it, but it
 might be better if you check that it plays nicely with your
 new code. Or
 maybe make the ScrollToAbsPos not crash when called with
 unexpected
 values, -1 for example.
 
 
 Thanks for fixing this! You're right, I didn't test loading a blank
 presentation... Your quick fix fits well with the rest of the code;
 nFirstVis will never be -1 if there are entries in the
 CustomAnimationList. I was sad that ScrollToAbsPos failed; it turns
 out that it's due to there being no entries in the list (I had added a
 check for negative scroll position values which would try to go to
 scroll to the first entry). I have attached a patch for ScrollToAbsPos
 that will check if there are entries in the list first, and if not
 just return. Could you please review/commit this?
 
 
 Kind regards,
 
 
 Luke.

-- 
Radek Doulík r...@novell.com
Novell, Inc.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] A good Sunday to you all

Hi Drew,

On Sun, 2011-06-26 at 11:33 -0400, drew wrote:
 http://conference.libreoffice.org/submit-your-paper/

Thanks for your great work on this ;-) I'll add it to the next TSC
agenda, hopefully we'll get some real thinking on that Thursday ... :-)
Otherwise we're going to have lots of BoFs I think: I'd love to run a
where UNO fails flame-fest :-)

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [GSOC] Multiline inputbar

2011-06-27 Thread Anurag Jain

Hello Noel,

Here I got some chance to play with MS Excel 2010 and I analyzed the
behavior of inputbar. I'm sending an image here showing the desire
behavior.

The first figure in the image shows the normal behavior showing only a
single line and keep on wrapping the content text on overflows.This is
what has already been done in single line mode.

2: Second thing is to enable the button press. On button press as you
can see, only two lines are shown and scrollbar shifts its position
below the button (that is probably to make the UI consistent adjusting
the button and scrollbar in double the height of the line. This
actually does  not affect the text output area, just makes things
consistent).Scrollbar works same way scrolling single line at a
time.This can be said as multiline mode.

3: The third thing is to make the inputbar re-sizable on the mouse
drag. On hovering the down edge of the inputbar here the cursor
changes and can be dragged to show the hidden contents (this also
happens in units of single line height. Also here the scrollbar's
thumb size changes depending on the height of the inputbar.)

So if this is implemented in similar way it can be good UI enhancement
to LO. As of now I'm trying to set the position of the scrollbar and
button, making them appear at the right place i.e. after the inputbar.
Also as of now I do not have any idea about the implementing the
resizing of inputbar. As I've already sent the patch for fixing the
width, height and border of the InputBarGroup and after i get the
positions correctly we can start working on these improvements.

Thanks and regards

-- 
Anurag Jain
Final yr B.Tech CSE
SASTRA University
Thanjavur(T.N.)-613402
attachment: 1.JPG___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH][PUSHED] impress: after adding a new animation, scroll down to it in the list.

2011-06-27 Thread Radek Doulík

Hi Luke,

 @@ -542,6 +543,7 @@ void
 CustomAnimationList::select( CustomAnimationEffectPtr pEffect, bool
 bSelect
  {
  append( pEffect );
  select( pEffect );
 +MakeVisible( Last() );

we don't need to call it here ^^^, as select( pEffect ); on the previous
line recursively calls this function again and it is made visible from
the loop above already. So it should be enough to add it to the loop.

I have updated your patch and pushed it.

Cheers
Radek

  }
  }

On Sun, 2011-06-26 at 22:27 +1200, Luke Symes wrote:
 Hi Radek,
 
 On Sat, Jun 25, 2011 at 3:35 AM, Radek Doulik r...@novell.com wrote:
 
 At least I am not reaching the part you modified when adding
 custom
 animation thru custom animation pane (using the add button and
 custom
 animation dialog). If we move it to the loop, it will be
 reached always
 when selecting an entry - the select method is called
 recursively when
 adding new pEntry in:
 
if( !pEntry  bSelect )
{
append( pEffect );
select( pEffect );
}
 
 I wonder how do you reach that part of code?
 
 
 Hmm. I think the code is incorrect here. That last if statement should
 really only be used if the effect wasn't in the list  needs to be
 added. But when I added the MakeVisible in the if statement, it made
 new animations be scrolled to, and I was doing it via add-custom
 animation dialog too. What do you think of my attached patch? Once we
 have found the given entry, we should select it and then we are done,
 aren't we?
 
 
 Kind regards,
 
 
 Luke.

-- 
Radek Doulík r...@novell.com
Novell, Inc.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH][PUSHED] impress: after adding a new animation, scroll down to it in the list.

2011-06-27 Thread Luke Symes

2011/6/27 Radek Doulík r...@novell.com

 Hi Luke,

  @@ -542,6 +543,7 @@ void
  CustomAnimationList::select( CustomAnimationEffectPtr pEffect, bool
  bSelect
   {
   append( pEffect );
   select( pEffect );
  +MakeVisible( Last() );

 we don't need to call it here ^^^, as select( pEffect ); on the previous
 line recursively calls this function again and it is made visible from
 the loop above already. So it should be enough to add it to the loop.


Ah yes, of course!

I have updated your patch and pushed it.


Thanks very much :)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] WeLiket: Real-time Online With Your Friends

2011-06-27 Thread Select2gether

Hello,
The WeLiket toolbar is a revolutionary new way to discuss your favorite
items live and online with your friends. Get the free WeLiket toolbar now
and start chatting with your best friends in a Live Show Room today!

 
Kind regards, Select2gether
Give the people you care about gift of real-time social interaction. Share
the news about WeLiket with your friends and family now!
 
Email Preferences
If you wish to change your email address or unsubscribe from future email
advertisements from Select2gether.com, please update your email preferences.
We respect your privacy. For more information, please read Select2gether's
privacy policy.

inline: logo_mh.pnginline: weliket_download.jpginline: weliket_download_01.jpginline: bot-link-01a.pnginline: bot-link-02.png___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] external LinLibertineG not available


On Fri, 2011-06-24 at 17:48 +0200, Christian Lippka wrote:
 I'm doing a windows build, fetching
 
 881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip
 
 failed, looks like domain www.numbertext.org is expired.

Which makes me wonder: why are we not mirroring these ourselves ? I
feel slightly nervous about the build downloading files from here, there
 everywhere :-)

Thoughts ?

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] l10n process for help content (WAS: [PATCH] Update help fdo#31652)


On Sun, 2011-06-26 at 18:57 +0700, Korrawit Pruegsanusak wrote:
 On Fri, Jun 24, 2011 at 19:47, Caolán McNamara caol...@redhat.com wrote:
  Seems nuts to me that its better to keep translations of incorrect help
  content in sync than to have at least some of them right, but *shrug*,
  whatever's easiest to manage.
 
 Currently there are many help contents that obsolete or inaccurate.
 But wrt the string freeze, we couldn't release the fix of them
 (because they all must happen in master), and user have to wait for
 the next 3.x major release to have them correct, which is every
 too-long six months.

Right - that is a pain, we'd like the stable branch to improve wrt.
translations too - but of course we don't want un-translated English
texts showing up either.

I wonder if there is an analog of the patch situation, whereby we can
back-port a set of string translations to all languages from master ?

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] external LinLibertineG not available

2011-06-27 Thread Francois Tigeot

On Mon, Jun 27, 2011 at 10:26:30AM +0100, Michael Meeks wrote:
 
 On Fri, 2011-06-24 at 17:48 +0200, Christian Lippka wrote:
  I'm doing a windows build, fetching
  881af2b7dca9b8259abbca00bbbc004d-LinLibertineG-20110101.zip
  failed, looks like domain www.numbertext.org is expired.
 
   Which makes me wonder: why are we not mirroring these ourselves ? I
 feel slightly nervous about the build downloading files from here, there
  everywhere :-)
 
   Thoughts ?

Depends if it's part of LibreOffice or not.

IMHO, every part of LibreOffice needed to produce a release should be
available from a single source, managed by the Project's team itself.

For now, 3 separate URLs are needed to produce packages with the options I
have choosen :

http://download.documentfoundation.org/libreoffice/src/
http://download.go-oo.org/src/
http://www.numbertext.org/linux/

The files under go-oo.org and numbertext.org should also be available from
download.documentfoundation.org.

-- 
Francois Tigeot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] l10n process for help content (WAS: [PATCH] Update help fdo#31652)

2011/6/27 Michael Meeks michael.me...@novell.com:

 On Sun, 2011-06-26 at 18:57 +0700, Korrawit Pruegsanusak wrote:
 On Fri, Jun 24, 2011 at 19:47, Caolán McNamara caol...@redhat.com wrote:
  Seems nuts to me that its better to keep translations of incorrect help
  content in sync than to have at least some of them right, but *shrug*,
  whatever's easiest to manage.

 Currently there are many help contents that obsolete or inaccurate.
 But wrt the string freeze, we couldn't release the fix of them
 (because they all must happen in master), and user have to wait for
 the next 3.x major release to have them correct, which is every
 too-long six months.

        Right - that is a pain, we'd like the stable branch to improve wrt.
 translations too - but of course we don't want un-translated English
 texts showing up either.

        I wonder if there is an analog of the patch situation, whereby we can
 back-port a set of string translations to all languages from master ?

The master copy of translations is with each l10n team and is not in
git or Pootle. That means we can back-port or fix anything in git or
Pootle, but translators can overwrite it with an older copy. So the
real challenge it to have something fixed at the translators' master
copy, which could be in Pootle, or a in a custom l10n system, or in
files on translator's hard disk etc.

Cheers,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...

Hi Cor,

On Sat, 2011-06-25 at 23:52 +0200, Cor Nouws wrote:
 And indeed, I see no reason why that would be a natural thing happening. 
 If there is a moment that we know: QA on this build is important, do 
 this ... that will help focussing :-)

So :-) now is this moment. It is important to have QA guys running the
daily builds for their day-to-day work / use-cases :-) I think this is
the basic problem, a lack of communication around what is good to be
testing, and a lack of willingness to test 'master' ( because it is too
buggy ;-) combined with a hope that master gets less buggy as/when we
release it.

Anyhow - there are various psychological ways we can approach this, by
having a different timetable for the QA team, that has a label marked
feature freeze (ONO) - whatever it is that triggers you guys starting
to do the QA, at a given date, and then the coder's feature freeze a bit
later ;-) We can put the prefixes 'soft' and 'hard' on this to make it a
bit clearer even if we want.

Anyhow - I assume you didn't submit the talk, since Drew was pointing
out the lack of papers, so I've just done that ;-)

[snip]
Title: Improving the Development / QA cycle

Short Summary:
A panel discussing how to better integrate the QA / Development cycle,
timelines, freezes and all

Abstract:
Many proposals to improve quality of the product have been made, some of
these revolve around scheduling and timing. Come hear a discussion about
our current release process, how it works what 'time based' really
means, and the impact that needs to have on our process. And hear about
what can be done to improve it from various perspectives.

I'd like to have: Cor Nouws, Rainer, Caolan, myself, Norbert, Petr
Mladek, and a few more QA'ish types of our selection :-)
[/snip]

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] fix broken image paths in help fdo#37509

Hi,

Can someone please push this to 3-4. I pushed a slightly different
version to master (image paths were changes in master).

Thanks,
Andras


0001-fix-broken-image-paths-in-help-fdo-37509.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...

2011-06-27 Thread Petr Mladek

Cor Nouws píše v Pá 24. 06. 2011 v 08:43 +0200:
 plino wrote (24-06-11 02:03)
  BTW since only Betas can be installed in parallel with the stable build
  under Windows and that was not added to the 3.4.x branch (at least from my
  understanding) I guess Windows Beta testers will have to wait for 3.5.x,
  right?
 
 Well, I don't see any betas coming for the 3.4.x branch, so whether is 
 has been added or not, does not make sense.
 I only can point to my favourite page: 
 http://wiki.documentfoundation.org/Installing_in_parallel

It is well recommended to use daily builds from
http://dev-builds.libreoffice.org/daily/. They include the very last
fixes and can be installed in parallel with the announced builds.

Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSOC][PATCH] Multiline inputbar

2011-06-27 Thread Noel Power


Hi Anurag
On 26/06/11 18:23, Anurag Jain wrote:

Hello Noel,

On Fri, Jun 24, 2011 at 7:53 PM, Noel Powernopo...@novell.com  wrote:

[...]

I'm sending the fix patch here which calculates the height and width
of the ScInputbarGroup and makes the border invisible.

great, thanks for that, more comments about the patch below

There is no class named as ScTextWindow

forgive my typo, I meant ScTextWn

I suggest this because it is intended when the gsoc code is initially
integrated that it be configurable and for this reason it probably makes
sense to preserve the original ScTextWindow class and distinguish it from
your new implementation. This will make maintenance easier.

So I guess there should not be any problem with the maintenance of
code as I've not renamed any pre existing class and just inserted a
new class i.e ScInputBarGroup.
well, true you have created a new class but additionally you have 
modified the existing class ScTextWnd, I suspect you will need to modify 
that class even more which is why I suggest that you rename the current 
version of ScTextWnd ( e.g. the one with your modifications ) to 
ScSomeNewName and restore the old ScTextWnd class. That way the old 
class is available to swap in at runtime and all ( or nearly all ) your 
modifications are in new classes.

Then next thing to concentrate on is getting the multi-line textbox
functionality to work and to make that behaviour switchable. I believe Kohei
suggested adding a button to the ScInputBarGroup window. So, you need to be
able to detect the button click and switch the state of the bIsMultiLine
flag that you have already added ( presumably for this purpose ) please do a
grep for PushButton  SetClickHdl in sc for sample code for handling the
button.

Next hurdle which I'm trying to get through is getting the Scrollbar
and Button at the right position after the Textbar ends. Does the
function SetPosSizePixel() or SetPosPixel() in window.hxx can be used
for getting them at the desired position.
yes, you will need to set the position of the controls within the window 
manually by the methods you mention

  Or is there any other more
modular way to decide the ordering of these items similar to
InsertWindow() and InsetItem() methods used in ScInputWindow ?
I don't think so, afaik the methods you mention are specific to a 
toolbar which has it's own custom layouting

When you get a button click you will need to resize your InputBarGroupbox
window based on the new state of the bIsMultiLine flag and of course
increase the height in multiples of the calculated height of a single line.
e.g. in Multiline mode the ScInputGroupBox height should be some multiple of
the calculated singleline height ( maybe 10 as a default ? ) Of course the
size of the ScMultiLineTxtWin (let's call it that for now but please rename
it as you wish ) window needs to also be adjusted and everything resized. I
would do this first before worrying about scrollbar behaviour.


yes as soon as I get things placed in right place I'll be working on
switching from single line to multiline mode on the button click.
please just implement the button and the multiline mode switching for 
the moment, adding the scrollbar to the mix adds more complexity and I 
would prefer to get the core functionality working first. Then you can 
build on that existing functionality to add more 'features'. Of course 
if you get the button and multiline-mode switching working then by all 
means start looking at the scrollbar part.


now, about the patch...

a) so, like mentioned above probably better to not enable those 
scrollbar drawing bits for the moment
b) Toolbox::Resize(), in line with the comments above about minimizing 
changes to the existing codebase by the multimode changes I'd prefer if 
the ScInputBarGroup class would take care of it's own resize. Currently 
how it's done doesn't make a whole lot of sense e.g. Toolbox::Resize 
manually calculates the size of the ScInputBarGroup, sets it's size then 
calls ScInputBarGroup::Resize, that just doesn't feel right. I think 
ScInputBarGroup::Resize should just calculate it's size ( taking 
whatever values from the parent window as needed )
c) at the moment ScInputBarGroup::Resize() is setting the aTextWindow's 
height to 22, I don't think the size of aTextWindow's height should be 
hardcoded to a number, looking in the code for ScTextWnd ( or whatever 
you rename it to be ) it already calculates the height ( single line 
height I guess ) I think it would make sense add a method to 
ScTextWndRenamedToSomething like 'GetSingleLineHeight' and then resize 
the ScInputBarGroup  ScTextWndRenamedToSomething  based on the number 
of lines you want to display, e.g. 1 * 
ScTextWndRenamedToSomething.GetHeight() for single line mode, and 'N' * 
ScTextWndRenamedToSomething.GetHeight() for multiline mode.


hope that makes sense :-)

Noel

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

[Libreoffice] opengrok - all code

Hi Cedric,

Can you please remove translations module from the all code
shourcut? I have to click that 50 times a day. :)

Many thanks,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging


On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote:
  I submitted the patch to the bug-make mailing list
 
 Note that, even if the patch is accepted by upstream, based on their
 recent 'schedule', It won't probably be available in a 'realeased'
 version until 2014 or something... so don't hold your breath.

You know; the temptation to check-in and build our own gnumake is
growing on me ;-) you know you want to (TM) ... IMHO there are a few
nonsensical things that are done of utter pointlessness in there.

It takes me only ~10 seconds to compile (and the same to configure
(urk)) gnumake.

My current incremental, no-op tail_build takes:

real0m18.519s
user0m17.679s
sys 0m0.769s

Which seems too slow (and it's set to get worse) - 500ms or more of
that seems to be in verify_file_database() eg. which just wanders around
banging on the L2 cache checking strings are still strings to no useful
purpose ;-) but no doubt there is a lot more that we can do to get this
improved.

ATB,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSOC] Multiline inputbar

2011-06-27 Thread Noel Power


On 27/06/11 09:24, Anurag Jain wrote:

Hello Noel,

Here I got some chance to play with MS Excel 2010 and I analyzed the
behavior of inputbar. I'm sending an image here showing the desire
behavior.

The first figure in the image shows the normal behavior showing only a
single line and keep on wrapping the content text on overflows.This is
what has already been done in single line mode.

2: Second thing is to enable the button press. On button press as you
can see, only two lines are shown and scrollbar shifts its position
below the button (that is probably to make the UI consistent adjusting
the button and scrollbar in double the height of the line. This
actually does  not affect the text output area, just makes things
consistent).Scrollbar works same way scrolling single line at a
time.This can be said as multiline mode.

3: The third thing is to make the inputbar re-sizable on the mouse
drag. On hovering the down edge of the inputbar here the cursor
changes and can be dragged to show the hidden contents (this also
happens in units of single line height. Also here the scrollbar's
thumb size changes depending on the height of the inputbar.)

So if this is implemented in similar way it can be good UI enhancement
to LO. As of now I'm trying to set the position of the scrollbar and
button, making them appear at the right place i.e. after the inputbar.
Also as of now I do not have any idea about the implementing the
resizing of inputbar. As I've already sent the patch for fixing the
width, height and border of the InputBarGroup and after i get the
positions correctly we can start working on these improvements.


so I would not get overly hung up by this, we don't have to have exactly 
the same arrangement, I think a workable and useful first cut is as 
Kohei and I mentioned already


1st pass

- single line mode ( you have this already ) but you need to add a new 
button for switching the mode ( don't even worry about a scrollbar )
- multi-line mode, same as above but give a 'bigger' input area, maybe 
5+ lines ( for the first pass I wouldn't even care about a scrollbar too 
much, just get it switching nicely, button placed properly etc.


2nd pass

- single line mode as above
- multi-line mode as above but with the scrollbar placed underneath the 
button


after you get the above working then you could try and make it a bit 
sexier with adding the scrollbar in single line mode and some of the 
other behaviour


thanks

Noel

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSOC] Multiline inputbar

2011-06-27 Thread Noel Power


On 27/06/11 12:14, Noel Power wrote:
so I would not get overly hung up by this, we don't have to have 
exactly the same arrangement, I think a workable and useful first cut 
is as Kohei and I mentioned already
oh and before I forget, I wouldn't even think about resizing by dragging 
with the mouse at least right now

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [GSoC] library merging

Hi Matus,

On Sat, 2011-06-25 at 16:21 +0200, Matúš Kukan wrote:
Well, that seems to be true. I haven't look at all yet. There is about
240 of them.

Heh :-) hopefully a ./g grep -6 component_getImple # will show you most
of them rather quickly.

But sometimes there also exist things like in:
http://opengrok.libreoffice.org/xref/components/extensions/source/preload/services.cxx#59
That doesn't seem interesting to me, but I don't know, maybe it
actually does something relevant.

Ooh - you discovered some more junk code - nice. It would be wonderful
if you could hunt down and kill any uses of this 'preload' code - we
don't do OEM preloads, similarly we don't have product registration
either so killing both of these components and their related scp2/ would
be nice:

STD_LIB_FILE( gid_File_Lib_Preload, preload)
SPECIAL_COMPONENT_LIB_FILE( gid_File_Lib_Productregistration,
productregistration.uno )

would help to shrink the codebase, distributed binary size and compile
time.

And default is: throw loader::CannotActivateFactoryException.
There always has to be some function.

Ok - but lets just not require this. AFAICS there is no good reason not
to default to the C++ / current-language-binding-name for that.

So, if CPPU_CURRENT_LANGUAGE_BINDING_NAME can be also defined in
shlib, we could use that directly to set the variable.

Right, it should be:

cppu/inc/uno/lbnames.h:#define CPPU_CURRENT_LANGUAGE_BINDING_NAME
CPPU_STRINGIFY( CPPU_ENV )

I may be missing something but if not I'd just remove
component_getImplementationEnvironment if it is not doing something
special and set the variable directly in shlib.

I don't think you're missing anything :-) Also I've never seen this
'getImplementationEnvironmentExt' method used - and it is another pretty
pointless (slowish) dlsym lookup on activating a component - it seems to
be the case that this is to allow people to have a different language
for several components they might export.

For 4.0 I think we want a single entry point, and if we want this
goodness, surely we can add it to the XML annotation more cleanly, I've
added it to the wiki page to track.

Thanks,

Michael.

--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

2011-06-27 Thread Bjoern Michaelsen

Hi Michael, all,

On Mon, 27 Jun 2011 12:03:16 +0100
Michael Meeks michael.me...@novell.com wrote:

   It takes me only ~10 seconds to compile (and the same to
 configure (urk)) gnumake.
 
   My current incremental, no-op tail_build takes:
 
 real  0m18.519s
 user  0m17.679s
 sys   0m0.769s
 
   Which seems too slow (and it's set to get worse) - 500ms or
 more of that seems to be in verify_file_database() eg. which just
 wanders around banging on the L2 cache checking strings are still
 strings to no useful purpose ;-) but no doubt there is a lot more
 that we can do to get this improved.

Waiting for a 2014 release is cleary not nice. IMHO we should still get
our stuff upstream, because diverting from upstream might create new
interesting problems. So my proposal would be:
 - upstream patches
 - get them through some basic review upstream
 - add them to our patched version when reviewed upstream

This way our patched version will:
 - not featurecreep away from upstream
 - get reviews by upstream
 - essentially be a prerelease of an upcoming make version
 - allow distros to still build with their default make by
   backporting the same patches that we do

@Michael: Did you try it again with make -sr gb_CHECKOBJECTOWNER=
because the checks for duplicate objects create some huge strings(*).

Best,

Bjoern

(*)
http://nabble.documentfoundation.org/gbuild-use-gb-CHECKOBJECTOWNER-to-check-for-double-linked-objects-td2827818.html


   ATB,
 
   Michael.
 
-- 
https://launchpad.net/~bjoern-michaelsen
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

2011-06-27 Thread Christian Lohmaier

Hi Michael, *,

On Mon, Jun 27, 2011 at 1:03 PM, Michael Meeks michael.me...@novell.com wrote:
 [...]
        You know; the temptation to check-in and build our own gnumake is
 growing on me ;-)

:-) I wouldn't object to this - as gnumake =3.81 is a requirement
that has to be manually installed on Mac OSX 10.4/PPC, (as XCode 2.x
only comes with make 3.80)

 you know you want to (TM) ... IMHO there are a few
 nonsensical things that are done of utter pointlessness in there.

Getting rid of those will be an additional benefit.

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging


I'll add the internal gmake suggestion as a TSC topic for Thursday;
personally I'd love to have a nice, faster, internal, GPL licensed build
tool in our tree ;-)

On Mon, 2011-06-27 at 13:24 +0200, Bjoern Michaelsen wrote:
 @Michael: Did you try it again with make -sr gb_CHECKOBJECTOWNER=
 because the checks for duplicate objects create some huge strings(*).

nice - that is better:

real0m12.445s
user0m11.611s
sys 0m0.771s

vs.

real0m18.068s
user0m17.193s
sys 0m0.805s

without it; so ~6 secs difference; I wonder if tail-build should
perhaps turn that off, leaving it for developers to see when they
re-build just their piece [ inconsistent I know but ... ;-].

Thanks,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] fdo#38457: Crash in DataPilot on moving the fields

2011-06-27 Thread Katarina Machalkova

Ladies  gents, 

attached patch (somehow) fixes the crash in Calc's DataPilot caused by field 
indexes being off-by-N. Consequent attempt to move such fields leads to 
segfault.

It is regression from 3.3, the orig code was as follows:

SCCOL nColAdd = 0;
if ( bForFile )
{
// in old file format, columns are within document, not within source 
range

DBG_ASSERT( pSheetDesc, FillOldParam: bForFile, !pSheetDesc );
nColAdd = pSheetDesc-aSourceRange.aStart.Col();
}

where 'if' branch has been unused since 2004 at least, as 'bForFile' variable 
has been always set to false elsewhere in the code.

Later, it has been changed into this: 

SCCOL nColAdd = pSheetDesc-GetSourceRange().aStart.Col();

apparently to fix a build failure (commit 523a8f41388f6d). But this seems to 
produce wrong results -- shifts column index of DP field by N and attempt to 
move such field crashes the whole thing. 

From the comment in the 3.3 code (mentioning old file format) I guess we can 
assume column offset always set to 0 i.e. no column offset at all. But not 
really sure about that, this is Yoshida-san's baby.  

Consequently, some further code cleanup could be needed (i.e. nCollAdd param 
can be completely removed from lcl_FillOldFields() ), but that's more a 
material for master branch

hB.
-- 
  \  Katarina Machalkova
  \\\__o  LibO developer
__\\\'/_   hedgehog painter
From 19dada4d1cf45b1042788cd6ec3c7ea56c45e3a6 Mon Sep 17 00:00:00 2001
From: Katarina Machalkova kmachalk...@suse.cz
Date: Mon, 27 Jun 2011 13:35:01 +0200
Subject: [PATCH] fdo#38456: Always set column offset to 0

Setting it to anything else moves field indexes off-by-N and causes crash
in some cases (the original code has been unused since 2004 at least)
---
 sc/source/core/data/dpobject.cxx |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/sc/source/core/data/dpobject.cxx b/sc/source/core/data/dpobject.cxx
index 472c451..93bfebb 100644
--- a/sc/source/core/data/dpobject.cxx
+++ b/sc/source/core/data/dpobject.cxx
@@ -1860,9 +1860,6 @@ sal_Bool ScDPObject::FillOldParam(ScPivotParam rParam) const
 // ppLabelArr / nLabels is not changed
 
 SCCOL nSrcColOffset = 0;
-if (IsSheetData())
-// source data column offset is only for internal sheet source.
-nSrcColOffset = pSheetDesc-GetSourceRange().aStart.Col();
 
 bool bAddData = ( lcl_GetDataGetOrientation( xSource ) == sheet::DataPilotFieldOrientation_HIDDEN );
 lcl_FillOldFields(
-- 
1.7.3.4



signature.asc
Description: This is a digitally signed message part.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] fix broken image paths in help fdo#37509

2011/6/27 Andras Timar tima...@gmail.com:
 Can someone please push this to 3-4. I pushed a slightly different
 version to master (image paths were changes in master).

two more paches of the same type:
http://cgit.freedesktop.org/libreoffice/help/commit/?id=ac114c54e5aa5c487070efe88dc3334503a81c95
http://cgit.freedesktop.org/libreoffice/help/commit/?id=5a6bf68cdeac23f873fa58246c42d426d3b552ff

Thanks,
Andras
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Blockers for 3.4.1 release - central bug ID ?

2011-06-27 Thread Petr Mladek

Alexander Thurgood píše v Pá 24. 06. 2011 v 11:54 +0200:
 Hi,
 
 I might have missed it, but do we have a bug ID for blockers for the
 3.4.1 release ? 

Blockers has to be linked to the meta bug for most annoying bugs
(fdo#35673) and set the severity Blocker, see
http://wiki.documentfoundation.org/Release_Criteria#Blocker_Bug_Nomination



Best Regards,
Petr

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

On Mon, Jun 27, 2011 at 6:03 AM, Michael Meeks michael.me...@novell.com wrote:

 On Sat, 2011-06-25 at 15:44 -0500, Norbert Thiebaud wrote:
  I submitted the patch to the bug-make mailing list

        You know; the temptation to check-in and build our own gnumake is
 growing on me ;-) you know you want to (TM) ... IMHO there are a few
 nonsensical things that are done of utter pointlessness in there.

I wouldn't mind so long as we keep that in dev-tools and don't mess
with the main repos.
iow: we build by default with the 'standard' make, but direct dev that
are interested to dev-tools to get a better 'make'.



Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] opengrok - all code

2011-06-27 Thread Korrawit Pruegsanusak

Hello all,

On Mon, Jun 27, 2011 at 18:02, Andras Timar tima...@gmail.com wrote:
 Can you please remove translations module from the all code
 shourcut? I have to click that 50 times a day. :)
And maybe add testing into all code as well?

Best Regards,
-- 
Korrawit Pruegsanusak
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...

2011-06-27 Thread plino


Petr Mladek wrote:
 
 It is well recommended to use daily builds from
 http://dev-builds.libreoffice.org/daily/. They include the very last
 fixes and can be installed in parallel with the announced builds.
 

That may be true for other OSes but not for Windows. Once LO gets to 3.5.x
that will (hopefully) be a correct statement.

You can in fact install 3.4.x in such a way that it doesn't uninstall or
overwrite the stable build. But it is a hack. Not a proper install.

Interestingly I have mentioned in another (ignored) topic that the Windows
daily builds are based on code previous to the pre-releases (pre release is
on 3.4.1rc3, daily builds are based on 3.4.1rc1)

After a quick check, it seems that ALL daily builds for all OSes are based
on 3.4.1rc1... I must be missing the logic here...

--
View this message in context: 
http://nabble.documentfoundation.org/minutes-of-tech-steering-call-tp3100951p3113845.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Re; windows daily builds availability

On Mon, 2011-06-27 at 07:19 -0700, plino wrote:
 Petr Mladek wrote:
  
  It is well recommended to use daily builds from
  http://dev-builds.libreoffice.org/daily/. They include the very last
  fixes and can be installed in parallel with the announced builds.
  
 
 That may be true for other OSes but not for Windows. Once LO gets to 3.5.x
 that will (hopefully) be a correct statement.

Yes, we need to get windows and mac master daily builds especially.
There's only two tinderboxes listed at
http://tinderbox.libreoffice.org/MASTER/status.html and I think they've
been turned over to 3.4.X series.

Given that the windows ones are a bottleneck, this is something where
people with spare windows boxes can help out right now, e.g. see
http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2011-02.html#2011-02-18T21_38_49.htm
about how to set them up.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG

On Fri, 2011-06-24 at 20:02 +0200, Julien Nabet wrote:
 But when i use  the test file, nothing as you can see below :
 
 $ g++ -D_GLIBCXX_DEBUG attachment.cxx
 $ echo hello world | ./a.out
 Line is: hello world

Hmm, hard to track down a reproducible test-case then. Anything in 
echo hello world | valgrind ./a.out ?
And was this with a system cppunit or the built-in one ?

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] can no longer encrypt files if build with --disable-mozilla

On Sun, 2011-06-26 at 20:26 +0200, Markus Mohrhard wrote:
 Hello,
 
 is it in our intention that we can no longer encrypt files if we build
 with --disable-mozilla? It seems that this was introduced through our
 latest merge from OOo. It seems that we need SHA-1 and SHA256 since
 the latest merge. SHA-1 still works but for SHA-256 we rely on NSS
 which is disabled if we build with --disable-mozilla.

This looks wrong to me, --disable-mozilla should only disable the moz
build, not nss.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED] Re: [PATCH] fix broken image paths in help fdo#37509

On Mon, 2011-06-27 at 12:51 +0200, Andras Timar wrote:
 Hi,
 
 Can someone please push this to 3-4.

Looks sane to me, pushed.

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX

Hi *,

Downloaded daily build from yesterday for Mac :

MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21

Installed, started.

There is no Python script menu entry in the Tools  Macros  Organise UI
menu, only Basic, Javascript and Beanshell.

They are present in the app bundle in :
 /Applications/LibO-dev.app/Contents/basis-link/share/Scripts

Alex

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED][PATCH] fix broken image paths in help fdo#37509

On Mon, 2011-06-27 at 14:54 +0200, Andras Timar wrote:
 2011/6/27 Andras Timar tima...@gmail.com:
  Can someone please push this to 3-4. I pushed a slightly different
  version to master (image paths were changes in master).
 
 two more paches of the same type:
 http://cgit.freedesktop.org/libreoffice/help/commit/?id=ac114c54e5aa5c487070efe88dc3334503a81c95
 http://cgit.freedesktop.org/libreoffice/help/commit/?id=5a6bf68cdeac23f873fa58246c42d426d3b552ff

Also pushed to 3-4

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX

2011-06-27 Thread Christian Lohmaier

Hi Alexander,

On Mon, Jun 27, 2011 at 5:14 PM, Alexander Thurgood
alex.thurg...@gmail.com wrote:

 Downloaded daily build from yesterday for Mac :

 MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21

Does that build include the python-scripting-provider extension?

If not, then it's a build-configuration problem

(Tools|Extension Manager)

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] minutes of tech steering call ...

Hi there,

On Mon, 2011-06-27 at 07:19 -0700, plino wrote:
 That may be true for other OSes but not for Windows. Once LO gets to 3.5.x
 that will (hopefully) be a correct statement.

Oh - well - since master is going to turn into 3.5, if that is not
parallel installing, then we have a problem - is it the case that the
3.5 (master) snapshots - whatever we call them version-wise [ what do we
do there ? ] do not parallel install on windows still ?

It also seems, that we don't in fact have windows or linux daily /
release snapshots of master either - which is not a happy place to be;
any thoughts on that Fridrich ?

Good feedback plino ! :-)

Thanks,

Michael.

-- 
 michael.me...@novell.com  , Pseudo Engineer, itinerant idiot


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw protected file without pw

2011-06-27 Thread Dennis E. Hamilton

The Change Password feature is not present in LibreOffice 3.3.2.  It does 
appear in some sort of partially-implemented form in LibreOffice 3.4.

I suspect that there may be interference of that feature with 
encryption-password handling.

 - Dennis

ESSAY ON ENCRYPTION VERSUS LOCKING AND HOW DIFFERENT THEIR PASSWORDS ARE

We need to remember that password use for encryption (i.e., Save As ... dialog 
Save with password check box) is very different from a password used for 
locking things in the document.  

Lock passwords are inherently insecure, since the hash is recorded in the 
document.  So it is really not doing much harm to cache them, although they are 
a potential security exposure too.  (I can understand why one might create and 
hold onto multiple hashes for a lock when it is not known which hash will be 
required by a format the document might be saved in and also while the user may 
still be fiddling with lock settings.)

ENCRYPTION PASSWORDS DO NOT NEED A CACHE

Encryption passwords should not be retained very long, and there is only one 
hash needed for an encryption password.  Since it is known at the time the Save 
As ... is being done which initial-password hash algorithm will be used, this 
is when the password should be requested.  As soon as all the key generations 
have been done and the file saved in encrypted form, that hash should 
disappear.  There is no meaningful further use for it and it is a critical 
secret.  Knowledge of that hash is enough for an attacker to be able to decrypt 
the document.  Any memory residue of the original password and the hash used 
for encryption key generation must be obliterated as soon as possible for each 
of them.

Even if there is a future provision for ODF 1.x encryption following signing 
(i.e., on an already-saved document), the password should not be requested 
until the encryption process is prepared to commence.  So again, there is need 
to produce only the one initial password hash, depending on what the 
implementation of password-based key derivation requires, and that hash should 
disappear from memory (ideally, the stack or a randomized local heap 
allocation) as soon as the encryption completes.

For decryption, the need for a password or its hash is likewise of short 
duration.  Fitting the decryption password-hash into some common hash cache is 
not only unnecessary, it risks disclosure.  Furthermore, on the off chance that 
a user uses the same password for encryption and for locking, there is an 
exposure to having a lingering cache even for locking, though if a machine is 
compromised the cache is the least of our worries.  

(Lock hashes are inaccessible in an encrypted document, but unencrypted 
documents from the same party definitely provide a source of hashes that one 
would try first in an attack on an encrypted document.)

THIS MAY BE AN INTERFERENCE WITH CHANGES FOR LOCKING

The partially implemented change password button on the LibreOffice 3.4 
Document Properties | General tab, if related to encryption, doesn't make any 
sense to me.  If it is related to document protection (not encryption) it is in 
the wrong place.

CALLING THE WRONG THINGS SECURITY IS NOTHING BUT TROUBLE  

Calling protection a security feature is also problematic since locking a 
document against writing or making untracked changes is not a security feature. 
 Protection (not encryption) in all forms is trivially subverted unless the 
document is signed, and that's an authenticity feature, not a security feature.

If we are so confused about what is security and what is not, how are we 
helping users adopt safe practices and to, possibly, comprehend what is unsafe 
about actions they find convenient.  I am thinking about the tendency to use 
the same memorable password for something as trivial as a lock and as important 
as an encryption password or for something even more valuable.

I have a utility on my computer that will crack SHA1 hashes of not too long, 
memorable passwords in mere seconds using a well-crafted brute-force attack and 
the high-end GPU of my video card.  Putting password hashes where they can be 
retrieved and attacked is an arms race we cannot win by simply choosing more 
complex hash algorithms and allowing users to believe their lives have been 
made more secure.

 - Dennis

-Original Message-
From: libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org 
[mailto:libreoffice-bounces+dennis.hamilton=acm@lists.freedesktop.org] On 
Behalf Of Markus Mohrhard
Sent: Monday, June 27, 2011 01:40
To: Andras Timar
Cc: libreoffice-dev
Subject: Re: [Libreoffice] [REVIEW] patch for fdo#38561: can't save pw 
protected file without pw

Hello Andras,




It's not clear to me why the functionality works in 3.3. Encryption
data is not cleared there, too.




I only had a closer look at the xls export and we didn't use the EncryptionData 
in the export there, at least not to detect if the

[Libreoffice] Extension manager does not start when dragging extensions from Finder onto main app window - build 350m1 from master nightly 27/06/2011 for Mac OSX

So testing, testing, 1..2..3... ;-)

In 3.3.x and 3.4.x you can drag and drop extensions from the Mac OSX
Finder onto the LibreOffice main application window and it will launch
the Extensions Manager.

This no longer works in the nightly build from yesterday.

Alex

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Extension manager does not start when dragging extensions from Finder onto main app window - build 350m1 from master nightly 27/06/2011 for Mac OSX

Le 27/06/11 18:27, Alexander Thurgood a écrit :

Drag and drop also works if the extension is dropped onto the App icon
in the Dock. This then launches the Extension Manager and proposes
installation of the extension.

Alex

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Re; windows daily builds availability

On Mon, Jun 27, 2011 at 9:35 AM, Caolán McNamara caol...@redhat.com wrote:
 On Mon, 2011-06-27 at 07:19 -0700, plino wrote:
 Petr Mladek wrote:
 
  It is well recommended to use daily builds from
  http://dev-builds.libreoffice.org/daily/. They include the very last
  fixes and can be installed in parallel with the announced builds.
 

 That may be true for other OSes but not for Windows. Once LO gets to 3.5.x
 that will (hopefully) be a correct statement.

 Yes, we need to get windows and mac master daily builds especially.
 There's only two tinderboxes listed at
 http://tinderbox.libreoffice.org/MASTER/status.html and I think they've
 been turned over to 3.4.X series.

My mac one push dailies, and it is based on 'master'

http://dev-builds.libreoffice.org/daily/MacOSX_10.6.7_Intel_no-moz/master/2011-06-27_08.26.21/

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

2011-06-27 Thread Tor Lillqvist

 You know; the temptation to check-in and build our own gnumake is growing on 
 me ;-)

If we do that, we definitely should then also add built-in mkdir and cp 
commands in it, for the benefit of especially us poor Windows builders... But 
probably pointless to try to upstream that.

--tml


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] No Python scripts visible in UI - build 350m1 from master nightly 27/06/2011 for Mac OSX

Le 27/06/11 18:53, Alexander Thurgood a écrit :

And here's the error message :

Error while installing extension MRI - UNO Object Inspection Tool. The
error message is: python-loader:exceptions.SyntaxError: ('invalid
syntax',
('/Applications/LibO-dev.app/Contents/basis-link/program/pythonloader.py',
116, 29, 'except ImportError as e:\n')), traceback follows
no traceback available
The extension will not be installed.



Alex

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist tlillqv...@novell.com wrote:
 If we do that, we definitely should then also add built-in mkdir and cp
 commands in it,

 Hmm, or actually, I don't think that will be such a great win after all, as 
 the gbuild recipies where tons of mkdir commands are being run typically are 
 in a shell expression with  anyway, so they couldn't be run as built-in 
 simple make commands anyway. Forget it.

Yeah, but maybe there is something to be investigated to avoid fork
when running recipies... I've read somewhere that spawn was much more
performant than fork under cywin (note: I don;t know if make already
do that or not, nor what are the implication...)

Another thing: I think most of these mkdir could be avoided at the
cost of another layer of dependencies: create rules for every target
so that the parent directory is a pre-req target and have rules for
directories to build them... that should put most of the the workload
on make itself an limit drastically the number of mkdir...

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] patch for make to help in gbuild debugging

On Mon, Jun 27, 2011 at 12:26 PM, Norbert Thiebaud nthieb...@gmail.com wrote:
 On Mon, Jun 27, 2011 at 12:03 PM, Tor Lillqvist tlillqv...@novell.com wrote:
 If we do that, we definitely should then also add built-in mkdir and cp
 commands in it,

 Hmm, or actually, I don't think that will be such a great win after all, as 
 the gbuild recipies where tons of mkdir commands are being run typically are 
 in a shell expression with  anyway, so they couldn't be run as built-in 
 simple make commands anyway. Forget it.

 Yeah, but maybe there is something to be investigated to avoid fork
 when running recipies... I've read somewhere that spawn was much more
 performant than fork under cywin (note: I don;t know if make already
 do that or not, nor what are the implication...)

 Another thing: I think most of these mkdir could be avoided at the
 cost of another layer of dependencies: create rules for every target
 so that the parent directory is a pre-req target and have rules for
 directories to build them... that should put most of the the workload
 on make itself an limit drastically the number of mkdir...

Another solution is a quick and dirty path to make to have ot try to
create the base directory of a target before running a recipe for it.
i don't like it because it will never be accepted upstream and would
prevent building without a patched version...
But since there is a platform/* support we could have conditional on
windows to not do the mkdir if we have the 'right' make.
(iow maintain the buidability with a vanilla make, but still improve
perf when a 'lo-make' is available.)

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [SOLVED] Debug-mode getline-using sal unittest crashes, triggered by _GLIBCXX_DEBUG

2011-06-27 Thread Julien Nabet


Le 27/06/2011 16:57, Caolán McNamara a écrit :

On Fri, 2011-06-24 at 20:02 +0200, Julien Nabet wrote:

But when i use  the test file, nothing as you can see below :

$ g++ -D_GLIBCXX_DEBUG attachment.cxx
$ echo hello world | ./a.out
Line is: hello world

Hmm, hard to track down a reproducible test-case then. Anything in
echo hello world | valgrind ./a.out ?

$ cat test.c
#include iostream
#include string

using namespace std;

int main (int argc, char * const argv[]) {
string line;
getline(cin, line);
cout  Line is: \  line  \  endl;
   return 0;
}
$ g++ -D_GLIBCXX_DEBUG test.c
$ echo hello world| valgrind ./a.out
==2612== Memcheck, a memory error detector
==2612== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2612== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2612== Command: ./a.out
==2612==
Line is: hello world
==2612==
==2612== HEAP SUMMARY:
==2612== in use at exit: 0 bytes in 0 blocks
==2612==   total heap usage: 5 allocs, 5 frees, 96 bytes allocated
==2612==
==2612== All heap blocks were freed -- no leaks are possible
==2612==
==2612== For counts of detected and suppressed errors, rerun with: -v
==2612== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 6)
$

And was this with a system cppunit or the built-in one ?
libcppunit-1.12-1 and libcppunit-dev are not installed and in 
config.log, I've got :

configure:14349: checking which cppunit to use
configure:14449: result: internal

So I suppose I use the build-in one.

Are there other tests I could do ?

Julien.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] development summary: year 2011, week 24

2011-06-27 Thread Petr Mladek

Hi John,

I am happy that your are working on it and have some nice results.

John LeMoyne Castle píše v Pá 24. 06. 2011 v 02:38 -0700:
 Hi Petr, 

 Sorry about the confusion I created on a previous summary thread in my
 brainstorming attempt to get development summaries into the wiki.  
 I know it was bad because it even seemed to infect your response a little.  

I am not aware of any confusion. It is normal to have different views on
something and exchange ideas :-)

 This should be clearer.  
 
 Here is an example of a wrapper (wiki-dev-sum) 
 http://nabble.documentfoundation.org/file/n3103449/wiki-dev-sum wiki-dev-sum 

OK, if I understand it correctly, it has the following purpose:


1. purpose is to generate the statistic for all active branches.

   Well, this might make sense. I actually use a similar
   wrapper that updates the repository to a given branch
   and get the last changes. It is written in bash. Please,
   find it attached.

   It would be great to pass the list of branches via the
   command line options.

   You could use --option=param even in bash. You could get
   the param via:

  param=`echo $arg | sed s/--option=//`

 
   Note that the situation is a bit complicated. I have separate
   git tree for master, libreoffice-3-4* and libreoffice-3-3*
   branches because they are not compatible:

 + libreoffice-3-3 uses build repo as the
   toplevel dir ; bootstrap repo is in
   build/clone/bootstrap.

 + libreoffice-3-4 uses bootstrap as the top level
   module

 + master is going to be switched to single git
   repository, see
http://wiki.documentfoundation.org/Development/One_Git_Conversion


   Well, it might be interesting to move this functionality to
   the lo-commit-stat script. You could add new option:

  --branches=branch[,...]

   I created extra wrapper because it was easier to do it in
   bash and I wanted a quick solution ;-)


2. purpose is to define the start and end day according to the
   week.

  It would be great to have it in the lo-commit-stat script. It
  is very useful also for generating the plain log for E-mail.

  Could you please add --year=year --week=week --last-week
  options int lo-commit-stat? You could do something like:

 if (defined $last_week) {
$year = get_this_year();
$week = get_this_week();
 }

 if (defined $week  ! defined $year) {
$year = get_this_year();
 }

 if (defined $week  defined $year) {
die Error: Do not define extra git arguments together
with --year, --week, --this-week options
if (@git_args);
@git_args = get_git_args_for_feek($year, $week);
$log_suffix = week-$year-$week unless (defined
   $log_suffix)
 }

   You need not process these options in the wiki-dev-sum
   wrapper. It might be enough to pass them to the
   lo-commit-stat script.
   
3. Is there any other purpose of the wiki-dev-sum script?


BTW1: I was not sure what the --echo option means. Such functionality is
usually enabled via the option --verbose ;-)

Also the following negative condition looks a bit cryptic:

(! defined $echo) || show_call

I think that 

(defined $verbose)  show_call(...)

or

show_call(...) if (defined $verbose);

is slightly better readable ;-)


BTW2: Using /tmp/commit-log-$branch-wiki.log is a bit dangerous because
any user could write to this file (security hole, write access
problems). I suggest to create a temporary directory
under /tmp/wiki-dev-sum-XX and put files under it. The question is
why you need the temp file at all. It would be better if lo-commit-stat
generates the right file to the final location and no postprocessing is
needed.


 that operates on a slightly modified lo-commit-stat script (basically just
 adds --wiki format option)
 http://nabble.documentfoundation.org/file/n3103449/lo-commit-stat
 lo-commit-stat 

It looks great. I am just not sure about the change:

--- cut ---
-(defined $top_dir) || die Error: top directory is not defined\n; 
+if (! defined $top_dir) { 
+   usage(); 
+   exit; 
+} 
--- cut ---

I think that the user might be confused why it prints help and what is
the exact problem.


 The intention is to make as few changes as possible in lo-commit-stat while
 getting to where a Weekly Development Summary wiki page is generated easily. 

Do not hesitate to do more changes in lo-commit-stat ;-)

 I attached full scripts and not patches because the pair is brand new and
 neither fully

Re: [Libreoffice] patch for make to help in gbuild debugging