Re: [Libreoffice] linking against a .a and *not* exporting those symbols ?
On Tue, 2011-07-26 at 18:19 +0100, Michael Meeks wrote:
Hi Caolan,
On Tue, 2011-07-26 at 15:46 +0100, Caolán McNamara wrote:
...
nm -D workdir/unxlngx6/LinkTarget/Library/libooxlo.so|grep
EVP_MD_CTX_create
00666d00 T EVP_MD_CTX_create
That is really dumb :-) this is presumably the joy of using visibility
markup instead of map files.
Yeah, its a downside of using visibility markup vs map files.
I believe if we compile it with:
-fvisibility=hidden
Then all of its symbols should disappear when we link them into liboox
- if we're lucky, perhaps some of the code will go too.
Or perhaps I mis-understood ;-) is it easy to inject those flags ?
Not particularly easy, but ended up doing that anyway.
I was sort of hoping for a fire-once solution which could be wrapped
around all .a files we link against without having to go around custom
hacking various externals. Those makefile.mks are already in
impossible-to-read land :-(
something like...
echo FOO {
echo local:
nm --defined-only -g *.a | grep -v ^$ | grep -v : | cut -d' ' -f 3 |
sed 's/.*/;/'
echo global:
echo *;
echo };
would probably work to generate a suitable map file, but then have to
collect up which libs are .a's on a given link execution, generate a
single map file from them, pass it to the compiler, etc. etc.
Anyway, for this specific case we currently build both shared and static
libs in openssl, but indeed only deliver and use the static ones under
unix platforms.
a) We can't disable shared libs, because then the static libs build
without -fPIC, and aren't suitable for inclusion into a final .so
b) We can't just use CFLAGS because the openssl build system doesn't use
honour it
c) We can munge the flag in through $CC however
d) We then have to *just* build with make build_libs to avoid building
the openssl demos and tools which would attempt to link against the new
useless shared libs that export no symbols
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PUSHED] [REVIEW 3.4] In Calc, after using FindBar, the Search Replace options do not work any more
On 26/07/11 23:31, Jan Holesovsky wrote: Hi, https://bugs.freedesktop.org/show_bug.cgi?id=33593 The fix for that was provided in CWS dr78 which is integrated in LibreOffice, but apparently got lost during a merge - I did not investigate more if it happened already in Mercurial (when the CWS was merged into DEV300), or later in git. The commit that fixes that is this: http://cgit.freedesktop.org/libreoffice/calc/commit/?id=16b812b29614d8a321f6cf38a5908fcffc2baf7e Please cherry-pick to libreoffice-3-4 (1 review), and push :-) Thank you, Kendy yeah patch works like a charm on 3.4 so cherry-picked to 3.4 Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 36915, which changed state. Bug 36915 Summary: Beanshell scripts don't work https://bugs.freedesktop.org/show_bug.cgi?id=36915 What|Old Value |New Value Resolution||DUPLICATE Status|REOPENED|RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [Libreoffice-ux-advise] [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog
This seems to be unexpected - using the FindBar, one should be able to find everything. That would be my assumption when using it, too. With the patch I am proposing for cherry-picking to 3.4 (I have pushed that to master), the options are unset when you use the FindBar, ie. it resets whatever flags the user has set in the Search Replace dialog too. This is not easy to fix, so I wonder if you consider this stop-gap solution bearable for the users? Is this serious enough to warrant fixing it in a point release? As a stop-gap measure it certainly seems an adequate solution, but I'd rather the focus be on decoupling Find bar and Search/Replace dialogue for 3.5. Just two currency units. Astron. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc need too much RAM to open large spreadsheets than Excel, fix?
Hi Sam, On Wed, 2011-07-27 at 16:12 +0700, Samphan Raruenrom wrote: Last year I've done a comparison of memory usage on Windows between OpenOffice.org Calc 3.1 and MS Excel 2003/2007 for spreadsheets with simple formula of various size. I found that Calc take a lot more memory than Excel 2003/2007 when loading large spreadsheets. This is quite well known :-) thanks for the pretty graph though. Is there any work on LibreOffice to reduce memory usage of LibreOffice Calc on large spreadsheets? So - Kohei is working on 'ixion' - which attempts to thread re-calculation, but IMHO -the- fundamental design problem with calc, is something quite banal - the concept that a spreadsheet is built from cells: without breaking that basic misconception I don't think we can do any of the really interesting space / time optimisations we need to do. Having said that - the first trick with optimisation is profiling. Do you have a memory profile ? until we have that it is impossible to see what is chewing the memory - sadly, formulae are -very- large storage-wise in calc [ cf. the above ], and are duplicated for every cell. Even so, it'd be nice to run a memory profiler eg. http://projects.gnome.org/memprof/ [ you will need to export G_SLICE=1 to get real results ] And see what is consuming the most memory, most likely one type will dominate. Then we can help provide some pointers to improving that. How does that sound ? Thanks for the investigation ! :-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix parallel build crash in translate_toolkit requiring solenv
Thanks for that; those parallel build pieces can be hard to catch when they're missing. Nice catch :-) Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Small Question About sal_* Types
On Tue, 2011-07-26 at 23:44 -0500, Norbert Thiebaud wrote: the goal is also to get rid of BOOL, but again being careful with uno interaction: if uno - sal_Bool otherwise bool (this is particularly tricky when touching the prototype of a virtual function... as all of the derived virtual of a given function must be change at once) Ah - indeed; I am hoping that Peter's new gcc analytics work will be able to find instances where we got this wrong with virtual methods and warn us. Peter - prolly another good thing to look at catching initially. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [review for 3.4] fix for bnc#707486
I would really like to get this patch into 3.4, the patch affects vba related calls only and imo safe. Basically the patch allows copy to work for appropriate multi-area ranges. The core calc function 'CopyToClip' variant that is modified is used *only* by vba api implementation code so shouldn't affect ordinary calc operations at all. Note: there is a really evil copy'n'paste-fest going on here, the fix for that in 3.4 would be too risky I think. Basically the ScViewFunc::CopyToClip is largely a line by line copy of the variant of the same name that is used by core calc. Similarly the function ScDocument::CopyToClip4VBA is largely a line by line copy of ScDocument::CopyToClip. For once I am not responsible for such a shameful practise ;-) but I attempted to fix this on master http://cgit.freedesktop.org/libreoffice/calc/commit/?id=38cae5f0a09508f48825a7049cb1508b0251fbf0 which also needs http://cgit.freedesktop.org/libreoffice/calc/commit/?id=e9abbfb34d0b57127688fc0135b463cd3ecaaf2d The result is not pretty but.. thanks, Noel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc need too much RAM to open large spreadsheets than Excel, fix?
At 6:07am -0400 Wed, 27 Jul 2011, Michael Meeks wrote: On Wed, 2011-07-27 at 16:12 +0700, Samphan Raruenrom wrote: Is there any work on LibreOffice to reduce memory usage of LibreOffice Calc on large spreadsheets? but IMHO -the- fundamental design problem with calc, is something quite banal - the concept that a spreadsheet is built from cells: without breaking that basic misconception I don't think we can do any of the really interesting space / time optimisations we need to do. Can you elaborate a little on this fundamental design flaw? As a naive and unfortunately focused elsewhere personality, I don't immediately know of a better model for creating a spreadsheet. Is it just a problem of sparsity? Or is there a much more sophisticated method for memory sharing of various similar cell attributes, perhaps analogous to CSS? Thanks, Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Manuel Reimer manuel.s...@nurfuerspam.de changed: What|Removed |Added Depends on||39560 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC 2011][svgexport] weekly report #9
On Tue, 26 Jul 2011 15:35:27 +0200, Thorsten Behrens t...@documentfoundation.org wrote: Hi Thorsten, welcome back! :) Marco wrote: skip == 2 == For each slide all animations are exported into the svg document: the exported animation elements are the same that are created by the odp format exporter. Interesting - but maybe easier to have some pre-processed subset first? Well surely I chose the hard way, but indeed after seeing how animations are exported in odp, it looks to me the more natural one. Not sure what you mean with to have some pre-processed subset could you elaborate ? == 3 == Read SMIL documentation section on transition filters. In order to understand how to implement the javascript code for performing the exported animations, I started analyzing the slideshow animation engine. Hmm - I guess re-implementing larger parts of the animation engine in JS is out of scope for this project (though of course would be cool to have) - maybe limiting ourselves to what smil is natively supported in a browser (e.g. https://developer.mozilla.org/en/svg/svg_animation_with_smil) is better? What I am aiming to do is to perform a selective port of the slideshow engine to JavaScript. I'm still analyzing the animation engine implementation though, and I have to admit that is not a smooth path. Obviously the benefits would worth the effort, making a strong base for being able to implement the shape effects more easily. For instance I have already a good idea of how to port animation node classes, but then there is the need for events and activities too. As for exploiting the smil-subset supported by the svg language, I took it into account, anyhow after performing some test I saw that support for it is lacking in Firefox 3.6.x and above all in Internet Explorer 9, and also Google Chrome have same issue. I attached a patch set based on the master branch, as it was on Monday July 7, that includes all enhancements I implemented until now. Thx a lot, will look into this - please give me a day or two, just back from vacation. ;) No problem! :) Cheers, Marco -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc need too much RAM to open large spreadsheets than Excel, fix?
Hello, I have been working a bit on performance related calc problems for 3.5. I have at least one item left for 3.5: for nearly every undo step we create a full copy of the whole document. For 3.5 I planned to improve the undo code for sheets that means that we no longer copy every sheet to an undo document which is insane. If I have a good idea i might as well have a look at the undo code for a single sheet. I hope that there is a better solution than to copy the whole content of a sheet to a new sheet. Then we have of course a little problem with columns. We create for every sheet 1024 ScColumns and ScAttrArray even if we don't need them which needs some memory. I think I did some profiling and a single sheet needs about 150kB on a 64bit computer. These are at least two problems I know, but we have for sure several other problems too. Regards, Markus 2011/7/27 Kevin Hunter hunt...@earlham.edu At 6:07am -0400 Wed, 27 Jul 2011, Michael Meeks wrote: On Wed, 2011-07-27 at 16:12 +0700, Samphan Raruenrom wrote: Is there any work on LibreOffice to reduce memory usage of LibreOffice Calc on large spreadsheets? but IMHO -the- fundamental design problem with calc, is something quite banal - the concept that a spreadsheet is built from cells: without breaking that basic misconception I don't think we can do any of the really interesting space / time optimisations we need to do. Can you elaborate a little on this fundamental design flaw? As a naive and unfortunately focused elsewhere personality, I don't immediately know of a better model for creating a spreadsheet. Is it just a problem of sparsity? Or is there a much more sophisticated method for memory sharing of various similar cell attributes, perhaps analogous to CSS? Thanks, Kevin __**_ LibreOffice mailing list LibreOffice@lists.freedesktop.**org LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/libreofficehttp://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] linking against a .a and *not* exporting those symbols ?
On Wed, 2011-07-27 at 09:18 +0100, Caolán McNamara wrote:
Or perhaps I mis-understood ;-) is it easy to inject those flags ?
Not particularly easy, but ended up doing that anyway.
Great - and I hope it works :-)
I was sort of hoping for a fire-once solution which could be wrapped
around all .a files we link against without having to go around custom
hacking various externals. Those makefile.mks are already in
impossible-to-read land :-(
Yes - horrible :-)
something like...
echo FOO {
echo local:
nm --defined-only -g *.a | grep -v ^$ | grep -v : | cut -d' ' -f 3 |
sed 's/.*/;/'
echo global:
echo *;
echo };
would probably work to generate a suitable map file, but then have to
collect up which libs are .a's on a given link execution, generate a
single map file from them, pass it to the compiler, etc. etc.
Sure - but we can't apply a map file to a .a - it is just an archive of
object files; we'd need to apply it to all those that link against it;
and of course map-files are nastily non-portable and ...
Anyway, for this specific case we currently build both shared and static
libs in openssl, but indeed only deliver and use the static ones under
unix platforms.
Ah ok; glad we don't deliver the shared one.
a) We can't disable shared libs, because then the static libs build
without -fPIC, and aren't suitable for inclusion into a final .so
b) We can't just use CFLAGS because the openssl build system doesn't use
honour it
c) We can munge the flag in through $CC however
d) We then have to *just* build with make build_libs to avoid building
the openssl demos and tools which would attempt to link against the new
useless shared libs that export no symbols
Ah - right :-) I forgot that; then again - though it's a pain - might
help accelerate shrink our make ?
Thanks so much for unwinding it all ! prolly worth adding a README in
that directory - or comment in the makefile.mk with the above contained
for the next unlucky victim that has to gnumake-ify it ;-)
Regards,
Michael.
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] DDEInitiate bug
Hi Knut, On Tue, 2011-07-26 at 23:20 +0200, Knut Olav Bøhmer wrote: Sadly I don't know. I imagine you need to avoid the splash binary - and run soffice.bin. I would be tempted to remove soffice.exe rename soffice.bin - soffice.exe and debug that way. I found it. devenv /debugexe program args Great ;-) I had to cd URE\bin\ because I got an error message about sal3.dll. Why does we have two binaries? Well - one in theory is a small binary that passes its arguments to the main 'factory' process that is running: this speeds up the 2nd launch. Unfortunately the 'small-ness' of that binary is bloated to (was it 3 or 6 Mb I forget) by all the embedded icons needed for associating that with the umpteen file-types we support [ or something ]. Oooh ! and if you can build / debug on windows :-) perhaps you could help fix the dumb-ness that we duplicate many megabytes of icons between soffice.bin and soffice.exe (?) it requires only a small set of hacks I think. Do you have more information? Those same icons are then all present in soffice.bin as well in order to get window icons correct. Instead of that we should just be loading the window icons from our images.zip [ where they also live ], and setting them on the window at run-time I think. That is what we do for the gtk+ backend, cf. GtkSalFrame::SetIcon and just needs replicating for Windows - so we can drop that duplication. gtk+ has a means of doing this for windows, so there is the API support there somewhere. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] bugfixes which break the string freeze for 3.4.3
Hi Michael, *
2011. 07. 26, kedd keltezéssel 17.06-kor Michael Meeks ezt írta:
On Tue, 2011-07-26 at 15:17 +0200, Andras Timar wrote:
I'd like to add the bugfix for
https://bugs.freedesktop.org/show_bug.cgi?id=32895
Somebody some day marked it as critical.
:-) So - I'm not a huge fan of the code. What does:
+ for( int i = 0; i nCount; ++i )
+ {
+ if( rString == ResId::toString( (const ResId)SfxResId(
(sal_uInt16)(nSourceResIds + i) ) ) )
+ {
+ return ResId::toString( (const ResId)SfxResId( (sal_uInt16)(nDestResIds +
i) ) );
+ }
+ }
do ? it looks a tad baroque to me. I also dislike seeing it cut/pasted
into impress as well.
The bug (fdo#32895), which we are talking about affects 'dlgass' (the
welcoming wizard of impress) and dialogue 'doctempl' (Impress - File -
Templates - Save).
While 'doctempl' uses the template handling module of sfx2,
unfortunately, 'dlgass' uses TemplateScanner (inside sd/source/ui/{inc,
gui}) which seems to be a re-implementation of a subset of the services
granted by the template handling module in sfx2.
So that's why I copy/pasted the mentioned code snippet.
Sorry, but I don't really get what do you mean by 'tad baroque'.
Can we get a cleaner reading patch, that re-uses that in impress ? :-)
I think the best would be to make Impress/ui stuff use the sfx2 template
handling and eliminate TemplateScanner. Would you like me to do that?
ATB,
Michael.
Best regards,
Péter
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] linking against a .a and *not* exporting those symbols.
On Wed, 2011-07-27 at 13:01 +0100, Michael Meeks wrote: On Wed, 2011-07-27 at 09:18 +0100, Caolán McNamara wrote: Or perhaps I mis-understood ;-) is it easy to inject those flags ? Not particularly easy, but ended up doing that anyway. Great - and I hope it works :-) Apparently, crash-be-gone anyway, nm -D gives me what I expect now on the final .so. I'd like to propose that fix 1022b20da6e234349b9c8d094670297a8e523c86 in libs-extern for 3-4. Sure - but we can't apply a map file to a .a - it is just an archive of object files; we'd need to apply it to all those that link against it. Yeah, it's not the .a file that gets munged if that approach was taken, but the .so into which it gets linked, i.e. the above pseudo-example would get passed to the linker when making liboox. So in the generic case the above would need to get run over all -lfoo.a's getting linked into a final (otherwise visibility controlled).so target to get a single linker-map for use with that final .so target. and of course map-files are nastily non-portable and ... Anyway, for this specific case we currently build both shared and static libs in openssl, but indeed only deliver and use the static ones under unix platforms. Ah ok; glad we don't deliver the shared one. Yeah, on the other hand this means that we link the static openssl libs to about three or so other libs which isn't awesome either. Someone with sufficient cunning would likely be able to use libnss instead for some of those openssl usages instead. d) We then have to *just* build with make build_libs to avoid building the openssl demos and tools which would attempt to link against the new useless shared libs that export no symbols Ah - right :-) I forgot that; then again - though it's a pain - might help accelerate shrink our make ? Yup, silver lining is that it's a titchy bit faster to build now. ... - or comment in the makefile.mk with the above contained for the next unlucky victim part of patch, yes. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Rainer Bielefeld libreoff...@bielefeldundbuss.de changed: What|Removed |Added Depends on|39560 | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] About merging and people not paying attention
I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. A good example is 3ad912abd7c2106c4ba6cd35e2ead954759d5cc8. Just egrep for '(|)' ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEWED] linking against a .a and *not* exporting those symbols.
On Wed, 2011-07-27 at 13:27 +0100, Caolán McNamara wrote: Apparently, crash-be-gone anyway, nm -D gives me what I expect now on the final .so. I'd like to propose that fix 1022b20da6e234349b9c8d094670297a8e523c86 in libs-extern for 3-4. Wonderful - cherry picked it to -3-4 just now. Ah ok; glad we don't deliver the shared one. Yeah, on the other hand this means that we link the static openssl libs to about three or so other libs which isn't awesome either. Someone with sufficient cunning would likely be able to use libnss instead for some of those openssl usages instead. Oh - goodness; what a bunch of lamers we are ! ;-) neon, python, ucb etc. Clearly the whole world should be using NSS. Thanks ! :-) Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEWED] linking against a .a and *not* exporting those symbols.
On Wed, 2011-07-27 at 14:21 +0100, Michael Meeks wrote: Oh - goodness; what a bunch of lamers we are ! ;-) neon, python, ucb etc. Clearly the whole world should be using NSS. *mumble*, last time I looked at this I couldn't figure out the equivalent NSS api. Since then there's http://fedoraproject.org/wiki/FedoraCryptoConsolidation which might help with some pointers to conversion and/or compatibility layer api. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Calc - a better design ...
Hi Kevin, On Wed, 2011-07-27 at 06:56 -0400, Kevin Hunter wrote: At 6:07am -0400 Wed, 27 Jul 2011, Michael Meeks wrote: but IMHO -the- fundamental design problem with calc, is something quite banal - the concept that a spreadsheet is built from cells: without breaking that basic misconception I don't think we can do any of the really interesting space / time optimisations we need to do. Can you elaborate a little on this fundamental design flaw ? Hah - so, yes - and not easily - I'd really need a whiteboard. As a naive and unfortunately focused elsewhere personality, I don't immediately know of a better model for creating a spreadsheet. So - of course, the first thing to say is that (at a first pass), I'd want the UI to continue to look the same - all that would change would be the underlying model. Is it just a problem of sparsity? Or is there a much more sophisticated method for memory sharing of various similar cell attributes, perhaps analogous to CSS? Here is the thing - since we work on a per-cell basis, all of our type checking, and formula adaptation, and storage, and dependencies etc. are all ultimately per-cell based. This (crudely) means that we have an O(n) where n is the number of cells in vast numbers of operations where we do not want it. It also tends to explode storage and computation time around dependencies - which is a substantial cost. NB. much of this is quite normal for a spreadsheet FWIW, I believe Excel is not completely dis-similar; however I think we can do better with much improved (much more complex / slow) data structure design that will ultimately be far faster to execute. Take a banal example; when we do a SUM() of a million rows containing plain doubles, we would want to (at root) have a function that [ in the ideal case ] does: double sum (double *array, sal_Int64 nItems); Which we can shove onto a gpu, multi-thread if nItems is big, etc. etc. unfortunately approaching this limit is basically impossible in calc. Instead for this case we would do a very slow, pointer-chasing iteration over a million scattered ScCell's - we would do type checking - to ensure that each one was a double, and only then would we add / accumulate them. Of course none of that can be pushed to a GPU, none of it can be SIMD accelerated, and threading it is rather hard. Now ... if we stored contiguous spans of identically typed items [ ie. a column of doubles ], as value runs in our data structures; currently we (amazingly) have arrays of (row/cell*) pairs incidentally. Then we could push a lot of branch-heavy, expensive type checking, and lots of pointer chasing outside the main-loop, we'd also use rather less memory. That's fine for doubles of course; but the really huge wins come from an entirely new model of dependencies and areas containing formulae - I propose only storing a base formula, and an iterator to describe how that formula changes down a row: to compress an entire column of formulae to a single formula. Futhermore on top of that substantially discarding the existing dependency mechanism such that a single-cell change in a contiguous range of doubles would have a shared broadcast on that whole range (with the specific detail of what cell changed), such that that could be turned into a specific row (or row range) to re-compute in any dependent by comparing the base formula, plus it's iterator with the range that changed ;-) So - in a nutshell, compressing and making explicit the vast amount of duplication and uniformity present in all big spreadsheets. IMNSHO if we can get to this world, we can kick Excel's backside in the performance and scalability arena, storage-wise we can become as tiny as we should be :-) and thus ideally we can also start to address far larger and more interesting data-sets. Anyhow - as text, this is not terribly convincing; drawing on a whiteboard would be more so, and with lots of working code - even more so ;-) I keep hoping to have time to play with ixion with Kohei in this regard. ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On 07/27/2011 02:35 PM, Robert Nagy wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. A good example is 3ad912abd7c2106c4ba6cd35e2ead954759d5cc8. Just egrep for '(|)' Hey Robert, I think this was not intended. Simple solution would be to add some ' HEAD' .* '===' .* ' master' stuff to git hooks. So git would block commits with conflicts. Thomas ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On Wed, 2011-07-27 at 14:35 +0200, Robert Nagy wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. So, I basically agree with you that we all need to be careful when merging etc. Having said that, when you have a branch with a large set of code changes to merge, sometimes your mind slips and occasionally you overlook one or two things. So, I don't want us to resort to this accusatory tone of voice when something like this happens. And I don't think any one of us want to introduce breaks intentionally, and I tend to believe that we developers do spend reasonable amount of time double-checking changes unless there is evidence to support otherwise. So, let's just take it as it is, and try to be supportive fix things instead of going on a rampage to put a blame on those who work hard to improve the code base. I'm pretty sure you mean well, but I'm just a bit concerned about your tone of voice in your email. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Kill Dtwm/CDE
So I removed this Property checks for various vendors with commit
http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?id=6b344d2654eb6a87f6e759376e7ee988f1a52761
If someone needs this back, feel free to do so (only jobset.{h,c}xx was
a mis-merge, sorry for that).
Thomas
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [Bug 35673] LibreOffice 3.4 most annoying bugs
https://bugs.freedesktop.org/show_bug.cgi?id=35673 Bug 35673 depends on bug 36631, which changed state. Bug 36631 Summary: Writer crashes when using undo-redo on formula https://bugs.freedesktop.org/show_bug.cgi?id=36631 What|Old Value |New Value Resolution||FIXED Status|NEW |RESOLVED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [REVIEW] fdo#36631 crash for undo/redo with ole/math objects in writer
Proposing for 3-4. Makes the crash in one of those most-annoying bugs go away. http://cgit.freedesktop.org/libreoffice/writer/commit/?id=c234df7779b0e43e4433e71933c22f9e703da735 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW] bugfixes which break the string freeze for 3.4.3
Hi Peter,
On Wed, 2011-07-27 at 13:21 +0200, Péter Rabi wrote:
The bug (fdo#32895), which we are talking about affects 'dlgass' (the
welcoming wizard of impress) and dialogue 'doctempl' (Impress - File -
Templates - Save).
Okay ! :-)
While 'doctempl' uses the template handling module of sfx2,
unfortunately, 'dlgass' uses TemplateScanner (inside sd/source/ui/{inc,
gui}) which seems to be a re-implementation of a subset of the services
granted by the template handling module in sfx2.
Riight - so this 're-implementation' stuff needs to be consolidated
wherever we see it: that is useful work saving us compile time,
run-time, and download size. The trick of course is to try to work out
why there are two copies ;-) and then add conditionals to the sfx2 one
to behave as expected, I suppose. Can you do that, at least in master.
So that's why I copy/pasted the mentioned code snippet.
Ah - but copy/paste is -the- pre-eminent sin of programming.
Sorry, but I don't really get what do you mean by 'tad baroque'.
Let me explain:
+ if( rString == ResId::toString( (const ResId)SfxResId(
(sal_uInt16)(nSourceResIds + i) ) ) )
+ {
+ return ResId::toString( (const ResId)SfxResId( (sal_uInt16)(nDestResIds +
i) ) );
+ }
+ }
do ? it looks a tad baroque to me.
Well - its function is not that clear to me :-) can we really not
compare rtl::OUString with String ? the casting frenzy is a bit painful
and un-necessary too, the compiler knows an SfxResId is a ResId
(surely?) ;-) too - so this:
for( int i = 0; i nCount; ++i )
{
if( rString == ResId::toString( SfxResId( nSourceResIds + i) ) )
return ResId::toString( SfxResId( nDestResIds + i ) );
}
should be just as good, and easier on the eye too ;-) It is also safer
- since adding redundant un-checked casts has a habit of coming back to
bite you later :-)
Can we get a cleaner reading patch, that re-uses that in impress ? :-)
I think the best would be to make Impress/ui stuff use the sfx2 template
handling and eliminate TemplateScanner. Would you like me to do that?
That'd be nice - of course, prolly worth cleaning up the master commit
as per above, and knocking up a cleaner / simpler patch to review vs.
3.4.x :-)
ATB,
Michael.
--
michael.me...@novell.com , Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEWED] [PUSHED 3-4] fix for fdo#37628: pssword button is always disabled
On Tue, 2011-07-26 at 14:34 -0400, Kohei Yoshida wrote: On Tue, 2011-07-26 at 18:25 +0100, Michael Meeks wrote: On Tue, 2011-07-26 at 10:37 -0400, Kohei Yoshida wrote: Just to spell out my intention more clearly, if nobody disagrees that this minor quirk will not cause any issues (after all, right now, the whole functionality is not working) within the next few days, I will push Markus' patch with my sign-off, to the 3-4 branch (for 3.4.3), with this as a known bug. IMO this is still much better than what we currently have. Sounds reasonable to me. You've done some of that heavy-testing (TM) on password protection that we know love :-) ? Anyway. I just pushed this to the 3-4 branch with my sign-off. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On Wed, Jul 27, 2011 at 7:35 AM, Robert Nagy rob...@openbsd.org wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. A good example is 3ad912abd7c2106c4ba6cd35e2ead954759d5cc8. Just egrep for '(|)' Robert, Having done massive merge with conflicting files numbering in the thousands, I would be less quick to throw a stone here. I also had to iron some kink on MacOs this week-end as a fallback of gnumake4 merge... but all in all it 'cost' me few hours for the benefit of the whole gnumake4. I'm sure glad I did not have to pass the dozen and dozen of hours it took to extract the relevant part of a cws and merge them onto a moving target been there, done that, glad someone else took the bullet this time. So sure, that sound like a 'oops' moment... but put it in context. all in all that is a pretty low rate of screw-up. Certainly from your angle that is 100% screw-up because the _one_ file that is core to your build got hosed... but you should not conclude that it is because the dev did not care, but because that was one file in a thousand he had to deal with, and that he had no environment to check against And please, please avoid stuff like : please do not touch files that you don't understand because you _will_ break things. Presuming incompetence is un-called for, and in that particular case comedic, since you are basically telling that the guy that basically designed the new build system and converted a bunch of the of dmake to gbuild do not 'understand' the build system... gee, we are in trouble indeed :-) maybe an active tinderbox would help other realized they broke your platform, and maybe fix things they accidentally broke before you ran into them ? Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On Wed, 27 Jul 2011 14:35:23 +0200 Robert Nagy rob...@openbsd.org wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. Which part of these quotes: Brace for impact - gnumake4 to hit master As this changes a lot of low-level build system stuff, there will be quite few temporary instabilities and problems (esp. on non-Linux platforms) after the merge. If nobody protests, I will merge the branch to master on Sunday afternoon, so that I wont break the master for volunteers on the weekend, and so that we have good tinderbox result on Monday. http://nabble.documentfoundation.org/Brace-for-impact-gnumake4-to-hit-master-td3192816.html was hard to understand? As there is no tinderbox for BSD, you could have at least tried to test build the feature branch. From the warning email until integration, you had two days for that. If you would have needed another one, you would have got it. However, nothing wrt that was heard from you. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog
Hi Kendy, On Wed, 2011-07-27 at 00:51 +0200, Jan Holesovsky wrote: With the patch I am proposing for cherry-picking to 3.4 (I have pushed that to master), the options are unset when you use the FindBar, ie. it resets whatever flags the user has set in the Search Replace dialog too. This is not easy to fix, so I wonder if you consider this stop-gap solution bearable for the users? So, this is a tough call, but I'm *personally* not in favor of putting this to 3.4 because, to me, this would only replace one quirk - re-using the options from the find replace dialog when doing the find bar search, with another one - resetting the options when the user does find bar search, which would also reset the options in the find replace dialog. Also, after testing this on master, the similarity search option doesn't get reset even after the find bar usage while all the other options do get reset. So, the changed behavior feels a bit more weird than the old one (to me). I would much rather we keep the current behavior over the new one for 3.4, while trying to fix this the right way on master. BTW, we do have similar issues with the CSV import options dialog, which we happen to re-use for Data - Text to Columns. Over there, we (somehow) manage to retain the options set in the CSV import while using a pre-defined set of options for the Text to columns operation, without having them interfere with each other. Perhaps we could do something similar with the find bar / find replace dialog code while fixing on master. Having said all this, I'm just one developer, and this is just my personal opinion. And I would be interested to hear from other folks as well. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc need too much RAM to open large spreadsheets than Excel, fix?
Hi Samphan, On Wed, 2011-07-27 at 16:12 +0700, Samphan Raruenrom wrote: Last year I've done a comparison of memory usage on Windows between OpenOffice.org Calc 3.1 and MS Excel 2003/2007 for spreadsheets with simple formula of various size. I found that Calc take a lot more memory than Excel 2003/2007 when loading large spreadsheets. So, this would very much depend on the characteristics of the document you used to run the benchmark. Otherwise it'd be hard for us to do anything useful. If you don't mind, could you file a bug in bugzilla, with the information you gave here, as well as the actual document you used to produce the data as an attachment? I don't think this is something we can quickly address in one or two release cycles, but it would be nice to have a reference document handy to see whether we are making progress in performance or going backward. Thanks a lot! Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [DON'T PUSH] Re: [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog
Hi Astron, Kohei, On 2011-07-27 at 12:10 -0400, Kohei Yoshida wrote: Having said all this, I'm just one developer, and this is just my personal opinion. And I would be interested to hear from other folks as well. We have already 2 vetos (and I was warning about the controversy of this too), so let's not cherry-pick this one to 3.4 :-) Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [PUSHED 3.4] Re: [REVIEW] fdo#36631 crash for undo/redo with ole/math objects in writer
Hi Caolán, On 2011-07-27 at 15:11 +0100, Caolán McNamara wrote: Proposing for 3-4. Makes the crash in one of those most-annoying bugs go away. http://cgit.freedesktop.org/libreoffice/writer/commit/?id=c234df7779b0e43e4433e71933c22f9e703da735 Thank you very much for that one - everything seems to work, crash is gone. Pushed to 3.4. Regards, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [REVIEW 3.4] FindBar silently reuses options from the Search Replace dialog
Hi Kendy, Jan Holesovsky wrote (27-07-11 00:51) With the patch I am proposing for cherry-picking to 3.4 (I have pushed that to master), the options are unset when you use the FindBar, ie. it Fine for me as temporary solution! The annoyance of not understanding what happens with the Find bar is larger then the problem of having to set options again .. Plus, what IMO is more important ... resets whatever flags the user has set in the Search Replace dialog too. This is not easy to fix, so I wonder if you consider this stop-gap solution bearable for the users? ... is the older discussion from ux@ooo (1) and an/more issue (2), about the unexpected, invisible reuse of options previous set in the FR dialog and some inconsistencies/debatable choices made in the implementation. Would be useful I guess to at least consider those too, before touching the code for a real solution. Regards, Cor 1) http://openoffice.org/projects/ux/lists/discuss/archive/2009-10/message/8 2) http://openoffice.org/bugzilla/show_bug.cgi?id=88714 and -- - Cor - http://nl.libreoffice.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Import of xrefs to numbered paragraphs from docx
On Fri, 2011-07-22 at 23:59 +1000, Troy Rollo wrote: This replaces the earlier version of this patch, which was wrong for the NUMBER_FULL_CONTEXT cross-reference type. I believe this is Cedric's area, but he is on vacation at the moment. I'm also CC'ing Lubos as well since I've seen him make changes in this area just recently. ;-) I think either Lubos or Cedric (when he is back) will be able to review your patch. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix field values in export to docx
On Sat, 2011-07-23 at 00:18 +1000, Troy Rollo wrote: Prior to this patch, fields were being exported to docx file with the field value being the name of the field. This patch changes it to export the field value as the field value. Ditto with this one. I'll CC Cedric and Lubos for review. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix parent level count in numbering from docx
On Sat, 2011-07-23 at 01:24 +1000, Troy Rollo wrote: Before this patch, when importing from docx, if there were no parent numbering levels in the number formats for outline numbered paragraphs, the import would include all parent levels back to the second numbering level, in the third and subsequent numbering levels. This one also put in queue for Cedric and Lubos. Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Fix fdo#36868 - doc import list numbering error
On Sun, 2011-07-24 at 00:03 +1000, Troy Rollo wrote: This patch appears to be fix fdo#36868. The problem is that the paragraph style was never being assigned an outline list level. The saved file did not have an sprmPOutLvl for that paragraph (although it did have one for the level 0 style), just an sprmPIlvl and an sprmPIlfo. Therefore there was no call to SwWW8ImplReader::Read_POutLvl to set nOutlineLevel. And this one too (in queue for Cedric and Lubos for review). -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [PATCH] Import of xrefs to numbered paragraphs from docx
On Thu, 2011-07-21 at 23:27 +1000, Troy Rollo wrote: The first part of this patch adds importing of cross-references to numbered paragraphs from docx file. I believe this one has been replaced by your other patch submitted on Friday, July 22nd. No need to follow up on this. Kohei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] Inconsistencies in GoDownSel and GoUpSel (cell selection in Calc)
Hi Investigating sc/sdi/cellsh.sdi I see the following code for the commands GoDown, GoDownSel, GoUp, GoUpSel (+ left and right movement and selection) //cursor down SfxVoidItem GoDown SID_CURSORDOWN ( SfxInt16Item By FN_PARAM_1, SfxBoolItem Sel FN_PARAM_2 ) [ ExecMethod = ExecuteCursor ; StateMethod = GetStateCursor ; Cachable ; ] SfxVoidItem GoDownSel SID_CURSORDOWN_SEL ( SfxInt16Item By FN_PARAM_1 ) [ Export = FALSE ; ExecMethod = ExecuteCursorSel ; StateMethod = GetStateCursor ; Cachable ; ] // cursor up SfxVoidItem GoUp SID_CURSORUP ( SfxInt16Item By FN_PARAM_1, SfxBoolItem Sel FN_PARAM_2 ) [ ExecMethod = ExecuteCursor ; StateMethod = GetStateCursor ; Cachable ; ] SID_CURSORUP_SEL[ ExecMethod = ExecuteCursorSel; StateMethod = GetStateCursor; ] So it looks like GoDownSel has an argument By, which seems to be select FN_PARAM_1 cells down, but GoUpSel (GoRightSel and GoLeftSel) does not have this parameter. Which one is the correct? Thanks -- Olivier Hallot Founder and Steering Commitee Member The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On (2011-07-27 10:03), Kohei Yoshida wrote: On Wed, 2011-07-27 at 14:35 +0200, Robert Nagy wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. So, I basically agree with you that we all need to be careful when merging etc. Having said that, when you have a branch with a large set of code changes to merge, sometimes your mind slips and occasionally you overlook one or two things. So, I don't want us to resort to this accusatory tone of voice when something like this happens. And I don't think any one of us want to introduce breaks intentionally, and I tend to believe that we developers do spend reasonable amount of time double-checking changes unless there is evidence to support otherwise. So, let's just take it as it is, and try to be supportive fix things instead of going on a rampage to put a blame on those who work hard to improve the code base. I'm pretty sure you mean well, but I'm just a bit concerned about your tone of voice in your email. I did not say that it was intentional but I am so used to people testing only one platform because they just don't give a damn about the others. If a patch/merge touches all of the platform files then it should be sent to the developers responsible for that part of the tree directly, instead of sending it to the development mailing list which has too many traffic to actually follow (for me at least). ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST] GDB doesn't show name of methods in backtrace
On 07/22/2011 06:51 PM, Andor E wrote:
Hi,
did you build module sw with debug=t? Otherwise you won't get any
method names and line numbers.
Greetings
eymux
On Fri, Jul 22, 2011 at 12:57 PM, Ta Duc Tungtatung2...@gmail.com wrote:
Hi,
I've tried to add a radio button into print dialog for Writer.
In /sw/source/core/view/printdata.cxx, I have this piece of code (around
line 310)
http://pastebin.com/gMu70wYm
~~~
aChoices[3] = aLocalizedStrings.GetString( 30 );
aChoicesDisabled[3] = sal_False;
aHelpIds[3] = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
.HelpID:vcl:PrintDialog:PrintContent:RadioButton:3 ) );
m_aUIProperties[nIdx++].Value = getChoiceControlOpt( rtl::OUString(),
aHelpIds,
aPrintRangeName,
aChoices,
0 /* always default
to 'All pages' */,
rtl::OUString(
RTL_CONSTASCII_USTRINGPARAM( Radio ) ),
aChoicesDisabled
);
After that I add an item to PRINTOPTUI in /sw/source/ui/config/optdlg.src
-- the Current Page
http://pastebin.com/nrNBz7A6
~~
StringArray STR_PRINTOPTUI
{
ItemList [en-US] =
{
..
~All pages;;
Pa~ges;;
~Selection;;
Cu~rrent page;;
};
};
~
When I try to run it, the radio button does appear but when I click on that
radio button (Current page), Writer just stop and dismiss.
I've tried to debug it by gdb and this is the message.
http://pastebin.com/i4QpmjDS
Program received signal SIGSEGV, Segmentation fault.
0x0013391a in rtl_uString_acquire ()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
~
I put breakpoint in SwXTextDocument::getRendererCount() (#5 in gdb log from
pastebin link above). The program does stop at that breakpoint, but when I
want to step in, it just pass through it :( Like this:
Breakpoint 1, 0x04384774 in
SwXTextDocument::getRendererCount(com::sun::star::uno::Any const,
com::sun::star::uno::Sequencecom::sun::star::beans::PropertyValue const)
()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/program/libswlo.so
(gdb) step
Single stepping until exit from function
_ZN15SwXTextDocument16getRendererCountERKN3com3sun4star3uno3AnyERKNS3_8SequenceINS2_5beans13PropertyValueEEE,
which has no line number information.
In unotxdoc.cxx/getRendererCount, after check IsValid()
In unotxdoc.cxx/getRendererCount 1
[New Thread 0xb1620b70 (LWP 14464)]
[Thread 0xb1620b70 (LWP 14464) exited]
[New Thread 0xb223fb70 (LWP 14465)]
In unotxdoc.cxx/getRendererCount 2
In unotxdoc.cxx/getRendererCount 3
In unotxdoc.cxx/getRendererCount 4
In unotxdoc.cxx/getRendererCount/check pSwView 1
[New Thread 0xb1620b70 (LWP 14466)]
[Thread 0xb223fb70 (LWP 14465) exited]
In unotxdoc.cxx/getRendererCount/check pSwView 2
In unotxdoc.cxx/getRendererCount/check pSwView 3
Program received signal SIGSEGV, Segmentation fault.
0x0013391a in rtl_uString_acquire ()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
(gdb)
~
Did I miss any thing? Please help :)
Thanks for your help!
Ta Tung
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Hi,
I've tried to make with debug=t but no change. GDB log still the same :(
Any one please help!
Thanks,
Ta Tung
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On (2011-07-27 10:50), Norbert Thiebaud wrote: Having done massive merge with conflicting files numbering in the thousands, I would be less quick to throw a stone here. I also had to iron some kink on MacOs this week-end as a fallback of gnumake4 merge... but all in all it 'cost' me few hours for the benefit of the whole gnumake4. I'm sure glad I did not have to pass the dozen and dozen of hours it took to extract the relevant part of a cws and merge them onto a moving target been there, done that, glad someone else took the bullet this time. So sure, that sound like a 'oops' moment... but put it in context. all in all that is a pretty low rate of screw-up. Certainly from your angle that is 100% screw-up because the _one_ file that is core to your build got hosed... but you should not conclude that it is because the dev did not care, but because that was one file in a thousand he had to deal with, and that he had no environment to check against And please, please avoid stuff like : please do not touch files that you don't understand because you _will_ break things. Presuming incompetence is un-called for, and in that particular case comedic, since you are basically telling that the guy that basically designed the new build system and converted a bunch of the of dmake to gbuild do not 'understand' the build system... gee, we are in trouble indeed :-) maybe an active tinderbox would help other realized they broke your platform, and maybe fix things they accidentally broke before you ran into them ? Norbert Merge branch 'master' into feature/gnumake4 Conflicts: Repository.mk RepositoryFixes.mk configure configure.in set_soenv.in solenv/config/sdev300.ini solenv/gbuild/ComponentTarget.mk solenv/gbuild/CppunitTest.mk solenv/gbuild/CustomTarget.mk solenv/gbuild/Deliver.mk solenv/gbuild/Executable.mk solenv/gbuild/JavaClassSet.mk solenv/gbuild/Library.mk solenv/gbuild/LinkTarget.mk solenv/gbuild/StaticLibrary.mk solenv/gbuild/TargetLocations.mk solenv/gbuild/gbuild.mk solenv/gbuild/platform/linux.mk solenv/gbuild/platform/macosx.mk solenv/gbuild/platform/solaris.mk solenv/gbuild/platform/windows.mk solenv/gbuild/platform/winmingw.mk solenv/gbuild/templates/Executable.mk solenv/gbuild/templates/Library.mk solenv/inc/libs.mk solenv/inc/unxobsd.mk That ain't a 1000 files. Oh look there is something I can't test, who cares, let's push it. Anyways I don't think that anyone is incompetent, I am just asking everyone to be more careful. Of course this was my fault too because I was on vacation so I could not test in time, so let's just put this behind and continue the work (more carefully :) ). ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On (2011-07-27 15:53), Thomas Arnhold wrote: On 07/27/2011 02:35 PM, Robert Nagy wrote: I would like to ask my fellow developers to be more careful about merging and _touching_ files at all that they don't understand. During the last two days I had to fix several problems that were introduced by merging changes, hell I even found files with _conflicts_ in them and the guy who pushed it did not even bother to have a look. This is painful and tiring, so whenever you merge, please double check before pushing and please do not touch files that you don't understand because you _will_ break things. A good example is 3ad912abd7c2106c4ba6cd35e2ead954759d5cc8. Just egrep for '(|)' Hey Robert, I think this was not intended. Simple solution would be to add some ' HEAD' .* '===' .* ' master' stuff to git hooks. So git would block commits with conflicts. That would help the developers for sure. It would make it easier to spot errors. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [MHST] GDB doesn't show name of methods in backtrace
On 07/22/2011 06:51 PM, Andor E wrote:
Hi,
did you build module sw with debug=t? Otherwise you won't get any
method names and line numbers.
Greetings
eymux
On Fri, Jul 22, 2011 at 12:57 PM, Ta Duc Tungtatung2...@gmail.com wrote:
Hi,
I've tried to add a radio button into print dialog for Writer.
In /sw/source/core/view/printdata.cxx, I have this piece of code (around
line 310)
http://pastebin.com/gMu70wYm
~~~
aChoices[3] = aLocalizedStrings.GetString( 30 );
aChoicesDisabled[3] = sal_False;
aHelpIds[3] = rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(
.HelpID:vcl:PrintDialog:PrintContent:RadioButton:3 ) );
m_aUIProperties[nIdx++].Value = getChoiceControlOpt( rtl::OUString(),
aHelpIds,
aPrintRangeName,
aChoices,
0 /* always default
to 'All pages' */,
rtl::OUString(
RTL_CONSTASCII_USTRINGPARAM( Radio ) ),
aChoicesDisabled
);
After that I add an item to PRINTOPTUI in /sw/source/ui/config/optdlg.src
-- the Current Page
http://pastebin.com/nrNBz7A6
~~
StringArray STR_PRINTOPTUI
{
ItemList [en-US] =
{
..
~All pages;;
Pa~ges;;
~Selection;;
Cu~rrent page;;
};
};
~
When I try to run it, the radio button does appear but when I click on that
radio button (Current page), Writer just stop and dismiss.
I've tried to debug it by gdb and this is the message.
http://pastebin.com/i4QpmjDS
Program received signal SIGSEGV, Segmentation fault.
0x0013391a in rtl_uString_acquire ()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
~
I put breakpoint in SwXTextDocument::getRendererCount() (#5 in gdb log from
pastebin link above). The program does stop at that breakpoint, but when I
want to step in, it just pass through it :( Like this:
Breakpoint 1, 0x04384774 in
SwXTextDocument::getRendererCount(com::sun::star::uno::Any const,
com::sun::star::uno::Sequencecom::sun::star::beans::PropertyValue const)
()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/program/libswlo.so
(gdb) step
Single stepping until exit from function
_ZN15SwXTextDocument16getRendererCountERKN3com3sun4star3uno3AnyERKNS3_8SequenceINS2_5beans13PropertyValueEEE,
which has no line number information.
In unotxdoc.cxx/getRendererCount, after check IsValid()
In unotxdoc.cxx/getRendererCount 1
[New Thread 0xb1620b70 (LWP 14464)]
[Thread 0xb1620b70 (LWP 14464) exited]
[New Thread 0xb223fb70 (LWP 14465)]
In unotxdoc.cxx/getRendererCount 2
In unotxdoc.cxx/getRendererCount 3
In unotxdoc.cxx/getRendererCount 4
In unotxdoc.cxx/getRendererCount/check pSwView 1
[New Thread 0xb1620b70 (LWP 14466)]
[Thread 0xb223fb70 (LWP 14465) exited]
In unotxdoc.cxx/getRendererCount/check pSwView 2
In unotxdoc.cxx/getRendererCount/check pSwView 3
Program received signal SIGSEGV, Segmentation fault.
0x0013391a in rtl_uString_acquire ()
from
/home/tatung/mhstlibo/git/libo/solver/350/unxlngi6.pro/installation/opt/program/../basis-link/ure-link/lib/libuno_sal.so.3
(gdb)
~
Did I miss any thing? Please help :)
Thanks for your help!
Ta Tung
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Hi,
After some manual tracings, I see that the Segmentation fault happen in
http://opengrok.libreoffice.org/xref/writer/sw/inc/viewsh.hxx#423
~~~
inline const SwViewOption *GetViewOptions() const { return pOpt; }
~~~
I don't know how to fix this. Any hint, please?
After adding new radio button to print dialog as above, do I have to
modify somewhere to get it work?
Thanks,
Ta Tung
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [review for 3.4] fix for bnc#707486
Hi Noel, On Wed, 2011-07-27 at 11:50 +0100, Noel Power wrote: I would really like to get this patch into 3.4, the patch affects vba related calls only and imo safe. Basically the patch allows copy to work for appropriate multi-area ranges. The core calc function 'CopyToClip' variant that is modified is used *only* by vba api implementation code so shouldn't affect ordinary calc operations at all. Hmm... did you forget to attach your patch by any chance? I tried to cherry-pick the commits you referenced from master, but they don't apply cleanly... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc kyosh...@novell.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On Wed, 27 Jul 2011 20:06:06 +0200 Robert Nagy rob...@openbsd.org wrote: If a patch/merge touches all of the platform files then it should be sent to the developers responsible for that part of the tree directly, Completely unworkable for a cws that was open (not integrated) at OOo, needed huge rework (endless rebases) to make into a linear patch queue, had to migrated over to git and be merged again with master (50KLOC change in over 200 dirs and over 100 changesets IIRC). We also discussed testbuilding the feature branch on the ESC (I proposed that), but that was turned down as it would have bound quite some resources. instead of sending it to the development mailing list which has too many traffic to actually follow (for me at least). You are free to do so, but if you do, please dont expect complaining to exactly _that_ _list_ where the big, fat warning was posted two days before the merge will win you flowers. ;) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On (2011-07-27 20:31), Bjoern Michaelsen wrote: On Wed, 27 Jul 2011 20:06:06 +0200 Robert Nagy rob...@openbsd.org wrote: If a patch/merge touches all of the platform files then it should be sent to the developers responsible for that part of the tree directly, Completely unworkable for a cws that was open (not integrated) at OOo, needed huge rework (endless rebases) to make into a linear patch queue, had to migrated over to git and be merged again with master (50KLOC change in over 200 dirs and over 100 changesets IIRC). We also discussed testbuilding the feature branch on the ESC (I proposed that), but that was turned down as it would have bound quite some resources. instead of sending it to the development mailing list which has too many traffic to actually follow (for me at least). You are free to do so, but if you do, please dont expect complaining to exactly _that_ _list_ where the big, fat warning was posted two days before the merge will win you flowers. ;) I aggree, I will bitch in private next time :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSoC 2011][svgexport] weekly report #9
Marco wrote: For each slide all animations are exported into the svg document: the exported animation elements are the same that are created by the odp format exporter. Interesting - but maybe easier to have some pre-processed subset first? Well surely I chose the hard way, but indeed after seeing how animations are exported in odp, it looks to me the more natural one. Not sure what you mean with to have some pre-processed subset could you elaborate ? Hi Marco, as outlined below - hard-code a fixed set of effects. What I am aiming to do is to perform a selective port of the slideshow engine to JavaScript. I'm still analyzing the animation engine implementation though, and I have to admit that is not a smooth path. Obviously the benefits would worth the effort, making a strong base for being able to implement the shape effects more easily. For instance I have already a good idea of how to port animation node classes, but then there is the need for events and activities too. As for exploiting the smil-subset supported by the svg language, I took it into account, anyhow after performing some test I saw that support for it is lacking in Firefox 3.6.x and above all in Internet Explorer 9, and also Google Chrome have same issue. I'd strongly advise against trying to reimplement the animation engine just yet. It's a large surface to cover - better have a handful of animations hardcoded, that work next week - if there's time later on, as I said, would be happy to see it. ;) Cheers, -- Thorsten pgpgMulTiF1WT.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [LibreOffice][EasyHack] Hybrid PDF improvement 1 and 2
Hello, Could you tell me if the first easyHack mentioned in the subject is still alive? Because for me it seems to be already resolved in version 3.5(However in 3.4 it can be seen). And as for the second hack, could someone tell me if it is alive? And where can I find the source code that does PDF export? If the second one is alive I would try to resolve it. Gabor Jenei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [EasyHack] Hybrid PDF improvement 1 and 2
Hello, Could you tell me if the first easyHack mentioned in the subject is still alive? Because for me it seems to be already resolved in version 3.5(However in 3.4 it can be seen). And as for the second hack, could someone tell me if it is alive? And where can I find the source code that does PDF export? If the second one is alive I would try to resolve it. Gabor Jenei ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
On Wed, 27 Jul 2011 20:10:21 +0200 Robert Nagy rob...@openbsd.org wrote: That ain't a 1000 files. And bootstrap is not the only repo. -- https://launchpad.net/~bjoern-michaelsen ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [review for 3.4] fix for bnc#707486
Hi Kohei,
On 27/07/11 19:23, Kohei Yoshida wrote:
Hi Noel,
On Wed, 2011-07-27 at 11:50 +0100, Noel Power wrote:
I would really like to get this patch into 3.4,
[...]
Hmm... did you forget to attach your patch by any chance?
yes, ouch I did forget :-) ( although it is attached to the bug )
I tried to
cherry-pick the commits you referenced from master, but they don't apply
cleanly...
well, I didn't want the master fix going into 3.4 ( slightly nervous as
it affects the core CopyToClip )
Noel
diff --git sc/source/ui/inc/viewfunc.hxx sc/source/ui/inc/viewfunc.hxx
index deca468..5c54d76 100644
--- sc/source/ui/inc/viewfunc.hxx
+++ sc/source/ui/inc/viewfunc.hxx
@@ -108,7 +108,7 @@ public:
SC_DLLPUBLIC void CutToClip( ScDocument* pClipDoc = NULL, sal_Bool bIncludeObjects = false );
SC_DLLPUBLIC sal_Bool CopyToClip( ScDocument* pClipDoc = NULL, sal_Bool bCut = false, sal_Bool bApi = false,
sal_Bool bIncludeObjects = false, sal_Bool bStopEdit = true );
-SC_DLLPUBLIC sal_Bool CopyToClip( ScDocument* pClipDoc, const ScRange rRange, sal_Bool bCut = false,
+SC_DLLPUBLIC sal_Bool CopyToClip( ScDocument* pClipDoc, const ScRangeList rRange, sal_Bool bCut = false,
sal_Bool bApi = false, sal_Bool bIncludeObjects = false, sal_Bool bStopEdit = true );
ScTransferObj* CopyToTransferable();
SC_DLLPUBLIC sal_Bool PasteFromClip( sal_uInt16 nFlags, ScDocument* pClipDoc,
diff --git sc/source/ui/vba/excelvbahelper.cxx sc/source/ui/vba/excelvbahelper.cxx
index cbf30eb..cc2a768 100644
--- sc/source/ui/vba/excelvbahelper.cxx
+++ sc/source/ui/vba/excelvbahelper.cxx
@@ -286,13 +286,22 @@ void implnPasteSpecial( const uno::Reference frame::XModel xModel, sal_uInt16
}
-void implnCopyRange( const uno::Reference frame::XModel xModel, const ScRange rRange )
+bool implnCopyRanges( const uno::Reference frame::XModel xModel, ScRangeList rRangeList )
{
+bool bResult = false;
ScTabViewShell* pViewShell = getBestViewShell( xModel );
if ( pViewShell )
{
-pViewShell-CopyToClip( NULL, rRange, false, true, true );
+bResult = pViewShell-CopyToClip( NULL, rRangeList, false, true, true );
}
+return bResult;
+}
+
+bool implnCopyRange( const uno::Reference frame::XModel xModel, const ScRange rRange )
+{
+ScRangeList aRanges;
+aRanges.Append( rRange );
+return implnCopyRanges( xModel, aRanges );
}
ScDocShell*
diff --git sc/source/ui/vba/excelvbahelper.hxx sc/source/ui/vba/excelvbahelper.hxx
index eebeaff..a5ceb81 100644
--- sc/source/ui/vba/excelvbahelper.hxx
+++ sc/source/ui/vba/excelvbahelper.hxx
@@ -55,7 +55,8 @@ void implnCopy( const css::uno::Reference css::frame::XModel xModel );
void implnPaste ( const css::uno::Reference css::frame::XModel xModel );
void implnCut( const css::uno::Reference css::frame::XModel xModel );
void implnPasteSpecial( const css::uno::Reference css::frame::XModel xModel, sal_uInt16 nFlags,sal_uInt16 nFunction,sal_Bool bSkipEmpty, sal_Bool bTranspose);
-void implnCopyRange( const css::uno::Reference css::frame::XModel xModel, const ScRange rRange );
+bool implnCopyRanges( const css::uno::Reference css::frame::XModel xModel, ScRangeList rRange );
+bool implnCopyRange( const css::uno::Reference css::frame::XModel xModel, const ScRange rRange );
ScTabViewShell* getBestViewShell( const css::uno::Reference css::frame::XModel xModel ) ;
ScDocShell* getDocShell( const css::uno::Reference css::frame::XModel xModel ) ;
ScTabViewShell* getCurrentBestViewShell( const css::uno::Reference css::uno::XComponentContext xContext );
diff --git sc/source/ui/vba/vbarange.cxx sc/source/ui/vba/vbarange.cxx
index 1689b13..09a4e5c 100644
--- sc/source/ui/vba/vbarange.cxx
+++ sc/source/ui/vba/vbarange.cxx
@@ -2597,8 +2597,6 @@ ScVbaRange::getMergeCells() throw (script::BasicErrorException, uno::RuntimeExce
void
ScVbaRange::Copy(const ::uno::Any Destination) throw (uno::RuntimeException)
{
-if ( m_Areas-getCount() 1 )
-throw uno::RuntimeException( rtl::OUString( RTL_CONSTASCII_USTRINGPARAM(That command cannot be used on multiple selections ) ), uno::Reference uno::XInterface () );
if ( Destination.hasValue() )
{
uno::Reference excel::XRange xRange( Destination, uno::UNO_QUERY_THROW );
@@ -2616,11 +2614,22 @@ ScVbaRange::Copy(const ::uno::Any Destination) throw (uno::RuntimeException)
}
else
{
-ScRange aRange;
-RangeHelper thisRange( mxRange );
-ScUnoConversion::FillScRange( aRange, thisRange.getCellRangeAddressable()-getRangeAddress() );
-uno::Reference frame::XModel xModel = excel::GetModelFromRange( mxRange );
-excel::implnCopyRange( xModel, aRange );
+if ( m_Areas-getCount() 1 )
+{
+uno::Reference frame::XModel xModel = excel::GetModelFromRange( mxRanges );
+ScCellRangesBase* pUnoRangesBase = getCellRangesBase();
+
Re: [Libreoffice] About merging and people not paying attention
If a patch/merge touches all of the platform files then it should be sent to the developers responsible for that part of the tree directly, I didn't know we had responsibility for the tree split up to specific developers? Everybody else encounters problems now and then caused by others. Get used to it. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] About merging and people not paying attention
I am talking about things that were fixed once and then overwritten by a merge. I mean it conflicts for a reason! On (2011-07-27 13:32), Tor Lillqvist wrote: If a patch/merge touches all of the platform files then it should be sent to the developers responsible for that part of the tree directly, I didn't know we had responsibility for the tree split up to specific developers? Everybody else encounters problems now and then caused by others. Get used to it. --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
[Libreoffice] building with mac osx lion and 10.7 SDK and 10.4 SDK
I have successfully run autogen.sh with 10.7 sdk. Now when i run make i get the error below, I am not sure if this is an error caused by the integration of gnumake4 into master, or the use of 10.7 SDK Jonathan-Aquilinas-MacBook-Pro:bootstrap eagles051387$ make Fetching dependencies for module berkeleydb from solver... failed ERROR: incomplete dependencies! make: *** [all] Error 1 Also i stumbled upon this by total accident. Those of you that are worried about 10.4 SDK after upgrading to latest xcode, it seems to move the old xcode and developer tools to a new directory from developer to developer-old. is there a patch that I could submit that will allow those users who have upgraded to the latest xcode, yet still allow users and developers to use the 10.4 SDK. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Inconsistencies in GoDownSel and GoUpSel (cell selection in Calc)
Hi Olivier, On Wednesday, 2011-07-27 14:50:33 -0300, Olivier Hallot wrote: Investigating sc/sdi/cellsh.sdi [...] So it looks like GoDownSel has an argument By, which seems to be select FN_PARAM_1 cells down, but GoUpSel (GoRightSel and GoLeftSel) does not have this parameter. Which one is the correct? Tricky.. both ;-) The slot parameters of the first definition of an ExecMethod are inherited by following definitions with the same ExecMethod. So actually SID_CURSORUP_SEL inherits By from the first definition of ExecuteCursorSel that happens to be SID_CURSORDOWN_SEL. Compare with the generated sc/$INPATH/inc/scslots.hxx Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpQ8fZ4LFjSw.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [ANN] LibreOffice 3.4.2 RC3 available
Dear Community, The Document Foundation is happy to announce the third release candidate of LibreOffice 3.4.2. The upcoming 3.4.2 will be the second in a series of frequent bugfix releases for our 3.4 code line. Please be aware that LibreOffice 3.4.2 RC3 is not yet ready for production use, you should continue to use LibreOffice 3.3.3 or 3.4.1 for that. The release is available for Windows, Linux and Mac OS X from our QA builds download page at http://www.libreoffice.org/download/pre-releases/ Should you find bugs, please report them to the FreeDesktop Bugzilla: https://bugs.freedesktop.org For other ways to get involved with this exciting project - you can e.g. contribute code: https://www.libreoffice.org/get-involved/developers/ translate LibreOffice to your language: http://wiki.documentfoundation.org/Translation_for_3.4 or help with funding our foundation: http://challenge.documentfoundation.org/ A list of known issues with 3.4.2 RC3 is available from our wiki: http://wiki.documentfoundation.org/Releases/3.4.2/RC3 Please find the list of changes against LibreOffice 3.4.2 RC2 here: http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-4-2-release-3.4.2.3.log Let us close again with a BIG Thank You! to all of you having contributed to the LibreOffice project - this release would not have been possible without your help. Yours, The Steering Committee of The Document Foundation pgpiiTnGKpe6S.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Inconsistencies in GoDownSel and GoUpSel (cell selection in Calc)
Thans Eike for the enlighment. I am not skilled in C++ (thanks for your patience), but scslots.hxx looks different for GoUpSel and GoDownSel, if that matters, around the line that starts with 73/*Offset*/ and 74/*Offset*/ // Slot Nr. 145 : 26521 SFX_NEW_SLOT_ARG( ScCellShell,SID_CURSORDOWN_SEL,SID_CURSORDOWN_SEL,GID_NAVIGATOR, 0 ,aScCellShellSlots_Impl[146] /*Offset Next*/, SFX_STUB_PTR(ScCellShell,ExecuteCursorSel),SFX_STUB_PTR(ScCellShell,GetStateCursor), SFX_SLOT_CACHABLE|SFX_SLOT_SYNCHRON|SFX_SLOT_RECORDPERSET|SFX_SLOT_ACCELCONFIG|SFX_SLOT_READONLYDOC|0, 0, SfxVoidItem, 73/*Offset*/, 1/*Count*/, 0, SFX_SLOT_METHOD|0,GoDownSel ), // Slot Nr. 146 : 26522 SFX_NEW_SLOT_ARG( ScCellShell,SID_CURSORUP_SEL,SID_CURSORUP_SEL,GID_NAVIGATOR, 0 ,aScCellShellSlots_Impl[147] /*Offset Next*/, SFX_STUB_PTR(ScCellShell,ExecuteCursorSel),SFX_STUB_PTR(ScCellShell,GetStateCursor), SFX_SLOT_CACHABLE|SFX_SLOT_SYNCHRON|SFX_SLOT_RECORDPERSET|SFX_SLOT_ACCELCONFIG|SFX_SLOT_READONLYDOC|0, 0, SfxVoidItem, 74/*Offset*/, 1/*Count*/,.GoUpSel,SFX_SLOT_METHOD|0,GoUpSel ), Anyway, the whole thing is that GoDownSel (/UpSel/LeftSel/RightSel) has thus a property value FN_PARAM_1 which represent a repetition of the command named (By), I guess.. 1) So the following code rem -- dim args1(1) as new com.sun.star.beans.PropertyValue args1(0).Name = By args1(0).Value = 10 args1(1).Name = Sel args1(1).Value = True dispatcher.executeDispatch(document, .uno:GoDown, , 0, args1()) should select 10 lines downward, no? But it don't as far as I can see. It moves 10 lines and select one more, the 11th. I think the issue is in sc/source/ui/view/cellsh4.cxx, where the repetition nRepeat if( IS_AVAILABLE( FN_PARAM_1, pItem ) ) nRepeat = static_castSCsCOLROW(((const SfxInt16Item*)pItem)-GetValue()); is not used as loop or passed properly when bSel is true, just below... 2) And the code rem -- dim args2(0) as new com.sun.star.beans.PropertyValue args2(0).Name = By args2(0).Value = 10 dispatcher.executeDispatch(document, .uno:GoDownSel, , 0, args2()) does not select more than 2 cells, probably because the loop nRepeat is missing, it is not taken from rReq in method void ScCellShell::ExecuteCursorSel( SfxRequest rReq ) and besides, the recent fix of bug https://bugs.freedesktop.org/show_bug.cgi?id=38955 fixes the recording but does not return the By property, as it may miss a line like rReq.AppendItem( SfxInt16Item(FN_PARAM_1, static_castsal_Int16(nRepeat)) ); thus the recorded macro does not show the By property Again sorry for bothering, but isn't this a defect? I am not sure with respect to the specifications. Kind regards Olivier 2011/7/27 Eike Rathke o...@erack.de Hi Olivier, On Wednesday, 2011-07-27 14:50:33 -0300, Olivier Hallot wrote: Investigating sc/sdi/cellsh.sdi [...] So it looks like GoDownSel has an argument By, which seems to be select FN_PARAM_1 cells down, but GoUpSel (GoRightSel and GoLeftSel) does not have this parameter. Which one is the correct? Tricky.. both ;-) The slot parameters of the first definition of an ExecMethod are inherited by following definitions with the same ExecMethod. So actually SID_CURSORUP_SEL inherits By from the first definition of ExecuteCursorSel that happens to be SID_CURSORDOWN_SEL. Compare with the generated sc/$INPATH/inc/scslots.hxx Eike -- PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication. Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Olivier Hallot Founder and Steering Commitee Member The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Calc - a better design ...
At 9:42am -0400 Wed, 27 Jul 2011, Michael Meeks wrote: Anyhow - as text, this is not terribly convincing; drawing on a whiteboard would be more so, and with lots of working code - even more so ;-) I keep hoping to have time to play with ixion with Kohei in this regard. Actually, as text it is convincing. So my original analogy to CSS works, but your example of sum(*array) vs for(i = 0...) and making use of SIMD is also telling. Who is working on these particular internals, if anybody? Do I take from your last sentence that the answer is partially nobody? I would /love/ to get my hands dirty on exactly this kind of restructuring and code work ... if only my hands weren't currently tied to a graduate degree that I also enjoy. Sigh. Cheers (and thanks for the extensive reply!), Kevin ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
