StylePoolImpl::createIterator function does not take 0 arguments

[himajin100000]

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

[Tor Lillqvist]

> 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

[Tor Lillqvist]

> 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

[himajin100000]

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

[himajin100000]

> 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

[Tor Lillqvist]

>
> --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

[Kaganski Mike]

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

[Miklos Vajna]

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

[himajin100000]

> 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

[Tor Lillqvist]

> 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

[Jan Iversen]

> 
> 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

[Tor Lillqvist]

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

[Stephan Bergmann]

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

[himajin100000]

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