On Sun, 20 Nov 2022 at 16:26, Scott Kostyshak wrote:
> On Sun, Nov 20, 2022 at 03:25:09PM +0100, Thibaut Cuvelier wrote:
> > commit f3862130cf687854dbff2df348f34659ca602a02
> > Author: Thibaut Cuvelier
> > Date: Sun Nov 20 16:19:17 2022 +0100
> >
> > Am
On Sun, Nov 20, 2022 at 03:25:09PM +0100, Thibaut Cuvelier wrote:
> commit f3862130cf687854dbff2df348f34659ca602a02
> Author: Thibaut Cuvelier
> Date: Sun Nov 20 16:19:17 2022 +0100
>
> Amend 48d9d01a: remove debug output
> ---
> src/insets/InsetIndex.cpp |6
Le 25/02/2021 à 07:30, Stephan Witt a écrit :
Am 25.02.2021 um 00:31 schrieb Richard Kimberly Heck :
On 2/24/21 4:03 PM, Stephan Witt wrote:
Hi all,
while trying to understand bug #11013 I have a problem with message pane output.
The output is as follows:
frontends/qt/GuiApplication.cpp (23
Am 25.02.2021 um 00:31 schrieb Richard Kimberly Heck :
>
> On 2/24/21 4:03 PM, Stephan Witt wrote:
>> Hi all,
>>
>> while trying to understand bug #11013 I have a problem with message pane
>> output.
>>
>> The output is as follows:
>>
>> frontends/qt/GuiApplication.cpp (2329): action first set
On 2/24/21 4:03 PM, Stephan Witt wrote:
Hi all,
while trying to understand bug #11013 I have a problem with message pane output.
The output is as follows:
frontends/qt/GuiApplication.cpp (2329): action first set to []
The corresponding debugger terminal output is:
frontends/qt/GuiApplication
Hi all,
while trying to understand bug #11013 I have a problem with message pane output.
The output is as follows:
frontends/qt/GuiApplication.cpp (2329): action first set to []
The corresponding debugger terminal output is:
frontends/qt/GuiApplication.cpp (2329): action first set to [dialog-t
On Thu, Sep 03, 2020 at 03:54:58PM -0400, Richard Kimberly Heck wrote:
> On 9/3/20 3:01 PM, Enrico Forestieri wrote:
> >
> > I would also like to backport the changes to the autocorrect file made
> > at 9bf8c873, 3b1ee921, 16d87a61, and 1df3151b. These are collected in
> > the attached patch.
> >
>
c9e08809c02bb3682ac50439d97951
>>>> Author: Enrico Forestieri
>>>> Date: Tue Sep 1 12:12:55 2020 +0200
>>>>
>>>> Adjust debug output for fonts
>>>>
>>>> This restores the debug output as it was intended before the
>>
> >> Date: Tue Sep 1 12:12:55 2020 +0200
> >>
> >> Adjust debug output for fonts
> >>
> >> This restores the debug output as it was intended before the
> >> introduction of the LYXERR macro that was unconditionally outpu
On 9/3/20 4:55 AM, Enrico Forestieri wrote:
> On Tue, Sep 01, 2020 at 11:54:46AM +0200, Enrico Forestieri wrote:
>> commit 8039b34802c9e08809c02bb3682ac50439d97951
>> Author: Enrico Forestieri
>> Date: Tue Sep 1 12:12:55 2020 +0200
>>
>> Adjust debug out
On Tue, Sep 01, 2020 at 11:54:46AM +0200, Enrico Forestieri wrote:
> commit 8039b34802c9e08809c02bb3682ac50439d97951
> Author: Enrico Forestieri
> Date: Tue Sep 1 12:12:55 2020 +0200
>
> Adjust debug output for fonts
>
> This restores the debug output as it wa
On Sun, Apr 26, 2020 at 03:20:59AM -0400, Richard Kimberly Heck wrote:
> On 4/8/20 8:20 PM, Scott Kostyshak wrote:
> > What effect does the friend have? ParagraphParameters::write() is public.
>
> I think I was just mimicking other code. Gone now.
Thanks,
Scott
signature.asc
Description: PGP
On 4/8/20 8:20 PM, Scott Kostyshak wrote:
> On Wed, Apr 08, 2020 at 11:03:56PM +0200, Richard Kimberly Heck wrote:
>> commit eea4ef9b6e8c103b8d77fb456214a116c68f58a7
>> Author: Richard Kimberly Heck
>> Date: Wed Apr 8 17:17:14 2020 -0400
>>
>>
On Wed, Apr 08, 2020 at 11:03:56PM +0200, Richard Kimberly Heck wrote:
> commit eea4ef9b6e8c103b8d77fb456214a116c68f58a7
> Author: Richard Kimberly Heck
> Date: Wed Apr 8 17:17:14 2020 -0400
>
> Debug output for paragraph params.
> ---
> src/ParagraphParameters.cpp
On 09/21/2018 03:13 PM, Enrico Forestieri wrote:
On Fri, Sep 21, 2018 at 01:32:24PM -0400, Paul A. Rubin wrote:
On 09/21/2018 01:28 PM, Jean-Marc Lasgouttes wrote:
Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :
I'm embarrassed to have to ask, but how does one get debug output
with the Wi
On 9/21/18 2:06 PM, Paul A. Rubin wrote:
> On 09/21/2018 01:32 PM, Scott Kostyshak wrote:
>> On Fri, Sep 21, 2018 at 01:20:21PM -0400, Paul A. Rubin wrote:
>>> I'm embarrassed to have to ask, but how does one get debug output
>>> with the
>>> Windows vers
On Fri, Sep 21, 2018 at 01:32:24PM -0400, Paul A. Rubin wrote:
> On 09/21/2018 01:28 PM, Jean-Marc Lasgouttes wrote:
> > Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :
> > > I'm embarrassed to have to ask, but how does one get debug output
> > > with the Windows ver
On 09/21/2018 01:32 PM, Scott Kostyshak wrote:
On Fri, Sep 21, 2018 at 01:20:21PM -0400, Paul A. Rubin wrote:
I'm embarrassed to have to ask, but how does one get debug output with the
Windows version of LyX (2.3 or later)? From a command window, I've tried
both "start LyX2.3 -db
On 09/21/2018 01:28 PM, Jean-Marc Lasgouttes wrote:
Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :
I'm embarrassed to have to ask, but how does one get debug output
with the Windows version of LyX (2.3 or later)? From a command
window, I've tried both "start LyX2.3 -dbg all"
On Fri, Sep 21, 2018 at 01:20:21PM -0400, Paul A. Rubin wrote:
> I'm embarrassed to have to ask, but how does one get debug output with the
> Windows version of LyX (2.3 or later)? From a command window, I've tried
> both "start LyX2.3 -dbg all" and "cmd /
Le 21/09/2018 à 19:20, Paul A. Rubin a écrit :
I'm embarrassed to have to ask, but how does one get debug output with
the Windows version of LyX (2.3 or later)? From a command window, I've
tried both "start LyX2.3 -dbg all" and "cmd /K LyX2.3 -dbg all", a
I'm embarrassed to have to ask, but how does one get debug output with
the Windows version of LyX (2.3 or later)? From a command window, I've
tried both "start LyX2.3 -dbg all" and "cmd /K LyX2.3 -dbg all", and
have tried surrounding the executable name and flags
Abdelrazak Younes schrieb:
Good boy!
The new TOC "dialog" is damn cool :-)
Michael
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Dear Michael,
I am trying to identify a freeze in release mode so I use "-dbg any".
But the volume of CT debug info is so voluminous that it is unusable.
Could you please try to get rid of some?
I tried and I succeeded :-)
Good boy!
Thanks,
Abdelrazak Younes schrieb:
Dear Michael,
I am trying to identify a freeze in release mode so I use "-dbg any".
But the volume of CT debug info is so voluminous that it is unusable.
Could you please try to get rid of some?
I tried and I succeeded :-)
Michael
Dear Michael,
I am trying to identify a freeze in release mode so I use "-dbg any".
But the volume of CT debug info is so voluminous that it is unusable.
Could you please try to get rid of some?
Thanks in advance,
Abdfel.
People, when adding debug output please use the provided mechanisms so
that all other do not have to see the messages.
Currently trunk is close to untestable because of massive amounts of
debug output.
--
Lgb
On Mon, Jan 23, 2006 at 11:40:30PM +0200, Martin Vermeer wrote:
> That must have been a long time ago, when you were still on coffee...
It was never coffee. Just tea.
Andre'
On Mon, Jan 23, 2006 at 08:05:48PM +0100, Andre Poenitz wrote:
> On Mon, Jan 23, 2006 at 11:29:02AM +0200, Martin Vermeer wrote:
> > On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> > > This code compares pits,
On Mon, Jan 23, 2006 at 11:29:02AM +0200, Martin Vermeer wrote:
> On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > Martin> Ah yes... thanks. The attached should be OK in this respect.
> >
> >
> > I do not thin
On Mon, 2006-01-23 at 09:59 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Ah yes... thanks. The attached should be OK in this respect.
>
>
> I do not think so:
> - for ( ; it != et; it.forwardPos()) {
> + fo
On Mon, 2006-01-23 at 09:34 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> A patch for this is attached. An unbelievable story really...
> Martin> when doing cursor up/down, the new y co-ordinate is just _one
> Martin> pixel_ into the
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> This is nice and snappy. (Why would using the cache be
Martin> better?)
Using the cache is better for fixing bruteFind. You approach fixes a
different problem, in some sense.
JMarc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Ah yes... thanks. The attached should be OK in this respect.
I do not think so:
- for ( ; it != et; it.forwardPos()) {
+ for ( ; it != et && it.pit() < from + 2; it.forwardPos()) {
This code compa
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> BTW, in
Martin> inset->cursorPos(it.top(), c.boundary() && ((i+1) ==
Martin> it.depth()), xo, inset-> yo);
Martin> what precisely is the (i+1) == it.depth() condition for? Looks
Martin> nonsensical to me. i is the counter of doc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> A patch for this is attached. An unbelievable story really...
Martin> when doing cursor up/down, the new y co-ordinate is just _one
Martin> pixel_ into the next/previous row! Therefore the test for
Martin> being inside a math ins
On Sun, 2006-01-22 at 20:43 +0100, Andre Poenitz wrote:
> > The patch makes cursor movement a little more generous ;-)
>
> A comment stating this would be in order...
>
> Andre'
OK, see attached.
Would somebody test this, please?
Further remarks:
1) I don't think it is possible to get this co
> The patch makes cursor movement a little more generous ;-)
A comment stating this would be in order...
Andre'
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
| > On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
| > > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
| > > > > "Martin" == Martin Vermeer <[EM
On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> ...
>
> BTW2, we stil
On Sat, Jan 21, 2006 at 02:13:47PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> > On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> ...
>
> > It's snappy
On Fri, Jan 20, 2006 at 04:11:24PM +0100, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I have some questions/points for you...
>
> + // Unsafe if .find() can return .end()
> CoordCache::InnerParPosCache const & cache =
> theCoords.getPa
On Sat, Jan 21, 2006 at 05:59:08PM +0100, Georg Baum wrote:
> Am Samstag, 21. Januar 2006 13:13 schrieb Martin Vermeer:
> > About the rottenness, one thing is that in bruteFind2, the co-ordinates
> > xo, yo produced by the cursorPos call are relative, while the arguments
>
> There is an explanatio
Am Samstag, 21. Januar 2006 13:13 schrieb Martin Vermeer:
> About the rottenness, one thing is that in bruteFind2, the co-ordinates
> xo, yo produced by the cursorPos call are relative, while the arguments
There is an explanation about relative/absolute coordinates in some math
header file, but I
On Fri, Jan 20, 2006 at 10:06:15PM +0200, Martin Vermeer wrote:
> On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> It's snappy for me... BTW there is something rotten also in cursor
> positioning _inside_
On Fri, Jan 20, 2006 at 04:04:36PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> The slowness is really huge, so yes, that's what I think.
>
> Martin> I didn't give up though... attached a modification of
> Martin> bruteFind3 that do
Did I send this one already? Don't see it on the list.
This searches previous, current and next paragraph. I made bruteFind3 do
this, which was also simpler than I thought... and, I think, rather
risk-free.
This is nice and snappy. (Why would using the cache be better?)
...and what shall we do
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I have some questions/points for you...
+ // Unsafe if .find() can return .end()
CoordCache::InnerParPosCache const & cache =
theCoords.getParPos().find(cursor.bottom().text())->second;
bv::funcs::status does the same, so it
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> The slowness is really huge, so yes, that's what I think.
Martin> I didn't give up though... attached a modification of
Martin> bruteFind3 that does the three-paragraph trick. There is still
Martin> a slight delay, but it's much
On Fri, 2006-01-20 at 13:19 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> The other one would "fix" this bug by just moving to in
> Martin> front/behind the math inset. Ugly, but it remembers the x
> Martin> location when you press fu
Jean-Marc Lasgouttes wrote:
> The code that initializes the iterators looks a bit ugly, but it can
> be
> - factored out somewhere in bufferview.C
> - probably improved by someone who is better at STL than I am.
>
> I think it works, and would be interested by some testing. I believe
> the bruteF
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Searching the coordcache would be better.
Martin> I'm sure it would be possible, but too risky now for 1.4.0.
Here is what I have in mind. My assumptions here are that
1/ in a map, the elements are ordered wrt the key (pit_type he
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> The other one would "fix" this bug by just moving to in
Martin> front/behind the math inset. Ugly, but it remembers the x
Martin> location when you press further cursor ups/downs.
>> That is kind of ugly indeed. I was about to s
On Fri, 2006-01-20 at 11:17 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Yes. The one modifying bruteFind was rejected by Lars, on the
> Martin> ground (sound IMO) that he wants to keep that as a
> Martin> super-general find routine
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes. The one modifying bruteFind was rejected by Lars, on the
Martin> ground (sound IMO) that he wants to keep that as a
Martin> super-general find routine for when everything else fails.
I think it is possible to fix bruteFind
On Thu, Jan 19, 2006 at 04:17:15PM +0100, Jean-Marc Lasgouttes wrote:
> >>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> >> The following patch gets
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Please change this to "Setting new encoding for Qt:" which is
Martin> correct. My bad in Paris ;-)
I did so and committed.
JMarc
>>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
>> The following patch gets rid of some debug output. It also improves
>> some Counters error messages to be
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch gets rid of some debug output. It also improves
| some Counters error messages to be more useful (I saw these with
| beamer.layout).
|
| Lars, OK?
ok
--
Lgb
On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> The following patch gets rid of some debug output. It also improves
> some Counters error messages to be more useful (I saw these with
> beamer.layout).
>
> Lars, OK?
- lyxerr << "Setting new lo
On Thu, 2006-01-19 at 14:53 +0100, Jean-Marc Lasgouttes wrote:
> The following patch gets rid of some debug output. It also improves
> some Counters error messages to be more useful (I saw these with
> beamer.layout).
>
> Lars, OK?
Didn't you find goUpDown (moving up and down
The following patch gets rid of some debug output. It also improves
some Counters error messages to be more useful (I saw these with
beamer.layout).
Lars, OK?
JMarc
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx
On Saturday 14 August 2004 08:52, Michael Schmitt wrote:
> Hello,
>
> when loading a multi-part document, I get a lot of debug messages. Are
> they important, i.e., would you like to get more information?
No, these debug message are just very verbose. You cannot use LyX without
getting a lot of t
Hello,
when loading a multi-part document, I get a lot of debug messages. Are
they important, i.e., would you like to get more information?
Kind regards, Michael
.
examining inset 0x44dcad58 xo: 30...1246 yo: 1636...1660
examining inset 0x46d89f80 xo: 32...171 yo: 1679...1707
examining inset
64 matches
Mail list logo
