Re: [Libreoffice] [PATCH] Mark ecx register as clobbered (in cpp_uno/gcc3_macosx_intel)
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
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
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
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
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?
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
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
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 ...
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
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 ...
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 ...
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?
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
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
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 ...
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
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)
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)
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/
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)
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)
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)
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/)
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)
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)
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)
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
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
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
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)
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
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
(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?
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
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
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.
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)
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
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
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
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
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
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?
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
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
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?
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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?
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)
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
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)
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?
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?
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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)
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)
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
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 ...
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)
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
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
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)
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)
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)
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 ?
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
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
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
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
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