Re: [Libreoffice] [PATCH] Mark ecx register as clobbered (in cpp_uno/gcc3_macosx_intel)

2011-10-18 Thread Stephan Bergmann

On 10/15/2011 01:25 AM, Kristian Rietveld wrote:

Without this patch, Cpp bridgetest on a Clang-compiled UNO runtime will
not complete successfully.


Btw, pushing some clang-related patches, mainly based on abandoned work 
I did earlier this year.  Your go at this gave me fresh enthusiasm.  :) 
 Hope you don't mind me picking up on this.


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


Re: [Libreoffice] Trying to diagnose base running extremely slowly

2011-10-19 Thread Stephan Bergmann

On 10/19/2011 04:10 PM, John Talbut wrote:

What I notice is that there is a set of lines starting with
read(72
and ending with
close(72)

(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02 seconds that alone would account for some 4 minutes of the run.


7321 times reading out /proc/self/map -- no idea why it does that, but 
that clearly ain't no good...


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


Re: [Libreoffice] Trying to diagnose base running extremely slowly

2011-10-19 Thread Stephan Bergmann

On 10/19/2011 05:07 PM, Michael Meeks wrote:

On Wed, 2011-10-19 at 16:34 +0200, Stephan Bergmann wrote:

(the number is not always 72) that is repeated more or less identically
some 12,000 times in the 7 minute run. Since each set appears to take
around .02 seconds that alone would account for some 4 minutes of the run.


7321 times reading out /proc/self/map -- no idea why it does that, but
that clearly ain't no good...


Yep :-) If I remember rightly - the only moving part in this
side-to-side performance comparison that causes a substantial decrease
in performance is Java 7 vs 6 right ? The strace shows it poking
at /proc/self/map endlessly (something that is not done by any
LibreOffice code I can find off hand), which perhaps helps isolate the
problem rather better ?


What the LibO hsqldb code does a lot is call JNI's 
Attach/DetachCurrentThread.  Googling around, 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067 Stack 
guard pages should be removed when thread is detached suggests that 
reading /proc/self/maps might have been added into 
Attach/DetachCurrentThread as part of a bug fix.  That would explain things.


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


Re: [Libreoffice] Trying to diagnose base running extremely slowly

2011-10-20 Thread Stephan Bergmann

On 10/19/2011 07:17 PM, Andrew Haley wrote:

On 10/19/2011 05:57 PM, Michael Meeks wrote:


On Wed, 2011-10-19 at 17:32 +0200, Stephan Bergmann wrote:

What the LibO hsqldb code does a lot is call JNI's
Attach/DetachCurrentThread.  Googling around,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929067  Stack
guard pages should be removed when thread is detached suggests that
reading /proc/self/maps might have been added into
Attach/DetachCurrentThread as part of a bug fix.  That would explain things.


Good catch ! The irony ... :-) this Java bug was kindly fixed for us
indirectly via Andrew Haley to address the bad stack page left around when
we had run some java. That page was causing crashes in calc formula computation
in large sheets.

It seems we can't win at some stage here. Andrew - I wonder are other
people getting frustrated by performance here too ? it seems there is
some huge /proc/self/maps thrash as we enter/exit Java now on Linux.


Hmmm, I thought this had been fixed.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6978641


This might still hit us, if the LibO hsqldb code runs in the main thread 
(which I'm pretty sure it does).  That code calls 
Attach/DetachCurrentThread frequently.


I think the best solution here would be to change the LibO hsqldb code, 
to call Attach/DetachCurrentThread rarely rather than frequently, but 
according to Ocke Janssen (who used to maintain that code) that was no 
easy option.


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


Re: [Libreoffice] Fwd: Re: patch for scan-diialog

2011-10-20 Thread Stephan Bergmann

On 10/19/2011 10:30 PM, Rob Snelders wrote:

I tried to add the XScannerManager2. But when I try with this patch then
the menu-items are disabled. I have tried to search where the problem
was but I can´t find it. Can you help me?


Hi Rob,

The new file offapi/com/sun/star/scanner/XScannerManager2.idl is missing 
from the patch (I guess you did not git add it before you created the 
git diff).


Then, as Markus already pointed out, the ScannerManager class needs to 
be adapted, to derive from XScannerManager2.


Further, I noted that when configureScannerAndScan in scanunx.cxx calls 
the SaneDlg constructor, it should pass listener.is() instead of 
(listener != NULL) for bScanEnabled.  While the latter (happens to) 
work as well, the former is much cleaner and the preferred idiom when 
working with com::sun::star::uno::Reference.


And finally, the scanwin.cxx case does not support the new feature at 
all, right?  Then we should at least change the end of the changed line 
in that file from const uno::Reference lang::XEventListener  
rxListener ) to const uno::Reference lang::XEventListener  ), to 
avoid warnings about unused parameters.  Better yet, the button should 
be hidden.  (Or even better yet, the new functionality should be 
implemented...)


If you provide the missing XScannerManager2.idl, I can tweak the above 
issues in the patch for you, if you like.


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


Re: [Libreoffice] make experts: progress information?

2011-10-20 Thread Stephan Bergmann

On 10/20/2011 07:35 AM, Kevin Hunter wrote:

Beyond myself, are others interested in having a finer-grained
indication of where is the build currently in the whole process??


Honestly, I'm not.  Please don't add too much magic to make the build 
output nicer.  It does get in your way, sooner or later.  (And I also 
--disable-zenity, as it IMO just adds noise.)


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


Re: [Libreoffice] [PUSHED] Fwd: Re: patch for scan-diialog

2011-10-20 Thread Stephan Bergmann

On 10/20/2011 08:37 PM, Rob Snelders wrote:

Here are 3 patches that together make the code for adding the
scan-button to the sanedlg.

These patches are submitted under the LGPLv3+/MPL-licence.


Pushed now as 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=638804f7e2c26047da15af26dfb8eb35b9ee0feb 
(combined into a single changeset and with some minor tweaking -- hope I 
did not break anything with that, as I have no scanner attached to test 
the new Scan button actually does what it should do...)


Thanks again for the patch and all the work you put into this.

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


[Libreoffice] Python on Windows

2011-10-20 Thread Stephan Bergmann
I must confess that in 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=fecde94354a46463d346a1a78962f39a5a6f9eb8 
Undo basis/brand split: moved Python from basis to brand. I did some 
blind changes to Windows-only code in pyuno/zipcore/python.cxx.  (Did I 
mention I still did not succeed with a Windows-in-a-virtual-machine LibO 
build?  Yeah, should probably try a MinGW cross-compile instead...)


Anyway, if anybody less Windows-phobic than me would like to check out 
whether pyuno still works on Windows, that would be great:


(a) pyuno/zipcore/pyhton.cxx might actually not compile at all -- 
tinderboxes should already note that...


(b) pyuno within LibO might no longer work.  An easy way to test that is 
to build desktop/$INPATH/misc/passive.oxt via cd 
desktop/test/deployment/passive  dmake, install it in LibO, and see 
that the three entries in the new passive menu each pop up a dialog 
(esp. the python entry, of course).


(c) pyuno as run from an external python process might no longer work. 
An easy way to test that is to start the interactive python executable 
from the LibO program directory and execute include uno (and/or 
include pyuno; not sure right now which one is the more interesting, 
but if both work I'd guess that's good).


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


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

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 02:06 AM, Kevin Hunter wrote:

At 4:52pm -0400 Thu, 20 Oct 2011, Michael Meeks wrote:

http://wiki.documentfoundation.org/Development/LibreOffice4



+ getting stuck into Windows / mingw build etc.


 From the wiki page, one of the concerns is binary incompatibility. I
assume this is in reference to extensions?

Question: is there merit to moving toward an enforced sub-process model
for extensions? My first thought is that this would do a couple of things:

[...]

5. That API definition will be a *lot* of work, but hopefully somewhat
thought out already through only a mild reengineering of the current
binary API.


The UNO API is already there.  Or what do you mean?

[...]

The upside is that if we're talking a major version change, /now/ would
be the time to do this.


A downside is that you would still need to maintain (and build!) the UNO 
runtime for the MSVC ABI.


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


Re: [Libreoffice] Python on Windows

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 01:20 AM, Miklos Vajna wrote:

On Thu, Oct 20, 2011 at 11:21:52PM +0200, Stephan Bergmannsberg...@redhat.com 
 wrote:

(c) pyuno as run from an external python process might no longer work.
An easy way to test that is to start the interactive python executable
from the LibO program directory and execute include uno (and/or
include pyuno; not sure right now which one is the more interesting,
but if both work I'd guess that's good).


You mean import in both cases, not include, right?


Yes, sure, sorry.

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


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

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 11:08 AM, Kevin Hunter wrote:

At 4:11am -0400 Fri, 21 Oct 2011, Stephan Bergmann wrote:

On 10/21/2011 02:06 AM, Kevin Hunter wrote:

5. That API definition will be a *lot* of work, but hopefully somewhat
thought out already through only a mild reengineering of the current
binary API.


The UNO API is already there. Or what do you mean?


I was talking about an API that is not dependent on an ABI. But I freely
admit I know very little about ABIs, so I may have just conflated that
term. See below.


The upside is that if we're talking a major version change, /now/ would
be the time to do this.


A downside is that you would still need to maintain (and build!) the UNO
runtime for the MSVC ABI.


This may be the crux of what I'm not getting, but why? Why can't a
protocol be, say, text-based via (local, or other) socket? In my mind, I
see two independent programs, from two different compilers, using the OS
and something akin to pipes to communicate. I admit it might a smidgen
slower to do it that way, but do people actually use LO in HPC
scenarios? (And I fully accept that they might, I just haven't seen it
yet in my various interactions.)


That's all already there with UNO.  Only, for any code to make use of 
that, it needs to talk with bridge code that handles the (intra- or 
inter-process) communication.  That bridge code (which is necessarily 
ABI-specific) is also already there.


The only thing is that, if you wanted to give up building LibO with MSVC 
and switch to MinGW, but wanted to retain the MSVC-specific bridge code 
(so that old extensions can continue to run, in- or out-of-processes), 
you could not give up building LibO with MSVC completely, because you 
would still need to build that bridge code with MSVC.


Designing a new communication protocol would not buy you anything.

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


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

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 10:39 AM, Michael Meeks wrote:

Hi Kevin,

On Thu, 2011-10-20 at 20:06 -0400, Kevin Hunter wrote:

   From the wiki page, one of the concerns is binary incompatibility.  I
assume this is in reference to extensions?


Sure; of course we only export a reasonably small ABI, the 'ure' (big
chunks of which are in-lined C++ methods that call SAL_CALL C functions
that we havn't changed and should cross-compile nicely). The
C++ helper classes (it is hoped) due to windows direct linking, and a
different ABI anyway shouldn't conflict.

My hope was(is) that UNO can shine here (with some tweaks) as a
bridging technology between the ABIs - at some fairly minimal
performance cost. At least, given Stephan's expertise  a little
testing, it might just work. That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.


It would not suffice to ship them, one would also need to build them. 
Kind of back to square one.



Question: is there merit to moving toward an enforced sub-process model
for extensions ?


It is an interesting idea; of course in theory UNO makes this easy, in
reality - I would scream and run away from cross-process component
usage. Debugging reference leaks / cycles / etc. is bad enough
in-process, never-mind cross-process; or worse between many (external)
components.


Note that freshly installed extensions *are* routinely loaded off to an 
external uno process.


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


Re: [Libreoffice] comprehensive binfilter tests?

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 02:38 PM, Caolán McNamara wrote:

On Wed, 2011-09-28 at 21:58 +0200, Andras Timar wrote:

In rsc/doku/feinkonz.43 there are 3 sdw files, LibreOffice 3.4.x
crashes on all of them under Linux/Windows. I did not try master. 3.3
is OK.


master crashes for me alright,
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=86db50edeee1d556f993589da73140582789ef42
 fixes it again for those docs anyway.

caolanm-sberg: can you have a look at my fix, looks like merge bustage
on merging in the fix for #i117310#, though that would indicate that
whatever problem exists in 3.4.3 is different.


http://hg.services.openoffice.org/cws/sb140/rev/85f71dba0516 
(referenced from https://issues.apache.org/ooo/show_bug.cgi?id=117310) 
removes the


  if( !rPropSetInfo.is() )
rPropSetInfo = rPropSet-getPropertySetInfo();

part only from 
binfilter/bf_xmloff/source/style/xmloff_SinglePropertySetInfoCache.cxx 
but not from the corresponding 
xmloff/source/style/SinglePropertySetInfoCache.cxx.  I guess it was a 
mistake I introduced when manually copying over the changes I made to 
the latter to the former, and it simply went unnoticed until now.


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


Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 11:13 AM, Michael Meeks wrote:

Hi August,

On Thu, 2011-10-20 at 15:01 -0400, August Sodora wrote:

On Tue, Oct 18, 2011 at 3:01 PM, August Sodoraaug...@gmail.com  wrote:

I've attached a new patch that includes some tests for the BASIC
scanner. Most of the test cases are just to get an idea of how the
scanner handles certain situations but I tried to make sure I included
ones that specifically trigger where the GetBufferAccess was.


Ooh ! :-) this is really nice. I was previously fooled by the subject
into not noticing that this was some sexy code cleanup + unit testing
patch.

Lovely work ! I added a doc. header for the new sal/ method, and since
I have: (setq-default show-trailing-whitespace t) in my ~/.emacs I see
red warnings of trailing whitespace - so removed a bit of that. One
thing I tweaked in one place is using sal_Int32 indexes into
rtl::OUStrings where previously sal_uInt16 indexes were adequate, one
benefit of your cleanup is that we can handler bigger scripts of course.

Anyhow - a lovely job :-) I'm really looking forward to see what you
touch next :-)

