Re: [Libreoffice] Trying to diagnose base running extremely slowly
Hi Is there a way of getting a stacktrace from this tool, so we could see where the /proc/self/map access is coming from? Regards, Noel. 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 ? Ideally of course, we would have a native SQLite database to avoid needing to use that hsqldb thing (as you do) - potentially it is provoking java performance problems by using a method call that used to be fast but is now slow; or ... ? So - it's not clear what best to do about this really, Is there a good java profiler out there we could use on a mixed C++ / Java process like ours ? Thanks, Michael. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trying to diagnose base running extremely slowly
John, which version of java are you running? Running java -version at the command line should tell you. On 19 October 2011 19:17:02, 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 Andrew. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc - a better design ...
Hi Sounds like a good idea would be to create a master tracking bug in bugzilla around this plan, then split off the different changes into blocking sub-bugs, and mark some of the easier ones so that other people can start doing them. Regards, Noel. Michael Meeks wrote: Hi Kevin, On Thu, 2011-10-20 at 02:00 -0400, Kevin Hunter wrote: I'm hesitant to ask this because I cannot personally promise time toward LO (only on an as-can basis, which is dismally small ATM), but hey, you can easily so no. :-) You mention really need[ing] a whiteboard to elaborate properly. That really helps; having said that - I sat down with Eike Kohei to discuss this in Paris, and (I hope) managed to communicate the essence of the idea. I submit that putting your thoughts together, perhaps in picture form and available on the LO wiki, or put together as a small video to Youtube, would be extremely useful to casual LO coders like myself. Sure - so first off, since I'm not actively hacking on calc (as of now), this is really not my call. I tried to persuade Kohei Eike of the intrinsic improvements possible with the new design - if I'm lucky then they agree that I'm not mad might think about that. Of course - I can create a video too, but ... ;-) As an individual volunteer without a face-to-face LO team member against whom to bounce ideas, I'd thoroughly love an actual-paid-engineer's thoughts on how best to proceed on this front. So - the very essence of what I'd like to see happen in calc, and the foundation for it - is to remove the idea that a spreadsheet is a collection of 'Cell' objects. This seems (to me) to be the foundation of our scalability problems. I'm personally motivated for Calc because in my science career, I really have to bend over backwards to make Calc work effectively for my needs where Excel works just plain better/faster/smaller, yet I philosophically have stuck myself with Free software. To me, one of the biggest areas of weakness for LO, after the various random crashes (which are getting better!), is the memory bloat, and speed. It's not features. Right. So the biggest piece (I see) that need tackling here before we can take advantage of the new code is to start restricting the scope of 'ScBaseCell' pointers in LibreOffice calc. Last I looked (which was a while ago) we use ScBaseCell pointers all around the place for things like undo/redo, change tracking, copy/paste, document construction etc. If you wanted to re-start the effort to remove ScBaseCell's mpNote pointer (which is very infrequently used) - that'd be a great place to see some of the problems: ultimately I think we want to remove ScBaseCell (and it's derivatives) entirely - leaving a (numeric) cell as a single 'double' inside a fixed column-array of entries of the same type. Of course, even without the grand vision coming to fruition, saving 4 (or 8) bytes per cell would be worthwhile, and improving the above areas to handle storage of ranges of cell contents in a better encapsulated way would be rather valuable - I think. But of course, you really want to talk to Eike / Kohei / Markus. I'm happy to mess with Ixion (and indeed have poked at it some already) Right - IMHO, the real problem we have is not so much Ixion (which is great), but massaging the existing code into a good shape to be ready for it's heart transplant ;-) The above would be a great step in that direction. Of course, if the calc developers don't object, I'm happy to create a video of me making a fool of myself with a whiteboard too if you think it helps :-) All the best, Michael. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build error in tail_build
Cool, thanks! Michael Stahl wrote: On 20/10/11 09:00, Noel Grandin wrote: Hi Building on Windows using Visual Studio, running into a build error in ScriptProviderForJava. Trimmed build log attached. Any ideas? Thanks, Noel Grandin have had this problem myself today, the command for compiling java files does not do the right thing in case of a partial rebuild. fixed on master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=81042d7a366ad8d5f52fcd78e4b44183f62ce0e1 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] feature/gtk3 merged ...
Duration timers are best implemented using the system's monotonic clock.In Java, this is System.nanoTime(),under linux, this is clock_gettime(CLOCK_MONOTONIC),under windows, it is GetTickCount() On Tue, Oct 25, 2011 at 17:40, Michael Meeks michael.me...@suse.com wrote: On Tue, 2011-10-25 at 13:54 +0100, Michael Meeks wrote: There is one minor annoyance I discovered of a warning under gtk2: g_main_context_prepare(): main loop already active in another thread I pushed a fix for this by implementing a custom timer GSource that we can query for expiration more easily. Of course - custom timer GSources can introduce all manner of fun stuff: pwrt. dis-contiguous time - some testing on suspend/resume, and changing system time not causing LibreOffice to lock-up would be much appreciated [ when using the gtk2 frontend: export SAL_USE_VCLPLUGIN=gtk forces that ]. Thanks, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] feature/gtk3 merged ...
Getting there :) almost have a complete build on my machine :) On Tuesday, October 25, 2011, Michael Meeks michael.me...@suse.com wrote: Hi Noel, On Tue, 2011-10-25 at 18:51 +0200, Noel Grandin wrote: Duration timers are best implemented using the system's monotonic clock.In Java, this is System.nanoTime(),under linux, this is clock_gettime(CLOCK_MONOTONIC),under windows, it is GetTickCount() You're certainly right; I'm really just replacing what was there before; but patches as always are welcome :-) vcl/unx/gtk/* ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] (real) Windows build, needs help.
When the windows build fails, the real error is often hidden pretty far up the log. That error message probably indicates that some earlier stage failed to link that file. Kohei Yoshida wrote: I've been trying to build master on Windows with MSVC, and could use some help. Multiple git pull -r, and multiple clean builds over the past several days, and my build always fails in desktop with the following message: (lots of WARN prior to this similar to the one below) /cygdrive/c/libo/core-master/desktop/Executable_unopkg.mk:41: [ WARN ] !!! [ WARN ] !!! desktop/win32/source/extendloaderenvironment is linked in by Executable/soffice.exe Executable/unopkg.exe [ WARN ] !!! [ build DEP ] SRS:deployment/res [ build SRS ] deployment/res [ build DEP ] SRS:deploymentgui/res [ build SRS ] deploymentgui/res [ build DEP ] SRS:dkt/res [ build SRS ] dkt/res [ build LNK ] Executable/soffice_bin.exe 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. Stop. Anyone has any clue off the top of your head as to what could be going wrong here? TIA, Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] syntax highlighting extension not working on LO wiki
Hi I think one of the MediaWiki extensions might have been turned off. See this page: http://wiki.documentfoundation.org/Development/Native_Build And do a search for syntaxhighlight lang=bash Regards, Noel Grandin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] syntax highlighting extension not working on LO wiki
Weird. My browser must have had something dodgy stuck in it's cache. On Mon, Oct 31, 2011 at 18:34, Petr Mladek pmla...@suse.cz wrote: Noel Grandin píše v Po 31. 10. 2011 v 17:03 +0200: Hi I think one of the MediaWiki extensions might have been turned off. See this page: http://wiki.documentfoundation.org/Development/Native_Build And do a search for syntaxhighlight lang=bash It seems to work now. The syntax is highlighted and the I can't fix the above text on the page. Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build breaking in configure
Hi Sometime in the last 24 hours something changed in the mozilla configure stuff, which means that autogen is failing for me now. Running on a Windows7 machine with Visual Studio. See attached log. Anybody have any ideas? Thanks, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ./autogen.sh running ./configure with '--with-max-jobs=9' '--with-num-cpus=2' '--without-junit' '--with-ant-home=/cygdrive/c/Components/apache-ant-1.8.0' '--disable-build-mozilla' '--disable-atl' '--disable-activex' '--disable-nss-module' '--without-java' '--disable-mozilla' configure: WARNING: unrecognized options: --disable-nss-module * * Running LibreOffice build configuration. * checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for gawk... gawk checking for gawk... /usr/bin/gawk checking for sed... /usr/bin/sed checking for bash... /usr/bin/sh checking for GNU or BSD tar... tar checking for Cygwin gcc/g++... found checking for ccache... not found checking gcc home... /usr checking whether to enable crashdump feature... no checking whether to build a 64-bit LibreOffice... no checking whether to use DirectX... yes checking whether to use ActiveX... no checking whether to use ATL... no checking whether to turn warnings to errors... no checking whether to do a debug build... no checking whether to build with additional debug utilities... no, full product build checking whether to use linkoo for the smoketest installation... yes checking whether to use link-time optimization... no checking whether to include symbols... no checking whether to strip the solver or not yes checking whether we need fontconfig... no checking whether to enable filters for legacy binary file formats (StarOffice 5.2)... no checking whether to build help... yes checking whether to use RPATH in shared libraries... yes checking whether to include MySpell dictionaries... yes checking whether to use dicts from external paths... no checking whether to enable pch feature... no checking for GNU make... /opt/lo/bin/make checking the GNU make version... /opt/lo/bin/make 3.82 checking for --hash-style gcc linker support ... no checking for perl... /usr/bin/perl checking the Perl version... checked (perl 5) checking for required Perl modules... all modules found checking for a friendly Microsoft C/C++ compiler installation path... /cygdrive/c/PROGRA~1/MICROS~1.0/VC checking the Microsoft C/C++ Compiler... found (/cygdrive/c/PROGRA~1/MICROS~1.0/VC/bin/cl.exe) checking the Version of Microsoft C/C++ Compiler... found compiler version 00153072 (MSVS 2008). checking the dependency generation prefix (cl.exe -showIncludes)... Note: including file: checking for a x64 compiler and libraries for 64bit ActiveX component... not found configure: WARNING: Installation set will not contain the 64-bit Explorer extension checking for midl.exe... no checking for csc.exe... no checking .NET Framework... found checking valgrind.h usability... no checking valgrind.h presence... no checking for valgrind.h... no checking valgrind.h usability... no checking valgrind.h presence... no checking for valgrind.h... no checking Whether building STLPort library makes sense... yes checking Whether STLPort library will be actually built... yes checking whether /cygdrive/c/PROGRA~1/MICROS~1.0/VC/bin/cl.exe supports thread safe statics... unknown (assuming no) checking which memory allocator to use... internal checking whether to add custom build version... no checking whether to build with Java support... no checking for dmake... no dmake will be built on ./bootstrap checking whether to enable EPM for packing... no checking for gperf... /usr/bin/gperf checking gperf version... OK checking whether to build the stax... checking whether to build the ODK... yes checking whether to provide libstdc++/libgcc_s in the installset... yes checking which zlib to use... internal checking which jpeg to use... internal checking which expat to use... internal checking which libvisio to use... internal checking which libcmis to use... internal checking which libwpd to use... internal checking which cppunit to use... internal checking which libwps to use... internal checking which libwpg to use... internal checking which libxslt to use... internal checking which libxml to use... internal checking which Python to use... internal checking for bzip2... /usr/bin/bzip2 checking which db to use... internal checking whether to build the MySQL Connector extension... no checking which libcurl to use... internal checking which boost to use... internal checking which mdds to use... internal checking which hash container mdds shall use... boost::unordered_map checking which vigra to use... internal
Re: [Libreoffice] build breaking in configure
Hi I fixed this by installing the mozilla-build tool, and using --with-mozilla-build=, but I'm surprised that the configure process now requires that, since I thought I had disabled everything mozilla related. Regards, Noel Grandin. Noel Grandin wrote: Hi Sometime in the last 24 hours something changed in the mozilla configure stuff, which means that autogen is failing for me now. Running on a Windows7 machine with Visual Studio. See attached log. Anybody have any ideas? Thanks, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] build break in toolkit component (unresolved externals)
Hi
Building on Windows7 with Visual Express 2008
Getting an unresolved externals problem in the toolkit component, log
attached.
Regards, Noel Grandin
Disclaimer: http://www.peralex.com/disclaimer.html
[ build LNK ] Library/itk.lib
R=c:/libreoffice O=$R/libo/solver/wntmsci12.pro
W=$R/libo/workdir/wntmsci12.pro S=$R/libo mkdir -p
$W/LinkTarget/Library/ rm -f $W/LinkTarget/Library/itk.lib
RESPONSEFILE=C:/cygwin/tmp/gbuild.BfL2cV link -DLL -release -opt:noref
-incremental:no -debug -safeseh -nxcompat -dynamicbase -SUBSYSTEM:CONSOLE
-MACHINE:IX86 -MANIFEST -LIBPATH:C:/libreoffice/libo/solver/wntmsci12.pro/lib
-LIBPATH:C:/PROGRA~2/Java/JDK16~1.0_2/lib
-LIBPATH:C:/PROGRA~2/MICROS~1.0/VC/lib
-LIBPATH:C:/PROGRA~1/MICROS~3/Windows/v7.1/lib
-LIBPATH:C:/PROGRA~1/MICROS~3/Windows/v6.0A/lib
-LIBPATH:C:/PROGRA~2/MI0FC3~1/lib/x86@${RESPONSEFILE} icomphelp.lib
icppu.lib icppuhelper.lib isal.lib itools.lib iutl.lib ivcl.lib uwinapi.lib
advapi32.libuser32.lib -out:$W/LinkTarget/Library/tklo.dll
-implib:$W/LinkTarget/Library/itk.lib; RC=$?; rm ${RESPONSEFILE} ; if [ ! -f
$W/LinkTarget/Library/tklo.dll ]; then rm -f $W/LinkTarget/Library/itk.lib
false; fi ; exit $RC
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/asynccallback.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/stylesettings.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxaccessiblecomponent.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxbitmap.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxbutton.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxcontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxdevice.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxdialog.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxfixedline.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxfont.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxgraphics.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxmenu.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxplugin.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxpointer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxprinter.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxregion.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxscroller.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxspinbutton.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxsplitter.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxsystemdependentwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabpage.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabpagecontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/animatedimagespeer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtoolkit.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtopwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindow1.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindows.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/xsimpleanimation.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/xthrobber.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/accessiblecontrolcontext.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/controlmodelcontainerbase.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/dialogcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/eventcontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/formattedcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/geometrycontrolmodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/defaultgridcolumnmodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/defaultgriddatamodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/gridcolumn.o
c:/libreoffice
[Libreoffice] build break in drawinglayer component (unresolved external in BZPixelRaster)
Hi
Building on Windows 7 with Visual Studio, build is breaking in drawinglayer
with unresolved externals.
Looks like a destructor got removed?
Regards, Noel.
Disclaimer: http://www.peralex.com/disclaimer.html
[ build LNK ] Library/itk.lib
R=c:/libreoffice O=$R/libo/solver/wntmsci12.pro
W=$R/libo/workdir/wntmsci12.pro S=$R/libo mkdir -p
$W/LinkTarget/Library/ rm -f $W/LinkTarget/Library/itk.lib
RESPONSEFILE=C:/cygwin/tmp/gbuild.BfL2cV link -DLL -release -opt:noref
-incremental:no -debug -safeseh -nxcompat -dynamicbase -SUBSYSTEM:CONSOLE
-MACHINE:IX86 -MANIFEST -LIBPATH:C:/libreoffice/libo/solver/wntmsci12.pro/lib
-LIBPATH:C:/PROGRA~2/Java/JDK16~1.0_2/lib
-LIBPATH:C:/PROGRA~2/MICROS~1.0/VC/lib
-LIBPATH:C:/PROGRA~1/MICROS~3/Windows/v7.1/lib
-LIBPATH:C:/PROGRA~1/MICROS~3/Windows/v6.0A/lib
-LIBPATH:C:/PROGRA~2/MI0FC3~1/lib/x86@${RESPONSEFILE} icomphelp.lib
icppu.lib icppuhelper.lib isal.lib itools.lib iutl.lib ivcl.lib uwinapi.lib
advapi32.libuser32.lib -out:$W/LinkTarget/Library/tklo.dll
-implib:$W/LinkTarget/Library/itk.lib; RC=$?; rm ${RESPONSEFILE} ; if [ ! -f
$W/LinkTarget/Library/tklo.dll ]; then rm -f $W/LinkTarget/Library/itk.lib
false; fi ; exit $RC
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/asynccallback.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/stylesettings.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxaccessiblecomponent.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxbitmap.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxbutton.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxcontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxdevice.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxdialog.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxfixedline.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxfont.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxgraphics.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxmenu.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxplugin.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxpointer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxprinter.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxregion.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxscroller.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxspinbutton.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxsplitter.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxsystemdependentwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabpage.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtabpagecontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/animatedimagespeer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtoolkit.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxtopwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindow.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindow1.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/vclxwindows.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/xsimpleanimation.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/awt/xthrobber.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/accessiblecontrolcontext.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/controlmodelcontainerbase.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/dialogcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/eventcontainer.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/formattedcontrol.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/geometrycontrolmodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/defaultgridcolumnmodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/defaultgriddatamodel.o
c:/libreoffice/libo/workdir/wntmsci12.pro/CxxObject/toolkit/source/controls/grid/gridcolumn.o
Re: [Libreoffice] build break in drawinglayer component (unresolved external in BZPixelRaster)
thanks. Thorsten Behrens wrote: Noel Grandin wrote: Building on Windows 7 with Visual Studio, build is breaking in drawinglayer with unresolved externals. Hi Noel, please pull - Fridrich just fixed that with commit f8508036d1f28765ad43055d9ba99219e1523087 Cheers, -- Thorsten Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build fails in extension module
Nope, still failing, see attached log. Regards, Noel Grandin Caolán McNamara wrote: On Tue, 2011-11-08 at 14:07 +0100, Jean-Baptiste Faure wrote: Hi all, This morning build (master on ubuntu 10.04 x86_64) fails in extensions module. This error comes after a fresh build following the same error on a standard build. Yes, pull and try again. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html = (1/1) Building module extensions = Entering /cygdrive/c/libreoffice/libo/extensions/inc Entering /cygdrive/c/libreoffice/libo/extensions/source/nsplugin/source Entering /cygdrive/c/libreoffice/libo/extensions/source/bibliography Entering /cygdrive/c/libreoffice/libo/extensions/source/oooimprovecore Entering /cygdrive/c/libreoffice/libo/extensions/source/propctrlr Entering /cygdrive/c/libreoffice/libo/extensions/source/update/ui Entering /cygdrive/c/libreoffice/libo/extensions/source/logging Entering /cygdrive/c/libreoffice/libo/extensions/source/config/ldap Entering /cygdrive/c/libreoffice/libo/extensions/source/activex/msidl Entering /cygdrive/c/libreoffice/libo/extensions/source/update/feed Entering /cygdrive/c/libreoffice/libo/extensions/source/update/check Entering /cygdrive/c/libreoffice/libo/extensions/source/activex/main Entering /cygdrive/c/libreoffice/libo/extensions/source/dbpilots Entering /cygdrive/c/libreoffice/libo/extensions/source/resource Entering /cygdrive/c/libreoffice/libo/extensions/source/xmlextract Entering /cygdrive/c/libreoffice/libo/extensions/source/scanner Entering /cygdrive/c/libreoffice/libo/extensions/source/abpilot Entering /cygdrive/c/libreoffice/libo/extensions/source/oooimprovement Entering /cygdrive/c/libreoffice/libo/extensions/source/ole Entering /cygdrive/c/libreoffice/libo/extensions/source/plugin/base Compiling: extensions/source/plugin/base/service.cxx ../inc\plugin/plcom.hxx(75) : error C2146: syntax error : missing ';' before identifier 'NPP_Write' ../inc\plugin/plcom.hxx(75) : error C2433: 'PluginComm::int32' : 'virtual' not permitted on data declarations ../inc\plugin/plcom.hxx(75) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/plcom.hxx(75) : error C2061: syntax error : identifier 'int32' ../inc\plugin/plcom.hxx(76) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/plcom.hxx(76) : warning C4183: 'NPP_Write': missing return type; assumed to be a member function returning 'int' ../inc\plugin/plcom.hxx(77) : error C2146: syntax error : missing ';' before identifier 'NPP_WriteReady' ../inc\plugin/plcom.hxx(77) : error C2433: 'PluginComm::int32' : 'virtual' not permitted on data declarations ../inc\plugin/plcom.hxx(77) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/plcom.hxx(77) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/plcom.hxx(77) : warning C4183: 'NPP_WriteReady': missing return type; assumed to be a member function returning 'int' ../inc\plugin/plcom.hxx(75) : error C2253: 'PluginComm::NPP_Write' : pure specifier or abstract override specifier only allowed on virtual function ../inc\plugin/plcom.hxx(77) : error C2253: 'PluginComm::NPP_WriteReady' : pure specifier or abstract override specifier only allowed on virtual function ../inc\plugin/win/sysplug.hxx(90) : error C2061: syntax error : identifier 'uint16' ../inc\plugin/win/sysplug.hxx(93) : error C2061: syntax error : identifier 'uint16' ../inc\plugin/win/sysplug.hxx(102) : error C2146: syntax error : missing ';' before identifier 'NPP_Write' ../inc\plugin/win/sysplug.hxx(102) : error C2433: 'PluginComm_Impl::int32' : 'virtual' not permitted on data declarations ../inc\plugin/win/sysplug.hxx(102) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/win/sysplug.hxx(102) : error C2061: syntax error : identifier 'int32' ../inc\plugin/win/sysplug.hxx(103) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/win/sysplug.hxx(103) : warning C4183: 'NPP_Write': missing return type; assumed to be a member function returning 'int' ../inc\plugin/win/sysplug.hxx(104) : error C2146: syntax error : missing ';' before identifier 'NPP_WriteReady' ../inc\plugin/win/sysplug.hxx(104) : error C2433: 'PluginComm_Impl::int32' : 'virtual' not permitted on data declarations ../inc\plugin/win/sysplug.hxx(104) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/win/sysplug.hxx(104) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ../inc\plugin/win
Re: [Libreoffice] build fail in scripting/Jar/aportisdoc
Hi I can confirm that this bug does not go away if I build it again from the root. Also tested by trying to build the scripting module a few times and that doesn't work either. Nor does trying to build the tail_build module, although that returns a different error message: /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/Dep/SdiTarget/basctl/sdi/basslots.d:1: *** target pattern contains no `%'. Stop. -- Noel Grandin Stephan Bergmann wrote: 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 Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build fail: workdir/wntmsci12.pro/Dep/SdiTarget/basctl/sdi/basslots.d:1: *** target pattern contains no `%'
Nope, that doesn't fix it. I'm fairly convinced that this is the same problem I've been having for a long time now, where the scripting module is not compiling one of the JAR's properly, and that is having knock-on effects. Specifically, the line that says this: [ build JCS ] Jar/ScriptProviderForJava is still spitting out lots of cannot find symbol. Regards, Noel Grandin Michael Meeks wrote: Hi Noel, On Thu, 2011-11-10 at 10:02 +0200, Noel Grandin wrote: Not quite sure where this build fail comes from - running make from the root says that the build fail is in tail_build, but running in the tail_build module gives a completely different error. :-) So I also ran a build under scripting and included that log. Any ideas? I guess it is from the new .sdi deps that has: c:/libreoffice/libo/workdir/wntmsci12.pro/SdiTarget/basctl/sdi/basslots : \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\editeng\editids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\editeng\memberids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\cntids.hrc \ Does the error change if we turn those '/' into '\' in the path name in the basslots.d file ? Thanks, Michael. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build fail in scripting/Jar/aportisdoc
/cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/Dep/SdiTarget/basctl/sdi/basslots.d looks like: c:/libreoffice/libo/workdir/wntmsci12.pro/SdiTarget/basctl/sdi/basslots : \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\editeng\editids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\editeng\memberids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\cntids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\sfx.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\sfx.sdi \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\sfxitems.sdi \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\sfx2\sfxsids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svl\cntwids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svl\memberid.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svl\solar.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svx\svx.sdi \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svx\svxids.hrc \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svx\svxitems.sdi \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svx\unomid.hxx \ C:\libreoffice\libo\solver\wntmsci12.pro\inc\svx\xoitems.sdi \ c:/libreoffice/libo/basctl/sdi/basslots.sdi \ c:\libreoffice\libo\basctl\sdi\baside.sdi \ c:\libreoffice\libo\basctl\sdi\basslots.hrc Bjoern Michaelsen wrote: On Fri, Nov 11, 2011 at 10:02:47AM +0200, Noel Grandin wrote: Nor does trying to build the tail_build module, although that returns a different error message: /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/Dep/SdiTarget/basctl/sdi/basslots.d:1: *** target pattern contains no `%'. Stop. And what looks /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/Dep/SdiTarget/basctl/sdi/basslots.d like? Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED][PATCH] Re: Easy hack regex compile infinite loop ( bug 41738 )
Seems like this is a case where you should be able to find unit testing in some other open source project, rather than writing them from scratch. Mozilla, Apache Harmony, Perl, Webkit, Python, should all have a bunch of unit testing code for their regular expression features. In fact, there are a couple of open-source libraries for regex stuff, I'm sure it would better to simply use the code of one of those other projects, rather than maintaining our own. Webkit/Mozilla should have excellent engines inside their JavaScript modules written in C++ that we could copy. And they would have seen an enormous amount of testing. Regards, Noel Grandin On Fri, Nov 11, 2011 at 18:48, koehlerk...@comcast.net wrote: Hi Eike, I confirm I contribute this and all future patches for LibreOffice under the LGPLv3+ and MPL 1.1 . Yes, there are quite some shortcomings and bugs with that code. I wouldn't invest too much time though, plan is to replace that legacy code entirely with the more suitable ICU regex. This seems like a nice idea .. is there already a bug/Easy hack for that ? Thanks ! - Karl ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trouble with autogen on WinXP
I found that I had to install the Mozilla build tools and point autogen at them to make my build work On Saturday, November 12, 2011, Regina Henschel rb.hensc...@t-online.de wrote: Hi all, this time my try to build fails already in autogen.sh. Up to now I had used the switches cited below. But now 1. It does not know --disable-nss-module 2. It tries to build mozilla, instead of using the prebuild ones Breaks here. Kind regards Regina ./autogen.sh \ --with-directx-home=/cygdrive/c/Programme/Microsoft DirectX SDK (March 2009) \ --with-cl-home=/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC \ --disable-activex \ --disable-build-mozilla \ --disable-nss-module \ --disable-binfilter \ --disable-odk \ --with-midl-path=/cygdrive/c/Programme/Microsoft SDKs/Windows/v6.0A/bin \ --with-asm-home=/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC/bin \ --with-jdk-home=/cygdrive/c/Programme/Java/jdk1.6.0_20 \ --with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5 \ --with-ant-home=/ant \ --with-mspdb-path=/cygdrive/c/Programme/Microsoft Visual Studio 9.0/Common7/IDE \ --without-junit \ But now 1. It does not know --disable-nss-module 2. It tries to build mozilla, instead of using the prebuild ones Breaks here. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trouble with autogen on WinXP
I used Mozillabuildsetup. On Sunday, November 13, 2011, Regina Henschel rb.hensc...@t-online.de wrote: Hi Noel, Noel Grandin schrieb: I found that I had to install the Mozilla build tools and point autogen at them to make my build work What do I need, MozillaBuildSetup or moztools-static ? Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace command domainname by getdomainname() on Unix
OpenGrok says that:
GetDomainName is only used by
GetYPDomainName
in the same file
which in turn is only used by
const rtl::OUString SubstitutePathVariables_Impl::GetYPDomainName()
in
/core/framework/source/services/substitutepathvars.cxx
which in turn is only used by
bool SubstitutePathVariables_Impl::FilterRuleSet( const
SubstituteRuleVector aRuleSet, SubstituteRule aActiveRule )
in the same file.
and that particular codepath in that method is only referenced when the
enum EnvironmentType {
ET_YPDOMAIN
constant is used.
which in turn is not used anywhere in the LO codebase.
On Sun, Nov 13, 2011 at 12:06, Tor Lillqvist t...@iki.fi wrote:
Seems that the original code was also broken of course, forking and
execing /bin/domainname is indeed a bit stupid, and the domainname
command is also specified (to the extent it is specified at all) to
return the NIS domain name.
But honestly, how many of the LibreOffice installations on Unix even
have the NIS domain name set? At least in my openSUSE 11.4 with fairly
default settings, the domainname command prints nothing. Neither does
it in my Mac OS X 10.7.2.
I guess the sane thing to do here is to 1) unravel the stack of static
functions in sal/osl/unx/socket.c and find out what public functions
they actually are used in; 2) if possible drop code that is not
needed; 3) and finally ponder what will break, if anything, if we just
don't bother with the NIS domain name. 4) If really necessary, then do
it right, as Lionel said:
The portable and strictly correct way seems to be to do a
DNS query on the result of gethostname() (gethostbyname or getaddrinfo
with AI_CANONNAME).
But in general we should avoid potentially pointless DNS calls. Let's
not risk having to wait for DNS timeouts in badly configured
situations. I think there has been bug reports of OOo and/or LO being
very slow to start in some cases, where the root cause has been some
DNS call timing out?
LibreOffice is an office suite, not some Internet service software,
why would it need to know the exact canonical official hostname of the
machine it is running on (or some other machine)? Especially as many
home end-user machines certainly don't have any public official DNS
name anyway, at least not one the machine itself would know, but some
cable-modem-42651e7a3c.isp.example.com.
--tml
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace command domainname by getdomainname() on Unix
Arnaud is correct, I was looking at the wrong method. But where do you see this method being used in file locking? Lionel, I've run across a lot of machines with badly configured DNS. socket.c: _osl_getDomainName is only used by socket.c: static sal_Char* _osl_getFullQualifiedDomainName (const sal_Char *pHostName) which is only used by socket.c: static oslHostAddr _osl_hostentToHostAddr (const struct hostent *he) which is used by socket.c: oslHostAddr SAL_CALL osl_psz_createHostAddrByName (const sal_Char *pszHostname) and socket.c: oslHostAddr SAL_CALL osl_createHostAddrByAddr (const oslSocketAddr pAddr) and I assume that SAL_CALL means that these are part of the public API. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Replace command domainname by getdomainname() on Unix
Hi On windows you could lookup the environment variable COMPUTERNAME and put that in the lock file. That would solve the issue with flaky remote shares. Could use uname on linux/MacOS. We could also use the IP address of the machine - that should help with flaky NFS shares. Although in the presence of DHCP, it can be hard to figure out who the problem machine was. For bonus points, put all of these in the lock file: (1) Some kind of COMPUTERNAME/uname lookup (2) IP address (3) MAC address That should be fast and safe, but necessarily as user-friendly as the current solution. For extra-extra bonus points, we could run the DNS resolution on a separate thread and also store that in the lock file if it is available when we create the lock file :-) Regards, Noel Grandin. Michael Stahl wrote: On 14/11/11 12:30, Michael Meeks wrote: On Sun, 2011-11-13 at 12:06 +0200, Tor Lillqvist wrote: But in general we should avoid potentially pointless DNS calls. Let's not risk having to wait for DNS timeouts in badly configured situations. I think there has been bug reports of OOo and/or LO being very slow to start in some cases, where the root cause has been some DNS call timing out? Yes - I've seen this. I spent a while debugging the: OO.o takes 14 seconds to start instead of 10 type bugs, which used to riddle the whole linux desktop in this situation, and that I spent time in a previous life fixing / working around. If, as Stephan suggests, we use this for .lock files - then I don't believe we should ;-) having a potential 10+ second delay before opening a file is not ideal. [ and the duplicate count for these huge login / startup delays was really quite real included me FWIW ]. hmm... but this is written in the lock file for a reason, so that people who edit files on NFS shares can figure out where the office process that is preventing them from editing is running. perhaps it would be possible to do the DNS lookup asynchronously, so it does not block the user experience? Indeed, it'd be rather nice if we could sort out our .lock files story so that I don't routinely see bogus/broken / stale lock file dialogs but ... ;-) that's a different story I guess; and one that needs some unit tests I suppose. please note that the file locking implementation is very brittle because it has to work on any number of randomly broken networking filesystem setups; changing anything there is a huge time sink with high regression risk (at least that's what i remember from my former colleague). ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] bug in Jar_ScriptProviderForJava.mk?
/scripting/Jar_ScriptProviderForJava.mk has the following lines in it: / 31 $(eval $(call gb_Jar_add_jars,ScriptProviderForJava,\ 32 $(OUTDIR)/bin/juh.jar \ 33 $(OUTDIR)/bin/jurt.jar \ 34 $(OUTDIR)/bin/ridl.jar \ 35 $(OUTDIR)/bin/unoil.jar \ 36 $(OUTDIR)/bin/ScriptFramework.jar \ 37 )) / But when I execute build --verbose in /scripting I get /[ build JCS ] Jar/ScriptProviderForJava R=c:/libreoffice O=$R/libo/solver/wntmsci12.pro W=$R/libo/workdir/wntmsci12.pro S=$R/libo mkdir -p $W/JavaClassSet/Jar/ScriptProviderForJava/ RESPONSEFILE=C:/cygwin/tmp/gbuild.4DIIuw C:/PROGRA~2/Java/JDK16~1.0_2/bin/javac.exe -cp C:/PROGRA~2/Java/JDK16~1.0_2/jre/lib/rt.jar;.;$O/bin/juh.jar;$O/bin/jurt.jar;$O/bin/ridl.jar;$O/bin/unoil.jar;$W/JavaClassSet/Jar/ScriptProviderForJava -d $W/JavaClassSet/Jar/ScriptProviderForJava @$RESPONSEFILE rm -f $RESPONSEFILE touch $W/JavaClassSet/Jar/ScriptProviderForJava/done [ build CHK ] loaded modules: scripting 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 / Note that despite being added in the build script, is ScriptFramework.jar is NOT on the command line. Any ideas? I'm afraid I'm still getting to grips with the gbuild framework. Thank, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] bug in Jar_ScriptProviderForJava.mk?
Michael Stahl wrote: hmm... if you edit Jar_ScriptProviderForJava.mk, and move ScriptFramework.jar first, what happens then? also you could try to edit solenv/gbuild/JavaClassSet.mk, and in the definition of gb_JavaClassSet_add_jar replace all eval with info, which should print some debug output (but it won't build that way...) Moving the ScriptFramework.jar line around doesn't change anything. Replacing eval with info gives me this: $ build --verbose = (1/1) Building module scripting = Entering /cygdrive/c/libreoffice/libo/scripting/prj cd .. /opt/lo/bin/make -r -j6 gb_PARTIALBUILD=T /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/HelloWorld/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/jurt.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/ridl.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/Highlight/done : JARDEPS += /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/unoil.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/MemoryUsage/done : /cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/MemoryUsage/done : CLASSPATH := $(CLASSPATH);/cygdrive/c/libreoffice/libo/solver/wntmsci12.pro/bin/juh.jar /cygdrive/c/libreoffice/libo/workdir/wntmsci12.pro/JavaClassSet/Jar/MemoryUsage/done : JARDEPS +=
Re: [Libreoffice] bug in Jar_ScriptProviderForJava.mk?
Michael Stahl wrote: hmm...so clearly it is added to CLASSPATH, but it does not end up in the command; that is most mysterious... what is the command like if, in the definition of gb_JavaClassSet__command (solenv/gbuild/JavaClassSet.mk), you a) replace gb_Helper_abbreviate_dirs_native with gb_Helper_abbreviate_dirs ScriptFramework.jar is still not on the command line, and javac blows up because it doesn't like paths that look like /cygdrive/c/yaddayadda b) remove the first line $(call gb_Helper_abbreviate_dirs_native,\ [and the matching closing parenthesis on the last line as well] ScriptFramework.jar is still not on the command line, and javac blows up because it doesn't like paths that look like /cygdrive/c/yaddayadda Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [ANNOUNCE] Partial Build without the need to source Env.Host.sh
Hi Thank you to all the hackers working to make the build process smoother! Your efforts are much appreciated. Having some time spelunking in the build system, I now understand why almost every large-scale software project ends up writing it's own build system - trying to read gmake/dmake macro code makes me think back to my programming-with-MSDOS-batch-file days :-) -- Noel Grandin Norbert Thiebaud wrote: Hi all, Having to source Env.Host.sh to do partial build is a pain, especially since it polute tour session environment quite a bit and essentially force you to start a new session eveytime ou need to re-autogen.sh, or go to another source tree I've recently pushed a series of patch to alleviate that problem. First, the patches do not hinder the 'old' way. If you were hapy to source Env.Host.sh... you can still do it.. nothing changes Second, after these patches, partial make on gbuildified moduel just work.. no need to do anything Third, for dmake module it is still a bit of work to do: There are two way to do it: a/ source the brand new build_env file generated during autogen The purpose of that file is essentially to create the proper aliases so that build and deliver 'works' b/ you can - copy solenv/bin/lo_find_src_root and solenv/bin/lo_proxy_start in a directory of your choice that is in your normal PATH - add alias build='lo_proxy_start build' alias deliver='lo_proxy_start deliver' to your .bashrc then build and deliver will do the 'right thing' based on the current working directory (that is, you can have more than one copy of the 'core' repo and can go from one to the other in the same session without having to source/re-source anything). As usual, if these broke something for you, please ping me. Norbert PS: I have not yet changed the build instruction, neither in build.pl nor on the Wiki... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Hi If you want to help, you need to get your hands on a Windows machine to test builds on. Preferably something with lots of cores and a reasonable amount of memory (4G or more) because the windows build is quite slow. Here are some links to help you get started with setting up a Windows machine: http://wiki.documentfoundation.org/Development/Windows_Build_Dependencies http://wiki.documentfoundation.org/Development/Native_Build http://wiki.documentfoundation.org/Development/BuildingOnWindowsWithCygwinAndMSVCExpress Regards, Noel Grandin Winfried Donkers wrote: Hello all, This bug (MS Access databases cannot be opened since LibO 3.4) is a serious problem for several cpmpanies that migrated from MS Office to LibO (including the company I work for). Comment 11 from Alex Thurgood gives a possible cause, but: -I am not familiar with the make system of LibO; -I am not sure is this can be tested on a Linux machine (I can't build a Windows version of LibO, I use openSUSE Linux); -I am still a newbie with hacking in LibO. However, I want to help wherever I can with this problem. Is there anyting I can do to (help) solve the bug, preferably with guidance from an expert? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Hi You don't need to pay for MSVC - there is a free Express version available (I'm using it). And if your machine is slower, it just means it'll take a little longer to give feedback. Even an older Windows-XP machine will do fine for this purpose. Really, there are not that many LibreOffice developers around. Your bug won't get priority unless either (a) you step in and at least help with running test, or (b) your company pays SUSE/Redhat to allocate one of their developers to it. -- Noel Grandin Winfried Donkers wrote: Sorry, I don't have a Windows machine available with lots of cores and memory. Neither do we have MSVC++. I'll have to wait till someone who does have such a machine (and time) picks up the bug. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Hi Excellent. Feel free to ask for help if you get stuck setting it up. -- Noel Grandin Alexander Thurgood wrote: Le 17/11/11 09:11, Winfried Donkers a écrit : Hi Winfried, Comment 11 from Alex Thurgood gives a possible cause, but: What we need is for someone to test it with a recent daily build on Windows from master, because it might already be fixed. Only then is it worthwhile investigating further. I don't recall that you could ever read MDB files from within OOo/LO on Linux (or Mac for that matter). There was a vague attempt to integrate MDB read capabilities into OOo, but I thought that faded out and certainly never got integrated into the main branch (unless some Linux distros did it ?). Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Hi It should be, from your perspective, /git/lib/moz/zipped For reference, my autogen looks like: --with-max-jobs=6 --with-num-cpus=6 --without-junit --without-java --with-ant-home=/cygdrive/c/libreoffice/apache-ant-1.8.2 --disable-build-mozilla --disable-atl --disable-activex --with-windows-sdk-home=/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.1 --with-mozilla-build=/cygdrive/c/mozilla-build -- Noel Grandin On 18 November 2011 14:52:51, Winfried Donkers wrote: Excellent. Feel free to ask for help if you get stuck setting it up. -- Noel Grandin I have installed all dependancies (I hope) and am now trying to get ./autogen.sh to succeed (so far, a lot of paths to be set as option). I keep having trouble with moz/zipped. Should this be (as seen from within cygwin) /moz/zipped, /git/libo/moz/zipped or something else (master is cloned to /git/libo)? It'll be monday before I can continue my struggle to get a Windows build, so that I can -with your help- try to include the mdbtools. Even a limited ability (reading and simple writing of ms access files) would be fine. Winfried Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Hmmm, that looks like a quoting problem with the $CPP variable. What does your $CPP variable look like? On Mon, Nov 21, 2011 at 13:07, Winfried Donkers w.donk...@dci-electronics.nl wrote: Excellent. Feel free to ask for help if you get stuck setting it up. -- Noel Grandin .autogen.sh succeeded, now make give a strange error: ... configure: creating ./config.status ./configure: line 8411: test: too many arguments ./configure: line 8411: test: too many arguments ./configure: line 8411: test: too many arguments ./configure: line 8411: test: too many arguments ./configure: line 8411: test: too many arguments ./configure: line 8411: test: too many arguments configure: error: could not make ./config.status ... line 8411 of configure is 'if test -z $CPP; then', whicj looks perfectly ok to me config.status has not been altered (size is 0bytes, timestamp is before starting time of make) Also, considering the vast amount of messages added to bug 36555 by Lionel Elie Mamane and Alex Thurgood, it may be wiser to abandon my attempts to build LibreOffice and continue with easy hacks on my Linus machine? Or do you still wish me to have a running windows machine for testing this (and possible other) bugs/patches? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] build break in drawinglayer component (unresolved?external in BZPixelRaster)
I also saw that error, and I seem to remember Fridrich fixing it. But I think I had to do a 'make clean' and then 'make' to fix it. On Mon, Nov 21, 2011 at 18:55, Thorsten Behrens t...@documentfoundation.org wrote: xuanyong.yang wrote: I got the following error. Any ideas? and I didn't make any changes in the code, just trying to build the master on winxp . Seen this a while ago, Fridrich or someone else fixed it - you may want to git pull -r rerun. Fridrich, weren't there some known-good-for-windows state in some git note? HTH, -- Thorsten ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] printing expert wanted
What you want is a way of dumping the PostScript output, so that you can compare the output from a previous version of LibO with a newer version of LibO. (Just stating the question better - I don't know the answer). Petr Mladek wrote: Hi, I wonder who would be interested into printing bugs, such as https://bugs.freedesktop.org/show_bug.cgi?id=42759 I do not see anyone at http://wiki.documentfoundation.org/FindTheExpert ;-) Best Regards, Petr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Assertions and Logging
Stephan Bergmann wrote: based one; given that configure currently rejects --enable-dbgutil for an MSVC based one I guess nobody cares for debug output for that configuration at the moment, anyway?) I think it's more a case of the Windows users struggling to get a basic build going reliably. Once that works we can start adding the nice-to-haves :-) Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Windows build breakage
Hi I tried to debug this with Michael Stahl's help, and I came to the conclusion that it is some kind of timing bug in make. Sometimes it works, sometimes not. In the end I gave up and disabled java. (--without-java). Regards, Noel Grandin. Kohei Yoshida wrote: Hi there, So, not having been able to build master on Windows for almost 2 months, I've decided to give it another go. But it fails in scripting this time, and I have no clue. The build log is attached. Hopefully this will ring a bell for someone... Kohei Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] help asked/offered for bug 36555
Maybe we need a check in configure to make sure we are running the correct version of make? Michael Stahl wrote: On 23/11/11 11:14, Winfried Donkers wrote: Now I get the following: config.status: executing depfiles commands MAKE version 5.2 Copyright (c) 1987, 2000 Borland Error makefile 871: Colon expected you shouldn't be using Borland make :) *** 1 errors during make *** make: *** [dmake/dmake.exe] Error 1 (On the machine is installed (it was already there) Borland C++Builder and QtCreator, with paths to Borland directories) you probably want to remove this Borland stuff from your path, building LO with it is certainly not supported. e.g. make should be GNU make ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] message construction bloat ...
Michael Meeks wrote: and I know var-args is type-unsafe, Don't all of the major compilers have extensions for compile-time checking of printf-style strings? Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] final and override
Hi I see the Mozilla project is adding MOZ_FINAL and MOZ_OVERRIDE macros to help control method overriding in their codebase http://whereswalden.com/2011/11/16/introducing-moz_override-to-annotate-virtual-functions-which-override-base-class-virtual-functions/ http://whereswalden.com/2011/11/26/introducing-moz_final-prevent-inheriting-from-a-class-or-prevent-overriding-a-virtual-function/ Would such things be useful additions to the LibreOffice codebase? -- Noel Grandin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] SWT window locks LOo
that's called open-source software: http://en.wikipedia.org/wiki/Open-source_software othman wrote: The best way to get things done is to do them yourself. Feel free to start on that topic if it's really a blocker for you. if i knew how to fix it i wouldn't have asked in this forum. It's strange when you ask for help for a project people tell you to do it yourself! very strange! -- View this message in context: http://nabble.documentfoundation.org/Re-SWT-window-locks-LOo-tp3545675p3547846.html Sent from the Dev mailing list archive at Nabble.com. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About build libo on Windows
You need an extra forward slash before the cygdrive On Thursday, 1 December 2011, Alex Sandro Fagundes alexsfagun...@gmail.com wrote: Thanks for the tip. But, now I'm with problems with SDK. The problem is on annex. I've tried: --with-jdk=cygdrive/c/Program Files/Java/jdk1.6.0_25 But, not work still. 2011/12/1 Andras Timar tima...@gmail.com Hi Alex 2011/12/1 Alex Sandro Fagundes alexsfagun...@gmail.com: The error is related to SeaMonkey that is build on Microsoft Visual Studio 2005, but how I have the Visual Studio 2008, I not can install the 2005. That's right. We don't build SeaMonkey on Windows. Use --disable-build-mozilla. See https://wiki.documentfoundation.org/Development/Windows_Build_Dependencies#Autogen_options for more info. Good luck! Andras -- Att, Alex Sandro Fagundes Twitter: @alexsfagundes Email : alexsfagun...@gmail.com Fone: (47) 84459054 WEB SITE: www.descobrindoideias.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Clipboard handling on Windows
I stand under correction, but I believe the correct answer is that ideally, you need to support **both**. I think the second one is the newer one, and Windows provides some support for interfacing applications using the first one with applications using the second one. Which is why you see some of the formats, but not all of them, when you use the second API. Ideally, I think LO needs to get a list from both API's and eliminate duplicates. Of course, you could always fire up Excel under a Windows debugger, put breakpoints on all of those API entry points, and see what it does :-) -- Noel Grandin Kohei Yoshida wrote: Hi fellow hackers, While investigating this bug https://bugs.freedesktop.org/show_bug.cgi?id=33100 which involves Windows' clipboard handling, I've come to the realization that, there are two ways to communicate with the clipboard on Windows. One is to use the regular clipboard API http://msdn.microsoft.com/en-us/library/windows/desktop/ms648709% 28v=vs.85%29.aspx which allows you to open, close, query the available formats, and fetch the raw clipboard data stream for a requested format. The other way is to obtain the IDataObject instance from the clipboard, and fetch the clipboard data stream from that object. http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421% 28v=vs.85%29.aspx First of all, I don't quite understand why two different ways, and what the differences are between the two. Our current clipboard implementation in dtrans uses the IDataObject-based approach. Now, as I discovered while investigating the bug, using the IDataObject method does not necessarily return all available clipboard formats, whereas using the regular clipboard API does. I was thinking naively about perhaps replacing our current IDataObject-based approach with the clipboard API based one, but the whole data transfer code does more than just handling the clipboard, so I don't really know how feasible replacing it would be... Does anyone have a better grasp on why we do it the way we do? Feedback and suggestions very much appreciated. Also, if anyone wants to grab Bug 33100, s/he will be more than welcome. :-) Thanks, Kohei Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Slow initialisation of template manager dialogue and subsequent screen corruption
Isn't that one of the pieces written in Java? Alex Thurgood wrote: Hi all, This is not the first time I've noticed on builds from master, but it appears to not have gone away, so I'm assuming no one else has noticed. I have been testing my Linux master builds on 32bit Ubuntu 11.10 with Gnome Classic desktop environment. 1) Start the office. 2) Click on the templates button 3) Wait, wait, wait and wait some more...in all about 30 seconds 4) The template manager dialog finally appears. 5) Now try to move it around the screen, corruption occurs. 6) Leave it alone for another 30 to 40 seconds until the display stabilises. 7) Now try and drag the template manager window around the screen, it leaves a short trail of frames (redraw problem), like something out of one of those ghastly old Windows 3.1 mouse cursors. Anyone else noticed this ? Alex ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] how to acquire an ScDocument reference from scratch
I don't have any unit tests in my tree yet, so feel free to go ahead. -- Noel Grandin Kevin Hunter wrote: At 4:47pm -0500 Thu, 08 Dec 2011, Michael Meeks wrote: On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote: More specifically, I wish there were a way to run exactly and only one test (i.e. a single ::testFunction()). Fine, sounds like a worthy goal. I suggest you hack cppunit to add some magic macro wrappers to stringify the function name, and allow some run-time parameter that will filter the tests immediately on entry down to the one you want. Oh! I didn't realize cppunit was open for hacking from our end. Let's see ... looking through that directory then ... the basic workflow is to write a patch to apply before we compile Cppunit, yes? Also - it seems Noel Grandin is working on a (somewhat different) re-hash of the note storage thing in his tree - worth not treading on his feet there; but of course the more unit tests for note stuff the merrier. Cheers. If Noel is working on that, then I'll turn my attention to something along the test lines. Given my $REAL_LIFE constraints, maybe what I work on should fall farther from the LO critical path ... Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] how to acquire an ScDocument reference from scratch
If there is no living upstream, surely we shouldn't let the current state of affairs hold us back? Why not add the features we need, and remove --with-system-cppunit? I see unit-testing as a project-internal thing anyhow, and it's a build-time dependency, not a run-time dependency, so I don't see --with-system-cppunit as being that important. But I could be wrong? I'd just hate to see our unit-testing efforts held back by the lack of an upstream Stephan Bergmann wrote: On 12/09/2011 12:55 PM, Kevin Hunter wrote: At 4:47pm -0500 Thu, 08 Dec 2011, Michael Meeks wrote: On Thu, 2011-12-08 at 13:05 -0500, Kevin Hunter wrote: More specifically, I wish there were a way to run exactly and only one test (i.e. a single ::testFunction()). Fine, sounds like a worthy goal. I suggest you hack cppunit to add some magic macro wrappers to stringify the function name, and allow some run-time parameter that will filter the tests immediately on entry down to the one you want. Oh! I didn't realize cppunit was open for hacking from our end. Let's Not really. Keep in mind that LO's configure has --with-system-cppunit, which people do make use of. The existing patches fix bugs or warnings, and should have been upstreamed if there were a living upstream. They do not introduce features. That said, AFAIU, xUnit in general and CppUnit in particular does support the notion of finer-grained test suites, allowing one to execute only a subset of a given set of tests. Never looked into how that works, though. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [board-discuss] Re: [Libreoffice-qa] End of the line for 3.3 family and regressions
People who think there should be zero regressions are welcome to donate the necessary time and financial resources to make it happen. Michael Meeks wrote: Hi Pedro, On Sat, 2011-12-10 at 11:46 +, Pedro Lino wrote: This isn't simply a matter of checking and reporting bugs. It involves the Quality of a product this Community claims to be Enterprise ready. IMO there can be NO regressions. Having no regressions is really a feature. That makes it rather incompatible with a time-based release schedule. It is also a highly expensive feature, and it is unclear who is going to do the work fixing every regression in 3.4.x, particularly as the majority of dev. work has switched focus to improving 3.5.x, and particularly since many bugs can be classed as regressions if we try hard :-) I agree with you that the claim of Enterprise ready is perhaps somewhat misleading and IMHO rather unhelpful. LibreOffice is not Enterprise ready without enterprise support (which is capable of fixing any regressions or issues a customer may experience). No matter how good the job we do, customers will always find more bugs they need fixing, regression or not. The TDF BoD and the Devs need to make a decision about how to handle this. I would recommend sticking to our time-based release schedule - there are rather a number of nice bug fixes in 3.4.5 as it is, I've been watching a few longer standing issues get nailed there. Having said all that, I don't see that 3.4.5 has to be the last release in that series. I anticipate that people will still continue to merge critical and/or obviously correct fixes and/or security fixes to the libreoffice-3-4 branch, and we may have a 3.4.6 at some stage. We had a particularly long 3.5 development cycle, so ... Of course, if some enterprise wants to support 3.4.x and continue porting fixes to it releasing they are of course most welcome to do that indefinitely. What we need to do about the 3.3.x bugs, I don't know. If we have no resources to re-test them vs. 3.4 - I would suggest we wait until we have a good 3.5 beta to point at, and close them all with a comment asking users to reproduce them in 3.5 and re-open/re-target them at that version. But perhaps that is too harsh ? :-) either way, leaving bugs malingering vs. 3.3.x while knowing full well that they'll be hidden vs. that version is not so useful I think. At least, that's my take :-) HTH, Michael. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [patch] german translations
Hi This patch is the result of a collaboration between myself and Mike Whitely. I machine-translated some German comments using google-translate and then Mike fixed up the results so the translations matched the original sense of the German comments :-) Patch is submitted under MPL/ LGPL3+, and I believe Mike has already submitted patches and given blanket permission. Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [patch] german translations
Hi
This patch is the result of a collaboration between myself and Mike Whitely.
I machine-translated some German comments using google-translate and then Mike
fixed up the results so the translations
matched the original sense of the German comments :-)
Patch is submitted under MPL/ LGPL3+, and I believe Mike has already submitted
patches and given blanket permission.
Regards, Noel Grandin
Disclaimer: http://www.peralex.com/disclaimer.html
--- a/autodoc/source/parser/cpp/all_toks.hxx
+++ b/autodoc/source/parser/cpp/all_toks.hxx
@@ -188,12 +187,12 @@ /* just for viewing:
class Tok_TypeKey : public cpp::Token // file-type-PE
class Tok_Template : public cpp::Token // file
class Tok_Namespace : public cpp::Token// file
-class Tok_Bracket : public cpp::Token // ueberall
-class Tok_Separator : public cpp::Token// ueberall
+class Tok_Bracket : public cpp::Token // everywhere
+class Tok_Separator : public cpp::Token// everywhere
class Tok_Identifier : public cpp::Token // ueberall
class Tok_NameSeparator : public cpp::Token// Type, Name
class Tok_BuiltInType : public cpp::Token // ueberall
class Tok_ConVol : public cpp::Token // class-FuVa
class Tok_StorageClass : public cpp::Token // file-type,FuVa
class Tok_OperatorFunctionName : public cpp::Token // class
--- a/basctl/source/basicide/baside2.cxx
+++ b/basctl/source/basicide/baside2.cxx
@@ -247,7 +246,7 @@ Size(
GetOutputSizePixel() ) );
}
-// Import von baside4.cxx
+// Import of baside4.cxx
void CreateEngineForBasic( StarBASIC* pBasic );
void ModulWindow::CheckCompileBasic()
--- a/basctl/source/basicide/macrodlg.cxx
+++ b/basctl/source/basicide/macrodlg.cxx
@@ -35,7 +34,7 @@ #include macrodlg.hxx
#include macrodlg.hrc
#include basidesh.hrc
#include basidesh.hxx
-#include baside2.hrc // ID's fuer Imagese
+#include baside2.hrc // ID's for Images
#include basobj.hxx
#include baside3.hxx
--- a/basic/source/classes/sb.cxx
+++ b/basic/source/classes/sb.cxx
@@ -1475,7 +1474,7 @@ // The mapping between the old and the new error codes
take place by searching
// through the table SFX_VB_ErrorTab[]. This is indeed not with good
performance,
// but it consumes much less memory than corresponding switch blocs.
// Because the conversion of error codes has not to be fast. there is no
-// binaere search by VB-Error - SFX-Error.
+// binary search by VB Error - Error SFX.
// Map back new error codes to old, Sbx-compatible
sal_uInt16 StarBASIC::GetVBErrorCode( SbError nError )
--- a/basic/source/classes/sbunoobj.cxx
+++ b/basic/source/classes/sbunoobj.cxx
@@ -2470,7 +2469,7 @@ }
if( !mxUnoAccess.is() )
{
-// #51475 mark an invalid objekt kennzeichnen (no mxMaterialHolder)
+// #51475 mark to indicate an invalid object (no mxMaterialHolder)
return;
}
--- a/basic/source/classes/sbunoobj.cxx
+++ b/basic/source/classes/sbunoobj.cxx
@@ -2700,9 +2699,9 @@ if( xNameAccess.is()
xNameAccess-hasByName( aUName2 ) )
{
Any aAny = xNameAccess-getByName( aUName2 );
-// ATTENTION: Die hier erzeugte Variable darf wegen
bei XNameAccess
-// nicht als feste Property in das Object aufgenommen
werden und
-// wird daher nirgendwo gehalten.
+// ATTENTION: The variables generated here may account
for XNameAccess
+// may not be included as a fixed property in the
Object and therefore
+// won't be kept anywhere.
// If this leads to problems, it has to be created
synthetically or
// a class SbUnoNameAccessProperty, whose existence
had to be checked
// constantly and which were if necessary thrown away
--- a/basic/source/classes/sbunoobj.cxx
+++ b/basic/source/classes/sbunoobj.cxx
@@ -2971,7 +2970,7 @@ SbUnoObjectRef xUnoObj = Impl_CreateUnoStruct(
aClassName );
if( !xUnoObj )
return;
-// return the objekt
+// return the object
SbxVariableRef refVar = rPar.Get(0);
refVar-PutObject( (SbUnoObject*)xUnoObj );
}
--- a/basic/source/classes/sbxmod.cxx
+++ b/basic/source/classes/sbxmod.cxx
@@ -1993,7 +1992,7 @@ SbModule::Notify( rBC, rHint );
}
-// Implementation SbJScriptModule (Basic-Modul fuer JavaScript-Sourcen)
+// Implementation SbJScriptModule (Basic module for JavaScript source code)
SbJScriptModule::SbJScriptModule( const String rName )
:SbModule( rName )
{
--- a/basic/source/inc/parser.hxx
+++ b/basic/source/inc/parser.hxx
@@ -83,7 +82,7 @@ sal_Bool bExplicit;// sal_True: OPTION
EXPLICIT
sal_Bool
Re: [Libreoffice] [patch] german translations
Hi Thanks Stefan. Any particular preference as to which areas should receive high priority for translations? -- Noel Stefan Knorr (Astron) wrote: Hi back, Please manually check your translations before submitting. This one for instance is complete garbage: -// Eine STD-Lib erzeugen, sonst macht es Peng! +// An STD-Lib product, otherwise it just looks good (~Correct translation: Create an STD-Lib, otherwise it goes boom. or something similar.) I'm fixing things up currently, I'll push this later today. Please also note that there's no real need to translate stuff in binfilter, as it will be removed sooner or later anyway. Astron. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] getting debug symbols when running build unit tests under gdb?
Hi This is under Ubuntu Linux. I'm trying to track down a stack overflow in my code, and I'm having some trouble running the unit tests under GDB and getting debugging symbols. I'm doing EXPORT GDBCPPUNITTRACE=gdb --args then running the module build under /sc build and then breaking the runaway process using kill -5 and then doing 'bt' in GDB But all I get is #110137 0x40b0ddc1 in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110138 0x40a96883 in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110139 0x40a6b9db in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110140 0x40b0ddc1 in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110141 0x40a96883 in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110142 0x40a6b9db in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so #110143 0x40b0ddc1 in ?? () from /home/noel/libo/solver/unxlngi6.pro/lib/libsclo.so Any ideas? Thanks, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] getting debug symbols when running build unit tests under gdb?
Thanks Markus, I'll try that in the morning. Do you know of any trick for catching stack-overflow problems? The trick I'm using is pretty painful. On Wed, Dec 14, 2011 at 17:52, Markus Mohrhard markus.mohrh...@googlemail.com wrote: Hello Noel, his is under Ubuntu Linux. I'm trying to track down a stack overflow in my code, and I'm having some trouble running the unit tests under GDB and getting debugging symbols. I'm doing EXPORT GDBCPPUNITTRACE=gdb --args then running the module build under /sc build and then breaking the runaway process using kill -5 and then doing 'bt' in GDB I think you should enable symbols in sc by running make clean make -sr debug=true in sc. Then normally EXPORT GDBCPPUNITTRACE=gdb --args should open a gdb shell where you just type run and can debug the unit test like a normal program. It might be a bit tricky depending on which unit test you want to debug because this works only for the first one. So you might need to remove the second one from Module_sc.mk if you want to debug the other one. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PATCH] removing mpNotes field from ScBaseCell
Hi
So I've been working on this patch to move mpNotes from ScBaseCell to
ScTable, and I got it mostly working.
But I was struggling with leaks and getting the lifecycle of the notes
to exactly match the lifecycle of the ScBaseCell object.
So then I had a weird idea - how about if I tied the lifecycles
together implicitly?
So I came up with this patch.
It compiles, and passes a make check.
I'll do a memcheck run on Monday when I can get access to my other
machine with tons of memory.
Regards, Noel Grandin
diff --git a/sc/inc/cell.hxx b/sc/inc/cell.hxx
old mode 100644
new mode 100755
index fa1b719..1755591
--- a/sc/inc/cell.hxx
+++ b/sc/inc/cell.hxx
@@ -122,11 +122,11 @@ public:
inline void SetScriptType( sal_uInt8 nNew ) { nScriptType = nNew; }
/** Returns true, if the cell contains a note. */
-inline bool HasNote() const { return mpNote != 0; }
+bool HasNote() const;
/** Returns the pointer to a cell note object (read-only). */
-inline const ScPostIt* GetNote() const { return mpNote; }
+const ScPostIt* GetNote() const;
/** Returns the pointer to a cell note object. */
-inline ScPostIt* GetNote() { return mpNote; }
+ScPostIt* GetNote();
/** Takes ownership of the passed cell note object. */
voidTakeNote( ScPostIt* pNote );
/** Returns and forgets the own cell note object. Caller takes ownership!
*/
@@ -169,7 +169,6 @@ private:
ScBaseCell operator=( const ScBaseCell );
private:
-ScPostIt* mpNote; /// The cell note. Cell takes ownership!
SvtBroadcaster* mpBroadcaster; /// Broadcaster for changed values. Cell
takes ownership!
protected:
diff --git a/sc/source/core/data/cell.cxx b/sc/source/core/data/cell.cxx
old mode 100644
new mode 100755
index 6cc8209..04aae8c
--- a/sc/source/core/data/cell.cxx
+++ b/sc/source/core/data/cell.cxx
@@ -82,10 +82,16 @@ IMPL_FIXEDMEMPOOL_NEWDEL( ScStringCell,
nMemPoolStringCell, nMemPoolStringCell
IMPL_FIXEDMEMPOOL_NEWDEL( ScNoteCell,nMemPoolNoteCell, nMemPoolNoteCell )
#endif
+/**
+ * The notes map. Because only a handful of notes typically exist in an
application, but there can be millions
+ * of cells, we don't want to store this on the cell itself
+ */
+typedef ::std::mapconst ScBaseCell*, ScPostIt* ScNotesMap;
+static ScNotesMap notesMap;
+
//
ScBaseCell::ScBaseCell( CellType eNewType ) :
-mpNote( 0 ),
mpBroadcaster( 0 ),
nTextWidth( TEXTWIDTH_DIRTY ),
eCellType( sal::static_int_castsal_uInt8(eNewType) ),
@@ -94,7 +100,6 @@ ScBaseCell::ScBaseCell( CellType eNewType ) :
}
ScBaseCell::ScBaseCell( const ScBaseCell rCell ) :
-mpNote( 0 ),
mpBroadcaster( 0 ),
nTextWidth( rCell.nTextWidth ),
eCellType( rCell.eCellType ),
@@ -104,7 +109,12 @@ ScBaseCell::ScBaseCell( const ScBaseCell rCell ) :
ScBaseCell::~ScBaseCell()
{
-delete mpNote;
+ ScNotesMap::iterator it = notesMap.find(this);
+ if (it != notesMap.end()) {
+ ScPostIt *pNote = it-second;
+ notesMap.erase(this);
+ delete pNote;
+ }
delete mpBroadcaster;
OSL_ENSURE( eCellType == CELLTYPE_DESTROYED, BaseCell Destructor );
}
@@ -244,12 +254,14 @@ ScBaseCell* ScBaseCell::CloneWithoutNote( ScDocument
rDestDoc, const ScAddress
ScBaseCell* ScBaseCell::CloneWithNote( const ScAddress rOwnPos, ScDocument
rDestDoc, const ScAddress rDestPos, int nCloneFlags ) const
{
ScBaseCell* pNewCell = lclCloneCell( *this, rDestDoc, rDestPos,
nCloneFlags );
-if( mpNote )
+ ScNotesMap::iterator it = notesMap.find(this);
+ if (it != notesMap.end())
{
if( !pNewCell )
pNewCell = new ScNoteCell;
bool bCloneCaption = (nCloneFlags SC_CLONECELL_NOCAPTION) == 0;
-pNewCell-TakeNote( mpNote-Clone( rOwnPos, rDestDoc, rDestPos,
bCloneCaption ) );
+ScPostIt* pNote = it-second;
+pNewCell-TakeNote( pNote-Clone( rOwnPos, rDestDoc, rDestPos,
bCloneCaption ) );
}
return pNewCell;
}
@@ -282,27 +294,63 @@ void ScBaseCell::Delete()
bool ScBaseCell::IsBlank( bool bIgnoreNotes ) const
{
-return (eCellType == CELLTYPE_NOTE) (bIgnoreNotes || !mpNote);
+return (eCellType == CELLTYPE_NOTE) (bIgnoreNotes ||
notesMap.find(this) == notesMap.end());
+}
+
+/** Returns true, if the cell contains a note. */
+bool ScBaseCell::HasNote() const
+{
+ return notesMap.find(this) != notesMap.end();
+}
+
+/** Returns the pointer to a cell note object. */
+ScPostIt* ScBaseCell::GetNote()
+{
+ ScNotesMap::iterator it = notesMap.find(this);
+ return it == notesMap.end() ? 0 : it-second;
+}
+
+/** Returns the pointer to a cell note object (read-only). */
+const ScPostIt* ScBaseCell::GetNote() const
+{
+ ScNotesMap::iterator it = notesMap.find(this);
+ return it == notesMap.end() ? 0
Re: [Libreoffice] [PATCH] removing mpNotes field from ScBaseCell
Hi Yeah, that is what I tried the first time. But it turns out to be incredibly hard to keep the lifecycle of the ScBaseCell objects and the lifecycle of the ScPostIt objects tied together, because ScBaseCell and it's child classes get allocated and deallocated in lots of different places, not just in ScTable. -- Noel On Sat, Dec 17, 2011 at 21:43, Markus Mohrhard markus.mohrh...@googlemail.com wrote: Hello Noel, So I've been working on this patch to move mpNotes from ScBaseCell to ScTable, and I got it mostly working. But I was struggling with leaks and getting the lifecycle of the notes to exactly match the lifecycle of the ScBaseCell object. I think that we should go another way. Firstly we should not use a static variable here. Please make the NotesMap a member variable of ScTable. I hope that this solves one part of your problem and then we should no longer need to make the notes directly available to the cells. Every information we need should already be available in ScTable and the idea behind this rework is not only to save a bit memory per cell but to prepare calc for ixion. Personally I think we should use another datastructure like std::mapAddress2D, ScPostIt* or bootst::ptr_mapAddress2D, ScPostIt but that is something we can figure out later. I think for now it is more important to move the container to ScTable and make it a member variable. So then I had a weird idea - how about if I tied the lifecycles together implicitly? So I came up with this patch. It compiles, and passes a make check. I'll do a memcheck run on Monday when I can get access to my other machine with tons of memory. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] removing mpNotes field from ScBaseCell
Hi The problem with doing the logic in ScTable is that an ScPostIt on an otherwise empty cell still needs an ScNoteCell object to exist. And the allocation and free'ing of Sc*Cell objects happens primarily in ScColumn. And all of the ScDocument/ScTable/ScColumn classes call one another all over the place, there is no strict hierarchy. As I said, I have a patch that puts a std::map in ScTable and performs most of the notes logic in ScColumn. I am prepared to finish debugging that patch and post it if the community decides that is still the way forward. But even with putting the notes logic next to the cell logic in ScColumn, the solution still looks extremely brittle to me. Moving the notes allocate/free logic from ScColumn to ScTable would only make it worse. To my mind, a better solution would look something like this: - create an ScCellManager class - move the cell data arrays from ScColumn to ScCellManager - in pieces, move API from Sc*Cell to ScCellManager until nothing else has direct access to the Sc*Cell classes - then change the internal representation inside ScCellManager to your hearts content Regards, Noel Grandin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [patch] translate some german comments in /svx
Hi
More translations, work by Mike Whiteley and Noel Grandin, patch is under
MPL/LGPL+
Regards, Noel
Disclaimer: http://www.peralex.com/disclaimer.html
diff --git a/svx/inc/svx/obj3d.hxx b/svx/inc/svx/obj3d.hxx
index 5cf5d03..e2d7e2d 100644
--- a/svx/inc/svx/obj3d.hxx
+++ b/svx/inc/svx/obj3d.hxx
@@ -118,7 +118,7 @@ private:
protected:
virtual sdr::properties::BaseProperties* CreateObjectSpecificProperties();
-E3dObjList maSubList; // child objekts
+E3dObjList maSubList; // child objects
basegfx::B3DRange maLocalBoundVol;// surrounding volume of
the object (from the geometry generation)
basegfx::B3DHomMatrix maTransformation; // local transformation
diff --git a/svx/inc/svx/sdrpagewindow.hxx b/svx/inc/svx/sdrpagewindow.hxx
index 7498c32..d1a2633 100644
--- a/svx/inc/svx/sdrpagewindow.hxx
+++ b/svx/inc/svx/sdrpagewindow.hxx
@@ -35,7 +35,7 @@
#include com/sun/star/awt/XControlContainer.hpp
#include com/sun/star/util/XModeChangeListener.hpp
#include cppuhelper/implbase4.hxx
-#include svx/svdtypes.hxx // fuer SdrLayerID
+#include svx/svdtypes.hxx // for SdrLayerID
#include svl/svarray.hxx
#include tools/contnr.hxx
#include svx/sdrpagewindow.hxx
diff --git a/svx/inc/svx/sdtakitm.hxx b/svx/inc/svx/sdtakitm.hxx
index a869003..2ac0dbb 100644
--- a/svx/inc/svx/sdtakitm.hxx
+++ b/svx/inc/svx/sdtakitm.hxx
@@ -43,48 +43,47 @@ enum SdrTextAniKind {SDRTEXTANI_NONE,
SDRTEXTANI_SLIDE};
// - SDRTEXTANI_BLINK:
-// Einfach nur Blinken. Direction und Amount ohne Wirkung.
-// Frequenz siehe Delay, 0=0.5Hz (Delay=250).
-// Count=Anzahl der blinker. 0=Endlos.
-// StartInside: sal_False=beginnend mit Pause, sal_True=Beginnend mit Puls
-// StopInside: sal_False=Nach Count blinkern nicht sichtbar,
sal_True=sichtbar
-//(nur wenn Count!=0)
+// Just blink. Direction and Amount don't effect things.
+// Frequency delay: 0 = 0.5Hz (Delay = 250).
+// Count = number of blinks. (0 = forever)
+// start inside: sal_False = begin with the blinker off, sal_True = begin
with the blinker on
+// stop inside: sal_False = end with the blinker off, sal_True = end with
the blinker on
+//(Only if count! = 0)
// - SDRTEXTANI_SCROLL:
-// Schrift laeuft rein, laeuft vollstaendig durch. Wenn ganz verschwunden
-// geht's wieder von vorne los.
-// Delay in ms, Sonderfall Delay=0 wird auf 50ms defaulted (20Hz)
-// Count=Durchlaufanzahl (0=Endlos)
-// Direction: ist eben die Richtung in die gescrollt wird.
-// StartInside: sal_False=Schrift wird auch beim ersten Durchlauf
reingescrollt
-//sal_True=Der linke Teil der Schrift steht beim ersten
Durchlauf
-// bereits da (im sichtbaren Scrollbereich)
-// StopInside: sal_False=Schrift wird auch beim letzten Durchlauf
vollstaendig
-// rausgescrollt
-//sal_True=Schrift wird beim letzten Durchlauf nicht
rausgescrollt
-//(nur wenn Count!=0)
-// Amount: Schrittweite in logischen Einheiten. Negative Werte bedeuten
-// Pixel statt log. Einheiten. Wenn Amount=0, dann wird auf
+// Text just scrolls all the way through, and starts over when it is done.
+//
+// Delay in ms: (except delay = 0 means 50ms (20Hz) default)
+// Count = number of passes (0 = go forever)
+// Direction: the direction to scroll
+// StartInside: sal_False = on the first pass, scroll the text in (not
initially visible)
+//sal_True = on the first pass, the left part of the text is
already visible
+// in the scroll area before starting.
+// StopInside: sal_False = on the last pass, scroll the text all the way out.
+//sal_True = on the last pass, keep the right part of the text
visible.
+//(Only if count! = 0)
+// Amount: Step size in logical units. Negative values = use Pixels instead
+// of logical units. If Amount = 0, then default to 1 Pixel.
// 1 Pixel defaulted.
// - SDRTEXTANI_ALTERNATE:
-// Wie SDRTEXTANI_SCROLL, nur wird nicht gescrollt bis Schrift ganz
-// verschwunden, sondern bis der letzte Teil vollstaendig sichtbar ist. Dann
-// wird die Richtung umgekehrt und zuruekgescrollt.
-// Count=Anzahl der Durchlaeufe=Anzahl der Richtungswechsel-1
-// Bei Count=1 ist SDRTEXTANI_ALTERNATE also identisch mit SDRTEXTANI_SCROLL
-// Direction ist die Startrichtung
-// Alle andern Parameter wie SDRTEXTANI_SCROLL
+// Like SDRTEXTANI_SCROLL, except don't scroll until all of the text is out,
+//but just until the last part is visible. Then, change direction and
+//scroll the text the other way.
+// Count = number of passes (number of direction changes minus 1)
+//If count = 1, this is the same as SDRTEXTANI_ALTERNATE
SDRTEXTANI_SCROLL
+// Direction = the starting direction.
+// All Other
[Libreoffice] bug in post-commit hook
there is something wrong with the post-commit hook - I'm getting repeats of the message below every few seconds. Original Message Subject:[Libreoffice-commits] Changes to 'refs/tags/libreoffice-3.4.3-final' Date: Thu, 22 Dec 2011 07:06:53 -0800 (PST) From: pmla...@kemper.freedesktop.org (Petr Mladek) Reply-To: libreoffice@lists.freedesktop.org To: libreoffice-comm...@lists.freedesktop.org Tag 'libreoffice-3.4.3-final' created by Petr Mladek pmla...@suse.cz at 2011-12-22 15:05 +0100 Tag libreoffice-3.4.3-final (3.4.3-final) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJO80dVAAoJEPQ0oe+v7q6jyMkP/3VN41X1EV4XKLEFwgJiCX4A veacVJnDz0Jeel6CugOumyDU0REfLlN6jL0jVfn4ogLdutMadmMOLhKHuyMLVRjJ EiZaMjp6bfj4olHvDFJPu29psqwxvI/yRweDjJw5i4i9qHYdUTx6Sg/5jWLMWE/g YKApm8nTNc4lD7rb/MxGpMTgCZyThoZh0ZR/O3xEs0CJQAVdKe9XuEjaxyYLB0iP nkvUIDj9/smNq4pf4psOau2CXOJL920+9POc2/RsC9NYQO0+vQG35SQO/pHx2nH/ DWx49nxG3U4uHmLXWuufWerV8BEdKUdkYlsYsIW5aisTMlJiZ0X0jQYHhv67Y7Pa qSbFo1MKmtr5UY6U3ztGZiZx0k4kZuT9zA51uhhgRCzdqv23JRAnljdI88kEqaVz t3OHb/bmsBVDYnmLfWlRjF9kLCYLuvH0vRVTip3f6yVHbf8uw/smpGlFdzgPDeXQ 4QaOkUCY0G7HpElf8f9ATzvYylw7PyCiyu/8Gus4RKrvubrpoJNdjEMfYZr4HMfW kiBne4ui3LrYAKultlPb0+Hd0yxjuo+QwhqXhBkLSnQhoc/AKng9odo7jvQCW1hO 5v3KqpryTQ6ViwLpeXSSBtJ/PvGvWTK/430bfXX2gfdYEHE+hb2f9zX7bf8QOCdK aFPhnf9yp7h74ehm2nHG =+ymJ -END PGP SIGNATURE- Changes since libreoffice-3.4.3.1-1: --- 0 files changed --- ___ Libreoffice-commits mailing list libreoffice-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] bug in post-commit hook
I've had about a 100 so far today On Thursday, 22 December 2011, Michael Stahl mst...@redhat.com wrote: On 22/12/11 16:12, Noel Grandin wrote: there is something wrong with the post-commit hook - I'm getting repeats of the message below every few seconds. are you sure? i guess there should be ~20 of them, one for each bootstrap based repo ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Removing LibO on Windows ...
In my experience, good uninstallers check if the application is currently running, and refuse to complete the uninstallation process until the user has exited the program. Something like: A LibreOffice application is still running. Please save and exit before continuing. And then grey out the Next button. For bonus points, the uninstaller should automatically continue without needing to be prompted when the user has exited the running LibreOffice application. Stefan Knorr (Astron) wrote: Hi all, Well, should be pretty easy to create a pre_uninstall event that kills the process before it is removed. Is there any historical reason for not doing it this way? That would be rude. Users may have unsaved data, etc. Can't we ask users if they really want to kill the application before we go and kill it? (something like Title: LibreOffice is currently active. Message: As long as LibreOffice is active, it can not be removed. Do you want to close LibreOffice now? Warning: you will lose any document you are currently working with in LibreOffice.) And, really we should detect if only the quick starter is active (no open files) and if that's the case why not just kill it? Astron. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trying to diagnose base running extremely slowly
Surely now that it's confined to a single thread, it can just call AttachThread() once at startup, and never need to call DetachThread() ? -- Noel Grandin On 2012-01-13 10:54, Stephan Bergmann wrote: On 01/12/2012 02:18 PM, Michael Meeks wrote: On Thu, 2012-01-12 at 10:44 +0100, Stephan Bergmann wrote: One drawback of using the thread-affine apartment is that all code related to the JDBC driver is effectively serialized, removing any potential performance advantage from accessing the driver from multiple treads. I do not know whether that is acceptable or not. Given the generally tangled locking everywhere I would expect that virtually everything is serialised anyway ;-) so ... It'd be great to have a fix for the base guys I guess. Yeah, probably not worth it bothering about MT-performance here. Anyway, pushed now to libreoffice-3-5 and master. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trying to diagnose base running extremely slowly
Yeah, but given that such a re-design is probably a long way off, and that other drivers seem are confined to a single-thread, and seem to have acceptable performance, perhaps we should just live with this limitation, and optimise the easy-case? On 2012-01-13 11:18, Stephan Bergmann wrote: On 01/13/2012 09:59 AM, Noel Grandin wrote: Surely now that it's confined to a single thread, it can just call AttachThread() once at startup, and never need to call DetachThread() ? Yes, one could improve it further based on the fact that it is confied now (it also internally uses some mutices that could go now). But: However, a better fix would still be to redesign the code so that it does not call Attach/DetachCurrentThread so frequently [and confinement to the thread-affine apartment can be undone again.], http://cgit.freedesktop.org/libreoffice/core/tree/connectivity/source/drivers/jdbc/jservices.cxx?id=bb59742bcf4883af5876a2ffadcc4a689e414b60#n95. Stephan Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ScColumn - convert array to vector
I forgot to say that the patch passes the unit tests, and a valgrind run (I love that tool). On 2012-01-13 09:06, Noel Grandin wrote: Hi This patch converts open-coded array management to std::vector in ScColumn Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Trying to diagnose base running extremely slowly
But anyway, I'll keep this in the back of my head, and if QA does not find any horrible problems with confining the JDBC driver in LO 3.5, we can probably simplify the code on master. (Would you be interested?) Got something else on my plate right now (moving notes out of ScCell), but once I'm over that hump, I'll take a look at it. -- Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ScColumn - convert array to vector
Hi Oh no!, I was testing some stuff and accidentally commented out the critical line in ScColumn::Append(). This line +//aItems.resize(nSize); should be +aItems.resize(nSize); We could call reserve() on the vector to allocate extra capacity, but I don't think there is any way to get exactly the same behaviour as before in the ScColumn::Append() method. I could add an extra method on ScColumn to reserve capacity, which would be a more explicit way for the import process to prevent extra re-allocation. On Fri, Jan 13, 2012 at 17:54, Kohei Yoshida kohei.yosh...@suse.com wrote: On Fri, 2012-01-13 at 10:39 -0500, Kohei Yoshida wrote: The only thing I'd like to check is that, I believe we had some sort of column array resizing policy which controls whether we should increase its size only to the minimum necessary size or increase it to a size larger than necessary to avoid future reallocation. We do change this policy sometimes during import which reduces import performance quite a bit. Yup, your change in ScColumn::Append() removes that policy. Let me think about how we can preserve that behavior... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] ScColumn - convert array to vector
Sorry to waste your time, I'll have another run at this on Wednesday, when I get back from a business trip. On Sat, Jan 14, 2012 at 00:32, Kohei Yoshida kohei.yosh...@suse.com wrote: On Fri, 2012-01-13 at 17:00 -0500, Kohei Yoshida wrote: On Fri, 2012-01-13 at 15:27 -0500, Kohei Yoshida wrote: Let me do a thorough review of your patch one more time, and I'll push to master. Unfortunately one of the filters-test fails on master, after applying the patch. The crash occurs in ScColumn::CloneCell, at line 824 which is switch (rSource.GetCellType()) Hmm Noel, it would be great to have you look into this. I don't have an immediate thought on what could be causing the crash, but we can't apply it as-is obviously. If you have the latest master build, try opening sc/qa/unit/data/ods/named-ranges-global.ods and it crashes over here. Without the patch, the file opens fine. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Structural QA activities
Coverity will do this themselves for LibreOffice for free: http://scan.coverity.com/ It just needs someone from the project to liaise with them and get it set up. On 2012-01-18 14:30, Luc Castermans wrote: Gents, I've been polling inside my work-environment whether I could run Coverity on the LibreOffice code tree. No success so far,it has my attention. From my past I know of similar tools, static code analysis tools, like QAC. Which triggers the question: has a QA-tool been run on the source code, if so which? Thx, Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Structural QA activities
I think the issue is that the guy who was managing the project (David Maxwell) has moved on from Coverity to eSentire. I've dropped him an email to see if he knows who took over from him at Coverity. On 2012-01-18 16:13, Michael Meeks wrote: Hi Noel, On Wed, 2012-01-18 at 14:54 +0200, Noel Grandin wrote: Coverity will do this themselves for LibreOffice for free: http://scan.coverity.com/ In theory :-) the reality is rather different, I've contacted those chaps both directly and indirectly and got no response at all. The sad story is that (in the past) they did the work to get this setup for OpenOffice.org - and then their work was ignored; so ... It just needs someone from the project to liaise with them and get it set up. It'd be great to have someone that could run this for us and share the report (if their license allows that). It'd make some great fruit for easy hacks. Then again - please do reach out to them again - perhaps things will go better this time ? [ asking for a free (evaluation?) license might be good too if someone wanted to set this up ]. All the best, Michael. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW][3-4] date change regression fdo#44385
On 2012-01-20 13:32, Noel Power wrote: [*] table of behaviour in vba, pre the bug being introduced and post patch msoold behaviour present date + numDate Date Date date - numDate DoubleDate date * numDoubleDoubleDouble date / numDoubleDoubleDouble date + date Date DoubleDouble [1] date - date DoubleDoubleDouble date * date DoubleDoubleDouble [1] the date + date is clearly wrong (fixing that would address '3.' above. ) The MSO behaviour mostly makes sense to me - using plus or minus on a date value returns a date value, using times or divide on a date value returns a double. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH V2] replace open-coded array with std::vector in ScColumn
I hereby confirm that this and my future contributions are licensed under GPLv3+/LGPLv3+/MPL1.1+ The problem was in ScColumn::Resize I was calling vector::resize when the correct call is vector::reserve At some point I should rename the ScColumn::Resize method to match the std::vector naming -- Noel Grandin On Fri, Jan 20, 2012 at 19:07, Kohei Yoshida kohei.yosh...@suse.com wrote: On Fri, 2012-01-20 at 15:15 +0200, Noel Grandin wrote: Hi this patch passes valgrind tests in the sc module, and passes a global make check. Yup. All looks green. Nice work. :-) Before I push, could you verify that you are submitting this patch under GPLv3+/LGPLv3+/MPL1.1+ licenses? Out of curiosity, what was the problem that was causing the unit test to fail with your earlier patch? Best, Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [bug fdo#41326] UI: Impossible to select text from the input line in a read-only document
Yes, that's why we need to develop patches. See here if you want to help: http://www.libreoffice.org/get-involved/developers/ On Sat, Jan 21, 2012 at 14:20, Rob Snelders programm...@ertai.nl wrote: Hi All, I had the same problem as the people in this bug. Isn't it possible to enable the feature to select text in Read-Only-documents by default? I think it will help a lot of people when opening documents from, for example, email. -- Greetings, Rob Snelders ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] validation documents for writer
I thought someone was running a test-bot that downloaded all of the documents from bugzilla and loaded them? Maybe the best place is just to attach them to the relevant bug entries in bugzilla? On Sun, Jan 22, 2012 at 12:12, Luc Castermans luc.casterm...@gmail.com wrote: Hi, Below documents could be used in the test-suite for writer: The first one contains a 2 column layout, but shows 4 columns in 3.5rc1, and triggered a crash in earlier versions, incl. 3.3.4: http://members.ziggo.nl/enouwens/permanente%20dingen/odt-docx/kubus.docx The odt version, triggered a crash in 3.5 beta version, is ok in 3.5rc1 http://members.ziggo.nl/enouwens/permanente%20dingen/odt-docx/kubus.odt Is there is place for these, or just hand-try with each validation test? Luc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] make check fails with lots of missing dictionaries
I had the same problem. Doing a make clean and then updating to HEAD fixed it for me, but can't say exactly why... On 2012-01-23 09:28, Chr. Rossmanith wrote: Hi, what can I do to make make check succeed? Currently it fails with: ... languages en-US ... ... analyzing files ... ERROR: The following files could not be found: ERROR: File not found: dict-an.oxt ERROR: File not found: dict-ar.oxt ERROR: File not found: dict-be.oxt ERROR: File not found: dict-bg.oxt ERROR: File not found: dict-bn.oxt ERROR: File not found: dict-de.oxt ERROR: File not found: dict-el.oxt ERROR: File not found: dict-gd.oxt ERROR: File not found: dict-gu.oxt ERROR: File not found: dict-hi.oxt ERROR: File not found: dict-lv.oxt ERROR: File not found: dict-pt-pt.oxt ERROR: File not found: dict-si.oxt ERROR: File not found: dict-te.oxt ... cleaning the output tree ... ... removing directory /tmp/ooopackaging/i_150701327301978 ... Mon Jan 23 07:59:43 2012 (00:05 min.) Failed to install: at /Space/LibreOffice_OneGit/core/solenv/bin/ooinstall line 129. dmake: Error code 255, while making 'localinstall' I don't think that this is related to modifications I've made during replacing ByteString with OString... Christina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: sorted_vector, constness, pointers, and structs
On Wed, Jul 18, 2012 at 7:23 PM, Lubos Lunak l.lu...@suse.cz wrote: But it is correct that you get an error in the second case and you ideally should be getting one in the first case as well. You cannot modify the elements of the vector because that might modify what defines their position in their sorted order, isn't that so? That is exactly the reason for those Ummm. No. The sorted_vector class is not intended for storing primitive values. Virtually all of the use-cases create a custom comparator operation. Almost all of time, we are storing complex structs/classes in these vectors, and they have numerous fields that can and do need to be easily modifiable. Returning const-only references defeats that. So we end up having to cast away the const-ness most of the time, which makes the supposed protection worthless. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: sorted_vector, constness, pointers, and structs
On Wed, Jul 18, 2012 at 8:09 PM, Lubos Lunak l.lu...@suse.cz wrote: You didn't read further than that part above, did you? What you want is broken. It is definitely broken from the theoretical point of view, since modifying the items may change the sort order. Aargh. Instead of casting aspersions on my replies, how about you actually read the o3tl::sorted_vector.hxx code and look at some of the use-cases in the LO codebase. What is broken is attempting to provide a level of protection that is not useful in practice, mostly get bypassed, and does not play nice with the C++ type-system. Now, however, if you look at my original email, I make some suggestions that will actually improve things. For example, we can split the problem into 2 sub-use-cases (a) sorted_vector_of_ptr_to_val (b) sorted_vector_of_val Then for each of these cases, we can apply some degree (but not a lot) of const-protection ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Thu, Jul 19, 2012 at 5:50 PM, Michael Meeks michael.me...@suse.com wrote: * 4.0 - when to call it that ? (Kendy) + http://wiki.documentfoundation.org/Development/LibreOffice4 + too much to do in one six-month section IMNSHO, most of the stuff on that page can be accomplished in small, easy chunks, with a minimum of disruption: For each piece, create an EasyHack that looks like: (a) create new methods, namespaces, etc. that fix the problem (b) mark old stuff as deprecated http://stackoverflow.com/questions/295120/c-mark-as-deprecated (c) let the compiler point out the places that need changing (d) leave the old stuff for a couple of releases, and then start a rolling delete ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [HELP] fdo#51239 how to debug it is slow
On 2012-07-19 14:38, Lionel Elie Mamane wrote: For example, to minimise the number of Java calls from C++ , maybe we could, when we retrieve a whole row through JDBC, doing this from Java code instead of from C++ code: for (i=0; i row-getNumberOfColumns; ++i) cacheEntry[i]=row-getColumnValue(i); This would bring us down from one call per column to one call per row, hopefully without duplicating *too* *much* logic between a C++ version and a Java version. For bonus points, retrieve a whole chunk of rows at a time, say around 1000. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: make check with DEBUGCCPUNIT=TRUE is waiting for console output
Ping? Anybody have any ideas? This is driving me nuts during my testing. On 2012-07-11 13:25, Noel Grandin wrote: OK, I'm closer to figuring this one out. When I do this: $ DEBUGCPPUNIT=TRUE make -s check gdb executes the unit tests, but then, if everything went OK, GDB __doesn't quit__ I have to enter a q on the console. However, if there actually was an exception, then GDB correctly prints it out, quits and returns to the command line. This is particularly annoying because, in this mode, there is no indication on the console that GDB is waiting for input. So I don't know if the test is just taking long, or if I need to do something. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: make check with DEBUGCCPUNIT=TRUE is waiting for console output
On 2012-07-23 09:27, Miklos Vajna wrote: So - I think this has been already mentioned in this thread, to just avoid the pain, the best is to run make check without DEBUGCCPUNIT=TRUE My point is that this used to work, and I'm pretty sure it's a bug in the make scripts, since it doesn't seem to be functioning as intended. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
does the windows build require VC10 now?
Hi I'm getting this error on my windows test box (which I'm trying to get building again) : : *** : ERROR: msm file not found: Microsoft_VC100_CRT_x86.msm ! : in function: merge_mergemodules_into_msi_database : *** I have visual studio 2008 installed. Any ideas? Thanks, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On 2012-07-30 11:50, John Smith wrote: On Mon, Jul 30, 2012 at 11:45 AM, Olivier Hallot olivier.hal...@documentfoundation.org wrote: On a second look, most of the issues are with 3rd parties code (nss, openldap, berkeleydb, etc...) Maybe. But even so, bugs in 3rd party software that LibreOffice depends on, potentially means problems in LibreOffice, right ? Yeah, but it's a lot more painful working on that stuff because of the need to push it upstream. I personally, would prefer a report that focussed on the LO-specific code, at least until we get the report down to a manageable size. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Re: [PATCH] Final stretch of converting SV_DECL_PTRARR to STL containers stage 3/3
On Tue, Jul 31, 2012 at 10:38 PM, Michael Stahl mst...@redhat.com wrote:
so with the subsequent removal of svarray.hxx (yay!) there are still
obsolete containers left in tools/inc/tools/{contnr,list,unqidx}.hxx if
you feel bored :)
Thanks for working through those patches.
I've already started on the DECLARE_CONTAINER ones :-)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: make OUString::copy() clip
On 2012-08-02 14:35, Stephan Bergmann wrote: No defensive programming, please. If we consider a given (beginIndex, count) arguments a violation of copy's precondition, then fail on it, as fast as possible (via assert - abort in a non-NDEBUG build, via undefined behavior (- hopefully crash soon) otherwise). Rather crash earlier than later. *NULL = 0xdeadbeef; can't be all that expensive. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PATCH] Convert usages of DECLARE_CONTAINER (5)
Hi These patches convert usage of DECLARE_CONTAINER (i.e. svl/cntnrsrt.hxx). They pass a full make check. After these patches are applied, it should be OK to delete svl/cntnrsrt.hxx Regards, Noel Grandin Disclaimer: http://www.peralex.com/disclaimer.html 0001-STL-ify-DECLARE_CONTAINER_SORT-SwXMLTableColumnsSort.patch Description: application/mbox 0002-STL-ify-DECLARE_CONTAINER_SORT-XMLFamilyDataList_Imp.patch Description: application/mbox 0003-STL-ify-DECLARE_CONTAINER_SORT_DEL-SvXMLAutoStylePoo.patch Description: application/mbox 0004-STL-ify-DECLARE_CONTAINER_SORT_DEL-XMLFontAutoStyleP.patch Description: application/mbox 0005-STL-ify-DECLARE_CONTAINER_SORT-XMLTextListAutoStyleP.patch Description: application/mbox ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Static src analysis of LibreOffice
On 2012-08-03 15:42, John Smith wrote: Well, the analyzer simply follows/precedes whatever you tell 'make' to do. So if the build includes 'make dbuild', then that *will* not only Is there not some kind of path based post-filter for the analyser? So we can tell it to filter out errors belong to certain path hierarchies? Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: STL'ifying UNO API
On 2012-08-06 13:52, Michael Stahl wrote: actually idl has absolutely nothing to do with UNO, it is the other IDL compiler we build called SvIDL that is used for the old non-UNO SFX framework. the UNO idl compiler is in idlc. Excellent. Then I can go ahead and update the IDL module code. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ref-count assertion in cppu::OWeakObject ...
On 2012-08-06 13:53, Michael Meeks wrote: Anyhow - the suggestion is, assuming we can find/cleanup this sort of badness [ incidentally a GObject takes a reference on itself during it's destruction to avoid double destruction ], is it a good idea to have an abort/assert whatever is fashionable in run-time code so we can be confident that we have caught these cases earlier ? I for one prefer an assertion-fail abort-app to a hard-to-catch memory corrupter later. My motto : Fail early, fail hard Causes some screaming early on, then later on, generates a pleasant quietness from the people using my software :-) Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: new style UNO port
Well, it's nice to have you join the cleanup patrol :-) On 2012-08-08 03:47, Jean-Tiare LE BIGOT wrote: Ok, I actually forgot one step in the file re-generation. Sorry for asking a silly question :s Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] more STL work in tools module (6)
Hi Would you mind reviewing the other 5 patches that I posted in the beginning of this thread? 0001-Convert-HashedEntryList-to-boost-ptr_vector.patch 0002-STL-ify-CustomShowList.patch 0003-Expand-the-only-use-of-the-SV_DECL_IMPL_REF_LIST-mac.patch 0004-Convert-SV_DECL_REF_LIST-SvBaseLink-to-std-vector.patch 0005-Remove-unused-SV_DECL_REF_LIST-SvRefBase-SvRefBase.patch Link to nabble in case you've already deleted the mail: http://nabble.documentfoundation.org/PATCH-more-STL-work-in-tools-module-6-td3999505.html Thanks, Noel Grandin On 2012-08-08 09:48, Tor Lillqvist wrote: Thanks, pushed. --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] more STL work in tools module (6)
On 2012-08-08 10:57, Tor Lillqvist wrote: Would you mind reviewing the other 5 patches that I posted in the beginning of this thread? Sorry, they don't seem to all apply cleanly any more: Oh no. OK, I'll rebase them and send out a new set in a couple of days. Thanks for trying. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] [PUSHED] more STL conversion work (8)
Ooop, sorry, my mistake. Having a really painful time today copying things backwards and forwards between my windows and linux boxes. The linux SMB client is just not that robust. On 2012-08-08 12:57, Tor Lillqvist wrote: I pushed those that applied. The 0002-STL-ify-CustomShowList.patch did not. (It probably had been attached by accident to the mail, as the [PATCH X/8] counter in the Subject didn't match that of the others, and there were two 0002-numbered patches?) --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] more STL work in tools module (6)
On 2012-08-08 12:50, Michael Stahl wrote: so it gets rid of Container, which is good. the UniqueIndex class used to be some kind of encoding of an associative array into an array, so using a std::map seems appropriate. but i think it would be even better to remove the UniqueIndex class completely I would have done that, but there are 2 usages of it: rsc/inc/rscdef.hxx:213:typedef UniqueIndexRscFile RscSubFileTab; tools/inc/tools/pstm.hxx:152:typedef UniqueIndexSvPersistBase SvPersistUIdx; , it appears that there are still remnants of the old array-mapping in e.g. UniqueIndexImpl::Insert that seem pointless, also the NextIndex() looks rather slow, just using map iterators directly would be faster. just compute the next key on inserting with something like rbegin()-first + 1 (check for empty() first), that could be a stand-alone function at the use site. UniqueIndex is both a map and a key generator. It also tries to keep the key space as small as possible The key generating part appears to be quite necessary to how the RSC module functions. Suggestions? Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] more STL conversion work (8)
I haven't had any mails at all ? I don't think it sends them to the originator, only to the person who pushes them. Which is probably something that needs fixing. In the tinderbuild status I see: - you've fixed a couple of the problems related to my patches (the missing file, and the extra typename declarations). - one of the boxes has a liblangtag problem - and the others are still catching up So it doesn't look that bad. On 2012-08-08 16:35, Tor Lillqvist wrote: Hmm, the tinderbox situation is quite bad at the moment, have you had a look at the mail you no doubt have been getting from them? Do you think it is something in your patches that were pushed today that could have broken the builds so badly? I probably will revert them... not that I have time any more today to follow whether that helps. --tml Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] more STL conversion work (8)
On Wednesday, 8 August 2012, Michael Stahl wrote: binfilter was completely broken; if you remove stuff from tools please build with --enable-binfilter. i just spent the last 2 hours fixing Oh dear. Very sorry. Will take that into consideration in future. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ODF angle in draw:transform are in degrees
One way would be to add a new attribute specifying either degrees or radians. Then modify the loader code so it looks at the application that created the file to determine what it should do in cases where there is not attribute. Fundamentally, I don't see that there is a perfect solution to this. On Thu, Aug 9, 2012 at 3:41 PM, Regina Henschel rb.hensc...@t-online.de wrote: Hi, there is a problem which I have not addressed in the Wiki (see other mail). As far as I see, the specification ODF 1.1 has no setting for the unit of the angles, but ODF 1.2 set it to degrees. SVG has it in degrees too, so this setting is reasonable. But our implementation uses radians. So there are a lot of documents out, that have the angle in radians in the document. Any idea how to proceed? Kind regards Regina ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On 2012-08-09 21:53, bfo wrote: If I may propose anything, please add: - zero tolerance policy for regression issues during development - zero tolerance policy for crash issues during development People who advocate zero tolerance for such things are welcome to provide the time and financial resources necessary to achieve this. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] More STL'ification (7)
On 2012-08-13 22:53, Michael Stahl wrote: On 13/08/12 15:37, Noel Grandin wrote: Hi These patches convert various places from using tools/list.hxx to using normal STL containers. thanks, pushed to master. Thanks. At this point, it seems like all of the STL'ification work is done, unless there is something more you are aware of? Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] More STL'ification (7)
On 2012-08-14 09:23, David Tardon wrote: There is still List (tools/inc/tools/list.hxx) and Container (tools/inc/tools/contnr.hxx :-) There is only one usage of tools/list.hxx remaining, after which it could be moved to binfilter. Although Michael might have already done that, in which case it could just get removed. The usage is: sd/source/ui/inc/animobjs.hxx but it makes extensive use of the CurPos property of List in interesting ways, which I'd probably break. Anything else that you're aware of? Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] More STL'ification (7)
On 2012-08-14 10:09, David Tardon wrote: Anything else that you're aware of? Well, there is still Container :-) It is used at ~10 places in svx and possibly elsewhere. Thanks, I'll go work on those. Disclaimer: http://www.peralex.com/disclaimer.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build time optimization
On Thu, May 24, 2012 at 5:08 PM, Norbert Thiebaud nthieb...@gmail.com wrote: I have not tested ramdisk on Windows, so I do not know how effective it is. I'm running a tinderbox with a ramdisk on Windows - reduces build time dramatically. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: build time optimization
On 2012-05-24 19:02, Norbert Thiebaud wrote: On Thu, May 24, 2012 at 10:44 AM, Noel Grandinnoelgran...@gmail.com wrote: I'm running a tinderbox with a ramdisk on Windows - reduces build time dramatically. can you post an How-to ? (and possibly some numbers) Note: I do not have enough memory to use it... but I may consider investing in some RAM if that is worth it... http://lists.freedesktop.org/archives/libreoffice/2012-May/031335.html ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
