Re: Expand debug to contain more than 31 cases
Am Tue, 26 Apr 2022 16:12:25 +0200 schrieb Pavel Sanda : > On Tue, Apr 26, 2022 at 03:35:30PM +0200, Jean-Marc Lasgouttes wrote: > > Le 26/04/2022 ?? 14:58, Pavel Sanda a écrit : > > >On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote: > > >>>I read somewhere that 64 bit for long long was a 'should' and not a > > >>>'must'. > > > > > >There is subtlety here, which might be the source of confusion. The > > >standard does > > >not tell you long long needs to be *implemented* by 64bits. It just tells > > >you to > > >contain the range of 2^64. So standard does not prohibit you to write > > >compiler which > > >uses 65 bits for long long. > > > > And if I understand correctly, C++11 tells you that 'long long' has to > > exist, which was not the case before if I am not mistaken. > > Yes, 1998 version of C++ Standard does not know long long, while C++11 > knows it and introduces with LLONG_MAX, but leaving the definition > on Standard C library header . > > Pavel I was about to propose #ifndef UNINT64_MAX // Make sure the type unit64_t exists #include #endif but QVariant does not know about uint64, only 'qulonglong type'. So in the end using 'long long' is the way. (The problem shows at GuiProgressView.cpp:113 item->setData(0, Qt::UserRole, dit->first); where we would have to use qulonglong(dit->first) ) Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpfs3YCuBFPv.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Tue, Apr 26, 2022 at 03:35:30PM +0200, Jean-Marc Lasgouttes wrote: > Le 26/04/2022 ?? 14:58, Pavel Sanda a écrit : > >On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote: > >>>I read somewhere that 64 bit for long long was a 'should' and not a 'must'. > > > >There is subtlety here, which might be the source of confusion. The standard > >does not tell you > >long long needs to be *implemented* by 64bits. It just tells you to contain > >the range of 2^64. > >So standard does not prohibit you to write compiler which uses 65 bits for > >long long. > > And if I understand correctly, C++11 tells you that 'long long' has to > exist, which was not the case before if I am not mistaken. Yes, 1998 version of C++ Standard does not know long long, while C++11 knows it and introduces with LLONG_MAX, but leaving the definition on Standard C library header . Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 26/04/2022 à 14:58, Pavel Sanda a écrit : On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote: I read somewhere that 64 bit for long long was a 'should' and not a 'must'. There is subtlety here, which might be the source of confusion. The standard does not tell you long long needs to be *implemented* by 64bits. It just tells you to contain the range of 2^64. So standard does not prohibit you to write compiler which uses 65 bits for long long. And if I understand correctly, C++11 tells you that 'long long' has to exist, which was not the case before if I am not mistaken. I agree with Pavel that using 'long long' works, although I am not sure that the removal of one header will save the world. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Tue, Apr 26, 2022 at 02:28:08PM +0200, Pavel Sanda wrote: > > I read somewhere that 64 bit for long long was a 'should' and not a 'must'. There is subtlety here, which might be the source of confusion. The standard does not tell you long long needs to be *implemented* by 64bits. It just tells you to contain the range of 2^64. So standard does not prohibit you to write compiler which uses 65 bits for long long. So if you were to write API with standardized data structures you need to send through some channel, you better be sure about size of int implementations. But there is no need to worry that 2^33 won't be contained in long long as is our usecase. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Mon, Apr 25, 2022 at 09:35:46PM +0200, Kornel Benko wrote: > > Can you explain to me what is the reason for "weakly opposing" it? > > Yes, the code does no harm, only gave me a guaranty. > I read somewhere that 64 bit for long long was a 'should' and not a 'must'. Nope, we are in the 'must' regime. Or rather 'shall' which is used in the standard. In ANSI ISO/IEC 9899 (second edition 1999-12-01) "Programming languages - C" (the one I easily have access to right now and which is referenced by C++ norm): 4. In this International Standard, "shall" is to be interpreted as a requirement on an implementation or on a program; ... 5.2.4.2.1 Size of integer types .. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign. ... - minimum value for an object of type long long int LLONG_MIN -9223372036854775807 // ?(2^63 - 1) - maximum value for an object of type long long int LLONG_MAX +9223372036854775807 // 2^63 - 1 - maximum value for an object of type unsigned long long int ULLONG_MAX 18446744073709551615 // 2^64 - 1 > But int64_t _has_ to contain valid 64 bits. I hope I made clear long long satisfies your thirst for 33 bits as well and does not rely on any unnecessary includes. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Mon, 25 Apr 2022 14:11:18 +0200 schrieb Pavel Sanda : > On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote: > > Am Sun, 24 Apr 2022 21:45:13 +0200 > > schrieb Pavel Sanda : > > > > > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote: > > > > Try to use > > > > $ lyx -dbg > > > > it should display > > > > ... > > > > 4294967296 debug ... > > > > then 1L would be correct. > > > > > > Seems to be correct now. > > > > > > > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > > > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : > > > > > > -1]; > > > > > > > > > > long long is supposed to be able to represent values between -(2^63 > > > > > -1) to 2^63 > > > > > -1 so I do not think this check is necessary. > > > > > > > > I wanted to be sure ... > > > > > > I do not see any ambiguity here. Mention of long long int goes back at > > > least to > > > ANSI C norm from 1998 and the range of 2^64 is already there. > > > > > > Pavel > > > > Pavel, I'd like to see the output of the following c++ source > > #include > > > > compiled with > > $ c++ -E -g3 > > The machine where it broke shows this: > https://pastebin.com/ubZVNKdr The output shows that your machine defines uin64_t as typedef unsigned long int uint64_t; at /usr/include/stdint.h:56 So, the include of "stdint.h" would be sufficient. > > because I prefer to use something like uint64_t over 'unsigned long long'. > > I dislike it because we use long long on bunch of different places in our > code already. This is introducing not yet used type depending on special > header. > This might break on whatever strange arch ppl try to compile for no obvious > gain. > > > Other than this, if the test is really too itching, I am not opposing too > > strong to > > remove it. > > I just pointed out that long long needs to contain 64 bit range as defined by > C(++) > standard. At about the same time as stdint.h was introduced to make the int-types portable. (At least, that is how I understood) > Can you explain to me what is the reason for "weakly opposing" it? Yes, the code does no harm, only gave me a guaranty. I read somewhere that 64 bit for long long was a 'should' and not a 'must'. But int64_t _has_ to contain valid 64 bits. > Pavel Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpRmef5x8oca.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Mon, Apr 25, 2022 at 10:10:26AM +0200, Kornel Benko wrote: > Am Sun, 24 Apr 2022 21:45:13 +0200 > schrieb Pavel Sanda : > > > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote: > > > Try to use > > > $ lyx -dbg > > > it should display > > > ... > > > 4294967296 debug ... > > > then 1L would be correct. > > > > Seems to be correct now. > > > > > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1]; > > > > > > > > > > > > > long long is supposed to be able to represent values between -(2^63 -1) > > > > to 2^63 -1 > > > > so I do not think this check is necessary. > > > > > > I wanted to be sure ... > > > > I do not see any ambiguity here. Mention of long long int goes back at > > least to > > ANSI C norm from 1998 and the range of 2^64 is already there. > > > > Pavel > > Pavel, I'd like to see the output of the following c++ source > #include > > compiled with > $ c++ -E -g3 The machine where it broke shows this: https://pastebin.com/ubZVNKdr > because I prefer to use something like uint64_t over 'unsigned long long'. I dislike it because we use long long on bunch of different places in our code already. This is introducing not yet used type depending on special header. This might break on whatever strange arch ppl try to compile for no obvious gain. > Other than this, if the test is really too itching, I am not opposing too > strong to > remove it. I just pointed out that long long needs to contain 64 bit range as defined by C(++) standard. Can you explain to me what is the reason for "weakly opposing" it? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Sun, 24 Apr 2022 21:45:13 +0200 schrieb Pavel Sanda : > On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote: > > Try to use > > $ lyx -dbg > > it should display > > ... > > 4294967296 debug ... > > then 1L would be correct. > > Seems to be correct now. > > > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1]; > > > > > > long long is supposed to be able to represent values between -(2^63 -1) > > > to 2^63 -1 > > > so I do not think this check is necessary. > > > > I wanted to be sure ... > > I do not see any ambiguity here. Mention of long long int goes back at least > to > ANSI C norm from 1998 and the range of 2^64 is already there. > > Pavel Pavel, I'd like to see the output of the following c++ source #include compiled with $ c++ -E -g3 because I prefer to use something like uint64_t over 'unsigned long long'. Other than this, if the test is really too itching, I am not opposing too strong to remove it. Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgp8Uu8kJRWMb.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Fri, Apr 22, 2022 at 01:56:20PM +0200, Kornel Benko wrote: > Try to use > $ lyx -dbg > it should display > ... > 4294967296 debug ... > then 1L would be correct. Seems to be correct now. > > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1]; > > > > long long is supposed to be able to represent values between -(2^63 -1) to > > 2^63 -1 > > so I do not think this check is necessary. > > I wanted to be sure ... I do not see any ambiguity here. Mention of long long int goes back at least to ANSI C norm from 1998 and the range of 2^64 is already there. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Fri, 22 Apr 2022 13:56:20 +0200 schrieb Kornel Benko : > then 1L would be correct. > We may need 1ULL here. Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpQQ3tmnTSXa.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Fri, 22 Apr 2022 13:40:19 +0200 schrieb Pavel Sanda : > On Fri, Apr 22, 2022 at 12:28:06PM +0200, Kornel Benko wrote: > > Am Thu, 21 Apr 2022 15:38:23 +0200 > > schrieb Pavel Sanda : > > > > > On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote: > > > > Do you have a better idea? > > > > > > long long ? > > > Pavel > > > > Ok, is the attached working for you? > > It compiles, I did not try to run (i.e. check whether literal 1L is correct). Try to use $ lyx -dbg it should display ... 4294967296 debug ... then 1L would be correct. > > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1]; > > long long is supposed to be able to represent values between -(2^63 -1) to > 2^63 -1 > so I do not think this check is necessary. I wanted to be sure ... > Pavel Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpDFf78g4QNE.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Fri, Apr 22, 2022 at 12:28:06PM +0200, Kornel Benko wrote: > Am Thu, 21 Apr 2022 15:38:23 +0200 > schrieb Pavel Sanda : > > > On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote: > > > Do you have a better idea? > > > > long long ? > > Pavel > > Ok, is the attached working for you? It compiles, I did not try to run (i.e. check whether literal 1L is correct). > +// Make sure at compile time that sizeof(unsigned long long) >= 8 > +typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1]; long long is supposed to be able to represent values between -(2^63 -1) to 2^63 -1 so I do not think this check is necessary. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Thu, 21 Apr 2022 15:38:23 +0200
schrieb Pavel Sanda :
> On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote:
> > Do you have a better idea?
>
> long long ?
> Pavel
Ok, is the attached working for you?
Kornel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/support/debug.h b/src/support/debug.h
index 681ef3fbaf..11a759f734 100644
--- a/src/support/debug.h
+++ b/src/support/debug.h
@@ -30,16 +30,19 @@ typedef basic_streambuf > streambuf;
} // namespace std
#endif
+// Make sure at compile time that sizeof(unsigned long long) >= 8
+typedef char p__LINE__[ (sizeof(unsigned long long) > 7) ? 1 : -1];
+
namespace lyx {
/// This is all the different debug levels that we have.
namespace Debug {
///
- typedef uint64_t base_type;
+ typedef unsigned long long base_type;
enum Type : base_type {
///
NONE = 0,
///
INFO = (1u << 0), // 1
pgpUsSk6xo5si.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Thu, Apr 21, 2022 at 02:53:37PM +0200, Jean-Marc Lasgouttes wrote: > Do you have a better idea? long long ? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Thu, 21 Apr 2022 14:45:39 +0200 schrieb Pavel Sanda : > On Tue, Apr 19, 2022 at 11:12:06AM +0200, Kornel Benko wrote: > > > I am not sure that we need a verbose level yet. What about > > > -dbg find => FINDSHORT > > > -dbg find --verbose => FIND > > > > > > JMarc > > > > I propose to do it as a next step. Better not too many changes at once IMO. > > > > make[5]: Entering directory '/lyx/src/support' > CXX debug.o > In file included from debug.cpp:15:0: > ./../support/debug.h:40:10: error: 'uint64_t' does not name a type > typedef uint64_t base_type; > > > Well, not that small change. On some gcc versions you need to include cstdint > header to have uint64_t available (AFAIK we don't use uint64_t anywhere else > in the code). > And including in debug.h which is used everywhere is not great idea. > > Pavel Does your /usr/include/stdint.h define anything appropriate? Here it includes /usr/include/x86_64-linux-gnu/bits/stdint-uintn.h which defines uint64_t OTOH, there is also the sequence #if __WORDSIZE == 64 typedef unsigned long int uint_least64_t; #else __extension__ typedef unsigned long long int uint_least64_t; #endif Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpzulYYUbcRF.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 21/04/2022 à 14:45, Pavel Sanda a écrit : Well, not that small change. On some gcc versions you need to include cstdint header to have uint64_t available (AFAIK we don't use uint64_t anywhere else in the code). Right. And including in debug.h which is used everywhere is not great idea. Here, expands to 300 line, many of them blank. I think we can cope with it. Do you have a better idea? JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Tue, Apr 19, 2022 at 11:12:06AM +0200, Kornel Benko wrote: > > I am not sure that we need a verbose level yet. What about > > -dbg find => FINDSHORT > > -dbg find --verbose => FIND > > > > JMarc > > I propose to do it as a next step. Better not too many changes at once IMO. make[5]: Entering directory '/lyx/src/support' CXX debug.o In file included from debug.cpp:15:0: ./../support/debug.h:40:10: error: 'uint64_t' does not name a type typedef uint64_t base_type; Well, not that small change. On some gcc versions you need to include cstdint header to have uint64_t available (AFAIK we don't use uint64_t anywhere else in the code). And including in debug.h which is used everywhere is not great idea. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Tue, 19 Apr 2022 13:05:37 +0200 schrieb Jean-Marc Lasgouttes : > Le 19/04/2022 à 11:07, Kornel Benko a écrit : > >> Besides the discussion of FINDSHORT, I do not think that size_t is a > >> good type, since the only guarantee is that it is more than 16 bits > >> (even on 32bit architectures, it is probably 32 bits). int64_t is > >> probably what you are after. > > > > Yes. I had the (apparently wrong) impression that size_t == . > > This is exact, regexp-wise: size_t is... something :) > > >> Using int64_t instead of Debug::Type is indeed the thing to do for > >> bitfields like this. However, it would be best to define this type as > >> Debug::base_type or some simpler name if you have one in mind. > > > > Like > > typedef uint64_t Debug::base_type; > > ? > > Right. > > JMarc Done at d09f5ce1. Needs recompiling everything because 'make' here has not all dependencies right. I had to do: $ make clean $ make package in the build directory to get it right. Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpNJWM1NZBXn.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 19/04/2022 à 11:12, Kornel Benko a écrit : I am not sure that we need a verbose level yet. What about -dbg find => FINDSHORT -dbg find --verbose => FIND JMarc I propose to do it as a next step. Better not too many changes at once IMO. As you prefer. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 19/04/2022 à 11:07, Kornel Benko a écrit : Besides the discussion of FINDSHORT, I do not think that size_t is a good type, since the only guarantee is that it is more than 16 bits (even on 32bit architectures, it is probably 32 bits). int64_t is probably what you are after. Yes. I had the (apparently wrong) impression that size_t == . This is exact, regexp-wise: size_t is... something :) Using int64_t instead of Debug::Type is indeed the thing to do for bitfields like this. However, it would be best to define this type as Debug::base_type or some simpler name if you have one in mind. Like typedef uint64_t Debug::base_type; ? Right. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Tue, 19 Apr 2022 10:53:40 +0200 schrieb Jean-Marc Lasgouttes : > Le 19/04/2022 à 10:08, Kornel Benko a écrit : > >> We do > >> currently have a "--verbose" but what I mean is to change "--verbose" to > >> accept a "" argument that determines how verbose the debug output > >> is. So this way, "lyx --debug find --verbose 1" would give the same > >> output as "FIND", and "lyx --debug find --verbose 2" would give the same > >> output as "FINDSHORT". > > > > Maybe the other way around. FIND -> FINDLONG, FINDSHORT -> FIND > > so that --verbose 2 would select FINGLONG. > > I am not sure that we need a verbose level yet. What about > -dbg find => FINDSHORT > -dbg find --verbose => FIND > > JMarc I propose to do it as a next step. Better not too many changes at once IMO. Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpRxsLpuqbIn.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Tue, 19 Apr 2022 10:51:14 +0200 schrieb Jean-Marc Lasgouttes : > Le 18/04/2022 à 12:21, Kornel Benko a écrit : > > The output while debugging findadv is overwhelming, but sometimes > > one needs only a small subset. Therefore the addition of -dbg findshort. > > Besides the discussion of FINDSHORT, I do not think that size_t is a > good type, since the only guarantee is that it is more than 16 bits > (even on 32bit architectures, it is probably 32 bits). int64_t is > probably what you are after. Yes. I had the (apparently wrong) impression that size_t == . > Using int64_t instead of Debug::Type is indeed the thing to do for > bitfields like this. However, it would be best to define this type as > Debug::base_type or some simpler name if you have one in mind. Like typedef uint64_t Debug::base_type; ? > JMarc > Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgpJO10cPlOVT.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 19/04/2022 à 10:08, Kornel Benko a écrit : We do currently have a "--verbose" but what I mean is to change "--verbose" to accept a "" argument that determines how verbose the debug output is. So this way, "lyx --debug find --verbose 1" would give the same output as "FIND", and "lyx --debug find --verbose 2" would give the same output as "FINDSHORT". Maybe the other way around. FIND -> FINDLONG, FINDSHORT -> FIND so that --verbose 2 would select FINGLONG. I am not sure that we need a verbose level yet. What about -dbg find => FINDSHORT -dbg find --verbose => FIND JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Le 18/04/2022 à 12:21, Kornel Benko a écrit : The output while debugging findadv is overwhelming, but sometimes one needs only a small subset. Therefore the addition of -dbg findshort. Besides the discussion of FINDSHORT, I do not think that size_t is a good type, since the only guarantee is that it is more than 16 bits (even on 32bit architectures, it is probably 32 bits). int64_t is probably what you are after. Using int64_t instead of Debug::Type is indeed the thing to do for bitfields like this. However, it would be best to define this type as Debug::base_type or some simpler name if you have one in mind. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
Am Mon, 18 Apr 2022 21:22:41 -0400 schrieb Scott Kostyshak : > On Mon, Apr 18, 2022 at 12:21:40PM +0200, Kornel Benko wrote: > > The output while debugging findadv is overwhelming, but sometimes > > one needs only a small subset. Therefore the addition of -dbg findshort. > > > > Also it would be possible to use constructions like > > LYXERR(Debug::FIND|Debug::FINDSHORT, "Setting regexp to : '" << > > regexp_str << > > "'") (mark the '|' in 'Debug::FIND|Debug::FINDSHORT' parameter) > > > > The changes to lyxfind.cpp are also attached. > > > > OK to commit? > > I'm surprised this hasn't come up with a different context. > > Would it make sense to have a more general mechanism? For example, > instead of find vs. findshort, what if we instead use --verbose ? Good idea. > We do > currently have a "--verbose" but what I mean is to change "--verbose" to > accept a "" argument that determines how verbose the debug output > is. So this way, "lyx --debug find --verbose 1" would give the same > output as "FIND", and "lyx --debug find --verbose 2" would give the same > output as "FINDSHORT". Maybe the other way around. FIND -> FINDLONG, FINDSHORT -> FIND so that --verbose 2 would select FINGLONG. > I am not opposed to the patch, but if we do this for other debug flags, > and if we then decide to add e.g. 'FINDMEDIUM' it can get complicated. > But on the other hand, you are the first to propose this at least since > I've been here I think, so perhaps it is indeed a "one-off" and your > patch of "FIND" and "FINDSHORT" are better than implemening a general > mechanism that not many will use. Indeed, I would not argue against > "Advanced find" being a tricky beast that needs a special treatment. > Thank you for tackling this beast, by the way. :) > We can always add a more general mechanism later (i.e., even if you > commit your patch) if there is interest. It's not like this is a LyX > fileformat change where once something is in it can be annoying to > change. Yes. > I propose that if no one else responds, you commit your patch. > > Scott Kornel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel pgp2D0BJNiuen.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Expand debug to contain more than 31 cases
On Mon, Apr 18, 2022 at 12:21:40PM +0200, Kornel Benko wrote: > The output while debugging findadv is overwhelming, but sometimes > one needs only a small subset. Therefore the addition of -dbg findshort. > > Also it would be possible to use constructions like > LYXERR(Debug::FIND|Debug::FINDSHORT, "Setting regexp to : '" << > regexp_str << "'") > (mark the '|' in 'Debug::FIND|Debug::FINDSHORT' parameter) > > The changes to lyxfind.cpp are also attached. > > OK to commit? I'm surprised this hasn't come up with a different context. Would it make sense to have a more general mechanism? For example, instead of find vs. findshort, what if we instead use --verbose ? We do currently have a "--verbose" but what I mean is to change "--verbose" to accept a "" argument that determines how verbose the debug output is. So this way, "lyx --debug find --verbose 1" would give the same output as "FIND", and "lyx --debug find --verbose 2" would give the same output as "FINDSHORT". I am not opposed to the patch, but if we do this for other debug flags, and if we then decide to add e.g. 'FINDMEDIUM' it can get complicated. But on the other hand, you are the first to propose this at least since I've been here I think, so perhaps it is indeed a "one-off" and your patch of "FIND" and "FINDSHORT" are better than implemening a general mechanism that not many will use. Indeed, I would not argue against "Advanced find" being a tricky beast that needs a special treatment. Thank you for tackling this beast, by the way. We can always add a more general mechanism later (i.e., even if you commit your patch) if there is interest. It's not like this is a LyX fileformat change where once something is in it can be annoying to change. I propose that if no one else responds, you commit your patch. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