Many thanks !


Unfortunately, this breaks the build, as basic now has a (missing) 
dependency on sfx2, which already depends on basic.


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


Re: [Libreoffice] IDL hyper / Java long

2011-10-21 Thread Stephan Bergmann
Marcin, hope you don't mind I bring this back to the public mailing 
list.  I'm no expert with Calc add-ins, so we should make sure I'm not 
telling nonsense:


On 10/21/2011 05:42 PM, MarcinGutman wrote:

Sorry, not sure what you want to tell me with the above.



If you create Java Calc Add-In you have a Java function.
There is also an IDL file that reflects definition of Java function.
Parameters types are mapped from Java to IDL
If Java parameter is int in IDL you put long.
If Java parameter is long in IDL you put hyper or unsigned hyper.
If you put hyper there is a mentioned problem.
If you put unsigned hyper there is no problem.

So there are three cases:
1) A comedy: it's only my box.
2) A drama: bug in SDK i.e. only new Calc Add-Ins are affected.
3) A horror: bug in LOo i.e. all existing Calc Add-Ins are affected.

Due to 3) somebody should check it.


As I wrote at https://bugs.freedesktop.org/show_bug.cgi?id=42005#c1, 
Calc add-ins do not support functions that take or return UNO type hyper.


So I think that explains why an add-in using hyper in the .idl file does 
not work.


Why, however, it should work if the .idl file instead uses unsigned 
hyper I do not know.


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


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

2011-10-21 Thread Stephan Bergmann

On 10/21/2011 03:57 PM, Michael Meeks wrote:

On Fri, 2011-10-21 at 14:51 +0200, Stephan Bergmann wrote:

That would of course mean shipping some
duplicate legacy MSVC++ compiled libraries, but ... surely do-able.


It would not suffice to ship them, one would also need to build them.
Kind of back to square one.


For windows - shipping a pre-canned set of compiled compatibility
libraries doesn't look too disgusting to me; at least - it seems a lot
less disgusting than using MSVC++ and cygwin :-)

tar xf ure-bincompat-win32-tgz

is not in itself such a horrific outcome from a cross-compiled solution
(assuming the build of that is well documented, should you happen to
have lots of time and a proprietary system + compiler to do it). Clearly
someone needs to build them once.


There will invariably be situations were things in there will need to 
get fixed.  And if that code is only built once in a year, it will 
bitrot and no longer build in a year from now.


Been there with moz_prebuilt.  No thanks.  :)

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


Re: [Libreoffice] [PUSHED] String::CompareIngoreCaseToAscii

2011-10-23 Thread Stephan Bergmann

On 10/21/2011 10:17 PM, Michael Meeks wrote:

On Fri, 2011-10-21 at 18:16 +0200, Stephan Bergmann wrote:

Unfortunately, this breaks the build, as basic now has a (missing)
dependency on sfx2, which already depends on basic.


Fair enough, my mistake. I dropped sfx from the link line, it's not
actually required, leaving the link dependencies the same as
Library_sb.mk - the beautiful unit test still passes nicely.


The funny thing is that it broke a make check build but not a 
tinderbox's plain make build (which also executes the unit tests, but 
appears to cluster them at the end of the build, when sfx2 has already 
been built anyway).


Thanks for fixing,

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


Re: [Libreoffice] [PATCH] [PUSHED] Match the correct function template specialization (in autodoc)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:37 AM, Kristian Rietveld wrote:

My understanding of the issue is that when the EV_TokenId typedef is
expanded, the resulting E_TokenId part is ambiguous. Therefore, fully
specifying the E_TokenId fixes the problem.


Yes.

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


Re: [Libreoffice] [PATCH] [PUSHED] Put neq-operator for awt::Size in correct namespace (in chartapiwrapper)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:39 AM, Kristian Rietveld wrote:

If not done, Clang will not find the operator overload.


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


Re: [Libreoffice] compilation error in binfilter/bf_svx/

2011-10-24 Thread Stephan Bergmann

On 10/24/2011 12:25 PM, Jean-Baptiste Faure wrote:

Compiling: binfilter/bf_svx/source/xoutdev/svx_xattr.cxx
/home/jbf/LibO/master/clone/binfilter/binfilter/bf_svx/source/xoutdev/svx_xattr.cxx:
In member function 'virtual binfilter::SfxPoolItem*
binfilter::XFillAttrSetItem::Create(SvStream, USHORT) const':
/home/jbf/LibO/master/clone/binfilter/binfilter/bf_svx/source/xoutdev/svx_xattr.cxx:3883:
error: 'stderr' was not declared in this scope
/home/jbf/LibO/master/clone/binfilter/binfilter/bf_svx/source/xoutdev/svx_xattr.cxx:3883:
error: 'fprintf' was not declared in this scope
dmake:  Error code 1, while making
'../../../unxlngx6.pro/slo/svx_xattr.obj'


Oops, had erroneously been pushed.  Fixed now 
http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=e8c71c5ae20d33f8aa3bf67296b71c955fd11b34.


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


Re: [Libreoffice] [PATCH] Also use .NET2003 build fix for Clang (in toolkit)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:47 AM, Kristian Rietveld wrote:

By far the quickest is to use the already existing fix for .NET2003 for
clang as well. In the future, this is something that possibly should be
avoided in the class hierarchy, there are more classes in the code base
that expose a similar problem.


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


Re: [Libreoffice] [PATCH] [PUSHED] Also use .NET2003 build fix for Clang (in toolkit)

2011-10-24 Thread Stephan Bergmann

On 10/24/2011 01:26 PM, Stephan Bergmann wrote:

Pushed, thanks.


[had forgotten to add the PUSHED marker]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [Libreoffice] [PATCH] [PUSHED] Argument to setTitle cannot be const (in fpicker/aqua)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:41 AM, Kristian Rietveld wrote:

This fixes the following warning:

/source/libo/libo/fpicker/source/aqua/ControlHelper.cxx:244:39: error:
cannot initialize a parameter of type 'NSString *' with an lvalue of type
'const NSString *'

I did not see another solution so quickly than removing const. Also, if
you want to modify the actual string contents, you need to use
NSMutableString anyway.


pushed

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


Re: [Libreoffice] [PATCH] [PUSHED] SystemFlavor NSStrings should not be const (in vcl/aqua/.../dtrans/)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:43 AM, Kristian Rietveld wrote:

This fixes an issue where const NSString* is assigned to a non-const
NSString* field in FlavorMap. The NSString cannot be const when passed
to an objective-C method expecting a non-const value (the NSStrings from
flavor map are passed to such methods elsewhere in the code). Also, if
you want to modify the actual string contents, you need to use
NSMutableString anyway.


pushed

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


Re: [Libreoffice] [PATCH] [PUSHED] Use NSString in template specification instead of objc_object (in macosxspell)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:45 AM, Kristian Rietveld wrote:

This fixes the following warnings:

/source/libo/libo/lingucomponent/source/spellcheck/macosxspell/macspellimp.cxx:176:39:

error: reference to type 'const value_type' (aka 'objc_object *const')
could not bind to an rvalue of type 'id'
postspdict.push_back( [ aLocales objectAtIndex:i ] );
^~~~
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/bits/stl_vector.h:600:35:

note: passing argument to parameter '__x' here
push_back(const value_type __x)


pushed

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


Re: [Libreoffice] [PATCH] [PUSHED] Eliminate ambiguous conversion to cppu::OWeakObject (in reportdesign)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:48 AM, Kristian Rietveld wrote:

This fixes the following error:

/source/libo/libo/reportdesign/source/core/sdr/ReportDrawPage.cxx:96:24:
error: ambiguous conversion from derived class 'SvxShapeControl' to base
class 'cppu::OWeakObject':
class SvxShapeControl - class SvxShapeText - class SvxShape -
SvxShape_UnoImplHelper - class cppu::OWeakAggObject - ::cppu::OWeakObject
class SvxShapeControl - class SvxShapeText - class SvxUnoTextBase -
class SvxUnoTextBase_Base - SvxUnoTextBase_Base0 - class
SvxUnoTextRangeBase - SvxUnoTextRangeBase_Base - class
cppu::OWeakAggObject - ::cppu::OWeakObject
xShape.set(*pShape,uno::UNO_QUERY);
^~~


pushed

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


Re: [Libreoffice] [PATCH] [PUSHED] Eliminate ambiguous conversion to cppu::OWeakObject (in svx/form)

2011-10-24 Thread Stephan Bergmann

On 10/22/2011 11:52 AM, Kristian Rietveld wrote:

Similar to the previous patch.


pushed, too

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


Re: [Libreoffice] IDL hyper / Java long

2011-10-24 Thread Stephan Bergmann

On 10/24/2011 08:46 PM, Eike Rathke wrote:

Why, however, it should work if the .idl file instead uses unsigned
hyper I do not know.


Wild guess: may it be that the .idl parser takes 'unsigned' of 'unsigned
hyper' and ignores the 'hyper', effectively mapping that to an unsigned
32-bit value and generating sal_Int32 (not uInt32 as API doesn't know
that)?


Nah, such basic brokenness would already be caught by 
testtools/source/bridgetest.


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


Re: [Libreoffice] [Libreoffice-qa] error checking in Base ODBC

2011-10-24 Thread Stephan Bergmann

On 10/24/2011 05:59 PM, Terrence Enger wrote:

I shall proceed with that.  And, unless somebody tells me otherwise, I
shall indulge myself with OSL_ENSURE() on the return values.


Note that OSL_ENSURE, OSL_ASSERT, and OSL_FAIL should only be used for 
logic errors (i.e., the program detects that it contains an error and 
ends up in a state that cannot happen), not for uncommon situations 
that nevertheless should be handled, like IO errors or malformed user 
input.  OSL_TRACE, on the other hand, is the tool of choice to document 
interesting events during program execution (which is only evaluated 
when built with DEBUG=TRUE, however).  --  Even if lots of places in the 
code base misuse the former for the latter.  Ideally, OSL_ENSURE et al. 
should directly abort program execution, but we're not there, yet.


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


Re: [Libreoffice] [Libreoffice-commits] .: writerperfect/source

2011-10-25 Thread Stephan Bergmann

On 10/25/2011 04:04 AM, Kevin Hunter wrote:

At 9:48pm -0400 Mon, 24 Oct 2011, Kevin Hunter wrote:

At 7:24pm -0400 Mon, 24 Oct 2011, Fridrich Štrba wrote:

for (std::mapWPXString, FontStyle *, ltstr::const_iterator iter =
mHash.begin();
- iter != mHash.end(); ++iter)
+ iter != mHash.end(); iter++)


Err, in terms of coding style, is a pre to post increment operator
merely a whitespace change? I seem to recall a message or two on the
subject but I'm having a difficult time tracking them down just now.
About 8 months ago, perhaps?


Kevin: open mouth, insert foot. I apologize. Just perusing commits,
should've kept going. I take it the pre to post is needed to fix the
build.


This looks more like fix the build reverted more than was really 
necessary in this case.


In general, and if the expression's value is not used, prefix 
increment/decrement is preferable to postfix, as the former conceptually 
avoids creation of a temporary that makes the old, unmodified value 
available as the expression's value.


That said, you see both forms with more-or-less similar frequency in the 
wild.


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


Re: [Libreoffice] [PATCH] [PUSHED] Match the correct function template specialization (in autodoc)

2011-10-25 Thread Stephan Bergmann

Kris,

