StylePoolImpl::createIterator function does not take 0 arguments
It seems that .hpp(and .hdl included from .hpp) for the RectanglePoint was created from .idl/.rdb by cppumaker that runs based on the .mk file, and the resulting files will be stored under C:\build\workdir\UnoApiHeadersTarget\offapi\comprehensive\ C:\build\workdir\UnoApiHeadersTarget\offapi\normal\ RectanglePoint.hdl says enum SAL_DLLPUBLIC_RTTI RectanglePoint { RectanglePoint_LEFT_TOP = 0, RectanglePoint_MIDDLE_TOP = 1, RectanglePoint_RIGHT_TOP = 2, RectanglePoint_LEFT_MIDDLE = 3, RectanglePoint_MIDDLE_MIDDLE = 4, RectanglePoint_RIGHT_MIDDLE = 5, RectanglePoint_LEFT_BOTTOM = 6, RectanglePoint_MIDDLE_BOTTOM = 7, RectanglePoint_RIGHT_BOTTOM = 8, RectanglePoint_MAKE_FIXED_SIZE = SAL_MAX_ENUM }; so...now there's no wonder the compiler complains about the mere LEFT_TOP. Fixed. I also confirmed successful compilation with << operator for RectanglePoint(with few modifications for the enum). Thank you all for the advice. I successfully made my own build with many of the macros intact from my own local branch. I've submitted most of the patches to gerrit, https://gerrit.libreoffice.org/#/c/52160/ https://gerrit.libreoffice.org/#/c/52161/ https://gerrit.libreoffice.org/#/c/52162/ https://gerrit.libreoffice.org/#/c/52163/ https://gerrit.libreoffice.org/#/c/52164/ https://gerrit.libreoffice.org/#/c/52166/ https://gerrit.libreoffice.org/#/c/52167/ https://gerrit.libreoffice.org/#/c/52168/ https://gerrit.libreoffice.org/#/c/52169/ except all the following. * RectanglePointToOUString , for the code's crappiness (unintentionally submitted. deleted from gerrit on my side: 52165) * the proposed << operator code for not knowing well about interception between the tools that automatically generate .hdl as mentioned above.( Unsubmitted) * the code for boxclipper.cxx( Unsubmitted ) Currently, I'm receiving Verified-1, but it's not my fault. I'll try later( Does this need to be rebased to trigger re-build then?) broken buildslave - failed to checkout the build failed because of an issue with the bot itself, not with the code. The Bot failed to checkout the source gerrit_mac -- himajin10 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: StylePoolImpl::createIterator function does not take 0 arguments
> Note that instead of a SAL_WARN as you have, I output the undefined value > as a number. That is more useful. > > ... because if somebody would happen to notice a warning "Unknown RectanglePoint Value", what would their first reaction be? Exactly, "Infuriating, why can't it then show *what* the unknown value is, that would help me figuring out what is going on?" Warning messages, intended for developers to see, about values being unexpected or undefined, should always show what the encountered unexpected or undefined value is. (Again, just my opinion, of course.) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: StylePoolImpl::createIterator function does not take 0 arguments
> OUString RectanglePointToOUString(const css::drawing::RectanglePoint& rp){ > if(rp == css::drawing::RectanglePoint::LEFT_TOP) > return OUString::createFromAscii("LEFT_TOP"); > ... > SAL_WARN("sd","Unknown RectanglePoint Value"); > return OUString::createFromAscii(""); > } > > The existing practice is to use a switch statement, not a sequence of if statements. Also, as css::drawing::RectanglePoint is a new-style so-called scoped enum (enum class, not plain enum), you should introduce a stream output operator<< directly, no need for a ToString function just for SAL_INFO etc usage. If you have an operator<< for it, you can use values of that css::drawing::RectanglePoint type directly in SAL_INFO etc. See for instance include/sfx2/event.hxx, this: template< typename charT, typename traits > inline std::basic_ostream & operator <<( std::basic_ostream & stream, const SvMacroItemId& id ) { switch(id) { ... That is my code, and my style, and it is I who (as far as I have noticed) have been adding such debug output operators when I have had the need. Nobody has opposed, so that is the existing style you should follow. If somebody now opposes, they are free to introduce another style, *if* they change there existing ones to be of that style, too. Just my opinion, of course. Note that instead of a SAL_WARN as you have, I output the undefined value as a number. That is more useful. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: StylePoolImpl::createIterator function does not take 0 arguments
Hi, I decided to try to fix the errors in the macros I have just commented out or deleted so far, and most of them seemed successful.However one of the errors start causing headaches on me(C++ newbie too), so the patches is to be submitted later than I expected, neither this evening nor tonight. === https://opengrok.libreoffice.org/xref/core/sd/source/filter/eppt/pptx-epptooxml.cxx?r=b2147abd#2887 CODE 1=START(concept)=== void dump_pset(Reference< XPropertySet > const& rXPropSet){ RectanglePoint pointValue; if (value >>= pointValue) SAL_INFO("sd.eppt", name << " = " << pointValue << " (RectanglePoint)"); } CODE 1==END the compiler complains that RectanglePoint can't be converted. so I wrote CODE 2==START OUString RectanglePointToOUString(const css::drawing::RectanglePoint& rp){ if(rp == css::drawing::RectanglePoint::LEFT_TOP) return OUString::createFromAscii("LEFT_TOP"); if(rp == css::drawing::RectanglePoint::MIDDLE_TOP) return OUString::createFromAscii("MIDDLE_TOP"); if(rp == css::drawing::RectanglePoint::RIGHT_TOP) return OUString::createFromAscii("RIGHT_TOP"); if(rp == css::drawing::RectanglePoint::LEFT_MIDDLE) return OUString::createFromAscii("LEFT_MIDDLE"); if(rp == css::drawing::RectanglePoint::MIDDLE_MIDDLE) return OUString::createFromAscii("MIDDLE_MIDDLE"); if(rp == css::drawing::RectanglePoint::RIGHT_MIDDLE) return OUString::createFromAscii("RIGHT_MIDDLE"); if(rp == css::drawing::RectanglePoint::LEFT_BOTTOM) return OUString::createFromAscii("LEFT_BOTTOM"); if(rp == css::drawing::RectanglePoint::MIDDLE_BOTTOM) return OUString::createFromAscii("MIDDLE_BOTTOM"); if(rp == css::drawing::RectanglePoint::RIGHT_BOTTOM) return OUString::createFromAscii("RIGHT_BOTTOM"); SAL_WARN("sd","Unknown RectanglePoint Value"); return OUString::createFromAscii(""); } void dump_pset(Reference< XPropertySet > const& rXPropSet){ // snip RectanglePoint pointValue; if (value >>= pointValue) SAL_INFO("sd.eppt", name << " = " << RectanglePointToOUString(pointValue) << "(RectanglePoint)"); // snip } CODE 2==END this thingy. but compiler started to complain: 'LEFT_TOP':illegal qualified name in member declaration 'LEFT_TOP':undeclared identifier himajin10 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
> Where did you find the info that suggested these are necessary? If > it's some wiki page, it would be good to fix it. nowhere. I just read man thing-y for the command, and for some options, I searched google, and for some other options, I read the configure.ac and so on just to fill my self-satisfactory desire of using the lastest environment (64bit, Windows 10 SDK. I failed to adapt to JDK 9-ea when it was still not RTM due to the removal of tools.jar ) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
> > --with-junit=... > --with-ant-home=... > Unless you specifically plan to work on something Java-related, I would recommend just using --without-java, and then you don't need any junit or ant switches, and there is a significantly larger chance your build will succeed. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
On 3/29/2018 3:45 PM, Miklos Vajna wrote: > The following switches are not necessary for a first debug build: > > - --disable-ccache It is advised for Windows actually (which uses pch). Unless it's off by default for Windows, it's better be used. -- Best regards, Mike Kaganski ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
Hi, On Thu, Mar 29, 2018 at 05:32:00PM +0900, himajin10 wrote: > SO THE COMMAND I USED WAS: > > /cygdrive/c/sources/libo-core/autogen.sh --enable-64-bit > --enable-sal-log --enable-dbgutil --enable-selective-debuginfo="sw/ sc/ > vcl/ sax/ svx/" --with-lang="ja" > --with-external-tar=/cygdrive/c/sources/lo-externalsrc > --with-junit=/cygdrive/c/sources/junit-4.12.jar > --with-hamcrest=/cygdrive/c/sources/hamcrest-core-1.3.jar > --with-ant-home=/cygdrive/c/sources/apache-ant-1.10.2 --enable-pch > --disable-ccache --with-windows-sdk=10.0 --with-visual-studio=2017 > > /cygdrive/c/cygwin64/opt/lo/bin/make build-nocheck gb_COLOR=1 dbglevel=3 > The following switches are not necessary for a first debug build: - --enable-sal-log - --enable-selective-debuginfo - --disable-ccache - --with-windows-sdk=10.0 - --with-visual-studio=2017 - --enable-64-bit - dbglevel=3 - gb_COLOR=1 Where did you find the info that suggested these are necessary? If it's some wiki page, it would be good to fix it. The more custom switches you use, the more probably you hit some corner case nobody tested before. I.e. something like this: --enable-dbgutil --enable-werror --with-junit=... --with-ant-home=... --with-external-tar=... should be enough. Regards, Miklos signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
> How exactly do you do your builds As is often the case with newbies to a certain domain, people are often afraid that they could have missed anything, and want to get relaxed with full-feature option, and that's what happened to me, as a newbie to OSS development. I spent several hours reading codes on opengrok, but what the program really does wasn't clear enough to me and wanted a logging feature. I came to know I can use SAL_INFO and SAL_WARN, and that was my ultimate goal at that time. Here I started to be in a status mentioned above, I chose to enable full feature. Most code seemed using OSL_DEBUG_LEVEL up to 2. Taking margins into account, I set dbglevel=3. SO THE COMMAND I USED WAS: /cygdrive/c/sources/libo-core/autogen.sh --enable-64-bit --enable-sal-log --enable-dbgutil --enable-selective-debuginfo="sw/ sc/ vcl/ sax/ svx/" --with-lang="ja" --with-external-tar=/cygdrive/c/sources/lo-externalsrc --with-junit=/cygdrive/c/sources/junit-4.12.jar --with-hamcrest=/cygdrive/c/sources/hamcrest-core-1.3.jar --with-ant-home=/cygdrive/c/sources/apache-ant-1.10.2 --enable-pch --disable-ccache --with-windows-sdk=10.0 --with-visual-studio=2017 /cygdrive/c/cygwin64/opt/lo/bin/make build-nocheck gb_COLOR=1 dbglevel=3 There were some rotting code, precisely rotten code, like basegfx/test/boxclipper.cxx?r=db045855#364 (missing argument). Not knowing what would be the ideal fix , I just commented out or deleted all those craps on my local branch, and I succeeded to make my own build and to use SAL_INFO. >it would not be set when you merely configure --enable-debug or --enable-dbgutil, >Having fallen into this pitfall a couple of times and got a headache understanding why the code was not executed, >What you say "make my own DEBUG build", what do you mean exactly? Wow. So I was also misunderstanding the DEBUG macro too. I was thinking, by using either of the options the DEBUG build in my definition would be made, and that's what I meant the "DEBUG build" for. I believe that developers( including me, as a newbie ) should put efforts in keeping compile task to be (mostly) successful as possible as they can, even if the code is not often used, and that was my motivation of writing "I will write a patch" in the aforementioned bug report. I already have prepared some patches(but does not cover all the problems) in my local branch to reduce someone's needs for his/her efforts in the future who would want to make his/her own build. If no one against this idea of mine appears by tomorrow afternoon, I will submit the patches to gerrit and wait for the code-review. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
> I am one of those who would like to remove the debug levels, but lately > (spending far too much time in the internal UNO workings), I am a little > afraid that we have a lot of bit rotten code waiting to become a problem. > So doing this change in a branch would be wise. > > Here I am of a different opinion. If something is risky and might break things, the best way to hide it and make sure that it gets no testing in various environments and use cases (but only by the person working on it) is to keep it in a branch;) --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
> > As it happens, in LibreOffice code, "#ifdef DEBUG" is 1:1 equivalent to "#if > (OSL_DEBUG_LEVEL >= 2)", and the thought was that perhaps all instances of > "#ifdef DEBUG" should be changed to that instead, to make it more clear that > it is a rather rare way to build, that code inside "#ifdef DEBUG" is *not* > compiled in a normal --enable-debug or --enable-dbgutil build, but one needs > the much more rare case of increasing the dbglevel thing. > > It has even been suggested in the past we should get rid of those dbglevel, > or OSL_DEBUG_LEVEL, things, to make the configuration space smaller. It is > quite enough (in my opinion) to have --enable-debug, --enable-dbgutil, > --enable-symbols, --enable-assert-always-abort, and --enable-sal-log, that > all have related but different meanings. Also --enable-release-build could be > interpreted as being related. And I probably forgot some... Having fallen into this pitfall a couple of times and got a headache understanding why the code was not executed, I highly favor to at least change to OSL_DEBUG_LEVEL >= 2. I am one of those who would like to remove the debug levels, but lately (spending far too much time in the internal UNO workings), I am a little afraid that we have a lot of bit rotten code waiting to become a problem. So doing this change in a branch would be wise. rgds jan I > > Currently, when somebody loosely talks about "debug mode" vs "release mode" > (as is common for people coming from a background of Visual Studio projects, > for instance), it is fairly unclear what they actually mean. We should strive > to make it clearer. > > What you say "make my own DEBUG build", what do you mean exactly? > > --tml > > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
Funny this '#ifdef DEBUG' was brought up now, it happened to be discussed on IRC yesterday. As it happens, in LibreOffice code, "#ifdef DEBUG" is 1:1 equivalent to "#if (OSL_DEBUG_LEVEL >= 2)", and the thought was that perhaps all instances of "#ifdef DEBUG" should be changed to that instead, to make it more clear that it is a rather rare way to build, that code inside "#ifdef DEBUG" is *not* compiled in a normal --enable-debug or --enable-dbgutil build, but one needs the much more rare case of increasing the dbglevel thing. It has even been suggested in the past we should get rid of those dbglevel, or OSL_DEBUG_LEVEL, things, to make the configuration space smaller. It is quite enough (in my opinion) to have --enable-debug, --enable-dbgutil, --enable-symbols, --enable-assert-always-abort, and --enable-sal-log, that all have related but different meanings. Also --enable-release-build could be interpreted as being related. And I probably forgot some... Currently, when somebody loosely talks about "debug mode" vs "release mode" (as is common for people coming from a background of Visual Studio projects, for instance), it is fairly unclear what they actually mean. We should strive to make it clearer. What you say "make my own DEBUG build", what do you mean exactly? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: 'StylePoolImpl::createIterator': function does not take 0 arguments
On 28/03/18 12:45, himajin10 wrote: Hello, I'm himajin10, often trying to make my own DEBUG build. This mail is just for explanation. I have written a bug report "tdf#116677:StylePool::createIterator has default paramters, but StylePoolImpl's does not" , but there Xisco FaulĂ kindly requested me to post these build issues to dev mailing-list, not to bugzilla. C:/sources/libo-core/svl/source/items/stylepool.cxx(410): error C2660: 'StylePoolImpl::createIterator': function does not take 0 arguments That code is inside a rather unusual #ifdef DEBUG block. According to solenv/gbuild/gbuild.mk, DEBUG would only be defined when gb_DEBUGLEVEL >= 2, i.e., when you call make with an argument like dbglevel=2. (AFAICS, it would not be set when you merely configure --enable-debug or --enable-dbgutil, something that many people routinely do.) How exactly do you do your builds (what is the content of your autogen.input, resp. what arguments do you pass to autogen.sh; and how do you invoke make)? Such #ifdef DEBUG code is likely rotting. The best thing probably is to determine whether such code is actually useful, and if it is, to put it behind more conventional #if checks that are triggered for --enable-debug or --enable-dbgutil builds. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
'StylePoolImpl::createIterator': function does not take 0 arguments
Hello, I'm himajin10, often trying to make my own DEBUG build. This mail is just for explanation. I have written a bug report "tdf#116677:StylePool::createIterator has default paramters, but StylePoolImpl's does not" , but there Xisco FaulĂ kindly requested me to post these build issues to dev mailing-list, not to bugzilla. C:/sources/libo-core/svl/source/items/stylepool.cxx(410): error C2660: 'StylePoolImpl::createIterator': function does not take 0 arguments on trying to write a patch for this issue, I also found that variable declaration for mnCount(only used in DEBUG builds) was removed by the commit 778e9a65bf5 done by Noel Grandin.(This removal would not be problematic on release builds, but is problematic for DEBUG builds) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice