Re: ANN: renaming of master branch to "main" for core repository and submodules (dictionaries, help, translations)
TLDR: - There does not appear to be a consensus on the usage of the default brach name, at least as of now. - I find the claim that all use of the word master is bad to be poorly argued. - This mostly appears to be an ongoing internal problem of one country. As a technical project we should not be taking sides in such politics, especially given that the problem does not appear to be resolved or even having a consensus. On Thursday 18 of March 2021, Thorsten Behrens wrote: > Lubos Lunak wrote: > > I disagree with the plan. Git uses master, so we should stick with > > that. > > Hmm. But someone else using outdated names shouldn't per se be a reason > for us? Also it appears things are moving there, too. - The name is not, at least as of now, outdated. As I've already said, the current name is 'master' and I don't see why GitHub or even LLVM should be authorities on that. - Not changing a default in 9 months is not appearing to be moving. I guess that could have been already done if things were simple? I find it a valid technical reason not to do so if they themselves do not do it. - If somebody else (not) doing something shouldn't be a reason for us, then why is it listed as a reason for us to do the change? - There appear to be many other projects that are, at least as of now, not moving. It doesn't look to me that there's a consensus on this. > > And that brings me to the non-technical part of this, because I > > really don't see the reason for this. > > The reason is, that language evolves, and bad habits (or metaphors) of > the past shouldn't be persisted, if we know they are offensive to > others. https://www.merriam-webster.com/dictionary/master lists ~20 meanings for the word, and there's only one of them marked outdated, and 5b, which is the one git uses, is not marked as bad, archaic, offensive, or anything like that. Similarly, I can find e.g. pages about getting Master's Degree in 2021 and various other uses of the other meanings for the word, which from here looks like it's fine to use them. On the other hand, the meaning related to slavery seems like a meaning that's obsolete. Now I'm not a native speaker and I don't live in an English-speaking country, so I may be getting something wrong, but then neither do you, so how come you should know this better? (FWIW, I find it offensive to get lectured on English by a German. Just saying. I consider getting occassionally, and often probably unintentionally, getting offended to be simply life.) > Generally, our approach in the community should be - if it doesn't > harm us [1], we should be considerate & welcoming. Then maybe we should consider the possibility that forcing one interpretation and not welcoming any other is not very considerate or welcoming. > The feedback towards using master/slave (and other > established-but-fraught-terms) was that it indeed is taken as offensive for > some people. This is not about master/slave. This is about master (copy of a) branch, which has nothing to do with slavery, and you have provided very poor reasoning for changing anything there, and there's no apparent consensus on any of your claims. If I'm reading the ESC proposal correctly, this is basically a proposal from Germans living in Germany to take a side in cultural/political/language problem of another country. Which just doesn't make sense. If they sort it out, fine (I guess that may take a while, given that from afar it looks that the US currently can't agree on anything right now). But I don't see a good reason why we should take a part in that now. -- Lubos Lunak ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ANN: renaming of master branch to "main" for core repository and submodules (dictionaries, help, translations)
On Wednesday 17 of March 2021, Christian Lohmaier wrote:
> Hi *,
>
> as requested and announced in previous ESC-minutes and infra-call
> minutes, master branch will be renamed for the LibreOffice core
> repositories and the submodules used by LibreOffice (dictionaries,
> help, translations).
>
> Current plan is to do the switchover on April 1st
> If you have objections to this date or the plan laid out below (for
> current changes please see also
> https://redmine.documentfoundation.org/issues/3442 please raise your
> concerns ASAP)
I disagree with the plan. Git uses master, so we should stick with that. And
by 'git uses master' I mean that if you check out the git repo of the git
tool, you'll get the master branch, there's no main branch, and if you build
it and run 'git init', it'll create a master branch. The option for the
default branch name was added 9 months ago, so they have had plenty of time
for switching, and if they haven't, then maybe we shouldn't either. We
already have this running joke of breaking every tooling, and I don't see a
reason why risk it here.
And that brings me to the non-technical part of this, because I really don't
see the reason for this. Is it written down somewhere? I find the ESC minutes
unclear on the motivation. The Redmine motivation link is to some RFC-like
document that talks about "master-slave", but it does not mention "master" on
its own a single time. Even the recommendations there refer
to 'term "master-slave"' and not just "master". The other Redmine ticket
links to GitHub, but why should we care what some other repository provider
does? (I mean, I understand GitHub is based in a country where they currently
have all kinds of problems with this, but do we need to take a part in
that?). And presumably the intention is not being compatible with new
repositories on GitHub, that wouldn't make much sense.
Finally, even if we assume that it would be a good idea to avoid the use of
the word 'master' altogether because one of the 20 meanings a dictionary
gives is bad, what's the plan for all the other 20059 ('git grep -i master |
wc -l') other uses in LibreOffice? We have master passwords, master slides,
master styles and so on, and mind you, that goes as far as changing the ODF
format, is the plan to change all those too? And if not, is there any plan
for when somebody points that out as hypocrisy? And before any of this is
done, shouldn't first be something done about those 487 occurences of the
actually problematic word, which would be way simpler and actually do
something related to the topic?
The way I see it, if this is supposed to fix something, then it actually
doesn't, and it can create technical problems. If it's supposed to do
something else, it's not up to us to solve somebody else's problem, and it
can backfire.
PS: I can't miss the irony of renaming 'master' in 'git', when it's the
latter word that's an actual insult.
--
Lubos Lunak
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: New Defects reported by Coverity Scan for LibreOffice
On Monday 02 of February 2015, Stephan Bergmann wrote: On 02/02/2015 10:39 AM, Caolán McNamara wrote: So, if we show coverity the asserts it removes a pile of warnings, but introduces another pile of deadcode given the way we have stacks of defensive this shouldn't happen, but if it does code :-) We either ifdef off NDEBUG, just go back to hiding asserts from coverity, or bravely claim that all our assert conditions never happen in release mode. My take on it is simple: There /is/ a flaw in the above code, and Coverity /does/ correctly identify it. If the asserted condition cannot legitimately be false at that place, the ?: check is wrong and must go away. If it can, the assert is wrong and must go away (or, depending on context, be replaced with a SAL_WARN_IF, say). That is indeed the theory, but what is the reality? Can somebody with such a monstrous codebase say for sure which case it is for every instance of the problem? If memory serves me well, we shipped a couple of releases that under some circumstances had VCL KFileDialog integration hitting asserts on improper locking, but release builds still managed to cope with it somehow (more often than not, anyway). Developer builds should of course fall flat on their face in such cases, but in practice it's probably better to value end product stability more than practically insignificant warnings from a tool. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Monday 08 of December 2014, Bjoern Michaelsen wrote: Hi Lubos, On Fri, Dec 05, 2014 at 06:46:17PM +0100, Lubos Lunak wrote: On Thursday 04 of December 2014, Michael Meeks wrote: * Large scale renames (Kendy) ... + if cleanup there; perhaps some improved naming too. http://qt-project.org/wiki/API-Design-Principles#d8bc4b5cb3e68ae6e38b29e3 71b7f734 would be a very worthwhile reading here. good link, thanks! I think the problem -- at least in Writer -- is a bit deeper, no only naming: the classes in sw/ have somewhat muddy purposes and arent too well defined in their scope. The naming is just the topping on the cake (What is a SwFmtFrmSize and how is (if at all) it related to a SwFrmFmt?). I would agree that unfortunately the problem indeed is deeper, to the core issue that code written poorly in some way attacts more code written poorly. So when we inherited this codebase from OOo, we also inherited code that's poorly named, poorly commented, poorly documented (et cetera). And with that, we also inherited a culture where all that is perfectly fine and acceptable, which was realistically inevitable if we wanted to actually get something done with the code. The bad part is that since it's fine and normal to have such poorly done code, it's also fine to keep with that tradition and continue producing new code that has the same flaws. Just look at some of the newly written code, such as Clang plugins (I explicitly documented the purpose of each of mine ones, but when I looked recently I either could guess from the name or decipher it from the code) or the OpenGL VCL backend (the main class there has functions DrawLine() and drawLine(), and yes, they differ). So if you treat this only as a problem of some localized code, you may end up in a situation of fixing up old code while new code gets written in a form that immediately qualifies them for a such cleanup as well. IMHO, the best way out of this mess would be to: 1/ find groups of around ~5 classes as a batch and define (and doxygen-document) the single responsiblity of each of those well. It likely makes sense to refer to the old ::SwFoo StarOffice/OpenOffice.org class name in doxygen too. 2/ move this set of classes a name matching the defined responsiblity in namespace sw That would mean we would try to start some consistent well-scoped naming in namespace sw, while the global (top-level) namespace still contains the old wild west naming. And them we would step by step grow the pocket by adding stuff in a ordered fashion to it. Given what I wrote above, I think this should start by first actually writing down somewhere what the new proper state of things should be. Otherwise nobody will know what the code ideally should look like, given that people either can write code based on what the existing code looks like (where the current code is pathetic when it comes to these criteria) or what some kind of OOo resource like the OOo coding style says (which is just as pathetic) or on their idea of what a good code should look like (which, to put it bluntly, is probably not that good either, given the above). And then require it for new commits. I'm generally not a big fan of being strict with rules (and it certainly can be taken too far, try e.g. to submit a patch to Clang), but then apparently the situation won't change on its own, if it hasn't in the last 4 years. Or, alternatively, we can just accept the fact that this codebase will in some aspects suck forever. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Thursday 04 of December 2014, Michael Meeks wrote: * Large scale renames (Kendy) ... + if cleanup there; perhaps some improved naming too. http://qt-project.org/wiki/API-Design-Principles#d8bc4b5cb3e68ae6e38b29e371b7f734 would be a very worthwhile reading here. + would support better names for Writer (Bjorn) + can re-write classes with Clang ? (Michael) Clang should be able to rewrite pretty much whatever would matter. E.g. compilerplugins/clang/store/changefunctioncalls.cxx could be used to rename all calls of a specific function. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Attempt to make vcl::Timer use boost's Signals2
On Tuesday 18 of November 2014, Chris Sherlock wrote: Hi all, I'm attempting to get Timer to use boost's Signals2. When I compile, however, I get a warning and an error: I should finally find the time to write down the howto for this I guess. You cannot just use a pointer to a member function, because that one requires also the this pointer, so you need to go with boost::bind. See e.g. 96369e97. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Attempt to make vcl::Timer use boost's Signals2
On Tuesday 18 of November 2014, Kohei Yoshida wrote: On Tue, 2014-11-18 at 23:50 +1100, Chris Sherlock wrote: Hi all, I'm attempting to get Timer to use boost's Signals2. When you do that, could you apply pimpl pattern to hide its boost usages from the header? He can't. Signals usually form part of the public API of a class. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Friday 14 of November 2014, Stephan Bergmann wrote: On 11/14/2014 07:49 AM, Noel Grandin wrote: (2) Perhaps we need to be using the extern template feature to limit the number of instantiations of various templates? Template instantiations, via the typical all-inline nature of the template declarations, have hidden visibility and should end up with one copy per dynamic object. But also with one copy per .o file, which presumably contributes to higher resource demands for building. It's also a question if the linker is as good at discarding duplicate debuginfo about templates. I'm not sure whether there would be much compile- or run-time benefit from using another strategy (plus, I'm not sure whether it would work well across the various toolchains to give template instantiations non-hidden visibility). Given we have SAL_DLLPUBLIC_TEMPLATE, it seems likely that there shouldn't be any big trouble there. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: minutes of ESC call ...
On Friday 14 of November 2014, Noel Grandin wrote: (3) Use gcc's -gsplit-dwarf feature to reduce size of debug information (clang also has some support for this) https://gcc.gnu.org/wiki/DebugFission We could auto-detect this in configure.ac and use it if available. There's rather tool poor support for this feature so far. It e.g. requires relatively recent gdb (and IIRC the support was buggy in some versions, I'm not sure how well it works now. Neither ccache nor icecream support the option (for ccache there's a 3rd party patch that has not been integrated, for icecream I have a patch but compilers do not allow specifying proper path refering to the .dwo file when building in a different path). -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: tracking down reference counting memory leaks
On Tuesday 21 of October 2014, Noel Grandin wrote: On 2014-10-20 06:27 PM, Michael Stahl wrote: there are 2 ways i've tried to track down the 2 leaking acquire()s: 1. instrument the acquire()/release() method and run the test in gdb, the script just takes 2 minutes to run (90 seconds of which are spent in a single regex) but unfortunately printing 4000 stack traces with gdb takes 3 hours on my laptop; probably that can be sped up by disabling The backtrace API in GLIBC would speed this up considerably http://www.gnu.org/software/libc/manual/html_node/Backtraces.html Sadly, it'd also break it considerably. Unless that has improved recently (which I doubt), things like hidden symbol visibility make these functions practically useless. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LO 4.3 build broken (related to bnc#891663)
On Tuesday 23 of September 2014, Andras Timar wrote: On Tue, Sep 23, 2014 at 10:10 PM, Jean-Baptiste Faure jbfa...@libreoffice.org wrote: Hi, The build of 4.3 branch fails on the following unit test : [build CUT] sw_ooxmlimport File tested,Execution Time (ms) bnc891663.docx,[...]/LibO/lo43/sw/qa/extras/ooxmlimport/ooxmlimport.cxx:2 284:testBnc891663::Import assertion failed - Expression: textNextRowTop = imageTop + imageHeight Unfortunately the fix worked only for master. I accepted the patch for libreoffice-4-3, but it was a mistake. I reverted it. My bad, the original code had several unhandled switch cases together and I overlooked that (not that I get how the fix worked in master). Andras, could you please include the commit back to 4.2+4.3 together with 74c6ba1b741ae76ad9e2f2b81be3e3178163f085 ? Thanks. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: stack-allocated Window subclasses
On Tuesday 23 of September 2014, Michael Meeks wrote: The question is; what should we replace it with. Personally I'm more of a fan of intrusive reference counting for VCL - we don't want lots of atomics, so that the optimizer can rid us of size inefficiency - and at least for now we can't ref-count those guys anyway I think. Then again rtl::ReferenceFoo lost its nasty virtual methods recently (IIRC), so - perhaps we could use that - but for the fact that it's unpleasantly long to type. I'd also love to avoid 'orrible casts everywhere when converting to references to parent types [ perhaps I just do this wrong myself ;-] So - possibly having a ButtonRef xFoo; type class that is (underneath) an rtl::ReferenceButton - and yet can easily be implicitly co-erced to a WindowRef etc. might fly ? I guess we need to have a plan in-place there before shunting all those widgets off onto the heap where we can lifecycle manage them sensibly =) Thoughts ? I must have missed it, where can I read what problems led to requiring a solution like this instead of the primitiveworking way of having parents responsible for cleaning up their children on destruction? Stack-allocated objects is probably the most sensible C++ lifecycle management ever, so if it doesn't work with vcl, vcl has got to be seriously broken in that regard. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: C++11
On Monday 15 of September 2014, Stephan Bergmann wrote: ...oh, and one important thing I forgot to mention: For the URE interface, it is probably best to stay with C++03 for now (to keep requirements laxer for 3rd party extension authors, and e.g. not force them to use http://people.centos.org/tru/devtools-2/ for Linux extensions). In other words, all the include files that end up copied to the SDK's include/ directory still need to be compileable by a non-C++11 compiler. But we are only people, so I added checking of this to the odk checkapi test. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: some clang plugins report bogus warnings (was: Re: GSoC Refactor god objects weekly report)
On Tuesday 29 of July 2014, Michael Stahl wrote: On 29/07/14 01:39, V wrote: The only thing bugging me is that the extern-and-not-defined plugin is not really werror compatible because it seems to warn in a lot of places. To disable it I moved into a disabled folder and told git to ignore it so I dont commit that changed, but it seems to reappear everytime I pull. interesting ... i've had the same problem with 2 of the clang plugins; at least with the clang packages on Fedora 20, they report warnings in _header_ files despite the plugins having a check that the offending statement isInMainFile() - perhaps it's some clang bug that does not occur with the clang versions the authors of the plugins used? well there is macro expansion involved in the problems i saw, argh... I think the call to isInMainFile() should not use spellingLocation, but just the location given by functionDecl-getLocation() . -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Unchecked dynamic_cast
On Saturday 07 of June 2014, Michael Stahl wrote:
On 06/06/14 13:41, Max Kellermann wrote:
Hi Caolan,
I just happened to read your Libreoffice commits while browsing the
git repository. For example:
if ( pFmt-Which() == RES_FLYFRMFMT )
{
-GetDoc()-SetFlyFrmTitle(
*(dynamic_castSwFlyFrmFmt*(pFmt)), +
GetDoc()-SetFlyFrmTitle( dynamic_castSwFlyFrmFmt(*pFmt), rTitle );
This, however, is still wrong. It just hides the warning.
We know already at this point that pFmt is not NULL. But what we
don't know is whether pFmt is a SwFlyFrmFmt instance. dynamic_cast
can return NULL even if its parameter is not NULL.
So, you have checked that its type is RES_FLYFRMFMT, and thus it must
be a SwFlyFrmFmt instance. Ok, but then you don't need the overhead
of dynamic_cast. A static_cast will do the same, with less runtime
overhead.
In any case, your changes do not actually address the Coverity
warnings; they merely hide them.
the warning above is bogus - the check on Which() is effectively a type
check, so any change that shuts up the warning is good enough; and i bet
the runtime overhead of this line would never show up in a profile
anyway.
actually i'd be annoyed if this were changed to check if the
dynamic_cast was successful - that has the potential to take us further
into the un-debuggable world of defensive programming, where nobody
knows what the invariants of some class or function actually are.
But that's exactly the point of what Max says. The warning is not bogus.
Using a dynamic_cast where a static_cast is known to work well is a sign of
the un-debuggable world of defensive programming that you speak of.
--
Lubos Lunak
l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: debug libreoffice for the first time: soffice.bin...(no debugging symbols found)...done.
On Tuesday 29 of April 2014, Marco Borra wrote: Hello, I'm trying to debug libreoffice for the first time I followed the instructions on the wiki. ./autogen.sh --enable-dbgutil --without-java --without-help --without-myspell-dicts --without-doxygen --with-parallelism=2 CFLAGS='-O0 -g0' CXXFLAGS='-O0 -g0' make From ddd: Open Program /home/marco/libreoffice/instdir/program/soffice.bin (gdb) file /home/marco/libreoffice/instdir/program/soffice.bin Reading symbols from /home/marco/libreoffice/instdir/program/soffice.bin...(no debugging symbols found)...done. (gdb) What am I doing wrong? Thanks for your help. You followed a tip that said the build will be faster if you disabled optimizations and debug info, and now you want to debug without debug info, which doesn't work. Do not use those C(XX)FLAGS you used (and I'll remove that from the wiki, it was apparently a bad idea to have it there). -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: upper case digits in OUString/OString::number() (was: [Libreoffice-commits] core.git: Change RGB FFFF00 - ffff00 to keep roundtrip test happy)
On Friday 25 of April 2014, Eike Rathke wrote: Hi Stephan, On Friday, 2014-04-25 10:06:17 +0200, Stephan Bergmann wrote: Would it be better to change oox::drawingml::DrawingML::WriteColor(sal_uInt32, sal_Int32) (oox/source/export/drawingml.cxx) to always write OOXML ST_HexColorRGB values in W3C XML Schema hexBinaryCanonical form, i.e., with upper case digits A--F? Which reminds me, we can't force upper case digits in OUString/OString::number(), can we? We can, the docs say it'll be a string representation of the number, it doesn't say whether hex will be uppercase or lowercase. The question is of course how much code makes an assumption about this and whether the change is worth it. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Cppcheck reports Deallocation of an auto-variable results in undefined behaviour in vcl part
On Saturday 26 of April 2014, julien2412 wrote: Hello, Cppcheck reported this: [vcl/source/gdi/bitmap4.cxx:229]: (error) Deallocation of an auto-variable results in undefined behaviour 137 long(*pKoeff)[ 256 ] = new long[ 9 ][ 256 ]; ... 229 delete[] pKoeff; See http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/bitmap4.cxx#137 False positive? Yes, it looks bogus. Moreover, I searched info about declaring 2D arrays and this notation new T[x][y] isn't supposed to work (see http://stackoverflow.com/questions/936687/how-do-i-declare-a-2d-array-in-c- using-new) Any idea? The sizes are constants, there's no such problem. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Fwd: [Bug 1087931] [abrt] libreoffice-core: KDE4FilePicker::execute - QTransform::type: soffice.bin killed by SIGABRT
On Thursday 17 of April 2014, Lubos Lunak wrote: On Wednesday 16 of April 2014, Stephan Bergmann wrote: Jan-Marek, all, Any details on the reason for the revert, and whether it could be the cause for the newly seen crash? KDE4 file dialog support is currently apparently broken one way or another. Current git master (or at least few weeks back when I checked) when built with dbgutil simply aborts on assertion failure about holding the yield mutex properly. Older LO version without these modifications sooner or later crashes on QTransform::type(), I'm not sure what has changed, since this used to be pretty stable for me on openSUSE 12.3, but with 13.1 it crashes easily. So it looks like so far the best option is just not including the Qt4 patch, which will mean the cumbersome generic LO file dialog :-/. I haven't had yet the time to look deeper into this, and getting this event loops stuff is not exactly trivial :(. Ok, I suffered enough with the generic file dialog, and found some time for this. I've just pushed 2cd8a1e0f1e81efd15979953d7f274ab8a6806d6 .. 508337db0c53caa5fb43ef26f781df159497a482 , which has links to Qt bugreports for needed fixes, if they're not present you get the generic file dialog without crashes (and without convenient use), otherwise KFileDialog seems to work fine for me. I haven't really tested it yet that much, but It Should Be Okay(TM), so feel free to backport to 4.2 if you feel like. -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Fwd: [Bug 1087931] [abrt] libreoffice-core: KDE4FilePicker::execute - QTransform::type: soffice.bin killed by SIGABRT
On Wednesday 16 of April 2014, Stephan Bergmann wrote: Jan-Marek, all, Any details on the reason for the revert, and whether it could be the cause for the newly seen crash? KDE4 file dialog support is currently apparently broken one way or another. Current git master (or at least few weeks back when I checked) when built with dbgutil simply aborts on assertion failure about holding the yield mutex properly. Older LO version without these modifications sooner or later crashes on QTransform::type(), I'm not sure what has changed, since this used to be pretty stable for me on openSUSE 12.3, but with 13.1 it crashes easily. So it looks like so far the best option is just not including the Qt4 patch, which will mean the cumbersome generic LO file dialog :-/. I haven't had yet the time to look deeper into this, and getting this event loops stuff is not exactly trivial :(. On 04/15/2014 06:12 PM, bugzi...@redhat.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1087931 Stephan Bergmann sberg...@redhat.com changed: What|Removed |Added - --- Summary|[abrt] libreoffice-core:|[abrt] libreoffice-core: |os::die()(): soffice.bin|KDE4FilePicker::execute | - | |killed by SIGABRT |QTransform::type: ||soffice.bin killed by ||SIGABRT --- Comment #12 from Stephan Bergmann sberg...@redhat.com --- The backtrace in attachment 886519 indicates this is a duplicate of bug 977068, which was fixed for libreoffice-4.1.3.2-7.fc19 via upstream http://cgit.freedesktop.org/libreoffice/core/commit/?id=13a34f4c6307d1bd 2443cbf3fbd83bfdd8cdbafb Rewrite Qt4 based nested yield mutex locking. But part of that got later reverted (and is reverted in libreoffice-core-4.2.3.2-3.fc20) via upstream http://cgit.freedesktop.org/libreoffice/core/commit/?id=daf011870efae282 244c0298494820d9a0c6d3bc Revert 'Rewrite Qt4 based nested yield mutex locking,' but unfortunately without any rationale. So it looks somewhat plausible that this got broken again (if it ever was actually truly fixed) with that revert. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice -- Lubos Lunak l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: eot embedded fonts
On Tuesday 27 of August 2013, Brennan T Vincent wrote:
Hi all,
One of the most commonly-occurring problems with .pub import is the fact
that we don't respect embedded fonts. Now that LibreOffice supports
embedded fonts, it should be possible to make this work.
That depends. EOT is a Microsoft proprietary font format (which has been
submitted to W3C, but AFAICT pretty much everybody else ignores it). There
are tools to convert e.g. TTF fonts to EOT, but I couldn't find absolutely
anything that'd convert from EOT and the only thing capable of at least
reading it is MS Windows itself. As far as I understand it, the available
documentation on it is unsufficient for implementing a reader if you'd decide
it'd be worth the effort (I'm not entirely sure on this part, feel free to do
your own research).
Here are some links that I found on the topic:
http://blog.yezhucn.com/gdi/t2embed_TTLoadEmbeddedFont.htm
http://www.pptfaq.com/FAQ00076_Embedding_fonts.htm
http://graphicdesign.stackexchange.com/questions/16234/are-there-any-free-tools-to-convert-eot-files-to-ttf-otf-or-any-other-font-f
http://www.w3.org/Submission/2008/SUBM-EOT-20080305/
http://www.w3.org/Submission/2008/SUBM-MTX-20080305/
http://lists.w3.org/Archives/Public/www-style/2008Apr/0227.html
http://securitylabs.websense.com/content/Blogs/3114.aspx
A few questions:
(1) Do we support Embedded OpenType fonts currently? (.eot)
No.
(2) If not (which I suspect), I can contribute some code to do this.
Microsoft and Monotype recently granted a perpetual, irrevocable free
patent and copyright license to implement the .eot format, so there should
be no legal issues. I have written a C library to convert from .eot to .ttf
and would like to know who to talk to in order to get this included in
LibreOffice.
Yes, adding support for export should be fairly easy, given that TTF-EOT
conversion is possible, but that's the easier part and it doesn't really help
LO much.
A kind of limited import support should be also doable, as the Windows
TTLoadEmbeddedFont() function can load such a font for use (unlike the normal
Windows function for opening fonts). See the attached hackish proof of
concept patch. That'd make import of it Windows-only, unless you find a way
to use EOT on other platforms. It'd also most probably require some changes
in VCL's font handling, as I couldn't get the activated font listed among
available fonts (which is what otherwise the current reading of embedded
fonts does, it adds the new font temporarily in whichever way the underlying
font system supports and then just uses it normally as if it was a system
font).
There's a class EmbeddedFontsHelper in VCL that I created for handling
embedded fonts, that should be the place to start if you want to give
implementing this a try.
--
Lubos Lunak
l.lu...@suse.cz
diff --git a/oox/Library_oox.mk b/oox/Library_oox.mk
index 8d07153..a4aeb7c 100644
--- a/oox/Library_oox.mk
+++ b/oox/Library_oox.mk
@@ -312,4 +312,10 @@ $(eval $(call gb_Library_add_generated_exception_objects,oox,\
CustomTarget/oox/generated/misc/vmlexport-shape-types \
))
+$(eval $(call gb_Library_use_system_win32_libs,oox,\
+ $(if $(filter $(COM),MSC), \
+ t2embed \
+ ) \
+))
+
# vim: set noet sw=4 ts=4:
diff --git a/oox/source/ppt/pptimport.cxx b/oox/source/ppt/pptimport.cxx
index a7e9922..d468d41 100644
--- a/oox/source/ppt/pptimport.cxx
+++ b/oox/source/ppt/pptimport.cxx
@@ -32,6 +32,13 @@ using namespace oox::core;
using ::com::sun::star::beans::PropertyValue;
using ::com::sun::star::lang::XComponent;
+#include vcl/embeddedfontshelper.hxx
+
+#undef WB_LEFT
+#undef WB_RIGHT
+#include windows.h
+#include t2embapi.h
+
namespace oox { namespace ppt {
OUString SAL_CALL PowerPointImport_getImplementationName() throw()
@@ -70,8 +77,51 @@ PowerPointImport::~PowerPointImport()
{
}
+
+FILE* ff;
+unsigned long readfunc( void*, void* out, unsigned long len )
+{
+int r = fread( out, 1, len, ff );
+SAL_DEBUG(RF: len : r );
+return r;
+}
+
+
+void hack()
+{
+EmbeddedFontsHelper::activateFont( Bauhaus 93, file://c:/cygwin/home/tinderbox/tmp/font.eof );
+return;
+
+
+ff = fopen( c:\\cygwin\\home\\tinderbox\\tmp\\font.eot, rb );
+SAL_DEBUG( F: (void*)ff );
+HANDLE ft;
+ULONG status1;
+ULONG status2;
+LONG ret = TTLoadEmbeddedFont(
+ft,
+0, //TTLOAD_PRIVATE,
+status1,
+LICENSE_DEFAULT,
+status2,
+readfunc,
+NULL,
+NULL,
+NULL,
+NULL );
+SAL_DEBUG( F2: ret : status1 : status2 );
+fclose( ff );
+wchar_t nm[ LF_FACESIZE + 1 ];
+char nm2[ LF_FACESIZE + 1 ];
+ret = TTGetNewFontName( ft, nm, sizeof( nm ), nm2, sizeof(nm2));
+SAL_DEBUG(F3: ret : OUString( nm ));
+}
+
+
bool PowerPointImport::importDocument() throw()
{
+SAL_DEBUG(HACK);
+hack();
/* to activate the PPTX dumper, define the environment variable
Re: eot embedded fonts
On Tuesday 27 of August 2013, Brennan T Vincent wrote: Thanks Lubos I should clarify, I already have an eot-ttf converter working; proof Ah, I read this the other way around the first time. positive that MS and Monotype's documentation is sufficient :). I just need to clean up the code, write some unit tests, etc. before I am comfortable submitting it to LibreOffice. I'll take a look at EmbeddedFontsHelper So in that case it should be sufficient just to detect EOT and convert it to TTF in the function that adds a font for LO's use, and convert or reuse back when writing out a document. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Daily Win32 debug builds
Hello, as mentioned earlier, I've switched #6 tinderbox to do --enable-debug builds, and thanks to Fridrich by now I have also a working version that allows anybody to get usable backtraces. In short, besides daily builds at http://dev-builds.libreoffice.org/daily/master/Win-x86@6-debug/ there is also a symbols directory. If you add the http://dev-builds.libreoffice.org/daily/master/Win-x86@6-debug/symbols URL to MSVC-Tools-Options-Debugging-Symbols , then MSVC will fetch needed .pdb files when debugging one of those builds. I have no yet updated the wiki and made this public in any other way, as I'd like this to be somewhat checked first, and I'm also not completely sure the server can handle it. Each full set of .pdb files is about 2.5GiB , the tinderbox currently uploads them only for the last 5 dailies for master. Additionally, the .pdb symbols store stuff is smart enough to reuse unchanged .pdb files (which is quite likely to happen for #6 tinderbox, as it does incremental builds, I'm not sure if that'd work also with clean rebuilds). So I think my questions are basically: - how much space can I take with this on dev-builds? If I enable it also for 4.0 and 4.1 tinderbox and keep it for 5 last dailies, the space requirements should be somewhere below 100GiB tops, but in practice probably less. - can the server take the bandwith load? Tinderbox is rate-limited for upload, so that's not a problem, but I don't have an estimate for download. MSVC downloads only those .pdb files it actually needs, and it can cache them locally, so it's hopefully not that much. - is there any other option I should be asking :) ? Attached is a tinderbox master.sh script I currently use. -- Lubos Lunak l.lu...@suse.cz master.sh Description: application/shellscript ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: 3 commits - include/xmloff sw/source xmloff/source
On Wednesday 15 of May 2013, Michael Stahl wrote: include/xmloff/xmlimp.hxx |1 sw/source/core/bastyp/init.cxx |2 - sw/source/core/doc/poolfmt.cxx |4 --- sw/source/core/unocore/unoframe.cxx| 16 sw/source/filter/html/swhtml.cxx |5 +++ sw/source/filter/ww8/ww8par.cxx|4 --- sw/source/ui/app/docshini.cxx | 11 xmloff/source/core/xmlimp.cxx | 33 + xmloff/source/draw/XMLGraphicsDefaultStyle.cxx | 8 ++ 9 files changed, 43 insertions(+), 41 deletions(-) New commits: commit d278cc769e484b0452b1fb6000e213561d8d955d Author: Michael Stahl mst...@redhat.com Date: Wed May 15 18:33:48 2013 +0200 sw: change pool default of RES_FOLLOW_TEXT_FLOW to false For a new document the default is already effectively false due to SwDocShell::InitNew() and the ODF and WW8 filters set it explicitly to false... which is also the appropriate value for RTF and DOCX. But only OOoXML and (perhaps) HTML (not sure) want true as the default. +mpImpl-mbIsOOoXML = +::comphelper::OStorageHelper::GetXStorageFormat(xStor) +SOFFICE_FILEFORMAT_8; Was the old OOo format really called OOoXML? Seeing this commit made me pretty confused until I figured out after a while that it has in fact nothing to do with OOXML. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Conflict between system and internal cairo
Hello, Clang tindebox currently fails because of a race and mixup of system and internal cairo/pixman libraries. Specifically, Executable_pluginapp.bin.mk links also against gtk, which links against cairo, which links against pixman. And there is a race that results in solver containing pixman but not cairo by the time Executable_pluginapp.bin.mk is being linked. The linker command has -L for the solver lib directory, so it picks up system cairo and internal pixman, and these are apparently incompatible. Changing StaticLibrary_plugcon.mk to $(eval $(call gb_StaticLibrary_use_externals,plugcon,gtk cairo)) helps with the problem, but I assume this cannot be just hardcoded and I don't know how to do it properly? Gbuild experts? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: conversion operators for UNO
On Thursday 25 of April 2013, Michael Stahl wrote: On 25/04/13 12:08, Noel Grandin wrote: On 2013-04-25 11:59, Michael Stahl wrote: e.g. this problem here caused a 3 % or so slowdown in ODF file load and/or save (i forgot which), mainly due to 2 additional queryInterface calls in a critical place: https://issues.apache.org/ooo/show_bug.cgi?id=108161 with your proposal it would be possible to write code like: ReferenceB b = ... methodFooThatTakesA( b ); methodBarThatTakesA( b ); methodBazThatTakesA( b ); ... and get 3 queryInterface calls instead of 1. or let me reformulate that: is it possible to implement your hypothetical operator such that it does not call queryInterface (i don't know). A and B are normal C++ classes with the right inheritance, aren't they? I'd expect a template uno::Reference ctor with the right check for allowing only inheriting types should do. My desire is to make the UNO code less noisy. And it matches the natural semantics of C++, which is that it's possible to pass a subtype of the expected parameter's type. hmmm... looking at the amount of boilerplate involved one gets the impression that UNO somehow appears more natural in languages that aren't C++ :) Probably nobody has spent enough time to design that boilerplate for those other languages :). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: unusedcode some step further
On Tuesday 02 of April 2013, Michael Meeks wrote: On Mon, 2013-04-01 at 16:04 +0200, Noel Grandin wrote: Another way is to use a clang plugin to generate a more accurate list of definitions and call sites. That's what I would do, because clang would handle all of the macro and language parsing. Completely agreed; I imagine it would be necessary to write some intermediate format out from each clang compile - and then crunch those together afterwards to see what was actually used. Hopefully - given the level of context that clang has - it'd be reasonably easy to identify and elide virtual methods even DLLPUBLIC ones - though we would presumably want to white-list any UNO interfaces' virtual methods - which may well never be called; yet can't be removed. The compilerplugins/ directory has some nice README about plugins and all the good things they can do :-) Potentially with a double pass through the code - clang could auto-generate diffs of things o remove ;- If somebody wants to play with this, there is a base for such a compiler check in compilerplugins/clang/store/unusedcode.cxx . It only checks whether all functions encountered are used or not (and it should handle both inline and virtuals correctly). It doesn't do anything more with it, but there are comments about what should be done with the data, which I expect should be fairly easy to do and just needs somebody to do it. It it to be used like other rewriters (see the README), expect it won't rewrite anything and only generate the data. There's no white-listing either, but that shouldn't be difficult, and the code could be similarly extended to also check for unused structs/classes, enums, etc. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: patch for postgresql driver
On Tuesday 16 of April 2013, Wols Lists wrote: The attached patch is not in logerrit (I've yet to set that up), and there's an error in it so I'm hoping someone can help. It does a TODO in the file, but I can't get my argument casting right - in the original code, matchIgnoreAsciiCaseAsciiL wraps its argument in RTL_CONSTASCII_STRINGPARAM. This is defined in sal/inc/rtl/string.h and passes both the string and its length. So me removing it is obviously a mistake, but it's got some integrity checking in there and I just can't get it to pass that. Actually removing it is not a mistake. The macro is a cumbersome micro-optimization and here it presumably doesn't make any difference. Just calling matchIgnoreAsciiCase() should do. Also note that LO has SAL_N_ELEMENTS macro for getting the number of items in an array. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Build Internal Error 512 ( tail_build ) on Ubuntu 12.04
On Saturday 13 of April 2013, Bjoern Michaelsen wrote: Hi, On Sat, Apr 13, 2013 at 06:35:19PM +0530, Anurag Kanungo wrote: $ ./g checkout -b libreoffice-4-0 origin/libreoffice-4-0(Branch libreoffice-4-0) Build log : http://pastebin.com/SqY406sA Please check and guide me how to solve the error . If you want to work on an EasyHack, then do not work in the libreoffice-4-0 branch, but in master, the main development branch. The problem from your log does not exist there. I would suggest not to use clang if this is your first build. _If_ you use clang, be prepared to do some work to keep it running now and then. Nah, the Clang build does not break more often than GCC build. But I don't know if Clang-3.0 builds LO without problems, you may need to upgrade to at least 3.1. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: PCH build times (Re: new gerrit-builds unit tests ...)
On Saturday 06 of April 2013, Bjoern Michaelsen wrote: Just out of curiousity, what are the numbers for sc now, if you have them at hand? make Library_sc PCH: 5:18 (PCH creation is about 24 seconds). non-PCH: 16:38 -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: rebuilt 1 .cxx, linked 184 libraries
On Thursday 04 of April 2013, Michael Stahl wrote: On 04/04/13 20:47, Bjoern Michaelsen wrote: On Thu, Apr 04, 2013 at 02:11:35PM -0400, Terrence Enger wrote: I just changed vcl/source/window/builder.cxx and did top-level make. The make had 184 [build LNK] steps. Is this to be expected? We could evade that with build order only deps (signified :|, see http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html ) and with (simplified): $(call gb_Library_get_target,a) :| $(call gb_Library_get_target,b) $(call gb_Library_get_target,a) : $(call gb_Library_get_headers_target,b) $(call gb_Library_get_target,b) : some object from lib b : some cxx from lib b This would make library a being rebuild only if one of the 'public', delivered headers of library b changed but not otherwise. And it would make sure, that if both library a and b need to be rebuild, a will always be rebuild after b. but it has the significant problem that you can remove implementations of the public API of library a without noticing it (which you would when library b fails to link), thus making incremental builds unsound. Significant? That scenario is already broken on its own. If a library changes its API, that means its headers need to change as well, thus the dependent library will eventually need to be relinked. If that's not the case, the change itself is broken. Moreover, this scenario is nowadays still somewhat likely, if one rebuild just a specific module, instead running toplevel make - how many of us do that after each change? I for sure don't, and won't as long as it takes that much time it takes. I actually agree with Terence. If a library changes, its dependent libraries should change and thus relink even without having .so - .so dependencies. I do not see a good use case where this would be a problem. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: moving global headers into one top-level location
on what this would (not might) fix? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
PCH build times (Re: new gerrit-builds unit tests ...)
On Friday 05 of April 2013, Bjoern Michaelsen wrote: On Fri, Apr 05, 2013 at 11:16:06AM -0500, Norbert Thiebaud wrote: I enabled pch because it was claimed to speed up things... I have not benchmark that claim. I would benchmark that, at least in the old days the results of PCH where really mixed: http://wiki.openoffice.org/wiki/Build_Environment_Effort/Performance and only reliably gave an advantage on incremental builds. OTOH, generating the PCH for a library was a singlethreaded bottleneck in the old build system and isnt anymore in gbuild, when doing a toplevel make, so this might be mitigated. Anyway, worth a benchmark IMHO. make Library_sw PCH: 7:01 non-PCH: 20:31 That's on Win86-6, MSVC2010, hot caches. The difference is of course smaller for modules lower in the stack, sw must use tons of includes. Full rebuild of master on Win86-6 is now something like 3 hours, without PCH it'd be at least 4 (I don't remember anymore and it'd take a while to measure). I have not tried with GCC, and with Clang it's actually not worth it at all. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: Branch 'libreoffice-4-0' - sc/CppunitTest_sc_subsequent_export_test.mk sc/qa sc/source xmloff/inc
On Thursday 28 of March 2013, Noel Power wrote: sc/CppunitTest_sc_subsequent_export_test.mk |1 sc/qa/unit/data/ods/rotflipshapes.ods |binary sc/qa/unit/helper/qahelper.hxx |5 + sc/qa/unit/subsequent_export-test.cxx | 78 sc/source/filter/xml/xmlexprt.cxx | 32 +++ xmloff/inc/xmloff/shapeexport.hxx |2 6 files changed, 117 insertions(+), 1 deletion(-) New commits: commit 2058479575e4a3e003eb1917c4f0947db9145623 Author: Noel Power noel.po...@suse.com Date: Tue Mar 26 18:21:27 2013 + hacky fix for export of cell anchored flipped custom shapes (fdo#62448) On export it is assumed the translate co-ords are the same as the topleft of the logical rectangle. What rectangle to use at any given time, the transformations and the fact that different object types seems to handle rotation etc. in their own way leaves me confused as to what the correct fix might be. This fix though won't make things worse ( afaict ) Change-Id: I6c704f9aebd650d530ebc32fbe73c251719494fe Reviewed-on: https://gerrit.libreoffice.org/3064 Tested-by: Petr Mladek pmla...@suse.cz Reviewed-by: Petr Mladek pmla...@suse.cz I have reverted this commit, as it fails on at least two 4-0 tinderboxes (Clang and Win-x86_6). I also couldn't find anything like this in master. Please check the commit. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: Branch 'libreoffice-4-0' - sc/CppunitTest_sc_subsequent_export_test.mk sc/qa sc/source xmloff/inc
On Friday 29 of March 2013, Noel Power wrote: On 29/03/13 16:18, Lubos Lunak wrote: On Thursday 28 of March 2013, Noel Power wrote: I have reverted this commit, as it fails on at least two 4-0 tinderboxes (Clang and Win-x86_6). I also couldn't find anything like this in master.there there is a good reason why there isn't something like this on master, the code around this area has changed and this patch isn't doesn't work as expected with the changed code Please check the commit. well it would be *really* useful to have the logs associated with the unit-test failure, then at least I could judge whether the patch really needs reverting or it is the unit test needs to be 'tweaked' a little. Naturally the test passes here for me What do you need besides http://tinderbox.libreoffice.org/libreoffice-4-0/status.html ? I can provide access to the boxes if needed (after Easter, I thought you've already left for it too). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: 2 commits - configure.ac i18npool/source
On Tuesday 26 of March 2013, Peter Foley wrote: On Tue, Mar 26, 2013 at 2:19 PM, Lubos Lunak l.lu...@suse.cz wrote: That already exists: configure CC=clang CXX=clang++ What's the point of having such an explicit option? We already have enough options that reinvent the wheel. I just felt it would be a convenient shorthand. If you don't think it's necessary, feel free to just revert it. AFAICT it's exactly the same like above, so it's duplicated code - I'll revert. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: 2 commits - configure.ac i18npool/source
On Sunday 24 of March 2013, Peter Foley wrote: configure.ac | 66 +++--- i18npool/source/localedata/localedata.cxx | 11 - 2 files changed, 44 insertions(+), 33 deletions(-) New commits: commit 02ed2608199f2adc466849d0f4864213ad07c445 Author: Peter Foley pefol...@verizon.net Date: Sun Mar 24 17:48:48 2013 -0400 add configure option to use clang That already exists: configure CC=clang CXX=clang++ What's the point of having such an explicit option? We already have enough options that reinvent the wheel. Change-Id: Ide63ef8bde7ed739b9bf29e936c01e156e8e3de4 diff --git a/configure.ac b/configure.ac index 6a31c89..898dedb 100644 --- a/configure.ac +++ b/configure.ac @@ -1158,6 +1158,11 @@ AC_ARG_ENABLE(winegcc, needed for MinGW cross-compilation.]), ) +AC_ARG_ENABLE(clang, +AS_HELP_STRING([--enable-clang], +[Build using the clang compiler.]), +) + -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] remove/add blank lines in sw/source/core
On Thursday 21 of March 2013, Eike Rathke wrote: Hi Philipp, On Wednesday, 2013-03-20 17:31:03 +, Philipp Riemer (via Code Review) wrote: remove/add blank lines in sw/source/core I'd prefer if such mere cosmetical changes would not be done; while inserting a blank line mostly is ok for readability, removing a blank line mostly for the same reason decreases readability. After all it boils down to personal preferences. i.e. personally I usually use two blank lines between method implementations, just because browsing the source on a quick fly in the editor is easier for the eye. How do others see this? I think there is still so much to do before arguing about spaces or other similar matter of taste details that have very little practical consequences. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: #ifdef vs #if for feature checks
On Tuesday 19 of March 2013, Thomas Arnhold wrote: On 19.03.2013 00:02, Norbert Thiebaud wrote: otoh, #pragma once is supported by all the compiler we use isn't it ? so if we are going to change it, why not use that instead. There are some discussions about that on the Internet. Most interesting: Some kind of benchmark comparison at http://tinodidriksen.com/2011/08/31/cpp-include-speed/ Looks like header guards as we have them are the best solution on gcc, but the worst for MSVC and no combination would be acceptable compared to 'plain' header guard with gcc. That's so suspicious just from considering the idea that there could possibly be any noticeable difference. I can't quite imagine how broken the implementation of #pragma once would have to be to be slower than include guards (and presumably they're both implemented the same way). I tried with 1 include files with GCC and the difference, if any, is just lost in the noise. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: icerun busts unit tests ?
On Monday 18 of March 2013, Michael Meeks wrote: - icerun $O/bin/cppunit/cppunittester $W/LinkTarget/CppunitTest/libtest_sc_ucalc.so ... || echo failed + $O/bin/cppunit/cppunittester $W/LinkTarget/CppunitTest/libtest_sc_ucalc.so ... || echo failed The 2nd produces a 'failed' but not the first. Is there some way we can propagate the failure / exit code from the spawned process through icerun ? perhaps that is fixed already, I have: $ icerun --version ICERUN 0.9.98.3 Hmm ... WEXITSTATUS fun :-/ ... I'll fix this upstream. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] various .ui fixes caught by linter tool
On Saturday 16 of March 2013, Michael Meeks wrote: Hi Jack, On Fri, 2013-03-15 at 18:32 +, Jack Leigh (via Code Review) wrote: various .ui fixes caught by linter tool Sounds really interesting :-) can we make the tool part of our build process somehow ? And do we need such a tool at all? If Glade is not capable of providing sensible defaults for spacing and similar features, cannot our code for loading the .ui files handle that? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
#ifdef vs #if for feature checks
Hello, I'd like to propose that we convert our #ifdef HAVE_FOO to #if HAVE_FOO The reason for this is that the sooner cannot tell a difference between the FOO feature not being there and any mistake (such as typo in name or #include config_xxx.h missing). As a practical example, I found out few days back that there was some code in the KDE vclplug that was never enabled, because I when writing it back then I added the necessary dmake stuff for the #define, but later vcl was converted to gbuild using gbuild patches from OOo, which didn't have it, so the feature was silently dropped. If we use the #if HAVE_FOO form, then with -Wundef any such mistake will be easily detected. It will also require adding #ifndef HAVE_FOO #define HAVE_FOO 0 #endif to config_xxx.h files, and the actual conversion, but that can be an easy hack. The problem with this change is that there still may be some cases where #ifdef is used, either because some system #defines work that way (so those would be valid but different), or people would still use #ifdef out of habbit or from AOO, which would then be broken, since the macro would be always defined. This however still should be possible to check mechanically, while I do not see a way to prevent the problem above. Opinions on this? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gmake instructions for running an individual unit test appear to be out of date
On Tuesday 12 of March 2013, Matúš Kukan wrote: On 12 March 2013 15:20, Noel Grandin n...@peralex.com wrote: to rerun just this failed test without all others, run: make /home/noel/libo/workdir/unxlngx6/JunitTest/sfx2_complex/done When it should actually say something like (I guess?) : to rerun just this failed test without all others, run: make JunitTest_sfx2_complex Certainly the current instructions don't work. Indeed, thanks. That's strange, though. The user-friendly JunitTest_* target is just a phony target depending on the .../done target, so they both should work. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] add pch support to gcc
On Monday 11 of March 2013, Michael Meeks wrote: Hi Peter, On Sun, 2013-03-10 at 21:50 +, Peter Foley (via Code Review) wrote: add pch support to gcc Sounds interesting :-) Any performance numbers and/or rough anecdotes of goodness to go with that ? I'd be interested too. I don't know about GCC (besides the rumour that PCH there is fragile), but with Clang I actually couldn't see any noticeable improvement when using PCH (barring the cases when it seems to make the compile even slower for me for some reason). With MSVC the difference is big though. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: --enable-pch option is broken?
On Sunday 10 of March 2013, Peter Foley wrote: David, Should be fixed now. you can just run ./solenv/bin/update_pch.sh to auto-regenerate all the pch files. Maybe a note should be added somewhere to run it whenever header files are moved around? That is not necessary, as it was the commit doing the change that was broken. PCH headers are not really that special, in this regard they are normal headers and could/should have been changed together with all the other changes. Such manual changes will of course be overwritten by next update_pch.sh run, but incorrect #include directives should not be left in the sources, one way or another. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] Replace rtl::O(U)String with O(U)String
On Friday 01 of March 2013, Christina Rossmanith wrote: Hi, Lubos Lunak has prepared a huge automatically generated patch removing all those ::rtl prefixes. So it is a little waste of time to prepare such patches manually. Instead maybe you could help removing RTL_CONSTASCII_(U)STRINGPARAM if you are looking for an easy entry level task? Lubos, please correct me if I'm wrong. No, this is correct, intentionally going after this change is a waste of time. Do we have it written down somewhere that this is wanted? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Grammar checker] Undocumented change in the API for LO 4
On Thursday 28 of February 2013, Olivier R. wrote: Stephan Bergmann-2 wrote How exactly do you launch LO? If by calling install/program/soffice.bin instead of install/program/soffice then the behavior is expected (soffice starts and controls soffice.bin, which needs to re-start on first start after any upgrade to cater for potential changes in bundled extensions etc.). I followed the instructions here: https://wiki.documentfoundation.org/QA/HowToBibisect I have edited the page to not recommend running the binary without the wrapper. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[PUSHED] Re: [PATCH] Translated comments from german to english
On Friday 22 of February 2013, Stefan Schick wrote: Hey, there are more translation patches to come in the next days... All of my past future contributions to LibreOffice may be licensed under the MPL/LGPLv3+ dual license. Pushed, thanks for the patch. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: WIN Tinderboxes are limping
On Tuesday 26 of February 2013, Rainer Bielefeld wrote: Hi, I'm urgently waiting for latest Master builds, but unfortunately Tinderboxes do not deliver. @6 shows a lot of red. @7 is green, but builds do not reach the server? [Bug 61482] New: MinGW: Index of /daily/master/Win-x86@7-MinGW shows several empty folders before current https://bugs.freedesktop.org/show_bug.cgi?id=61482 It would be great if someone could check and repair. The #6 tinderbox has been sending build failure mails since the instsetoo_native gbuild conversion. The #7 tinderbox apparently builds fine, but it looks like it doesn't create the .zip archives to upload, quite possibly for similar reasons. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: problem with assert statement in ustring.hxx
On Thursday 21 of February 2013, Markus Mohrhard wrote: Hey, I'm currently running the calc files throough the automatic import test and the first XLSX file that crashed was novell#349591. THe problem there is the assert statement in ustring.hxx:232 together with the vmldrawing.cxx:59. Is it correct that we can't handle \0 in a string literal or is the assert statement wrong? ustring.hxx:189 (i.e. doxygen docs for the function) : If there are any embedded \0's in the string literal, the result is undefined. Use the overload that explicitly accepts length. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: desktop/source
On Thursday 21 of February 2013, Stephan Bergmann wrote: FYI: Without having seen this mail thread, I did see the couple of recent commits to desktop/source/app/officeipcthread.cxx last night, saw that they still don't address all problems with the sending side not including NUL bytes at places where the receiving side expects them, worked on a clean-up of that code, but didn't come around yet to push it. Will happen shortly. I don't know what the code is supposed to do exactly, but just from looking at it I agree with Matteo's comments on it. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: About -std=c++98 by default in CXXFLAGS
On Thursday 21 of February 2013, julien2412 wrote: Hello, Since all compilers aren't ready for C++11, would it be relevant to include by default -std=c++98 in CXXFLAGS ? The goal is, for beginners like me, to avoid submitting things like https://gerrit.libreoffice.org/2302 :-) It is intentional that some C++11 features are used if available, in order to provide various benefits (SAL_OVERRIDE for example). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] minutes of ESC call ...
On Thursday 21 of February 2013, Michael Meeks wrote: Hi Lubos, On Mon, 2013-02-18 at 15:01 +0100, Lubos Lunak wrote: Heh; so do not merge is the equivalent of do not submit but much clearer and friendlier, fits inside the text limit. Huh? Friendlier? Clearer??? It says pretty much the same. It's hard for me to unwind the overlapping meanings here; do you mean: it was not worth changing it ? (to which I disagree), or that it is not sufficiently friendier ? (which could of course be improved), or ? I was refering to the one sentence quoted above, claiming that in do not merge and do not submit one is clearer, friendlier, or even different at all (given that gerrit seems to use submit for what I would call merge). All I'm saying is that 'do not merge' is vague enough to not say what it in fact does or where the line between -1 and -2 is, and 'I disagree with the change, needs discussion first' or similar is clearer there and still reasonably short. So can you propose a better string ? how about this one: block merging for now Which is brief, open-ended, uses merge not submit and describes the function of -2 perhaps better to both reviewer and reviewee. This is again vague enough to apply to -1 as well (-1 is also block merging for now). I did propose already one string I think is better, but if you want to put it this way, then it should be e.g. block merging until objections are cleared or so. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: desktop/source
On Tuesday 19 of February 2013, Julien Nabet wrote:
desktop/source/app/officeipcthread.cxx |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
New commits:
commit 7d9a7020eb5777f5baaa8beb6af5db9a8796c7c9
Author: Julien Nabet serval2...@yahoo.fr
Date: Tue Feb 19 21:35:19 2013 +0100
Good way to initialize array of char char var[NB]={0}
See http://stackoverflow.com/questions/1920430/c-array-initialization
Change-Id: Ibbbe249684dc34f8aa44868c99cc1344a2928ade
diff --git a/desktop/source/app/officeipcthread.cxx
b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
--- a/desktop/source/app/officeipcthread.cxx
+++ b/desktop/source/app/officeipcthread.cxx
@@ -497,23 +497,17 @@ OfficeIPCThread::Status
OfficeIPCThread::EnableOfficeIPCThread() else if( pThread-maPipe.create(
aPipeIdent.getStr(), osl_Pipe_OPEN, rSecurity )) // Creation not
successfull, now we try to connect {
osl::StreamPipe aStreamPipe(pThread-maPipe.getHandle());
-char pReceiveBuffer[sc_nCSASeqLength + 1];
+char pReceiveBuffer[sc_nCSASeqLength + 1] = {0};
int nResult = 0;
int nBytes = 0;
int nBufSz = sc_nCSASeqLength + 1;
// read byte per byte
-pReceiveBuffer[0] = 0;
while ((nResult=aStreamPipe.recv( pReceiveBuffer+nBytes,
nBufSz-nBytes))0) { nBytes += nResult;
if (pReceiveBuffer[nBytes-1]=='\0') {
break;
}
}
-/* make sure the buffer is \0 terminated */
-if (nBytes 0)
-{
-pReceiveBuffer[nBytes-1] = 0;
-}
Did you really mean to remove this part?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-commits] core.git: desktop/source
On Wednesday 20 of February 2013, julien2412 [via Document Foundation Mail
Archive] wrote:
Lubos Lunak wrote
On Tuesday 19 of February 2013, Julien Nabet wrote:
diff --git a/desktop/source/app/officeipcthread.cxx
b/desktop/source/app/officeipcthread.cxx index 8db7946..445ccb4 100644
--- a/desktop/source/app/officeipcthread.cxx
+++ b/desktop/source/app/officeipcthread.cxx
@@ -497,23 +497,17 @@ OfficeIPCThread::Status
OfficeIPCThread::EnableOfficeIPCThread() else if(
pThread-maPipe.create( aPipeIdent.getStr(), osl_Pipe_OPEN, rSecurity ))
// Creation not successfull, now we try to connect {
osl::StreamPipe aStreamPipe(pThread-maPipe.getHandle());
-char pReceiveBuffer[sc_nCSASeqLength + 1];
+char pReceiveBuffer[sc_nCSASeqLength + 1] = {0};
int nResult = 0;
int nBytes = 0;
int nBufSz = sc_nCSASeqLength + 1;
// read byte per byte
-pReceiveBuffer[0] = 0;
while ((nResult=aStreamPipe.recv( pReceiveBuffer+nBytes,
nBufSz-nBytes))0) { nBytes += nResult;
if (pReceiveBuffer[nBytes-1]=='\0') {
break;
}
}
-/* make sure the buffer is \0 terminated */
-if (nBytes 0)
-{
-pReceiveBuffer[nBytes-1] = 0;
-}
Did you really mean to remove this part?
Hi Lubos,
Yes I meant it, why? Is it wrong?
if pReceiveBuffer is initialized with 0 for the (sc_nCSASeqLength + 1)
elements thanks to = {0} initialization, what obvious thing did I miss?
Sorry, I did not realize that = { 0 } actually clears the rest of the array.
And I do not quite understand why clearing an entire array is supposed to be
a good way to initialize it when just setting the last one to 0 is enough.
Why pReceiveBuffer[nBytes-1] = 0; would need to stay?
If I'm reading the code correctly, nBytes-1 is not the position after the
read data, but the last read item. Which should mean that the repeated recv()
may rewrite all the 0's from the initialization. That rather begs the
question why it changes the last read item instead of terminating it, so the
code may have been already broken to begin with.
--
Lubos Lunak
l.lu...@suse.cz
--
View this message in context:
http://nabble.documentfoundation.org/Re-Libreoffice-commits-core-git-desktop-source-tp4038892p4038899.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
Re: New test to automatically importing all bugzilla documents
On Monday 18 of February 2013, Markus Mohrhard wrote: Currently I plan to run the script every 2 or 3 weeks on a TDF server and report the documents back. Hopefully some of these tasks can be automated by time and we only need someone to start the build. There are several open tasks and some things I noticed would be nice to have. I list them here to make is easier for others to step in and implement some of them or add their own ideas: TODOS: * Calc and Draw/Impress document import * Script allowing to manage running several scripts in parallel: In therory this is a task that can be done in perfect parallelisation and it would help with the time needed as we have alone more than 15000 writer documents, at least more than 8000 calc documents ... How long does it take to run the complete test? I'm asking because the practice with tinderboxes is often that if one of them collects a larger number of commits between two rebuilds, then if a breakage shows up, nobody seems to feel responsible. So, if possible, I think it'd be better if this was run more often than 2-3 weeks, possibly as another tinderbox running the check. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Gdb support for exceptions (Re: using backtrace() in exception throwing?)
On Monday 18 of February 2013, Tom Tromey wrote:
Lubos == Lubos Lunak l.lu...@suse.cz writes:
Lubos This could be very useful ('catch throw' is so cumbersome in
Lubos gdb),
Is there something we could do to improve it?
I don't know how much control gdb over exception handling has, so I don't
know :).
What I was refering to was the problem that if a catch block catches an
exception, it's often difficult to find out where it actually came from.
Using 'catch catch' doesn't show where it originated (unless I missed a
non-obvious way). And if the exception propagated out of complex nesting of
function calls, then 'catch throw' may trigger a number of times for
exceptions that will be handled elsewhere.
So it would be useful to have some kind of 'catch throw-for-this-catch', or
at least some 'show exception' (mentioned in 'help catch') that would show
where the currently propagating exception started.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
(KDE4) file dialog broken (Re: [Libreoffice-commits] core.git: 14 commits - basctl/source cui/source dbaccess/source desktop/source dtrans/Library_dnd.mk dtrans/Library_ftransl.mk dtrans/Library_sysdt
On Tuesday 12 of February 2013, Noel Grandin wrote: commit 4b51374a7021d52f7f1be1861e2ee6a011b30ecd Author: Noel Grandin n...@peralex.com Date: Tue Feb 12 09:23:05 2013 +0200 fdo#46808, Adapt ui::dialogs::FilePicker UNO service to new style Change-Id: I1cafbfc53994e5d74241042dbd1d292ddbda67d5 I see rather serious breakage with the KDE4 file dialog on master, automatic file extension adding doesn't work (the checkbox doesn't even show) and there's no existing file overwrite warning. From what I can tell, at least KDE4FilePicker::addCustomControl() doesn't get called anymore. As there have been no other changes in the area, I suspect this commit. Could you please have a look? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: using backtrace() in exception throwing?
On Sunday 17 of February 2013, Noel Grandin wrote:
Hi
Background: I'm looking at bug reports, and the messages are generally only
marginally useful, because I generally have no idea where the original
exception was actually thrown from.
Sometimes the message in the exception will narrow it down a little, but
that still often leaves a lot of likely places, and often the information
I'm really interested in, is a few frames worth of callng stack
information.
What would be the costs of calling backtrace()
http://www.gnu.org/software/libc/manual/html_node/Backtraces.html
in the exception base class, storing a few frames worth of data,
and then modifying the exception printing code to call
backtrace_symbols()
when writing out the exception?
For me personally, this would really speed up tracking down the source of
bugs.
This could be very useful ('catch throw' is so cumbersome in gdb), but I
think the first thing to check is if it would actually work. Last time I
checked, recent features like -fvisibility make backtrace() very often
generate call traces that are next to useless.
If it turns out the data actually is useful, then also
- you can't simply modify the Exception base class, because it's part of the
URE, so it should stay binary compatible. It'd need to be stored in the
message (which is a question if it's a good or bad idea) or some other way
would need to be found.
- it'd be good to know how fast/slow the function is. Exceptions generally
aren't very fast, but if the function was called every time in the ctor, then
depending on fast it is that might make it debug-build-only feature.
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] minutes of ESC call ...
On Saturday 16 of February 2013, Michael Meeks wrote: On Fri, 2013-02-15 at 21:50 +0100, Lubos Lunak wrote: PPS: please do not shoot the messenger... I'm not shooting the messenger, I'm telling him that the way it is he'll sooner or later need to go on more errands. Heh; so do not merge is the equivalent of do not submit but much clearer and friendlier, fits inside the text limit. Huh? Friendlier? Clearer??? It says pretty much the same. We need to be -very- polite, respectful and encouraging to those who have managed not only to build LibreOffice, but setup a gerrit account, change the code and finally submit it to gerrit. Potentially one reviewer might transiently not like the approach enough to block it - that's fine, but IMHO we need to make that message more appropriate - which AFAICS is now done :-) Are people really contesting do not merge ? No, people are not really contesting it. Apparently finding all the places around LO that are poorly named or plain misleading is an effort for a small army, and convincing people of an improvement for a somewhat larger army, and I've got things to do. All I'm saying is that 'do not merge' is vague enough to not say what it in fact does or where the line between -1 and -2 is, and 'I disagree with the change, needs discussion first' or similar is clearer there and still reasonably short. If so, there is an ESC call next week to discuss it of course, and you're welcome to put your points. Oh come on. Do I need to write down a design document too? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] minutes of ESC call ...
On Friday 15 of February 2013, Norbert Thiebaud wrote: On Fri, Feb 15, 2013 at 9:55 AM, Michael Meeks michael.me...@suse.com wrote: On Fri, 2013-02-15 at 16:16 +0100, Eike Rathke wrote: + Do not submit - I would prefer this not to be committed in this state. While the rewording for -1 is fine with me and in general also better describes why a -1 is given, I'm not satisfied with the -2 Do not I think we changed -2 to do not merge instead after some private discussion with Norbert :-) I think the consensus is that we shouldn't be using -2 unless there is something drastically wrong. For the record: Although -1 'description' has been toned down, it is _still_ the preferred and recommended way to express that a patch should not be push as is. -2 is essentially a veto on the 'idea' of the patch. -1 get reset when a new version of a patch is uploaded, whereas -2 are 'sticky'. That should be made more obvious in the wording then. I normally use -1/-2 as the reverse of +1/+2 and the current 'do not merge' is vague enough to mean anything in that direction. It should include 'I disagree with the change' or similar. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] minutes of ESC call ...
On Friday 15 of February 2013, Norbert Thiebaud wrote: On Fri, Feb 15, 2013 at 12:36 PM, Lubos Lunak l.lu...@suse.cz wrote: That should be made more obvious in the wording then. I normally use -1/-2 as the reverse of +1/+2 Well, there are not symetrical: Yes, I get that now. I didn't before, and that'll happen for more people, because it's non-intuitive. I guess the problem is the balance between 'clarity' and perceived 'abruptness'. The 'text' associated with the value has been tweaked in favor of the later... but Committers should really use the values and they 'abrupt' meaning to decide when to use them. Indeed, there's always the option of documenting why it's non-obvious somewhere where half of the people'll never find it, rather than simply making it easy. PPS: please do not shoot the messenger... I'm not shooting the messenger, I'm telling him that the way it is he'll sooner or later need to go on more errands. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice-qa] minutes of ESC call ...
On Friday 15 of February 2013, Bjoern Michaelsen wrote: On Fri, Feb 15, 2013 at 02:30:33PM -0600, Norbert Thiebaud wrote: -2 means I oppose the 'idea' of the patch. no amount of tweaking can address my concerns.. one could use a -2 on a technically perfectly valid/correct patch that remove dbaccess from libreoffice for instance. -2 is effectively a veto because it is a sticky state that remain even if a new version of the patch is uploaded... so as long as there is a -2 one cannot Submit the patch, short of hacking gerrit or pushing the patch directly to master, by-passsing gerrit-review altogether. Can we maybe make the text: There are concerns about the intend or implications of this change that need clarification. Please do not merge this before consensus is reached by discussion. That's rather long for a radiobutton text, isn't it? Besides, at least the first sentence should be superfluous, as -2 should have an accompanying comment explaining why from whoever gave it. Having a 'please' makes this much more friendly (although as Norbert said to push the change you would need to bypass gerrit anyway, but we dont have to rub that it) and 'consensus'/'discussion' gives a clear road on how to proceed for the contributor. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Make help
On Saturday 09 of February 2013, Gergő Mocsi wrote: Dear Developers, I'm trying to build LibreOffice, downloaded whit Git. I'm a trainee in Hugary. I get this error with make: ... [build CXX] UnpackedTarball/graphite/src/TtfUtil.cxx [build CXX] UnpackedTarball/graphite/src/UtfCodec.cxx [build LNK] StaticLibrary/libcodemaker_java.a [build JCS] Jar/unoloader [build C ] bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c [build C ] bean/native/unix/com_sun_star_beans_LocalOfficeWindow.c [build PAT] beanshell javac: error: unrecognized command line option ‘-source’ javac: error: 1.5: No such file or directory javac: error: unrecognized command line option ‘-target’ javac: error: 1.5: No such file or directory make[1]: *** [/home/stalker08/git/libo/workdir/ unxlngi6.pro/JavaClassSet/Jar/unoloader/done] Error 1 make[1]: *** Waiting for unfinished jobs Running 'make VERBOSE=1' will show you also the executed commands, so you can find the failing one and debug what the problem is. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
SAL log areas description (Re: [Libreoffice-commits] core.git: sal/inc)
On Tuesday 05 of February 2013, Stephan Bergmann wrote: sal/inc/sal/log-areas.dox |1 + 1 file changed, 1 insertion(+) New commits: commit 98146763e7ad954c647da018d5db451952caadfc Author: Stephan Bergmann sberg...@redhat.com Date: Tue Feb 5 17:32:13 2013 +0100 New log area (for previous commit) Change-Id: I9cc1fdfa7acad6c233b68eb23dea39c58d4cecaa diff --git a/sal/inc/sal/log-areas.dox b/sal/inc/sal/log-areas.dox index 83440bd..7f3f4a4 100644 --- a/sal/inc/sal/log-areas.dox +++ b/sal/inc/sal/log-areas.dox @@ -57,6 +57,7 @@ certain functionality. @li @c desktop @li @c desktop.deployment +@li @c desktop.migration Note that the idea is that next to the area name there is a very short description of it (especially for the non-obvious ones). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Adding/modifying UI strings
Hello,
do we have somewhere documentation on how UI strings are handled?
Specifically, I'd like to do something like in the attachment, adjusting the
tooltip for the font combo in the toolbar. Its tooltip text is hardcoded in
officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu . How do
I get the UI strings for the usage in the code (i.e. including l10n) and,
since I assume that includes removing it from the .xcu file, will something
else be affected by that?
--
Lubos Lunak
l.lu...@suse.cz
void SvxFontNameBox_Impl::CheckAndMarkUnknownFont( const OUString fontname )
{
if( fontname == GetText())
return;
GetDocFontList_Impl( pFontList, this );
// If the font is unknown, show it in italic.
Font font = GetControlFont();
if( pFontList != NULL pFontList-IsAvailable( fontname ))
{
if( font.GetItalic() != ITALIC_NONE )
{
font.SetItalic( ITALIC_NONE );
SetControlFont( font );
SetQuickHelpText( OUString( Font Name ));
}
}
else
{
if( font.GetItalic() != ITALIC_NORMAL )
{
font.SetItalic( ITALIC_NORMAL );
SetControlFont( font );
SetQuickHelpText( OUString( Font Name. Current font is not
available and will be substituted. ));
}
}
}
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: deps etc.
On Thursday 31 of January 2013, Michael Stahl wrote: On 31/01/13 08:01, Michael Meeks wrote: Hi guys, I was digging for the latest information on the size cost of our dependencies, and was interested to see things like: workdir/unxlngi6.pro/Dep/LinkTarget/Library/libfwklo.so.d contain only lots of: /data/opt/libreoffice/master/workdir/unxlngi6.pro/CxxObject/framework/sou rce/accelerators/globalacceleratorconfiguration.o :$(gb_Helper_PHONY) /data/opt/libreoffice/master/workdir/unxlngi6.pro/CxxObject/framework/sou rce/accelerators/keymapping.o :$(gb_Helper_PHONY) ... It seems some clever person deferred the dependency generation until an incremental build is done (?) :-) I assume that accelerates the straight-through build too (?). actually it makes a full build from scratch slower, expecially on Windows writing thousands of .d files takes several minutes. It's not as bad when using the patched make (and it's slow because of process forking, making concat-deps a make builtin would presumably make that as fast as on Linux). the advantage is that you can do a partial build; with the old way of doing things every object file in every module was built to include the .d file even when you only want something like make comphelper.all. Are you sure about this? From what I remember when doing the builtins for make, all .d files are first created with dummy content, so having or not having the LinkTarget .d files doesn't change anything there. As far as I understand it, the purpose of LinkTarget .d files is reading less files - gbuild includes only LinkTarget .d, not object .d files . And LinkTarget .d files are dummies (just like object .d files) during the first build, during that build object .d files are updated while building the targets, and before second build LinkTarget .d files are created from object .d using concat-deps. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: deps etc.
On Thursday 31 of January 2013, Michael Stahl wrote: i haven't measured it but i guess the majority of the problem is first writing the Object .d files, I have. Replacing concat-deps calls with mkdir+touch (for which there is a builtin) cuts the [build DEP] phase in tail_build to almost a half. But even as it is, the time spent that way is insignificant compared to the whole of the build. of which there are a lot more than LinkTarget .d files. which should make it easier because iirc object .d files are just echo foo: .PHONY foo.d while concat-deps has a bit of LO-specific logic (rewriting external headers to .done files, which is necessary for correctness of incremental builds) that doesn't make sense as a make builtin. Although concat-deps is not a trivial code, it's not that complicated either, and the builtins are already LO-specific code anyway. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: lots of .tests output during make hides error messages
On Monday 28 of January 2013, Michael Stahl wrote: On 28/01/13 09:23, Winfried Donkers wrote: The tests-output continues after a compile error. 'Long ago', there was a build_err.log produced in which errors could be searched, but that is no longer generated. that annoying test spew is fixed on master with 7cf3b1ffcb8dc6dbb643e12febe5415972a7c2fa and i have no idea what build_err.log is (or was). build_error.log used to be a file with build output from the module where build failed. Given that today pretty much everything is built from tail_build, it would be equivalent to 'make 21 | tee build_error.log' . -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [REVIEW 4-0, 4-0-0] ... sdremote foo ...
On Monday 28 of January 2013, Thorsten Behrens wrote: Michael Meeks wrote: I'd love to see it in -4-0 and -4-0-0 if possible; ideally tested on Windows too ... Pushed to -4-0, two more reviews missing for -4-0-0 - would love someone on windows to give it a spin. It doesn't even build on Windows because of a stray SAL_CALL, see 668bec99efb4a15ca0fe364fa3c217baba8a6f27 . -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Tinderbox failure, Win-x86@6, MASTER, last success: 2013-01-23 14:20:35
On Wednesday 23 of January 2013, Andras Timar wrote: On 2013.01.23. 16:24, Tinderbox wrote: checking for a x64 compiler and libraries for 64-bit Explorer extensions... found So we set BUILD_X64 to TRUE. Later we will need 64-bit CRT files for these extensions. configure: error: Failed to copy x64 merge modules Error running configure at ./autogen.sh line 201. Configure did not find MSM file 64-bit CRT. Did you have it? microsoft_vc100_crt_x86_x64.msm No, it is not there. There is only Microsoft_VC100_CRT_x64.msm and Microsoft_VC100_CRT_x86.msm . Are you sure it should be _x86_x64? Also, you changed the warning to an error, but given the vague log message, I don't know if that's right or a mistake. Before my patch the 64-bit MSM file name was wrong in configure, therefore it was not copied to solver, and installer creation failed. Also it did not work in VC90 case. So why is this not said in the commit log message? As it is, there was no way to find out what your commit was actually about, other than the obvious. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Create OUString and OString number(*) methods.
On Monday 21 of January 2013, Stephan Bergmann wrote: On 01/21/2013 06:05 PM, Lubos Lunak wrote: On Monday 21 of January 2013, Stephan Bergmann wrote: While the gotcha of printing a large unsigned value as a negative value thanks to calling rtl_ustr_valueOfInt64 internally can be a problem in some call sites, others might be fine with producing just some sort of informative value and won't mind generating negative output. If we would want to force the latter into using explicit casts to sal_Int64 (in case they don't do already anyway), wouldn't it be better to make the relevant large unsigned overloads = delete? That would mean blocking out all the values of the type, not just the problematic ones. Given that a number of system typedefs are internally unsigned integers despite all the signed vs unsigned trouble this causes, usage of the type is much more likely than usage of a problematic value of the type, so IMO it makes more sense to cater to realistic usage rathen than handle more problematic but next to impossible scenarios. I was thinking about scenarios like passing a sal_uIntPtr to rtl::OUString::number. If that sal_uIntPtr is derived from a pointer in the obvious way, it could, depending on platform, be highly likely that it triggers the assert. I did not think of that. It's probably still rather unlikely, but at least realistically possible. I think the simplest solution is just adding another valueOf helper that handles unsigned 64bit integer. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: About parenthesis problem in testintrosp.cxx
On Saturday 19 of January 2013, julien2412 wrote: Hello, Here's a problem in stoc/test/testintrosp.cxx, line 182 aRetStr = aRetStr + OUString( OUString( (Typ: ) ) + xIdlClass-getName() + OUString()); By taking a look at git history, I found that it was: aRetStr = aRetStr + OUString( OUString(RTL_CONSTASCII_USTRINGPARAM( (Typ: )) ) + xIdlClass-getName() + OUString(RTL_CONSTASCII_USTRINGPARAM())); before 02/06/2012 Presumably whoever did this used regular expressions to do the change and didn't get this one quite right. If testintrosp.cxx is still used, an idea how to make this line more clear (and perhaps removing the double use of OUString)? aRetStr += (Typ: + xIdlClass-getName() + ); -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PUSHED] Create OUString and OString number(*) methods.
On Monday 21 of January 2013, Stephan Bergmann wrote: On 01/18/2013 05:20 PM, Luboš Luňák (via Code Review) wrote: https://gerrit.libreoffice.org/1625 I must admit that I didn't review the later revisions of that patch while in progress at gerrit, That's actually from me afterwards, when fixing a problem on 32bit (or was that 64bit). but now the lines assert( ll = SAL_MAX_INT64 ); // valueOfInt64 may not be able to handle the highest bit in the various number() function definitions make me wonder. That implies that clients of those functions need to ensure to call them with small-enough arguments. Is that what we want? I think small-enough gives the wrong idea, it should be rather, say, not-insanely-large arguments or so :). And despite the smiley, I'm actually serious. This can trigger only when needing the topmost unsigned bit of 64bit value, which is a 20 digit decimal number, and more importantly those are values at the very limit of the supported integer range - there's nothing larger than long long. So even if there will be a legitimate case when unsigned long long will be needed for the extra bit (which is pretty unlikely already), a lot of care will be needed to handle it correctly (e.g. involving anything signed will be potential trouble). That'll make this problem just a little bit more of trouble. While the gotcha of printing a large unsigned value as a negative value thanks to calling rtl_ustr_valueOfInt64 internally can be a problem in some call sites, others might be fine with producing just some sort of informative value and won't mind generating negative output. If we would want to force the latter into using explicit casts to sal_Int64 (in case they don't do already anyway), wouldn't it be better to make the relevant large unsigned overloads = delete? That would mean blocking out all the values of the type, not just the problematic ones. Given that a number of system typedefs are internally unsigned integers despite all the signed vs unsigned trouble this causes, usage of the type is much more likely than usage of a problematic value of the type, so IMO it makes more sense to cater to realistic usage rathen than handle more problematic but next to impossible scenarios. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
-Wsign-promo (Re: [BUILD FAILS DEBUG MODE] with test_strings_valuex.cxx)
On Friday 18 of January 2013, julien2412 wrote: Hello, On pc Debian x86-64 with master sources after having runned make clean, I've got this: /home/julien/compile-libreoffice/libo/sal/qa/rtl/strings/test_strings_value x.cxx: In instantiation of ‘void testInt() [with T = rtl::OUString]’: /home/julien/compile-libreoffice/libo/sal/qa/rtl/strings/test_strings_value x.cxx:77:28: required from here /home/julien/compile-libreoffice/libo/sal/qa/rtl/strings/test_strings_value x.cxx:48:5: error: passing ‘unsigned char’ chooses ‘int’ over ‘unsigned int’ [-Werror=sign-promo] -Wsign-promo is a rather pointless warning these days (the section in the gcc manpage is a funny read and not only because it talks about Cfront). I've added more overloads to silence it, but I rather wonder why we have this explicitly enabled at all. My hypothesis is like this: - the idea behind the warning is just nonsense (who cares to what integer type the value is promoted) - but it incidentally triggers when passing bool to SvStream, because it doesn't have any overload for operator(bool), and int is chosen over unsigned char AKA sal_Bool , so Caolan added it in e8bbb76827dd7a0e30d7d1db34a812a84d85f390 - if SvStream gets overload for bool, the warning can be dumped Or am I missing something there? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Unit test failing on some machine
On Wednesday 16 of January 2013, Pierre-Eric Pelloux-Prayer wrote: Hi all, I recently added a new unit test to Writer docx test suite. It's quite simple: a single page document with one table filling all the page. The test then verifies that after import/export the document has indeed 1 page. (see sw/qa/extras/ooxmlexport/ooxmlexport.cxx and sw/qa/extras/ooxmlexport/data/1-table-1-page.docx) The problem is: on some machine, for instance Linux-openSUSE-x86@18-Clang Tinderbox, this test is failing like this: For the record, I've commented out calling this specific test, until it gets fixed. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: fdo#38838 - Removal/Replacement of the String/UniString with OUString once and for all.
On Tuesday 15 of January 2013, Norbert Thiebaud wrote:
On Tue, Jan 15, 2013 at 12:26 PM, Eike Rathke er...@redhat.com wrote:
For example, a
if (String.Search(...) == STRING_NOTFOUND)
replaced with
if (OUString.indexOf(...) == STRING_NOTFOUND)
will not work.
A even more tricky case is this:
String's functions usually deal silently with out-of-buffer
stituations, like asking to delete a part that overflow or even is
entirely outside a string.
and Search return as indicated above STRING_NOTFOUND that is 0x
i.e the max unsigned value of Xub_StrLen
so some code use this 'feature' to code something like:
pos=String.Search('#')
String.Erase(pos)
IOW: automated conversion is _not_ an option. String = OUString
convertion have to be carefully audited by hand,
What you wrote above is AFAIK not written down anywhere, not in the wiki
page, not in the (non-existent) String class documentation, so any bets on
what the reality is?
Could you please add these cases to the strings wiki page?
--
Lubos Lunak
l.lu...@suse.cz
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Monday 14 of January 2013, Noel Grandin wrote: OK, so I tried modifying my patch so that we have number(sal_Int64) number(float) number(double) At which point my unit tests fail when passing a 32-bit value in because the compiler does not know which overload to use - this is on 64-bit Ubuntu using gcc 4.7.2 I can't add a sal_Int32 variant because I suspect that will make the original problem come back, which was where we started, with all the static_castsal_Int32 stuff. Any ideas? You need to add overloads, for anything except signed/unsigned char/short: On Friday 11 of January 2013, Lubos Lunak wrote: So, based on this, the best solution to the problem that I can see is creating fromNumber() or number() , overloaded for all signed/unsigned int/long/long long types and all floats because of the lame language ambiguity. The original valueOf() can be wrapped inside #ifndef LIBO_INTERNAL_ONLY after LO is moved away from this problematic function to keep it only for external backwards compatibility, while LO itself will no longer have it. So rather than bitting us in small ways every now and then, the (possibly smaller in the end, if it wasn't for this discussion) effort is spent now, and the effort is not that big (all the duplicates can be only 6 lines, 2 for doxygen @overload @since, 4 for code forwarding to the overload taking the largest type). -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Friday 11 of January 2013, Noel Grandin wrote: On 2013-01-10 15:55, Lubos Lunak wrote: - There's no need for valueOfChar(). There is already OUString ctor from sal_Unicode, so the valueOf() overload for it is just making an obvious thing complicated. Code using it can be converted to use the ctor instead. I've already dealt with why we can't use the constructor. git grep String::valueOf.*Unicode says we do in fact appear to need such a method. OUString has a ctor that takes sal_Unicode and creates OUString. Your valueOfChar() proposal would add a function that takes sal_Unicode and creates OUString = complete duplicate, the ctor can be used instead. I do not even see API reasons to have it, it's different from the other valueOf() cases in that in the character case there's conceptually actually no conversion, so there's no need for consistency. - When more or less deprecating valueOf() this way, it has also float overloads, so something should be created for those too. Fair enough. We don't have many of them, but for completeness sake, it makes sense. Yes. They would be needed, if the original valueOf() is deprecated/removed. - I'm still not sold on the naming, OUString::valueInt() doesn't say much and OUString::valueOfInt() feels cryptic. Can we please use something obvious that doesn't need decyphering, such as , such as OUString::number() or OUString::fromInt() (as much as I still don't like the idea of harcoding the irrelevant type information in the name)? I think valueOf() is fine, but then I do a lot of programming in Java :-) But whatever, if the C++ people prefer another name, then so be it. I think I might know why we don't understand each other. There is a code problem and you've created new code to solve the problem, and, code-wise, your patch is correct. The catch is though that I'm not looking at this from the code point of view, but from the API point of view, and it is possible to have good code that nevertheless implements API that is not good. IOW, I'm not saying that your code is wrong, because I'm thinking one level up and saying that the problem you've solved wouldn't even exist at all if the API was done better. The purpose of libraries is to focus a solution to a problem in a single place and provide means to solve the problem. And a good library, among other things, solves as much as possible of the problem itself, making it easy for the library user. To take an example from elsewhere, cars have a button for switching the lights on, it has probably a shining bulb or similar symbol on it, and when the driver presses it, it switches the lights on. And that's really all the driver needs to know and cares about. The symbol on it doesn't show the battery that powers the lights or any other implementation details, nor does the button require that you press it with a specific finger. It's made as simple as possible and implementation details are hidden. The same way, good API should strive to make things as simple as possible and hide implementation details. Following this, what the developer really wants is to create a string from a number. So OUString::fromNumber() seems like the obvious name for it. And it should take numbers of any kind, as it doesn't really matter, in the common case give me this number as a string is conceptually the same whether the number is a long or float. So that should be the optimal API for the functionality. Now some real-world issues may enter into play, e.g. when the number is integer, it may be useful to specify the radix, which doesn't make much sense with floats; valueOf() has a default argument there, so it can be handled the same way. Another thing, since valueOf() is often used when constructing strings, OUString::fromNumber() may be considered a bit too long and it may be acceptable trade-off to shorten it to OUString::number(). Anything less, such as leaking irrelevant implementation details and forcing the developer to explicitly specify the underlying type, is settling on sub-optimal API that moves part of the implementation burden on the user of the library. So, based on this, the best solution to the problem that I can see is creating fromNumber() or number() , overloaded for all signed/unsigned int/long/long long types and all floats because of the lame language ambiguity. The original valueOf() can be wrapped inside #ifndef LIBO_INTERNAL_ONLY after LO is moved away from this problematic function to keep it only for external backwards compatibility, while LO itself will no longer have it. So rather than bitting us in small ways every now and then, the (possibly smaller in the end, if it wasn't for this discussion) effort is spent now, and the effort is not that big (all the duplicates can be only 6 lines, 2 for doxygen @overload @since, 4 for code forwarding to the overload taking the largest type). Win/win. And if this is still not convincing
Writing new Clang plugins (Re: replacing OUString::valueOf(static_castsal_Int32) ??)
On Friday 11 of January 2013, Jean-Noël Rouvignac wrote: 2013/1/10 Lubos Lunak l.lu...@suse.cz Unless all you want to convert is only places which do the explicit cast, this will need a (fairly simple) Clang plugin. Sure, if you feel like writing one. Actually, I'd prefer to write a howto about that first, whenever I get to doing that, so that I don't have to write every single plugin. Such a plugin will be still much simpler than a regexp or any other way. Please do, I would be interested in that. Maybe you already have some URLs to share on this subject? I'm not aware of anything very useful at this point. The existing tutorials that can be found mostly say how to create a plugin itself, but not much more. Since I've already created a plugin for LO, now writing a plugin in LO actually means adding another class with new functionality to the one LO plugin, so what is needed now is documentation on the internal Clang API that is used for writing the functionality. That API is documented at http://clang.llvm.org/doxygen/ , but I understand that throwing that at somebody unfamiliar with it must be scaring (hint: the most commonly needed is the class hiearchy starting from clang::Stmt, as those are classes representing the program in the AST). I myself actually find it easier to read directly doxygen docs in the includes, mostly Decl*.h Expr*.h Stmt*.h in include/clang/AST/ . The API is however rather intuitive and straightforward, once one gets into it. And finding out how a particular piece of code is represented in the AST is a matter of compiling it with 'clang++ -Xclang -ast-dump' and matching the output to Clang classes. If you want to give it a try now, look under compilerplugins/ in the LO sources. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Failure to build 3.6 branch
On Thursday 10 of January 2013, Alexander Thurgood wrote: Le 10/01/13 12:24, Caolán McNamara a écrit : Hi Caolán, I wonder if that file has grown too big for your toolchain. Try splitting up the file into two and see if you can get it to compile that way. Hmm, if I try and build just unotools, I get the following error when building unotools_inc : gb_Deliver-deliver : file does not exist in solver, and cannot be delivered : /Users/Shared/Repos/LO/core/solver/unxmacxi.pro/lib/libcomphelpgcc3.dylib make unotools.all -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
WITH_MOZAB4WIN needing msvc?80.dll
Hello, as far as I understand it, the current problem with W2008R2_20-With-Symbol-Bytemark-Hosting [*] , is caused by needing specifically *80 msvc dlls for WITH_MOZAB4WIN (grep under scp2 for the only 'msvcp' there). Does somebody have any idea why it's specifically this version and if it's really needed this way? It dates back to 2009, so repo history is as usually useless. [*] ERROR: The following files could not be found: ERROR: File not found: Microsoft.VC80.CRT.manifest ERROR: File not found: msvcp80.dll ERROR: File not found: msvcr80.dll -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: FYI: Make for faster windows build
On Thursday 10 of January 2013, Noel Grandin wrote: I think the WINDOWS32 #define is for building a native windows binary. (There is also stuff in there for building under AmigaOS and DOS, the gnumake code is pretty grotty) The cywin stuff is probably using a #ifdef CYGWIN. I don't see anything cygwin-specific there, except for handling the cygwin shell. And I expect the WINDOWS32 code should work just fine for cygwin make as well. You can't use the Win32 API as-is under cygwin, because you need to call cygpath() on the path argument first to convert from the cygwin filesystem structure to the Win32 representation. i.e. from /cygdrive/C/libo to C:\libo I have not done this, apparently make always gets windows paths when building LO, or does somebody have a problem with this (builtins have (Built-in) prefix when doing verbose make)? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: FYI: Make for faster windows build
On Thursday 10 of January 2013, Michael Meeks wrote: On Wed, 2013-01-09 at 20:01 +0100, Lubos Lunak wrote: Looks what I found under the tree! Faster make for Cygwin. Granted, I had put it there first, but still nice. Nice work ! :-) I'd love to see a configure option: --with-custom-gnumake that does the git clone, pre-builds, and uses our own gnumake (with the speedups). If I'm not mistaken, we need our custom make on Windows anyway, since LO build fails with the cygwin one for some reason (may or may not be our fault, I don't know). Moreover, this is most probably not going to work anyway, since it's the developer who runs the make, not the buildsystem (eventually, after we get rid of dmake). And Makefile.top has shown that make forwarding does not quite work as it should. Did you have any joy getting the fixes up-stream to gnumake ? ;-) I have not tried, the commands are rather LO-specific in some cases, so we need a patch anyway. I also consider it to be a bit of an ugly hack. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Thursday 10 of January 2013, Noel Grandin wrote: On 2013-01-09 19:58, Michael Meeks wrote: At least in my mind :-) but we're starting to bike-shed here... I didn't see anyone volunteering to do the actual batch cleanup there ;-) Regards, Michael. Created a proof-of-concept patch along with some unit tests and pushed to gerrit: https://gerrit.libreoffice.org/#/c/1625/ Can we please keep the discussion still here? Gerrit may be fine for pointing out technical details in the code, but it's not very suitable for discussions about anything beyond that. - There's no need for valueOfChar(). There is already OUString ctor from sal_Unicode, so the valueOf() overload for it is just making an obvious thing complicated. Code using it can be converted to use the ctor instead. - It's a question if we really need 'OUString::valueOfBool( foo )' instead of simply 'foo ? OUString( true ) : OUString( false )' (such a pity the string literals handling doesn't allow foo ? true : false' ). I wonder how many places in the code really need to convert a boolean to the hardcoded english string representation. - When more or less deprecating valueOf() this way, it has also float overloads, so something should be created for those too. - I'm still not sold on the naming, OUString::valueInt() doesn't say much and OUString::valueOfInt() feels cryptic. Can we please use something obvious that doesn't need decyphering, such as OUString::number() or OUString::fromInt() (as much as I still don't like the idea of harcoding the irrelevant type information in the name)? On Thursday 10 of January 2013, Noel Grandin wrote: On Wed, Jan 9, 2013 at 7:58 PM, Michael Meeks michael.me...@suse.comwrote: At least in my mind :-) but we're starting to bike-shed here... I didn't see anyone volunteering to do the actual batch cleanup there ;-) Doesn't sound that hard - some regular expression magic will do most of the work. I expect it won't, regular expressions can't tell what foo is in valueOf( foo ). Unless all you want to convert is only places which do the explicit cast, this will need a (fairly simple) Clang plugin. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gb_COMPILERNOOPTFLAGS does not even obey the user passed CFLAGS
On Thursday 10 of January 2013, Tomáš Chvátal wrote: Hi guys, As written in subject the variable is used on multiple targets and it ignores the user defined cflags/cxxflags. This should never happen and all our targets should take into effect the user defined options too. I am not sure which variable I should append there, so could anyone check if the diff in attachment is right? It doesn't look right. CXXFLAGS should always get used for building .cxx sources, so this should have no effect, moreover gb_COMPILERNOOPTFLAGS is simply the default noopt flag to use when doing debug build. And I don't quite understand why you'd want this change, what problem are you trying to solve? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Thursday 10 of January 2013, Noel Grandin wrote: On 2013-01-10 15:55, Lubos Lunak wrote: - There's no need for valueOfChar(). There is already OUString ctor from sal_Unicode, so the valueOf() overload for it is just making an obvious thing complicated. Code using it can be converted to use the ctor instead. Which doesn't help with overload resolution problems. It does. If you say it's wrong to use valueOfWhatever() for char-string conversion, there either will not be problems, or it will be wrong. If you want to fix an existing problem by introducing a new function, how does that make anything better than using an already existing function that does the job? - When more or less deprecating valueOf() this way, it has also float overloads, so something should be created for those too. If those also suffer from overload resolution problems, then sure. But git grep String::valueOf.*static_cast.*double doesn't find anything that looks like it needs help. - I'm still not sold on the naming, OUString::valueInt() doesn't say much and OUString::valueOfInt() feels cryptic. Can we please use something obvious that doesn't need decyphering, such as OUString::number() or OUString::fromInt() (as much as I still don't like the idea of harcoding the irrelevant type information in the name)? Which would be inconsistent with the existing method names. Oh. I think we may be talking past each others because we have different goals. Am I correct in the assumption that you merely want to add another set of functions that people can use whenever the originals don't work? I do not think it is a good idea to just do a quick hack to paper over a problem. The strings are one of the most basic classes in the LO code, and if we are going to do changes there, we may as well try to do them properly. Base classes are not something we should randomly throw changes at, and we can still spend ages fixing up all the design decisions in the string classes that already are there and could have been done better. So while I appreciate it that you're willing to write a kludge that'll help avoid a problem, I kind of consider it a waste of your time, when with just little more effort a proper solution could be created. If you just add another set of functions, it will be confusing which one to use. And people will still sometimes use the old one out of habbit or for whatever reason, and still the problem will occassionally show up, and then the code will need to be changed to the new function, which is not really that different to just adding a cast. And if you say that people should always directly use the new one, then you may as well remove the old one (except keep it for extensions backwards compatibility), and then all I've said applies (no need for char function, float function needed, use a good name, etc.). Or did I misunderstand the intent of your patch? I expect it won't, regular expressions can't tell what foo is in valueOf( foo ). Actually, regex can. It's called capturing groups. Capturing groups may tell you that foo is foo, but it won't tell you it's a float. So how will you know to which of your proposed valueX() functions you should change it? Unless all you want to convert is only places which do the explicit cast, this will need a (fairly simple) Clang plugin. Sure, if you feel like writing one. Actually, I'd prefer to write a howto about that first, whenever I get to doing that, so that I don't have to write every single plugin. Such a plugin will be still much simpler than a regexp or any other way. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gb_COMPILERNOOPTFLAGS does not even obey the user passed CFLAGS
On Thursday 10 of January 2013, Tomáš Chvátal wrote: 2013/1/10 Lubos Lunak l.lu...@suse.cz: As written in subject the variable is used on multiple targets and it ignores the user defined cflags/cxxflags. This should never happen and all our targets should take into effect the user defined options too. I am not sure which variable I should append there, so could anyone check if the diff in attachment is right? It doesn't look right. CXXFLAGS should always get used for building .cxx sources, so this should have no effect, moreover gb_COMPILERNOOPTFLAGS is simply the default noopt flag to use when doing debug build. And I don't quite understand why you'd want this change, what problem are you trying to solve? See how bridgetests are build, they fail on old systems because they just specify the -O0 and nothing else, not even march So Petr used this patch in build service [1] but i think we should make this respected everywhere. Reading this patch, your change looks to me like putting the CXXFLAGS in some random place where it will incidentally work, but the moment somebody doesn't include gb_COMPILERNOOPTFLAGS in the flags passed to add_cxxobject, the problem is back again. If add_cxxobject doesn't include CXXFLAGS, why not fix it to ensure that (which possibly may need others like add_noexception_object to delegate to add_cxxobject_internal instead of add_cxxobject)? [1] https://build.opensuse.org/package/view_file?file=bridges-missing-cxxflags. diffpackage=libreofficeproject=LibreOffice%3AUnstablerev=157 -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Doing massive source changes
On Saturday 05 of January 2013, Michael Meeks wrote: On Fri, 2013-01-04 at 15:12 +0100, Lubos Lunak wrote: Having said that - it is something we really want to do; can we drop the published easy hack bug in this regard (or just close it) to avoid the drip of patches there ? I'm not aware of any easy hack specifically for this, people simply do it as a part of string cleanups. And note that this is not the only case where it's possible to do the change as one big patch. I think it might be possible to e.g. get rid of all CONSTASCII macros in one go as well, or convert OSL_DEBUG, and so on. Unless we want to stay with those things forever (which I hope we don't), they will be eventually cleaned up one way or another. I suggest we do it at a similar time to Norbert's onegit - ie. around the 4.0.2 release or so - when the cross-branch cherry-picking starts to reduce in frequency. Ok, it can wait for a while. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Thursday 10 of January 2013, Noel Grandin wrote: You are correct, we are indeed talking past each other. If you go back to the very first message in this thread, the patch mentioned there will perhaps help to establish come context. But I will try to explain again. The constructors and existing methods don't help because the specific problem we are trying to solve is that the C++ overload resolution rules will sometimes pick a non-intuitive method or constructor to apply. This leads to code that looks like: aStyleName.Append( OUString::valueOf( static_castsal_Int32( nDepth ) ) ); which is the integer case. Similar problems apply to the char and bool cases. The purpose of these methods is purely to reduce this boilerplate coding and increase readability, so that we have: aStyleName.Append( OUString::valueOfInt( nDepth ) ); Given that our string classes are used pretty much everywhere, having a wide API that increases readability can only be a good thing. While you might not like the names of the new methods, I don't see how making the names of the new methods dramatically different from the names of the existing valueOf methods can be an improvement to the API. Sometimes, we have to work with what we have. That is not what I meant. What I wrote in my previous mail is that if these valueOf() issues are to be fixed, it's better to fix it completely rather than just slightly reduce the problem. And for that it would be better to remove the original valueOf() completely, and that results in all the follow-up issues that I raised. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Failure to build 3.6 branch
On Thursday 10 of January 2013, Alexander Thurgood wrote: Le 10/01/13 12:24, Caolán McNamara a écrit : I wonder if that file has grown too big for your toolchain. Try splitting up the file into two and see if you can get it to compile that way. Unfortunately, you have lost me there. I wouldn't know how to do that. I'm only trying to build at all to do get a debug build for QA. Development coding will be a very long way off yet. I'd rather guess simply a bug in the compiler (since it's on Mac, it's the old gcc-4.0.1, right?). Try if the file compiles successfully with 'make DEBUG=1', that will disable optimizations. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gmake: CXXFLAGS override gb_Library_add_cxxflags
On Thursday 10 of January 2013, Matúš Kukan wrote: On 10 January 2013 09:16, Stephan Bergmann sberg...@redhat.com wrote: Ah, so Petr's IMHO, it would make sense to use CXXFLAGS after the default global flags but before the source file specific flags sounds reasonable to me. See https://gerrit.libreoffice.org/#/c/1632/ for a reasonable easy way to do this. It should work, etc. But it may break PCH_CXXFLAGS. I don't feel like testing --enable-pch build. - for PCH gb_CxxObject__set_pchflags should be modified too. - shouldn't the new flags be initialized in gb_LinkTarget_LinkTarget? - (as a general rule) for non-obvious commits, please include in the commit log message not only what but also why, such as a link to this thread. In a year somebody's bound to want to reshuffle the flags and wonder about the commit. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Funding Wishlist
On Wednesday 21 of November 2012, Thorsten Behrens wrote: Marc Paré wrote: We are seriously looking at different teams' wishlists. Please do take a little time out of your busy schedule and speak to your teams about any funding for items that you think may be of importance to your team or the enhance the functioning of your team's work on the project. Hi Marc, thanks a lot for running this - and yes, I think the dev team would benefit from some more tinderboxes. Unless there's other support coming up, I'd like to suggest buying another Mac box for gerrit/tinderboxing. I have an offer for a used Mac Mini as follows: Mac Mini, last year's version, 2,7 GHz DualCore i7, 4 GB RAM, AMD Radeon HD 6630M, OS X Lion, Samsung SSD 128 GB 470 Series MLC, HDMI, DVI. ... Hello, I'd like to ask, is there any plan to have such a mac machine? Or preferably a shared mac build host where developers could test their changes or find out more about tinderboxes breakages (which are sometimes rather hard to debug from just the log)? Thanks. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Wednesday 09 of January 2013, Michael Meeks wrote: On Wed, 2013-01-09 at 16:10 +0200, Noel Grandin wrote: maybe we need OUString::valueOfInt32(sal_Int32) that does the cast for us? At least it'll be less noisy, Is there really such a big difference between OUString::valueOf( sal_Int32( 0 )) and OUString::valueOfInt32( 0 ) ? Yes, I know I used static_cast, but that's because of my undying love for all these integer problems, so I wanted to have a little fun as a compensation :). And I'd like to get rid of all this one day. and we can document in one place why it's necessary. So that other people don't have to search: According to my reading of the standard (mainly 13.3.3.1.1 and 13.3.3.2 [*]), this is because when choosing which conversion for overloaded functions is better, the standard treats all integer conversions[**] the same. I'm a bit confused by the rank of S1 is better than the rank of S2, in 13.3.3.2, since reading also 4.13 I would say that long and long long have different rank, therefore int-long should be prefered to int-long long, but a test with all GCC, Clang and MSVC shows that having f( long ) and f( long long ) makes f( 0 ) ambiguous :(. Makes me wonder if there is some obscure reason for this or if just the person coming up with this was having a bad day. [*] The draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf . [**] With the exception of promotion of types smaller than int to (unsigned) int. Looks less error prone to me; doesn't suffer from odd side-effects of un-related type changes as badly either; What makes you think so? Having the type directly in the function name is almost the same like the explicit cast. If you cast incorrectly, you'll just as well get incorrect implicit cast when calling the function renamed function. hopefully fixes the perennial 64bit vs. 32bit issues. Can be in-lined to produce ~identical code, we could deprecated the old valueOf() methods just to beef up the idea that we're continuing to evolve the sal API ;-) Any profound objections ? [ not that I've time to do it myself of course ]. Uhm, but we already have more than enough Hungarian notation all over the place. If the API is to evolve, it should not do so by going backwards :(. What I think would work better would be having overloads for each integer[***]/float type (or a template), all of them still named valueOf(). That means one wouldn't need to bother with what the type actually is and the functions would just do the right thing (well, as long as the type is not sal_uInt8 or sal_uInt16, since, SAL types madness striking again, those are actually sal_Bool resp. sal_Unicode). [***] That meaning language integer types, not the SAL stuff. Overloading on the latter would not change anything. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Availability of the SDK?
On Wednesday 09 of January 2013, Stephan Bergmann wrote: * http://dev-builds.libreoffice.org/daily/ appears to offer SDK in some cases (like http://dev-builds.libreoffice.org/daily/master/MacOSX-Intel@1-built_no-moz _on_10.6.8/2013-01-09_08.08.08/master~2013-01-09_08.08.08_LibO-Dev_4.1.0.0.a lpha0_MacOS_x86_sdk.dmg) but not in others (like http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-01-09_08.31. 35/). I think I have fixed this one in tinbuild. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: replacing OUString::valueOf(static_castsal_Int32) ??
On Wednesday 09 of January 2013, Michael Stahl wrote: On 09/01/13 17:02, Lubos Lunak wrote: Is there really such a big difference between OUString::valueOf( sal_Int32( 0 )) and OUString::valueOfInt32( 0 ) it has the advantage of being explicit in what type it expects; however i actually think that is quite irrelevant for a Integer-to-String conversion (as opposed to a -to-binary conversion); are there any use cases where converting to a too big integer type would mess up the result? You mean having just one overload taking the highest (signed) integer we support? I don't see a problem with that in practice. What makes you think so? Having the type directly in the function name is almost the same like the explicit cast. If you cast incorrectly, you'll just as well get incorrect implicit cast when calling the function renamed function. but you'll at least implicitly cast the same way on all platforms (since the sal types don't map to arbitrary types, but to types of a particular size). The explicit cast will also always be the same way on all platforms. What I think would work better would be having overloads for each integer[***]/float type (or a template), all of them still named valueOf(). That means one wouldn't need to bother with what the type actually is and the functions would just do the right thing (well, as long as the type is not sal_uInt8 or sal_uInt16, since, SAL types madness striking again, those are actually sal_Bool resp. sal_Unicode). i don't like that idea, actually because there are already valueOf overloads for integral types sal_Bool and sal_Unicode that do something other than produce a string representation of an integer value, which seems wrong to me to begin with. better to add a new overloaded function, say valueOfInt, and have overloads for all possible C++ integral types, all of which produce strings with numbers. using that consistently would also solve the problem of accidentally calling valueOf(a_sal_uInt16) and getting surprising results. Right, using a different name for the function would be even better. But while we're at it, I think it'd be better to not go the somewhat cryptic way and call it e.g. OUString::number() or similar. only question is what to do about the radix parameter which is supported by sal_Int32 and sal_Int64 parameters currently... likely it's not needed often? But there's not a problem with it, is there? -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: gmake: CXXFLAGS override gb_Library_add_cxxflags
On Wednesday 09 of January 2013, Stephan Bergmann wrote: On 01/09/2013 03:41 PM, Petr Mladek wrote: + openSUSE uses: CXXFLAGS=-fomit-frame-pointer ... What do you mean with openSUSE uses [that]? Is the env var preset when you run a shell? Why would openSUSE do that in the first place? It's when building RPM packages, which are supposed to be built with $RPM_OPT_FLAGS. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
FYI: Make for faster windows build
Looks what I found under the tree! Faster make for Cygwin. Granted, I had put it there first, but still nice. Those of you who build on Windows, you might want to pull again from git://gerrit.libreoffice.org/dev-tools.git and update your make. I've implemented built-in support for some simple commands used by gbuild such as mkdir or cp, and since fork() is pretty slow on Cygwin, this makes some operations such as delivering noticeably faster. Tinderbox #6 has been using it for two weeks without a problem. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: FYI: Make for faster windows build
On Wednesday 09 of January 2013, Lubos Lunak wrote: Looks what I found under the tree! Faster make for Cygwin. Granted, I had put it there first, but still nice. Oh well, looks like somebody actually does develop LO on Windows :). So on a related note, two more things that might be helpful but probably many people don't know: - make dev-install works on windows these days too. So there's no need to fiddle with the .msi or similar, just go to install/ . It is not symlinked like on Linux, but make dev-update after each time something's been built handles that (in fact I use non-symlinked dev-install even on Linux). - Tinderbox #6 has been building with precompiled headers enabled for a while too, so I guess that means it kinda works and non-PCH builds don't easily break PCH. So those who actually develop on Windows can give --enable-pch a try if you feel brave, as while I know it builds, I don't know what it's like to actually develop with PCH enabled. Note that only several libraries have PCH enabled so far, and see below for some details about using PCH that I should write to a PCH wiki page whenever I get to creating it. I expect the chances of PCH builds breaking non-PCH builds are much higher if not careful. PS: Don't get way too excited. It doesn't make things _that_ fast. Details about PCH, copypaste from IRC: 1) the pch includes all includes, even LO ones, except the ones from the module itself (i.e. you change something in editeng = whole sw rebuilds) 2) using PCH makes it easy to forget needed #include, so unless sure I think it'd be good to rebuild those changed files again with 'make ENABLE_PCH=' 3) dependencies don't work quite right when switching back and forth, so 'make ENABLE_PCH=' on a clean build probably won't trigger any rebuild if some headers have been modified in fact I think a library may not link if all the .o's haven't been built one way or another, but for the checking for #include it should be enough to touch all the .cxx files and see if those build fine -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: FYI: Make for faster windows build
On Wednesday 09 of January 2013, Lubos Lunak wrote: Looks what I found under the tree! Faster make for Cygwin. Granted, I had put it there first, but still nice. Those of you who build on Windows, you might want to pull again from git://gerrit.libreoffice.org/dev-tools.git and update your make. I've implemented built-in support for some simple commands used by gbuild such as mkdir or cp, and since fork() is pretty slow on Cygwin, this makes some operations such as delivering noticeably faster. Tinderbox #6 has been using it for two weeks without a problem. I knew there was one more thing I wanted to mention. The make we have in dev-tools actually doesn't build with WINDOWS32 #define (both as in that the #define doesn't get set by configure and that if it's explicitly set the code doesn't compile successfully). So there's apparenly some Win32-specific code there, but it doesn't get built. And sources for the cygwin make package have more Win32-specific code. I have no idea what difference that'd make, I think there's Win32-specific code instead of fork(), I don't know if there's any Win32-specific stat() replacement or whether that'd make a noticeable difference. So if somebody would feel like playing with it. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