The patches you sent are great; if you would want to apply for direct 
commit access 
(http://wiki.documentfoundation.org/Development#Getting_and_using_commit_access) 
-- go ahead, I'd say!


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


Re: [Libreoffice] SmART Gallery as integrated part of LibreOffice core

2011-10-26 Thread Stephan Bergmann

On 10/25/2011 10:50 PM, Kálmán „KAMI” Szalai wrote:

We (my friend Tibusz and me) are thinking about to integrate SmART into
LibreOffice suite. I hope you saw the ligtning talk about SmART. What
you think about this extension? What is your opinion about the
integration? We know this is currently impossible because SmART uses
Java. So we have plan to reimplement the SmART Gallery in C++. Of course
we do this huge task only if there is a chance to make SmART Gallery
functionality integral part of LibO. Should we create a chart2 like
module for SmART or what would be the best solution? If our plan get
green light from you we need a mentor who help us.


Just a blunt question:  Why not keep it as an extension, if that already 
works fine?  Could be a pre-installed one (in an extra package with a 
Java dependency, for those package distributions that choose to do so).


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


Re: [Libreoffice] SmART Gallery as integrated part of LibreOffice core

2011-10-26 Thread Stephan Bergmann
(don't get me wrong, folks; I have nothing against adding it into the 
core, was just wondering what the benefits of the rewrite would be)


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


Re: [Libreoffice] Dumping to valgrind.log from soffice shell script needed?

2011-10-26 Thread Stephan Bergmann

On 10/26/2011 01:55 PM, Petr Mladek wrote:

What is your preferred way of use?
What exactly do you hate and/or miss?


One problem is output of multiple (batched, like make subsequentcheck) 
valgrind'ed invocations of soffice.bin is lost.


Another problem is attaching a debugger (VALGRIND_OPTS=--db-attach=yes) 
does not work.


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


Re: [Libreoffice] semantics of ScBaseCell* lclCloneCell

2011-10-27 Thread Stephan Bergmann

On 10/27/2011 07:10 AM, Kevin Hunter wrote:

I'm nosing around ScBaseCell in sc/source/core/data/cell.cxx, and I'm
curious about the semantics of the function lclCloneCell. Specifically,
when would that function ever return a NULL pointer? Does Calc not know
about all its cell types? Perhaps extensions are able to add their own
cell types and still use this function? (Then why would they use this
function?!)


Not an sc expert, but from looking at the code it looks to me like the 
default case shall never be reached, but is there to (a) silence 
compiler warnings and (b) fire an OSL_FAIL in case there is a 
programming error that causes the case to be reached nonetheless (I 
usually put a this cannot happen into such OSL_FAILs, in good old 
Knuth tradition).  And since the function still needs to syntactically 
return something, even in this unreachable case, it returns the 
canonic null value.


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


Re: [Libreoffice] compilation issues of apple_remote

2011-10-27 Thread Stephan Bergmann

On 10/27/2011 08:36 AM, Jonathan Aquilina wrote:

I will give these a shot i have symbols enabled and at a certain point
its complaining about missing 64bit symbols. How come for users on 10.7
we dont have a native 64bit build as 10.7 runs as 64bit out of the box?


Jonathan, just for clarification:  Those missing symbols have nothing to 
do with having symbols enabled (aka --enable-symbols).  The former is 
about global symbols (representing C/C++ functions etc.) where one 
dynamic library depends on symbols provided by another dynamic library 
(i.e., one dynamic library calls a function implemented in another 
dynamic library).  The latter is about internal symbols within a single 
dynamic library (e.g., a static function that cannot be called from 
outside, anyway) that would not be needed at runtime but make debugging 
easier.


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


Re: [Libreoffice] (real) Windows build, needs help.

2011-10-27 Thread Stephan Bergmann

On 10/26/2011 09:52 PM, Kohei Yoshida wrote:

C:/libo/core-master/solenv/gbuild/Package.mk:33: ***
gb_Deliver_deliver: file does not exist in solver, and cannot be
delivered: 
/cygdrive/c/libo/core-master/solver/wntmsci12.pro/bin/soffice_bin.exe.manifest.


Voreppe Win32 tinderbox fails with the same error, fwiw, see 
http://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTERfull-log=1319695211.30309.


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


Re: [Libreoffice] [REVIEW-3-4-4] )one more needed) fix ole automation bridge handling of SAFEARRAY (fdo#38441)

2011-10-27 Thread Stephan Bergmann

On 10/27/2011 11:58 AM, Noel Power wrote:

and like the subject says. one more needed for 3.4.4


With the same caveat like the other reviewers -- I'm rather illiterate 
with COM/OLE -- the change does look reasonable to me.  So go ahead!


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


Re: [Libreoffice] Mac OSX daily build 26/10/2011 - Base Report Builder, Beanshell, and Javascript extensions disabled

2011-10-28 Thread Stephan Bergmann

On 10/28/2011 10:07 AM, Alexander Thurgood wrote:

I can also confirm this with my own build from master from this morning
28/10/2011, build ID :


I'm having a look.

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


Re: [Libreoffice] Mac OSX daily build 26/10/2011 - Base Report Builder, Beanshell, and Javascript extensions disabled

2011-10-28 Thread Stephan Bergmann

On 10/27/2011 05:33 PM, Alexander Thurgood wrote:

In the daily build from 26/10/2011 the following extensions are present,
but disabled/non-functional. If you inspect the list of installed
extensions these appear greyed out.

[...]

See :
https://bugs.freedesktop.org/show_bug.cgi?id=42312


Alexander,

Can you please update the issue with the exact list of extensions that 
are greyed out for you?  Trying a local build with 
--enable-ext-numbertext --enable-ext-oooblogger 
--enable-ext-google-docs --enable-ext-barcode (as from your other mail) 
I see only Barcode 1.3.1 and Report Builder 1.2.1 greyed out.


Stephan


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


Re: [Libreoffice] Mac OSX daily build 26/10/2011 - Base Report Builder, Beanshell, and Javascript extensions disabled

2011-10-28 Thread Stephan Bergmann

On 10/28/2011 10:07 AM, Alexander Thurgood wrote:

I can also confirm this with my own build from master from this morning
28/10/2011, build ID :

[...]

--enable-ext-barcode


Kami, can you help me?  Just asked on #libreoffice-dev: does anybody 
know anything about the barcode extension?  Alexander Thurgood said on 
ML that it was not working in current Mac builds, but it (as downloaded 
from 
http://ooo.itc.hu/oxygenoffice/download/libreoffice/7e7efc5d4a03126bb9ae3ae9aa2c4e87-Barcode_1.3.1.0.oxt) 
appears to be not working in any recent LibO?  The included 
barcode-loader.py apparently still uses active registration, but does 
not provide a writeRegistryInfo function?


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


Re: [Libreoffice] Replace (Byte|Uni|Xub_)String with O(U)String: Fill() method is missing

2011-10-31 Thread Stephan Bergmann

On 10/29/2011 10:18 PM, Chr. Rossmanith wrote:

the deprecated string classes have a Fill(n,c) method which fills a
string with a single character c repeated n times. I found ~50
occurrences of Fill() using git grep, so it might be worth to add a
Fill() method to OUString. Maybe the name of the new method could be a
bit more verbose e.g. fillWithChar().

Probably I would have to add something similar to OUString
fillWithChar(sal_uInt32 nNumber,|sal_Unicode cChar=' '|) to ustring.hxx
and something like rtl_ustr_fillWithChar() to ustring.c|


This functionality IMO only makes sense as a constructor (esp. for 
immutable OUString), like


  rtl::OUString::OUString(sal_Unicode value, sal_Int32 count);

and probably some underlying C function like

  void rtl_uString_newFromValueAndCount(
rtl_uString **, sal_Unicode value, sal_Int32 count);

However, I would also be sceptical that there are that many places that 
actually need to construct such an (immutable!) string---maybe at least 
some of the places are misguided attempts at preallocating some buffer 
of a given length?  Those should then be rewritten to use 
rtl::OUStringBuffer instead.


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


Re: [Libreoffice] Debug build compilation fail

2011-10-31 Thread Stephan Bergmann

On 10/31/2011 02:20 PM, Rafael Dominguez wrote:

I tried to compile all the project with debug flags enabled (
--enable-dbgutil --enable-debug ) , and im getting this error

Compiling: connectivity/source/drivers/mozab/bootstrap/MNSINIParser.cxx
In file included from
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/debug/debug.h:126,
  from
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_algobase.h:71,
  from
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/bits/stl_tree.h:62,
  from
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/map:60,
  from ./MNSINIParser.hxx:35,
  from
/home/ralph/Proyectos/libreoffice/core/connectivity/source/drivers/mozab/bootstrap/MNSINIParser.cxx:31:
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/debug/formatter.h:
In constructor
'__gnu_debug::_Error_formatter::_Parameter::_Parameter(const
__gnu_debug::_Safe_iterator_Iterator, _Sequence, const char*,
__gnu_debug::_Error_formatter::_Is_iterator)':
/usr/lib/gcc/i686-pc-linux-gnu/4.4.5/include/g++-v4/debug/formatter.h:213:


connectivity/source/drivers/mozab/makefile_mozab.mk contains an explicit 
-fno-rtti, in three places, for various platforms.  This file looks odd, 
smells like these settings are there to ensure some form of ABI 
compatibility with linked-against Mozilla code, but enabling GCC's 
-frtti should have no negative consequences here, anyway.


Please re-try with those three lines removed.

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


Re: [Libreoffice] gravity of raised assertions?

2011-10-31 Thread Stephan Bergmann

On 10/31/2011 03:31 PM, Terrence Enger wrote:

There has been a lot of discussion in the past about raised
assertions and how seriously they should be treated.  Is
there a current concensus?

I raise the question again for no better reason than that
even a newbie like me can see a raised assertion and collect
a backtrace.  Guidance welcome.


OOo earlier this year introduced a mechanism to let smoketestoo_native 
fail in case of assertions (implemented by somebody who did not come 
from the assertions need to abort. period. camp, btw).  LibO promptly 
imported that feature (without any debate AFAIK).


For me at least, this implies that all occurrences of firing assertions 
should be tracked and fixed.


(For me at least, this also implies that assertions---OSL_ASSERT, 
OSL_ENSURE, OSL_FAIL, DBG_ASSERT---should only be used to flag illegal 
program states, not for unexpected but legal ones.  I don't think there 
is objection to this view in general.  I've only seen confusion about 
which macro was designed for which use case, and a sort of indifference 
a la half of the time, OSL_ASSERT etc. are used with the wrong 
semantics anyway; shrug.)


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


Re: [Libreoffice] Mac OSX daily build 26/10/2011 - Base Report Builder, Beanshell, and Javascript extensions disabled

2011-11-02 Thread Stephan Bergmann

On 11/01/2011 10:33 PM, Kálmán „KAMI” Szalai wrote:

I not tested Barcode on current master. I will do it in this week. I
hope I can provide the right extnsion soon.


Great.  Let me know if you have any trouble.


The included barcode-loader.py apparently still uses active
registration, but does not provide a writeRegistryInfo function?

I need more information about this. I will search around or can you give
me some pointers?


See 
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/File_Format#Passively_Registered_UNO_Components 
and links given there.


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


Re: [Libreoffice] [PUSHED-3-4] another build break in 3.4.x

2011-11-02 Thread Stephan Bergmann

On 11/01/2011 08:59 PM, Andreas Radke wrote:

osl_Security.cxx:216:Assertion
Test name: N12osl_Security10getHomeDirE::getHomeDir_001
assertion failed
- Expression: ( sal_True == strHomeDirectory.equals( strHome ) )  ( sal_True
== bRes )
- #test comment#: getHomeDir and compare it with the info we get at the beginni
ng.


Approved 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=84d10c7cda75b58384d1bbcd4022c3056002813d 
Remove the ::osl::Security getHomeDir() check for inclusion in 3.4 as 
http://cgit.freedesktop.org/libreoffice/ure/commit/?h=libreoffice-3-4id=bc9b86940a707e9e2e1076f2954f38075398b5d7.


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


Re: [Libreoffice] gravity of raised assertions?

2011-11-02 Thread Stephan Bergmann

On 11/01/2011 05:50 PM, Lubos Lunak wrote:

On Monday 31 of October 2011, Stephan Bergmann wrote:

For me at least, this implies that all occurrences of firing assertions
should be tracked and fixed.

(For me at least, this also implies that assertions---OSL_ASSERT,
OSL_ENSURE, OSL_FAIL, DBG_ASSERT---should only be used to flag illegal
program states, not for unexpected but legal ones.  I don't think there
is objection to this view in general.  I've only seen confusion about
which macro was designed for which use case, and a sort of indifference
a la half of the time, OSL_ASSERT etc. are used with the wrong
semantics anyway; shrug.)


  I think the only feasible way of fixing this is introducing a new set of
these macros (let's say LO_WARN, LO_ASSERT), deprecating the old ones and
converting their usage to the new ones. Otherwise we'll never know which
OSL_ASSERT is really meant to assert and which is just a warning.


On the non-fatal side, you will definitely want to have something more 
fine grained than just OSL_TRACE (i.e., various levels, and the ability 
to specify---at runtime---which levels to see; something at least 
conceptually alike log4cxx that julien2412 mentioned).


And yes, moving to yet another fresh set of such macros is probably 
best, as you describe.


Guess I'll need to come up with a proposal over the next weeks...

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


Re: [Libreoffice] Replace (Byte|Uni|Xub_)String with O(U)String: Fill() method is missing

2011-11-02 Thread Stephan Bergmann

On 11/01/2011 07:50 PM, Eike Rathke wrote:

Wouldn't they benefit/suffer from the stable ABI requirement then,
whereas in comphelper they don't? Or am I mislead?


Yup, that was the original rationale for introducing 
comphelper/string.hxx, see the comment at the start of the file.


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


Re: [Libreoffice] Replace (Byte|Uni|Xub_)String with O(U)String: Fill() method is missing

2011-11-03 Thread Stephan Bergmann

On 11/02/2011 05:21 PM, Michael Meeks wrote:

The benefits of the stable ABI requirement are somewhat unclear to me.


Mostly for the benefit of (external) client code.  Also, as a secondary 
effect, striving for a stable API probably tends to make the authors of 
the API work harder to produce good quality (documentation, minimalism, 
orthogonality, ...; at least, that's my personal experience).



If (as seems ~certain) we are going to have a flag day at some stage,
there is no harm moving this little lot into the sal/ library. To what


Sorry, don't get what you mean with flag day here.


So - I think this splitting code into lots of different places for ABI
reasons can be re-considered.


An API should strive for various, potentially competing qualities. 
Stability is one, discoverability is another.  Finding a good balance 
here can be a delicate exercise, and there is no single right answer. 
 The concept of additional, external convenience APIs is quite 
widespread.  So is the wisdom of if in doubt, leave it out.  Confer, 
for example, chapter 2 of Reddy's API design for C++ (MK, 2011).


Those are quite general remarks, meant more as something to keep in the 
back of your mind while working on LO's stable URE API, than as litmus 
tests how to handle the comphelper/string.hxx under discussion here (for 
which the case-by-case approach already discussed by Caolán sounds 
reasonable).


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


Re: [Libreoffice] String-rtl::OUString and removed unused code in vcl

2011-11-03 Thread Stephan Bergmann

On 11/03/2011 01:40 AM, August Sodora wrote:

It seems to me that class ApplicationAddress in vcl/svapp.hxx is
unused and that ApplicationEvent has two useless fields, one for the
application address and another string that is always empty and never
compared against or modified. I've attached a patch that cleans this
up a little bit and switches from String to rtl::OUString but
unfortunately I cannot compile the code that is in aqua, etc. Does
someone who has this capability mind building this and making sure
that nothing broke in those few areas?


I will have a look.

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


[Libreoffice] Registering UNO services/types of optional modules

2011-11-03 Thread Stephan Bergmann
http://cgit.freedesktop.org/libreoffice/core/commit/?id=8524330a746da6bd26ca5676b48cdce6bb722380 
Simplify addition of optional components to URE_MORE_{SERVICES,TYPES}. 
brings the following change:


The URE_MORE_SERVICES and URE_MORE_TYPES bootstrap variables now 
understand new syntax to not only include a single file (denoted by a 
plain URI), but also all files within a directory (denoted by the 
directory's URI enclosed in  and *).


Consequently, the LibO services.rdb has been moved to a new directory 
program/services/, and the LibO types (offapi.rdb and oovbaapi.rdb) have 
been moved to a new directory program/types/.


That way, it is simpler for optionally installed modules to get their 
services and types registered---just add files to the respective 
directories.


Of all the .component files currently lumped together into the single 
LibO services.rdb (see postprocess/packcomponents/makefile.mk), quite a 
number belong to optional modules and should thus go into discrete 
.rdbs.  There's clean up work ahead... ;)


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


Re: [Libreoffice] Registering UNO services/types of optional modules

2011-11-03 Thread Stephan Bergmann

On 11/03/2011 11:08 AM, Michael Meeks wrote:

Of all the .component files currently lumped together into the single
LibO services.rdb (see postprocess/packcomponents/makefile.mk), quite a
number belong to optional modules and should thus go into discrete
.rdbs.  There's clean up work ahead... ;)


Sure. Of course, I/O wise we don't really want to fragment big compact
files into lots of tiny files if we can avoid it, but it's a nice
capability to have for sure. How many files do you expect to drop in
there ?


Not more than a handful.  Surely bounded by the number of optional 
packages, so comparable to the number of configmgr .xcd files (where 
reading the small number of .xcd files completely upfront did not have a 
negative impact on start up).


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


Re: [Libreoffice] [PUSHED] String-rtl::OUString and removed unused code in vcl

2011-11-04 Thread Stephan Bergmann

On 11/03/2011 09:30 AM, Stephan Bergmann wrote:

On 11/03/2011 01:40 AM, August Sodora wrote:

It seems to me that class ApplicationAddress in vcl/svapp.hxx is
unused and that ApplicationEvent has two useless fields, one for the
application address and another string that is always empty and never
compared against or modified. I've attached a patch that cleans this
up a little bit and switches from String to rtl::OUString but
unfortunately I cannot compile the code that is in aqua, etc. Does
someone who has this capability mind building this and making sure
that nothing broke in those few areas?


Pushed now as 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e04249337551653f63ba9b2a2302578961e38562. 
 Some notes:


- Changed the code in sfx2/source/appl/appdde.cxx again, so that it does 
not replace '\n'-' ' within ''-quoted substrings.  That's how the 
original appears to have worked.


- Added 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=fb17dce09e29c4518129587d347cc3787f74c396 
so that newly introduced ...append('\n') does the right thing 
(traditionally, that would have been written as 
...append(sal_Unicode('\n'))).


- Not sure whether changing ApplicationEvent::aEvent from UTF-8 to 
UTF-16 is really useful, but changed that afterwards with 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=e66e54fb00bf74d13b7059bd32b6207a029afa5e 
anyway, more aggressively optimizing aEvent into an enum.


- August, http://wiki.documentfoundation.org/Development/Developers 
does not have a link in the License column for you.  Can you please 
add one?  (And I assume your contributions are the standard LGPL3+/MPL1.1?)


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


[Libreoffice] Extension dependencies

2011-11-04 Thread Stephan Bergmann

Hi all,

As already mentioned briefly in my talk at LOCon, we need to make up our 
mind how to handle LO extension dependencies.


Each .oxt extension can carry any number of dependencies, specifying 
conditions that need to be met by the hosting LO installation for the 
extension to be successfully deployable (see 
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Dependencies).


The mechanism was designed to allow for any number of fine-grained 
dependency specifications (this extension requires availability of 
com.sun.star.whatever.Service), but only a coarse-grained 
OpenOffice.org-minimal-version ever got defined (and also a 
maximal-version one).  After all, it is hard (or at least tedious) for 
extension developers to come up with a precise list of features they 
depend on, which would be needed to specify a precise list of 
fine-grained dependencies.  A single minimal-version dependency appeared 
so much easier to use.


The OpenOffice.org-minimal-version dependency worked fine as long as OOo 
was the de-facto standard, with derivatives tracking OOo development 
rather closely and producing new versions in sync with upstream OOo. 
The minimal-version dependency's version value was to be interpreted as 
the version of the underlying OOo reference version, so even if a 
derivative used a different versioning scheme everything worked out.  An 
extension developed for one product could also be deployed in a 
different one (at least in theory; of course there are always minor 
glitches that spoil the picture).


Now, LO and OOo (now AOOo) are no longer in such close relation.  LO is 
heading towards its version 3.5 already while AOOo did not yet publish 
its version 3.4, and new features are routinely added to LO that are 
unlikely to be included into AOOo.  This leads to the following items:


** How shall LO handle the OpenOffice.org-minimal-version dependency?

Strictly speaking, LO 3.4/3.5 should still check against an 
OpenOffice.org-minimal-version value of 3.3, as that's the latest 
available (A)OOo version.  However, for LO 3.4, this check has (probably 
accidentally) been changed to 3.4 (and with the current code towards 
LO 3.5 it has yet again changed to 3.5).  I would argue to leave it at 
3.4 for both LO 3.4 and LO 3.5.  (For one, it can obviously no longer 
be changed back to 3.3 for LO 3.4, and changing it back to 3.3 for 
LO 3.5 would probably cause more confusion than its worth.  For another, 
semantically the check will likely be more-or-less correct, matching the 
features an AOOo 3.4 will presumably come out with.)  If no one objects, 
I will adapt LO 3.5 so that it still checks for 3.4, not 3.5.


In the future, when AOOo releases new versions after AOOo 3.4, we would 
need to check whether it semantically makes sense for LO to bump its 
OpenOffice.org-minimal-version check (i.e., whether the features of that 
new AOOo version are also available in LO).


** How to specify dependencies for newly introduced LO features?

One option would be to add an additional LibreOffice-minimal-version 
dependency.  Another option would be to actually make use of 
fine-grained dependencies and introduce them as needed (i.e., whenever 
an extension developer wants to make use of a new LO feature, a 
corresponding dependency would have to be added).


The former has as pro its ease of use.  The latter has as pro that it 
shows a way out of the problems caused by OpenOffice.org-minimal-version 
and for an opportunity of continued sharing of extensions across 
products:  If each extension only lists the features it requires, 
regardless of any product's version numbers, it becomes much easier to 
match that extension against a given product's capabilities, regardless 
of brand.


I'd tend to give the fine-grained dependencies a try.  That would 
require cooperation from extension developers (they would need to voice 
their demand for dependencies for specific features, and they would need 
to make accurate use of those dependencies in their extensions).  To 
achieve cross-product extension compatibility, it would also require 
some sort of advertising of LO's newly introduced fine-grained 
dependencies (so that other products---where possible---would pick them 
up together with the corresponding features), but we would need a place 
to document any newly introduced dependencies, anyway.


What do other people think here?

** What happens when LO 4 becomes incompatible?

In that case, any OpenOffice.org-minimal-version dependency, regardless 
of version value, should be considered as not satisfied by LO 4. 
Similarly, if we did introduce a LibreOffice.org-minimal-version 
dependency, any version value of that dependency less than 4 should be 
considered as not satisfied.  On the other hand, treatment of any 
fine-grained dependencies would have to be handled on a case-by-case basis.


Stephan
___
LibreOffice mailing list

Re: [Libreoffice] [REVIEW] 3-4 cherry-pick fix to build with gcj 1.5.0

2011-11-04 Thread Stephan Bergmann

On 11/04/2011 12:41 PM, Caolán McNamara wrote:

i.e. com.sun.org.apache.xerces.internal.parsers.DOMParser is a
sun/oracle-only java api. Commit
http://cgit.freedesktop.org/libreoffice/core/commit/?id=04c5a36ab8d514cfbe8e40f4493787b2ab392ab5
(attached) I believe does the right thing, definitely builds anyway.


Looking at the patch, 
javax.xml.parsers.DocumentBuilderFactory.newInstance() smells like it 
internally uses the context class loader, even if that is not documented 
at 
http://download.oracle.com/javase/7/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#newInstance() 
(and at least in some Sun JRE 6 it indeed does so), so this could fail 
if the context class loader is null---as can happen in LibO, see 
https://issues.apache.org/ooo/show_bug.cgi?id=102164#c6.


That is, the call to DocumentBuilderFactory.newInstance() within 
OfficeDocumentReportTarget would need to be wrapped in something like



DocumentBuilderFactory dbFactory;
ClassLoader old = Thread.currentThread().getContextClassLoader();
ClassLoader c = OfficeDocumentReportTarget.class.getClassLoader();
if (c != null) {
// otherwise, hope context class loader already contains a non-null value
OfficeDocumentReportTarget.class.getClassLoader(c);
}
try {
dbFactory = DocumentBuilderFactory.newInstance();
} finally {
if (c != null) {
Thread.currentThread().setContextClassLoader(old);
}
}


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


Re: [Libreoffice] [REVIEW] 3-4 cherry-pick fix to build with gcj 1.5.0

2011-11-04 Thread Stephan Bergmann

On 11/04/2011 02:53 PM, Caolán McNamara wrote:

On Fri, 2011-11-04 at 14:01 +0100, Stephan Bergmann wrote:

That is, the call to DocumentBuilderFactory.newInstance() within
OfficeDocumentReportTarget would need to be wrapped


Erm...

http://opengrok.libreoffice.org/search?q=DocumentBuilderFactory.newInstanceproject=coredefs=refs=path=hist=

Looks we're fairly riddled with this pattern. So presumably if this
problem affects DocumentBuilderFactory.newInstance we already suffer
from it in our xsltfilter and other places ?


The pattern probably here is that the problem is not noticed as long as 
the Java code is called from the main thread.  (The empty context class 
loader problem arises only for native threads other than the initial JVM 
thread that are attached to the JVM via JNI.  Threads spawned by the JVM 
inherit the calling thread's context class loader, and the thread on 
which the JVM is originally initialized explicitly obtains a non-null 
context class loader during initialization, IIRC).


Anyway, you have been warned.  ;)

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


Re: [Libreoffice] [REVIEW] 3-4 cherry-pick fix to build with gcj 1.5.0

2011-11-04 Thread Stephan Bergmann

On 11/04/2011 04:55 PM, Caolán McNamara wrote:

On Fri, 2011-11-04 at 16:23 +0100, Stephan Bergmann wrote:

Anyway, you have been warned.  ;)


Pfff, seems a sure route to madness to have to second guess every
possible java api over and above its documentation in case it uses some
ContextClassLoader under the hood. *shudder*, that'd be some audit
effort. Direct uses are one thing, but indirect hidden ones.


The context class loader is a dirty hack in the Java API, broken by 
design.  Just goes to show how bad global variables are.



Anyway, is your suggested wrapper correct ? Looks a bit odd now that I
actually read it as opposed to boggle at it.


Just wrote it down as a quick sketch, so surely contains all sorts of 
errors.



  Thread.currentThread().setContextClassLoader(c); //like so I guess?


yes, sure

Anyway, given the code in question is likely called from the main 
thread, so would not exhibit any more of a problem than all the already 
existing instances of DocumentBuilderFactory.newInstance(), and 
presumably already works fine in master, I'm indifferent to whether any 
context class loader handling would be needed for a 3.4 cherry-pick 
after all...  Consider it as approvingly reviewed by me either way.


(That said, I'll make a mental note to revisit the problem on master and 
maybe introduce some code abstraction to wrap around calls of 
DocumentBuilderFactory.newInstance() and similar constructs.)


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


Re: [Libreoffice] gcc bug on Debian packages ?

2011-11-06 Thread Stephan Bergmann

On 11/06/2011 08:04 PM, julien2412 wrote:

#2  0xb7c01d42 in *__GI_abort () at abort.c:92
#3  0xb7c3eaeb in malloc_printerr (action=2, str=0x6Address 0x6 out of
bounds, ptr=0xb7e72950) at malloc.c:6288
#4  0xb7c43446 in *__GI___libc_free (mem=0x6) at malloc.c:3699
#5  0xb7e3cabf in operator delete(void*) ()
from
/home/maryline/compile-libreoffice/libo/solver/unxlngi6/installation/opt/program/../ure-link/lib/libstdc++.so.6
#6  0x7b581329 in __gnu_cxx::new_allocatorchar::deallocate
(this=0xbfffd14b, __p=0xb7e72950 )
 at /usr/include/c++/4.6/ext/new_allocator.h:98
#7  0x7b580992 in std::string::_Rep::_M_destroy (this=0xb7e72950, __a=...)
at /usr/include/c++/4.6/bits/basic_string.tcc:451
#8  0x7b57ff74 in std::string::_Rep::_M_dispose (this=0xb7e72950, __a=...)
at /usr/include/c++/4.6/bits/basic_string.h:244
#9  0x7b57eeac in std::basic_stringchar, std::char_traitslt;char,
std::allocatorchar  ::~basic_string (this=0xbfffd22c,
 __in_chrg=optimized out) at
/usr/include/c++/4.6/bits/basic_string.h:534
#10 0x7b57e63f in sql::SQLString::~SQLString (this=0xbfffd22c,
__in_chrg=optimized out)
 at
