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
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
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
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
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' re
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
> > > > $ ly
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 ...
> >
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.
>
> > > > +// M
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
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
--
ly
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 bette
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
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:
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
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
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.
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
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
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-de
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 (a
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,
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 FIND
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 f
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 t
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
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::FIN
26 matches
Mail list logo