/home/maryline/compile-libreoffice/libo/solver/unxlngi6/inc/mysqlcppconn/cppconn/sqlstring.h:33
#11 0x7b59ddb3 in connectivity::mysqlc::ODatabaseMetaData::getTables
(this=0x8ad0fc8, catalog=empty uno::Any, schemaPattern=%,
 tableNamePattern=%, types=uno::Sequence of length 3 = {...})
 at
/home/maryline/compile-libreoffice/libo/mysqlc/source/mysqlc_databasemetadata.cxx:1774


Looks like some sort of memory corruption, leading to deletion of a 
memory block at address 0x6, detected by your libc and causing an abort. 
 Try valgrind'ing it.


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


[Libreoffice] [PATCH] fix libreoffice-3-4 after make the 3D transitions work again

2011-11-07 Thread Stephan Bergmann
http://cgit.freedesktop.org/libreoffice/postprocess/commit/?h=libreoffice-3-4id=978f106a5e6851dc6e833ab33c437ad7baa2bb38 
make the 3D transitions work again causes libreoffice-3-4 build to 
fail for me in postprocess/packcomponents, not finding 
ogltrans.component.  Attached 0001-Fix-build-of-ogltrans.component.patch 
would fix that for me.  Please sign-off and commit.


Stephan
From 8ded95d08c34ab0253530f855b4e6a77d3c8c356 Mon Sep 17 00:00:00 2001
From: Stephan Bergmann sberg...@redhat.com
Date: Mon, 7 Nov 2011 21:23:24 +0100
Subject: [PATCH] Fix build of ogltrans.component

...now that postprocess/packcomponents wants to use it.
---
 slideshow/source/engine/OGLTrans/mac/makefile.mk |8 
 slideshow/source/engine/OGLTrans/unx/makefile.mk |8 
 slideshow/source/engine/OGLTrans/win/makefile.mk |4 ++--
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/slideshow/source/engine/OGLTrans/mac/makefile.mk 
b/slideshow/source/engine/OGLTrans/mac/makefile.mk
index aaaedb9..8f08080 100644
--- a/slideshow/source/engine/OGLTrans/mac/makefile.mk
+++ b/slideshow/source/engine/OGLTrans/mac/makefile.mk
@@ -85,3 +85,11 @@ DEF1EXPORTFILE=../exports.dxp
 # ==
 
 .INCLUDE : target.mk
+
+ALLTAR : $(MISC)/ogltrans.component
+
+$(MISC)/ogltrans.component .ERRREMOVE : $(SOLARENV)/bin/createcomponent.xslt \
+../ogltrans.component
+$(XSLTPROC) --nonet --stringparam uri \
+'$(COMPONENTPREFIX_BASIS_NATIVE)$(SHL1TARGETN:f)' -o $@ \
+$(SOLARENV)/bin/createcomponent.xslt ../ogltrans.component
diff --git a/slideshow/source/engine/OGLTrans/unx/makefile.mk 
b/slideshow/source/engine/OGLTrans/unx/makefile.mk
index 31066e3..2b31ac7 100644
--- a/slideshow/source/engine/OGLTrans/unx/makefile.mk
+++ b/slideshow/source/engine/OGLTrans/unx/makefile.mk
@@ -71,3 +71,11 @@ DEF1EXPORTFILE=../exports.dxp
 # ==
 
 .INCLUDE : target.mk
+
+ALLTAR : $(MISC)/ogltrans.component
+
+$(MISC)/ogltrans.component .ERRREMOVE : $(SOLARENV)/bin/createcomponent.xslt \
+../ogltrans.component
+$(XSLTPROC) --nonet --stringparam uri \
+'$(COMPONENTPREFIX_BASIS_NATIVE)$(SHL1TARGETN:f)' -o $@ \
+$(SOLARENV)/bin/createcomponent.xslt ../ogltrans.component
diff --git a/slideshow/source/engine/OGLTrans/win/makefile.mk 
b/slideshow/source/engine/OGLTrans/win/makefile.mk
index 7da3787..7f0ac88 100644
--- a/slideshow/source/engine/OGLTrans/win/makefile.mk
+++ b/slideshow/source/engine/OGLTrans/win/makefile.mk
@@ -74,7 +74,7 @@ DEF1EXPORTFILE=../exports.dxp
 ALLTAR : $(MISC)/ogltrans.component
 
 $(MISC)/ogltrans.component .ERRREMOVE : $(SOLARENV)/bin/createcomponent.xslt \
-ogltrans.component
+../ogltrans.component
 $(XSLTPROC) --nonet --stringparam uri \
 '$(COMPONENTPREFIX_BASIS_NATIVE)$(SHL1TARGETN:f)' -o $@ \
-$(SOLARENV)/bin/createcomponent.xslt ogltrans.component
+$(SOLARENV)/bin/createcomponent.xslt ../ogltrans.component
-- 
1.7.6.4

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


[Libreoffice] SolidMarkHandles

2011-11-08 Thread Stephan Bergmann

Hi all,

Looks like 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ec4f69493b50c15861b0cdcc290ecedd00efb51d 
removed Simple Handles option removed support for SolidMarkHandles 
property from sw/source/ui/uno/unomod.cxx while it is still listed in 
offapi/com/sun/star/text/ViewSettings.idl and checked in qadevOOo 
(mentioned in 
qadevOOo/objdsc/sw/com.sun.star.comp.office.SwXViewSettings.csv, 
qadevOOo/tests/basic/ifc/text/ViewSettings/test_ViewSettings.xba, and 
qadevOOo/tests/java/ifc/text/_ViewSettings.java), and so broke sw_unoapi 
subsequenttest:



Creating: sw.SwXViewSettings
[...]
LOG Execute: SolidMarkHandles
LOG Tested XPropertySet does not contain'SolidMarkHandles' property
Method SolidMarkHandles finished with state FAILED
LOG SolidMarkHandles: PASSED.FAILED
[...]
* State for sw.SwXViewSettings::com::sun::star::text::ViewSettings **
[sw.SwXViewSettings::com::sun::star::text::ViewSettings::SolidMarkHandles] is 
testcode: [SolidMarkHandles] - PASSED.FAILED


Given that SolidMarkHandles is listed in com.sun.star.text.ViewSettings, 
it is unclear to me whether it should indeed be removed?


(Btw, SolidMarkHandles is also still mentioned in 
sw/source/core/unocore/unoprnms.cxx, 
binfilter/bf_sw/source/core/unocore/sw_unoprnms.cxx, and 
binfilter/bf_sw/source/ui/uno/sw_unomod.cxx.)


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


Re: [Libreoffice] Extension dependencies

2011-11-09 Thread Stephan Bergmann

On 11/04/2011 01:33 PM, Eike Rathke wrote:

On Friday, 2011-11-04 13:02:02 +0100, Thorsten Behrens wrote:

I'd tend to give the fine-grained dependencies a try.


That won't work in practice, unless those can be
(semi-)automatically generated. Experience shows that all
programmers are lazy, and seldomly go extra miles.


Seconded, but some do, if it's achievable without a hyper-duper
incomprehensible framework.. Would it be possible to have both, a simple
version dependency, and if fine grained dependencies are present use
those as well?


Not sure if that's not starting to become overengineered, then.  The 
past has shown that most extension writers (even including core 
developers from inside HH that would have benefited from short and 
direct communication channels) are rather happy with quick and dirty 
dependencies (in some cases, it even looks like they are simply copied 
over from some other extension blueprint), so---if both a coarse grained 
and fine grained dependencies were available---would probably only 
bother to use the coarse grained, anyway.


Its true that this past experience looks counter to my enthusiasm to 
give the fine-grained dependencies a try---maybe I was too enthusiastic 
indeed.  Its also true that some mechanism to mechanically compute 
fine-grained dependencies for a given extension would be helpful, but 
I'm not sure the work is worth it.  (But volunteers are surely welcome!)


The good thing about those dependencies is that we could in principle 
wait until some extension developer expresses demand for one, either 
fine or coarse grained, and only then implement it.  Again in practice, 
however, that's not how it has turned out to work.  Extension developers 
make use of the dependencies they find available and rarely bother to 
ask for additional ones.  (And I don't blame them; this is surely 
tedious stuff where everybody is happy taking the easy way out.)


So, I think I will just introduce a new LibreOffice-minimal-version 
dependency after all.


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


Re: [Libreoffice] SolidMarkHandles

2011-11-10 Thread Stephan Bergmann

On 11/08/2011 10:29 PM, Stephan Bergmann wrote:

Given that SolidMarkHandles is listed in com.sun.star.text.ViewSettings,
it is unclear to me whether it should indeed be removed?


From private replies I received, I gather that the above was probably 
not phrased clearly enough to get my point across.  Let me rephrase: 
As class SwXViewSettings (sw/source/ui/uno/unomod.cxx) claims it

supports UNO service com.sun.star.text.ViewSettings, and that
published service contains a SolidMarkHandles property, I do not think
it is sound to remove support for it from SwXViewSettings towards LibO
3.5 (instead of, say, a potentially incompatible LibO 4).

An alternative, if SolidMarkHandles is really useless, bogus, and---with 
sufficiently high probability---not used by any external clients, would 
be to remove it from the published UNO API for LibO 3.5 (making it 
technically incompatible, but in a way that---hopefully---nobody 
notices).  I gather that this alternative is already discussed (off this 
list) and that Tim's patch posted to this thread would just achieve that.


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


Re: [Libreoffice] Extension dependencies

2011-11-10 Thread Stephan Bergmann

On 11/10/2011 12:24 PM, Cor Nouws wrote:

b. Will it be necessary with the new LibreOffice-minimal-version
dependency to have separate extensions for LibreOffice and OpenOffice or
will that be optional?


As long as a given extension works fine with both LO and OOo, there's no 
need to add a LibreOffice-minimal-version dependency to the extension at 
all.  An already existing OpenOffice.org-minimal-version (if one is 
needed at all) will still suffice.


And when the extension uses features only available in LO (and thus 
needs a LibreOffice-minimal-version dependency), that extension will not 
work in OOo anyway.


;)

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


[Libreoffice] New LO_{LIB, JAVA}_DIR make special inbuild component handling superfluous

2011-11-10 Thread Stephan Bergmann
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1bd2a254b4a22a02d515b084dabafe963f175ff 
does away with the need for specially crafted *.inbuild.component files. 
 It replaces the $BRAND_BASE_DIR/program[/classes] paths in the 
component files with ones based on new bootstrap varialbes LO_LIB_DIR 
(i.e., $BRAND_BASE_DIR/program) and LO_JAVA_DIR (i.e., 
$BRAND_BASE_DIR/program/classes) set in the fundamental ini.  In-build 
uses simply need to set those variables now (uses in CppunitTest.mk etc. 
already modified accordingly).


I tested this on a clean build only, non-clean builds may stumble over 
stale component files (when doing unit checks etc.).  If that is the case,


  find */${INPATH?}/ -name \*.component -exec rm {} \;

should clean up enough (and not be too expensive).

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


Re: [Libreoffice] build fail in scripting/Jar/aportisdoc

2011-11-10 Thread Stephan Bergmann

On 11/11/2011 08:03 AM, Noel Grandin wrote:

c:\libreoffice\libo\scripting\java\com\sun\star\script\framework\provider\java\ScriptProviderForJava.java:50:
 package com.sun.star.script.framework.container does not exist
import com.sun.star.script.framework.container.ScriptMetaData;


We used to have problems like this one (and I *think* it was also in 
scripting) like a few weeks ago.  It always went away on a second 
attempt to build the module, and I think it was finally solved by fixing 
some error in the gbuild system.


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


Re: [Libreoffice] Dumping to valgrind.log from soffice shell script needed?

2011-11-11 Thread Stephan Bergmann

On 10/26/2011 09:00 PM, Stephan Bergmann wrote:

On 10/26/2011 01:55 PM, Petr Mladek wrote:

What is your preferred way of use?
What exactly do you hate and/or miss?


One problem is output of multiple (batched, like make subsequentcheck)
valgrind'ed invocations of soffice.bin is lost.

Another problem is attaching a debugger (VALGRIND_OPTS=--db-attach=yes)
does not work.


So, meanwhile I had thought that I can somehow live with the 
inconvenience the automatic-valgrind.log feature brings, trying to 
remember to remove the relevant line from the soffice script in 
scenarios where it matters.


But today I had to find out that even a single invocation of the 
sw/qa_complex test internally starts multiple soffice instances in a 
row, and coming back to a multi-hour valgrind run of that test all I got 
was a most unhelpful valgrind.log for a single soffice invocation.


This feature turns out to be a real productivity problem for me after 
all.  Petr, can you please re-consider whether it is really too much to 
ask your clients to type


  VALGRIND=memcheck soffice 2valgrind.log

instead of

  VALGRIND=memcheck soffice

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


[Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-11 Thread Stephan Bergmann
With LO 3.5 by default using (new in ODF 1.2) AES encryption for 
password-protected documents (instead of Blowfish as used in older 
versions), people still using LO 3.4 would be unable to open such 
documents.  (And what's really ugly, all they would get is an 
incomprehensible error box Format error discovered in the file in 
sub-document styles.xml at 1,0 (row,col).)


http://pkgs.fedoraproject.org/gitweb/?p=libreoffice.git;a=blob;f=Backport-reading-AES-encrypted-ODF-1.2-documents.patch;h=e6c722598ab05464f09787355b621cbb0aa07c49;hb=e7a803540d408adab3d55fb2ae051ac4be599a72 
is a patch (actually, four separate patches for the components, 
lib-core, lib-gui, and ure repos) to backport support for reading (but 
not writing) AES-encrypted ODF 1.2 documents to libreoffice-3-4.  It is 
effectively all of CWS mav60 plus one additional typo fix, minus the 
writing support from mav60, and as such is quite large.


An alternative might be to cherry-pick the relevant commits from master 
into libreoffice-3-4, but that would have the drawback that it would 
cause later LO 3.4.y to write password-protected ODF documents using AES 
which earlier LO 3.4.x could no longer open---something that might not 
be desirable for a micro update.  Plus, the number of commits that would 
need to be picked would be quite large, too (the individual commits of 
mav60 are quite intertwined).


If people are happy with the linked patch: fine.  If people would prefer 
a cherry-picking approach, I could post a list of relevant commits 
(technically, I produced the patch in a different way, more or less 
applying mav60 to libreoffice-3-4 directly, so do not have that list 
handy).  (And if there are objections against including this in the 3.4 
code line at all, that would of course be fine as well.)


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


[Libreoffice] Make .component files directly usable within UNO_SERVICES

2011-11-11 Thread Stephan Bergmann
http://cgit.freedesktop.org/libreoffice/core/commit/?id=f66ac2934303e789014741547a06c98ab5433ca0 
makes tests a little simpler (but also requires another round of find 
*/${INPATH?}/ -name \*.component -exec rm {} \; for non-clean builds):


* solenv/bin/createcomponent.xslt now simply surrounds it output by 
components, so all the generated component files can be directly 
consumed as service rdbs (as listed in the UNO_SERVICES bootstrap 
variable) by the UNO runtime.


* solenv/gbuild/CppunitTest.mk got new functions 
gb_CppunitTest_add[_old]_component[s] (like their gb_RdbTarget_ 
predecessors), to directly list such component files in CppUnit tests.


* This obsoleted current uses of solenv/gbuild/RdbTarget.mk, which also 
does not work currently, as it catenates the input component files 
instead of passing them through packcomponents.xslt (which now takes 
care about the surrounding components in the input).  In the future, 
it will likely be combined with solenv/gbuild/ComponentsTarget.mk (which 
I invented recently to generate via packcomponents.xslt the 
multi-component files used by oxt extensions, unaware that RdbTarget.mk 
would already do the same thing; also, it turned out I did not need to 
create such oxt extensions at that time at all, so ComponentsTarget.mk 
is currently unused.)


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


Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-11 Thread Stephan Bergmann

On 11/11/2011 11:12 AM, Cor Nouws wrote:

Stephan Bergmann wrote (11-11-11 10:50)


is a patch (actually, four separate patches for the components,
lib-core, lib-gui, and ure repos) to backport support for reading (but
not writing) AES-encrypted ODF 1.2 documents to libreoffice-3-4.


Is included in the patch, that when a encrypted document is opened in
3.4.n and saved again, people are informed about the change in encryption?


No.

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


Re: [Libreoffice] Howto develop an extension with URE?

2011-11-13 Thread Stephan Bergmann

On 11/12/2011 12:43 PM, Michael Meeks wrote:

It seems a nonsense to me to not ship the pre-built C++ headers in the
sdk - particularly if that would make things easier for developers.

Stephan - is there a really good reason for not doing that ? clearly
the easier we make the sdk to use the better, and those headers can be
cut/pasted around / included into the code without problems surely.


No fundamental reason not to.  Probably more directed by the rationale 
to not ship what is easily (for whatever definition of easily) 
generated.  And I gather that if you use the SDK in the intended way, 
the included makefiles take care of header generation just fine.  (I do 
not argue that the way the SDK was designed to be used is necessarily 
useful, however.)  Plus, as soon as you want to introduce your own 
UNOIDL constructs, you need to use cppumaker etc. anyway.


Feel free to go ahead, I would say.

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


Re: [Libreoffice] Howto develop an extension with URE?

2011-11-14 Thread Stephan Bergmann

On 11/12/2011 03:09 PM, Christian Ehrlicher wrote:

Ok, next step - is it correct that I don't need a custom rdb anymore? The
example formerly created an own rdb but is now using offapi.rdb from basis-
link/program
The old rdb creation procedure also used some libs which are not there anymore
- remotebridge.uno.so and bridgefac.uno.so


Conceptually, there are two kinds of rdbs, those for types and those for 
services.  For types, LibO itself uses a types.rdb in the URE layer (for 
the general URE types) and an offapi.rdb in the basis layer (for the 
office-suite-specific types).  For services, LibO similarly uses a 
services.rdb in the URE layer and one in the basis layer.



Now when I try to use the provided rdb I get an error when I try to load a
document:
LoadFromUrl failed: Binary URP bridge disposed during call -
file:///home/chehrlic/Dokumente/test.odp
Out of curiosity the documentloader example can load my document and I can't
find a difference between the example and my code.


Binary URP bridge disposed during call indeed hints at broken 
plumbing, like the two ends of the bridge using different type 
descriptions (which appears unlikely if you use the offapi.rdb from 
LibO's basis layer---together with the types.rdb from LibO's URE layer) 
or something like that.


The easiest would be if you presented a (stripped down) version of your 
failing code.  It might be that you fail to include the URE's types.rdb, 
for example.


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


Re: [Libreoffice] [PATCH] Replace command domainname by getdomainname() on Unix

2011-11-14 Thread Stephan Bergmann

On 11/13/2011 03:42 PM, Lionel Elie Mamane wrote:

On Sun, Nov 13, 2011 at 03:04:57PM +0100, Arnaud Versini wrote:


I've seen it is used by using gdb on
_osl_getFullQualifiedDomainName. I don't remember how but I could
provide you the bt after the build. It's not directly but
_osl_getFullQualifiedDomainName is used during file locking.


That's probably for the name of the lockfile: If the same user runs LO
on two different machines that share (part of) the filesystem through
NFS, the lockfile should not have the same name so that the LO on one
machine does not see the lock of the LO on the other machine.


No, IIRC, that data ends up in the content of the lock file. So that (a) 
a meaningful message about who is currently locking a file can be 
presented upon concurrent access, and (b) a stale lock file from a 
crashed soffice instance run by the same user can be detected.


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


Re: [Libreoffice] Updating external to new version: mysqlcppconn

2011-11-14 Thread Stephan Bergmann

On 11/13/2011 02:41 AM, Lionel Elie Mamane wrote:

2) The tarball downloaded from mysql.com unpacks into
mysql-connector-c++-1.1.0, not mysql-connector-cpp. Am I supposed
to repackage the tarball so that it unpacks into
mysql-connector-cpp or to change makefile.mk to adapt to the new
name? (FYI, in my local copy, I have changed makefile.mk to adapt
to the new name.)


Yes, adapting makefile.mk sounds like right thing to do here.

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


Re: [Libreoffice] compile fails: solver/unxlngx6.pro/xml/ure/services.rdb not created

2011-11-14 Thread Stephan Bergmann

On 11/13/2011 01:28 PM, Luc Castermans wrote:

So I read 2 different names: uno_services.rdb and service.rdb; should
they be identical?


No, those two files are unrelated.

Your initial problem (missing solver/unxlngx6.pro/xml/ure/services.rdb 
is odd).  What does


  . Env.Host.sh  cd ure/source  dmake  deliver -verbose

give (if make clean did not succeed for you in the meantime)?

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


Re: [Libreoffice] compile fails: solver/unxlngx6.pro/xml/ure/services.rdb not created

2011-11-14 Thread Stephan Bergmann

On 11/13/2011 10:11 PM, Chr. Rossmanith wrote:

So it's save to remove .component files because they are regenerated
during building LibO? And the same is valid for .rdb's?


Removing .component files in the output should always be safe.  For .rdb 
files, some of them (the services ones) are generated in a two-step 
process, where the first step is the creation of some .input file (next 
to the .rdb file in the module's local output tree).  If you do not 
remove that .input file, the .rdb will be regenerated with potentially 
outdated data again.


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


Re: [Libreoffice] [Bug 42865] New: MySQL native driver: free() on non-heap pointer; in debug mode abort()

2011-11-14 Thread Stephan Bergmann

Lionel,

I must admit I'm confused.  On my system,


~ objdump -T /usr/lib64/libstdc++.so.6 | grep _ZNSs4_Rep20_S_empty_rep_storageE
003e504f45a0 gDO .bss  0020 GLIBCXX_3.4 
_ZNSs4_Rep20_S_empty_rep_storageE



~ objdump -T /usr/lib64/libmysqlcppconn.so | grep 
_ZNSs4_Rep20_S_empty_rep_storageE
  DO *UND*  GLIBCXX_3.4 
_ZNSs4_Rep20_S_empty_rep_storageE



~ objdump -t mysqlc/unxlngx6/lib/mysqlc.uno.so | grep 
_ZNSs4_Rep20_S_empty_rep_storageE
003dbe40 l O .bss  0020 
_ZNSs4_Rep20_S_empty_rep_storageE


That is, libstdc++.so.6 exports the symbol with version GLIBCXX_3.4 and 
libmysqlcppconn.so links against it, while mysqlc.uno.so emits its own 
definition of the symbol (as a local symbol, due to the map file).  Do 
you have an idea why mysqlc.uno.so emits its own definition at all?


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


Re: [Libreoffice] [PUSHED] add sqlite path to library path for unit tests

2011-11-15 Thread Stephan Bergmann

On 11/14/2011 11:49 PM, Markus Mohrhard wrote:

could someone without system libsqlite give the following patch a try.
Apply and rebuild sc. In theory the testPassword test should work
without a problem.


Checked on Linux with system libsqlite3.so removed.

I tweaked the patch a little, introducing gb_Helper_extend_ld_path for 
cases where gb_Helper_set_ld_path is not enough (like the uses of 
gb_CppunitTest_CPPTESTPRECOMMAND).  I noticed that many of the recently 
introduced solenv/gbuild/platform/OS_CPU_COMPILER.mk hardcode the value 
of gb_CppunitTest_CPPTESTPRECOMMAND, instead of going through 
gb_Helper_set_ld_path where applicable (and are also not modified by 
Markus' original patch)---I left them alone for now.


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


Re: [Libreoffice] [PUSHED] add sqlite path to library path for unit tests

2011-11-15 Thread Stephan Bergmann

On 11/15/2011 10:14 AM, Thorsten Behrens wrote:

Stephan Bergmann wrote:

I noticed that many of the recently introduced
solenv/gbuild/platform/OS_CPU_COMPILER.mk hardcode the value of
gb_CppunitTest_CPPTESTPRECOMMAND, instead of going through
gb_Helper_set_ld_path where applicable...


Sounds like an easy hack?


Not sure.  Given that, for example, 
solenv/gbuild/platform/DRAGONFLY_INTEL_GCC.mk currently first includes a 
definition of gb_CppunitTest_CPPTESTPRECOMMAND via the included 
solenv/gbuild/platform/unxgcc.mk and then provides its own, overriding 
definition, this looks more like it needs some knowledgeable clean up.


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


Re: [Libreoffice] Extension dependencies

2011-11-15 Thread Stephan Bergmann

On 11/09/2011 09:45 AM, Stephan Bergmann wrote:

So, I think I will just introduce a new LibreOffice-minimal-version
dependency after all.


http://cgit.freedesktop.org/libreoffice/core/commit/?id=8a993919377f0b602b7db88d1de6696b21a11cbf 
does that, see 
https://wiki.documentfoundation.org/Development/Extension_Development 
for details.


Developers of products derived from LO beware:  The value of the LO 
reference version (against which the actual values in such extension 
dependencies are compared) is taken from the 
/org.openoffice.Setup/Product/ooSetupVersionAboutBox configuration item 
(as that, unlike ooSetupVersion, contains all of major, minor, micro), 
which in turn obtains its value from the ABOUTBOXPRODUCTVERSION variable 
defined in instsetoo_native/util/openoffice.lst.  If you change that 
value to no longer match the value for the underlying LO reference 
version, you need to adapt the code in 
desktop/deployment/misc/dp_dependencies.cxx accordingly.


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


Re: [Libreoffice] Extension dependencies

2011-11-15 Thread Stephan Bergmann

On 11/15/2011 01:39 PM, Christophe Strobbe wrote:

At 09:59 4-11-2011, Stephan Bergmann wrote:

Each .oxt extension can carry any number of dependencies, specifying
conditions that need to be met by the hosting LO installation for the
extension to be successfully deployable (see
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Dependencies).



This page links to http://openoffice.org/extensions/description/2006,
which returns an ERROR 404, so even if an extension developer wanted to
document more detailed dependencies, they would not know what syntax or
elements to use in their description.xml file.


http://openoffice.org/extensions/description/2006; is only used as an 
XML namespace name on that page.  URLs used as XML namespace names are 
not generally expected to be dereferencable (and are often not).  (That 
the wiki software used for that page displays that string as a browsable 
link appears to be an unfortunate mis-feature.)


The general syntax for dependencies within description.xml is described 
on that page, in the second-last paragraph (that also contains the 
mis-links).  For the description of individual dependencies, follow the 
link to 
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements#Element_.2Fdescription.2Fdependencies 
labelled XML description for description.xml in the See also section 
at the bottom of the page.  (And for the description of individual 
dependencies relative to LO instead of OOo, 
https://wiki.documentfoundation.org/Development/Extension_Development 
is the new starting point.)



I was confronted with this problem just today because a new Java-based
extension cannot be installed on some Ubuntu systems even though it
installs without problems on Windows and some other Ubuntu systems.
The extension manager displayed the following error dialog:
(com.sun.star.deployment.DeploymentException) { { Message = An error
occurred while enabling: accessodf-addon.jar, Context =
(com.sun.star.uno.XInterface) @a403870 }, Cause = (any) {
(com.sun.star.registry.CannotRegisterImplementationException) {{ Message
= , Context = (com.sun.star.uno.XInterface)} @0 } } } }

It turns out that this issue can be solved with
sudo apt-get install libreoffice-java-common

So I thought about how to document that dependency in description.xml,
but I couldn't ... (And libreoffice-java-common or
openoffice.org-java-common may be rather broad.)


Yes, extension dependencies are currently only able to express 
dependencies on a complete LO installation.  Dependencies that are not 
fulfilled because only a subset of LO functionality is installed are not 
supported.  (And note that what those available subsets are is typically 
also specific to each LO distribution, even if the optional module 
structure in scp2 sets some common ground.)


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


Re: [Libreoffice] Extension dependencies

2011-11-15 Thread Stephan Bergmann

On 11/15/2011 04:53 PM, Christophe Strobbe wrote:

Ah, yes. I was hoping to find some information on the Others item in
the list of child elements at
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Extensions/Description_of_XML_Elements#Element_.2Fdescription.2Fdependencies.
My hope got the better of my XML knowledge :-(


How the information about dependencies is organized in the DevGuide is 
indeed not very user friendly...



OK. I have put a warning about sudo apt-get install
libreoffice-java-common on the extension's download page.
The error caused by the missing dependency was fairly serious; it caused
my Ubuntu-inside-VirtualBox installation to completely freeze in some
cases.


So it froze up when it displayed that inscrutable 
(com.sun.star.deployment.DeploymentException) ... dialog?


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


Re: [Libreoffice] [Libreoffice-commits] .: sc/inc sc/source

2011-11-15 Thread Stephan Bergmann

On 11/16/2011 06:45 AM, Kohei Yoshida wrote:

I would encourage you to not do this style of implicit inlining in your
code, sure, but I wouldn't want you go wild and start editing a bunch of
headers just for the sake of it.


While we are at it:  Not inlining functions can be especially beneficial 
for functions that are exported from a library.  For example, not 
inlining the destructor of a class with virtual functions gives the 
compiler a definite place to put the vtable, so it need not be 
duplicated across all the libraries that derive from that class.


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


Re: [Libreoffice] Extension dependencies

2011-11-15 Thread Stephan Bergmann

On 11/15/2011 05:33 PM, Christophe Strobbe wrote:

Actually, the first times I tried to install the extension, I got an
empty error dialog (I assumed it was an error dialog), and the system
froze.
More recently, I tried a more recent version of the extension, and this
time I got the error dialog with the puzzling DeploymentException. I
opened a command line and did ps -ax and killed one of the processes
(I can't remember which one). However, this only worked because I had
not wasted time copying the text in a text editor - which is what I did
the first time. Apparently, it was important to kill the process that
spawned the error dialog before it froze up the complete OS.

This all happened in LibreOffice 3.3.4 [OOO330m19 (Build:401)] on Ubuntu
11.04 (Natty Narwhal) inside VirtualBox.


Cannot reproduce this with current master-towards-3.5 build on Fedora 15 
x86_64:  Built the active.oxt from desktop/test/deployment/active (that 
contains a Java component that needs active Java registration during 
extension deployment) and removed ure/share/java/ridl.jar from the LO 
installation set.  Both soffice active.oxt and unopkg gui active.oxt 
display an error dialog but do not freeze.


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


Re: [Libreoffice] uno discoverability

2011-11-16 Thread Stephan Bergmann

On 11/16/2011 11:25 AM, Michael Meeks wrote:

IMHO we need to make that code efficient by having a var-args style
helper:

throw FooException(Failure loading file '%S' code %d,
   aOUStr.pData, nCode);

That would also be fairly code size efficient as well vs. the
heavy-lifting, and big string-buffer construction madness :-)


This (as well as cooking something up using OSL_FORMAT) would have the 
disadvantage that it potentially converts data from UTF-16 to char 
(%S) and then from char to UTF-16 (as UNO Exception's Message is of 
type rtl::OUString).


It seems like all attempts at true improvement in this area always 
collide with rtl::OUString being neither UTF-8 (i.e., layout compatible 
with plain char) nor wchar_t (at least on Linux etc.; and using GCC's 
-fshort-wchar would not help, as it breaks binary compatibility with 
libstdc++).  We'll probably wait until either all relevant compilers 
support C++11's new character types, or we incompatibly change 
rtl::OUString to UTF-8 (whatever happens first).



It'd be great to use a more pleasant format like Stephan's new configmr
XML - if we can get the performance we need there; and of course add the
API docs to some parallel docs file, only loaded when needed
(interactively by developers). But of course it's a good idea.


For types.rdb, my vision is to either use an XML format or, IMO even 
better, a new .idl format that is (a) less verbose (why the heck all 
those ; in there, etc.?) and (b) does not rely on a preprocessor. 
Then, a types.rdb could effectively be just one large .idl file.


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


Re: [Libreoffice] [Libreoffice-commits] .: testtools/source

2011-11-16 Thread Stephan Bergmann

On 11/17/2011 12:38 AM, Jan Holesovsky wrote:

  testtools/source/bridgetest/makefile.mk |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

New commits:
commit 4f11d0aa461537efa2705e7b49bc2c828a700e43
Author: Jan Holesovskyke...@suse.cz
Date:   Wed Nov 16 22:57:28 2011 +0100

 Revert the component.map removal from makefile to fix Windows build.


Can somebody with a working Windows build try out whether adding lines

  SHL1IMPLIB = i$(SHL1TARGET)
  SHL2IMPLIB = i$(SHL2TARGET)

would allow to revert the revert and keep Windows happy (it would at 
least not break the Linux build)?  I'm actually not really sure, because 
these libs are built differently than others (via LIBnTARGETs, probably 
because they share common objects), but in other cases that use 
SHLnUSE_EXPORTS=name, a SHLnIMPLIB was necessary for some reason or 
other (that I cannot remember; I always use configmgr/source/makefile.mk 
as a blueprint for building a dmake-based UNO component with 
visibility---I once tweaked that one with Ause until it was exactly 
what's needed, without any obsolete cruft).


Stephan


diff --git a/testtools/source/bridgetest/makefile.mk 
b/testtools/source/bridgetest/makefile.mk
index cc3661a..31c5b7e 100644
--- a/testtools/source/bridgetest/makefile.mk
+++ b/testtools/source/bridgetest/makefile.mk
@@ -88,7 +88,7 @@ SHL1STDLIBS= \
  SHL1LIBS= $(LIB1TARGET)
  SHL1DEF=  $(MISC)$/$(SHL1TARGET).def
  DEF1NAME= $(SHL1TARGET)
-SHL1USE_EXPORTS = name
+SHL1VERSIONMAP = $(SOLARENV)/src/component.map

  #  test object 

@@ -107,7 +107,7 @@ SHL2STDLIBS= \
  SHL2LIBS= $(LIB2TARGET)
  SHL2DEF=  $(MISC)$/$(SHL2TARGET).def
  DEF2NAME= $(SHL2TARGET)
-SHL2USE_EXPORTS = name
+SHL2VERSIONMAP = $(SOLARENV)/src/component.map

  SHL3TARGET = constructors.uno
  SHL3OBJS = $(SLO)$/constructors.obj

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


Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-17 Thread Stephan Bergmann

On 11/11/2011 12:01 PM, Stephan Bergmann wrote:

On 11/11/2011 11:12 AM, Cor Nouws wrote:

Is included in the patch, that when a encrypted document is opened in
3.4.n and saved again, people are informed about the change in
encryption?


No.


I see.  When you modify and save an encrypted document, you are not 
asked for the password again,  So to the user that does not appear like 
a save afresh as an encrypted document (in which case I would consider 
it plausible that the document is silently saved with the 3.4 encryption 
mechanism) but more like a plain update existing stored document.


Stephan

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


Re: [Libreoffice] [Libreoffice-qa] [REVIEWED] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-17 Thread Stephan Bergmann

On 11/17/2011 12:42 PM, Michael Meeks wrote:

On Thu, 2011-11-17 at 10:30 +, Caolán McNamara wrote:

On Thu, 2011-11-17 at 10:10 +, Michael Meeks wrote:

Out of interest - has Fedora shipped this yet ? and what was the
feedback like ?


It's in rawhide, i.e. will-be-F17, so its out there in our development
series with no obvious cockups yet, but no massive testing yet in
production series.


Thanks, we get some good bug reports from rawhide I guess, so that is
encouraging. Being of a lazy disposition, it'd be wonderful if you /
Stephan could cherry-pick / merge the patch to libreoffice-3-4 :-)


Yes, I can do the inclusion into -3-4.  AFAIU, Michael Stahl was also 
just looking at the patch, will wait until he gives a green light, too.


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


Re: [Libreoffice] Unable to build moz

2011-11-17 Thread Stephan Bergmann

On 11/16/2011 05:23 PM, Marc-André Laverdière wrote:

My autogen options now are:
--with-num-cpus=4
--with-system-libs
--with-system-headers
--with-system-dicts
--enable-lto


Maybe --enable-lto is not a good idea.

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


Re: [Libreoffice] unable to pass tests ...

2011-11-17 Thread Stephan Bergmann

On 11/17/2011 05:16 PM, Kevin Hunter wrote:

- file://[...]/libreoffice/workdir/unxlngx6.pro/ComponentTarget/uno
xml/source/rdf/unordf.component: component has empty uri attribute


Looks like you fell victim to the component file mess (where last round 
of mess there was that a make clean in one module can corrupt 
component files from other modules).  Please try a global


  find */${INPATH?}/ -name \*.component -exec rm {} \;

followed by a global make check again.

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


Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-18 Thread Stephan Bergmann

On 11/17/2011 10:37 PM, Cor Nouws wrote:

Stephan Bergmann wrote (17-11-11 09:02)

On 11/11/2011 11:12 AM, Cor Nouws wrote:



Is included in the patch, that when a encrypted document is opened in
3.4.n and saved again, people are informed about the change in
encryption?


No.


I see. When you modify and save an encrypted document, you are not asked
for the password again, So to the user that does not appear like a save
afresh as an encrypted document (in which case I would consider it
plausible that the document is silently saved with the 3.4 encryption
mechanism) but more like a plain update existing stored document.


Thanks for this clarification. Even better this way.


Not sure we're not talking past each other here.  My clarification is 
meant to clarify that yes, the patch leaves us with a somewhat 
unfortunate result.



(I was already thinking of a clear message for the release notes, but
that's superfluous now.)


You mean, superfluous to think of a clear message yourself, or 
superfluous to include a message in the release notes?


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


Re: [Libreoffice] [PUSHED, partial] Remove NULL checks from delete

2011-11-18 Thread Stephan Bergmann

On 11/10/2011 12:05 AM, Andrew Douglas Pitonyak wrote:

I would feel safer if pointers were set to NULL (or nullptr if we
support C++11) since it is not safe to delete a pointer twice.


I would rather argue that adding redundant p = 0; following a delete 
p; makes our code worse, not better (even if that may sound paradoxical 
at first):


For code to be maintainable, you need to be able to reason about it. 
One important concept here is to abstract over the typically huge space 
of potential program states, by introducing invariants.


For each use of a pointer in a C/C++ program text, an important piece of 
information is whether the pointer (a) is guaranteed to always point to 
valid memory when execution of the program passes that textual 
occurrence, (b) is guaranteed to never point to valid memory, or (c) can 
point to either valid or invalid memory.  It is highly desirable to be 
able to attach an invariant to each such textual occurrence.  Either the 
invariant that the pointer is guaranteed to always point to valid memory 
(so that, e.g., the pointer can be dereferenced), or the invariant that 
it is guaranteed to always not point to valid memory (so that, e.g., the 
pointer can be assigned a new value without having to delete its old 
value first).


If such an invariant can be attached to each occurrence of a given 
pointer, there is obviously no need to null the pointer after deletion.


However, if you do add that nulling, people will start to wonder what it 
is good for.  They will assume that it is there for a reason, that from 
this textual occurrence of nulling the pointer other occurrences of 
using that pointer in the program text can be reached for which it 
cannot be guaranteed that the pointer always either points to valid or 
invalid memory.  So that those other occurrences need a way to check 
what state the pointer is in before they dereference it, by first 
comparing the pointer against null, like


  if (p) {
 p-foo();
  } else {
 ???
  }

So the code is made more complex for no reason.  People will stop to 
understand the invariants that were once attached to each occurrence of 
p, and will instead assume that at each occurrence of p the worst will 
have to be assumed and catered for.  But what to put into that else 
branch?  Defensive programming perversion.  It won't be long until the 
first bug is introduced that goes unnoticed because it is hidden by one 
of those defensive else branches.


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


Re: [Libreoffice] Build fail in binfilter on Ubuntu 11.10

2011-11-18 Thread Stephan Bergmann

On 11/17/2011 08:16 PM, Alex Thurgood wrote:

If I disable the binfilter compilation, the build completes. This is
with the latest pulls from master, and even after a make clean.


But you also pulled the binfilter repo (./g pull), right?

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


Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-18 Thread Stephan Bergmann

On 11/18/2011 02:21 PM, Cor Nouws wrote:

So I have to interpret it as:
an encrypted document from 3.5 opened in 3.4 will be saved
with the old encryption, without notice?


Yes.  Sorry for my unclear muttering.

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


Re: [Libreoffice] [REVIEWED] [PUSHED] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-18 Thread Stephan Bergmann

On 11/17/2011 01:41 PM, Stephan Bergmann wrote:

Yes, I can do the inclusion into -3-4. AFAIU, Michael Stahl was also
just looking at the patch, will wait until he gives a green light, too.


Pushed as 
http://cgit.freedesktop.org/libreoffice/components/commit/?h=libreoffice-3-4id=c726de0c282cab62b9f1a3b51249e37224325fe9, 
http://cgit.freedesktop.org/libreoffice/libs-core/commit/?h=libreoffice-3-4id=443e1b1566d678c79658f2a48aa4b088ed914fa3, 
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?h=libreoffice-3-4id=d87712a52d33ade9fd2821b91caf92d11ef31a93, 
and 
http://cgit.freedesktop.org/libreoffice/ure/commit/?h=libreoffice-3-4id=d53922c3511a70567f43d17480514d77e81c168c.


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


Re: [Libreoffice] [PATCH/REVIEW-3-4] Backport reading AES-encrypted ODF 1.2 documents (as genereated by LibO 3.5)

2011-11-20 Thread Stephan Bergmann

On 11/19/2011 09:40 AM, Cor Nouws wrote:

So for the release notes something as follows would be appropriate:
 3.4.5
In LibreOffice 3.5 a new stronger encryption will be introduced. As
consequence files encrypted in LibreOffice 3.5 can not be opened by
LibreOffice 3.4.4 and earlier.
LibreOffice 3.4.5 enables you to open those files. However, on saving
again in LibreOffice 3.4.5, the old encryption will be used.
Files with the old encryption of course can be used in LibreOffice 3.5.0 

OK?


Sounds good.

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


Re: [Libreoffice] URE bootstrap - error establishing connection ?

2011-11-21 Thread Stephan Bergmann

On 11/18/2011 08:51 PM, Christian Ehrlicher wrote:

When I try to connect to libreoffice over a uno socket
(com.sun.star.bridge.UnoUrlResolver) in most cases I need to try at least two
times because the socket is not (yet) open:

Cannot establish a connection using
'uno:socket,host=localhost,port=2083;urp;StarOffice.ServiceManager': Connector
: couldn't connect to socket (Erfolg)

At least this is what I would interpret into this error message. Is this
correct? Then the solution would be to wait a little bit longer until I try to
connect to libreoffice if this helps...


Yes, there is of course a race between soffice starting to listen on the 
socket you passed it with the -accept argument and your code calling 
connect.  See, for example, the for -- try -- catch NoConnectException 
loop in unotest/source/cpp/officeconnection.cxx for how to live with 
that race.



Now the document loader example mentions another uno mechanism:

NOTE: This example does not use the new UNO bootstrap mechanism, it uses still
a socket connection.

Does this mean the socket connection is deprecated? And if so - what's the new
way and can someone give me an example? :-)


That note is misleading.  The simplified bootstrap mechanism internally 
still uses a socket connection.  See 
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/C%2B%2B/Transparent_Use_of_Office_UNO_Components.


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


Re: [Libreoffice] uno discoverability

2011-11-21 Thread Stephan Bergmann

On 11/17/2011 06:55 PM, Michael Meeks wrote:

On Wed, 2011-11-16 at 14:16 +0100, Stephan Bergmann wrote:

throw FooException(Failure loading file '%S' code %d,

...

This (as well as cooking something up using OSL_FORMAT) would have the
disadvantage that it potentially converts data from UTF-16 to char
(%S) and then from char to UTF-16 (as UNO Exception's Message is of
type rtl::OUString).


True - but by the time we throw an exception, efficiency already goes
to hell in a hand-cart (as it were) ;-) we start straining mind and limb
to find unwind info records, infer types, understand what is on the
stack and how to clean it up etc. An extra allocation or two isn't going
to hurt.


Its not any time/space overhead that makes me feel uneasy here, but the 
lack of elegance and of consistency.  We could come up with a mechanism 
now for composing exception messages using the new sal/log.h SAL_STREAM, 
like


  throw RuntimeException(rtl::OUString(SAL_STREAM(cannot open   
url).c_str()));


or even simplify that further with an additional macro like

  throw RuntimeException(SAL_STRING(cannot open   url));

Then again, the standard LO idiom to create a literal rtl::OUString is 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(...)), and the standard LO 
idiom to compose a string from to substrings is s1 + s2.  This is not 
only so for the special case of composing messages of UNO exceptions, it 
is so across all the code.  It is somewhat long-winded and ugly, but 
within today's constraints we won't be able to come up with something 
that is substantially better with regard to space/time complexity.


If we would optimize the user experience of composing exception 
messages (where the resulting space/time overhead would be harmless), we 
would pessimize the standard idiom, relative to it, even more.  People 
would probably start to use the optimization in general code, too.


In short, I would not over-emphasize the issue of ugly string 
composition in current LO, and rather live with it until we come up with 
something substantially better, benefiting all use cases, in LO 4.



   We'll probably wait until either all relevant compilers
support C++11's new character types, or we incompatibly change
rtl::OUString to UTF-8 (whatever happens first).


Which would be wonderful :-) I'm cheering that on. Having said that -
if we go with gcc for cross-compile to Windows too, does that help us ?


The Unicode String Literals row at 
wiki.apache.org/stdcxx/C++0xCompilerSupport suggests so.  But then 
again, we still depend on MSVC for Windows builds as of now.



For types.rdb, my vision is to either use an XML format or, IMO even
better, a new .idl format that is (a) less verbose (why the heck all
those ; in there, etc.?) and (b) does not rely on a preprocessor.
Then, a types.rdb could effectively be just one large .idl file.


Great. Of course, types.rdb being huge and empty would be fine if we
didn't load and read it at startup a lot ;-) IIRC one use-case there was
the lack of in-lined property Name/Value struct -  any conversions, so:

pArg.Name = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( foo ));
pArg.Value= ::rtl::OUString( RTL_CONSTASCII_USTRINGPARAM( baa ));

Is nice  efficient, and in-line-able; until that pArg ends up inside
an Any itself - at which point we suck in types.rdb, start loading type
data, inferring C++ structure offsets, and so on - just to allocate and
construct the local Any (which I assume we could do  in-line at compile
time).


The Any operator = for complex structures uses a generic 
(introspective) approach.  I guess that was mainly done to keep the code 
small (esp. given that anything else would have had to be inline-only).



Then again - perhaps we use introspection for something else more
serious on startup, or perhaps I'm out of date on this. Do you have a
feel for whether it is just a few silly cases like this that we could
work around ? or if there is some deep reason that types.rdb should be
necessary at startup ?


Any sort of bridging probably requires introspection already (and Kay's 
purpose-bridges are still used early on, IIRC).  Getting types.rdb out 
of the picture here could be done either via comprehensively compiled 
.hpp headers (that contain the type information in C code; but that 
would probably bloat the code if done everywhere) or replacing generic 
(introspective) algorithms with per-type-templated ones (that would 
again bloat the code).  Difficult to tell whether true benefit lurks 
there...


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


Re: [Libreoffice] Assertions and Logging

2011-11-21 Thread Stephan Bergmann

On 11/21/2011 01:30 PM, Caolán McNamara wrote:

On Fri, 2011-11-18 at 15:25 +0100, Stephan Bergmann wrote:

Alright, so we end up with
use assert if you want an assert
SAL_WARN if you want to warn about something odd, but which isn't
necessarily definitely wrong
SAL_INFO for verbose logging

Practical question though, is on windows where does the output go ?


SAL_INFO/WARN just go to stderr for now.  What should work to see them 
even for a gui soffice.exe is to add something like 2log.txt to the 
command line.  Not sure if there is enough of a Windows developer base 
that demands a more sophisticated solution?  (One could extend the 
SAL_LOG environment variable, so that a trailing file part would 
append the data to a given file, for example.  Or see to hook up Window' 
OutputDebugString.)



Should we write off all the DBG_ASSERTs as hopeless to unwind and mass
convert them all to SAL_WARNs ?


I would initially file an easy hack to do the conversion.  If that does 
not lead to clean-up in a reasonable time-frame, I would suggest to 
mass-convert the remainder to SAL_WARN.



How do we feel about code that does e.g.

assert(pFoo);
if (!pFoo)
 throw catchAbleFoo(wtf);

i.e. do we have a philosophical problem with gracefully/semi-gracefully
handing should-be impossible cases ?


I think that's a perversion, and should be avoided.  It the author could 
not convince himself that !pFoo is not impossible (modulo bugs), then he 
should use OSL_WARN instead.  If however he *is* convinced that !pFoo is 
impossible absent any bugs, but argues that if there *are* bugs, the 
added if statement adds some sort of safety, I would counter-argue that 
this alleged safety net pointlessly increases complexity and is probably 
full of holes and inconsistencies anyway (as it is likely an extremely 
untested code path).


Such defensive programming IMO would need to be architected into the 
code from the beginning.  It makes little sense to add such things 
locally just here and there.  And I'm not even convinced LO is an 
application for which an elaborate defensive programming architecture 
would be justified.  If there is a bug, crash early.  (One thing we 
could IMO improve though, is to not rely on trying to save open 
documents from within a signal handler, but instead rely on frequent 
auto-save and roll back to the last saved version after a crash.)


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


Re: [Libreoffice] Assertions and Logging

2011-11-21 Thread Stephan Bergmann

On 11/21/2011 04:14 PM, Terrence Enger wrote:

On Mon, 2011-11-21 at 14:30 +0100, Stephan Bergmann wrote:

   (One thing we
could IMO improve though, is to not rely on trying to save open
documents from within a signal handler, but instead rely on frequent
auto-save and roll back to the last saved version after a crash.)


Not disagreeing, but this would increase the fraction of the
time during which Writer, at least, ignores keystrokes.  If
you are looking at the screen when this happens, you just
wait for the autosave to finish and then carry on; if you
are looking at something else, you are faced later--for some
walue of later--with the challenge of trying to
reconstruct what you were thinking.


True.  So an improvement probably better left for the hypothetical 
future where we have really fast save and/or save in the background.


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


Re: [Libreoffice] Assertions and Logging

2011-11-21 Thread Stephan Bergmann

On 11/21/2011 04:50 PM, Michael Meeks wrote:

Until then, I think we need to stick with the signal handler, sadly, it
is truly ugly, and I assume it can deadlock too if the signal happens at
certain places wrt. holding mutex', remarkably few posix calls are
signal-safe.


One indeed occasionally observes hanging crashes or crashes within 
crashes caused by the illegal activities we start off the signal handler.


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


  1   2   3   4   5   6   7   8   9   10   >