> My small files still give wrong output, though (duplicated first line)
This was a last-minute clean-up, but I forgot to update the rp. This happens
before the algorithm really starts.
Fixed at r33184.
Now we have immediately a check whether the files are the same. If so, the
algorithm shoul
Jürgen Spitzmüller wrote:
> I think you need to set a GridLayout to the GroupBox (also, the two Radio
> buttons need accelerators, and the two Browse buttons need different
> accelerators)
As in the attached patch.
Jürgen
Index: src/frontends/qt4/ui/CompareUi.ui
>>
>> If you click Compare, a thread is started and the Close button
changes
>> to Cancel: to stop the thread.
>>
>> After pressing it, it will stop the thread and the button text
changes
>> back to Close: to close the window.
>
>Why not close the window right away?
>
I don't know.. Maybe becaus
"Vincent van Ravesteijn - TNW" writes:
>>BTW, when I click on Cancel, the button just turns to
>>'Close'. What does that mean?
>
> If you click Compare, a thread is started and the Close button changes
> to Cancel: to stop the thread.
>
> After pressing it, it will stop the thread and the button
Jürgen Spitzmüller wrote:
> and the two Browse buttons need different
> accelerators)
Sorry, this is only in the German localization.
Jürgen
Vincent van Ravesteijn - TNW wrote:
> >- with my qt 4.2.x the frame "Options" appears empty
>
> I don't really have a clue how to solve it. Isn't it the problem of the
> "Expanding" sizepolicy that is not understood by qt4.2 ?
I think you need to set a GridLayout to the GroupBox (also, the two Ra
>I do not like much this business of loading buffers without
>showing them, actually... And with this browse button, I feel
>the feature feels more like an additional utility than a part
>of the program.
That's why it is in the Tools menu ;).
>BTW, when I click on Cancel, the button just turns to
>Other remarks in no particular order:
>
>- with my qt 4.2.x the frame "Options" appears empty
>
I don't really have a clue how to solve it. Isn't it the problem of the
"Expanding" sizepolicy that is not understood by qt4.2 ?
>- Could we have nice names displayed instead of full names?
I don'
Jean-Marc Lasgouttes wrote:
> Pavel Sanda writes:
>
> > Abdelrazak Younes wrote:
> >> Maybe keep a Browse button in order to load another document in the
> >> background. And the combo box displaying the list of open buffers would be
> >> automatically updated; and maybe a coffee when you are a
Pavel Sanda writes:
> Abdelrazak Younes wrote:
>> Maybe keep a Browse button in order to load another document in the
>> background. And the combo box displaying the list of open buffers would be
>> automatically updated; and maybe a coffee when you are at it...
>
> i would also let the browse
Abdelrazak Younes writes:
> Maybe keep a Browse button in order to load another document in the
> background. And the combo box displaying the list of open buffers
> would be automatically updated; and maybe a coffee when you are at
> it...
I do not like much this business of loading buffers with
Abdelrazak Younes wrote:
> Maybe keep a Browse button in order to load another document in the
> background. And the combo box displaying the list of open buffers would be
> automatically updated; and maybe a coffee when you are at it...
i would also let the browse button live. and instead of ba
On 01/22/2010 04:48 PM, Jean-Marc Lasgouttes wrote:
Jean-Marc Lasgouttes writes:
Vincent van Ravesteijn writes:
Is it fixed at r33137 ?
Yes, and valgrind does not complain anymore. My small files still give
wrong output, though (duplicated first line)
Other remarks
Jean-Marc Lasgouttes writes:
> Vincent van Ravesteijn writes:
>> Is it fixed at r33137 ?
>
> Yes, and valgrind does not complain anymore. My small files still give
> wrong output, though (duplicated first line)
Other remarks in no particular order:
- with my qt 4.2.x the frame "Options" appear
Vincent van Ravesteijn writes:
> Is it fixed at r33137 ?
Yes, and valgrind does not complain anymore. My small files still give
wrong output, though (duplicated first line)
JMarc
#LyX 2.0.0svn created this file. For more info see http://www.lyx.org/
\lyxformat 376
\begin_document
\begin_header
Everytime compl_vector::operator[] needs an index that does not exist,
it does a push_back which can/will reallocate the whole vector when a
bigger memory block is necessary. I had the same mysterious bugs with
tex2lyx a few months ago.
This means that if you hold a DocIterator& of an element o
On Monday 18 January 2010 17:18:47 Jean-Marc Lasgouttes wrote:
> Everytime compl_vector::operator[] needs an index that does not exist,
> it does a push_back which can/will reallocate the whole vector when a
> bigger memory block is necessary. I had the same mysterious bugs with
> tex2lyx a few mon
On 01/18/2010 12:18 PM, Jean-Marc Lasgouttes wrote:
"Vincent van Ravesteijn - TNW" writes:
It still crashes, but in a less evident way. I therefore
ran it under valgrind, which complains a lot (but does
not crash). It looks like the code refers to memory that
has been freed already.
Jean-Marc Lasgouttes writes:
> (I am recompiling without stdlib-debug to see whether it makes things
> clearer, but I doubt it.)
Here is the new log file.
I think the problem lies in furthestDpathKdiagonal.
JMarc
"Vincent van Ravesteijn - TNW" writes:
>>It still crashes, but in a less evident way. I therefore
>>ran it under valgrind, which complains a lot (but does
>>not crash). It looks like the code refers to memory that
>>has been freed already.
>
> I'm not doing difficult memory things.. So i'm a bit
>It still crashes, but in a less evident way. I therefore
>ran it under valgrind, which complains a lot (but does
>not crash). It looks like the code refers to memory that
>has been freed already.
I'm not doing difficult memory things.. So i'm a bit puzzled.
Is this also caused by the stdlib-debu
Vincent van Ravesteijn writes:
>> It comes from gcc vector-index checks, so you may not see it. What
>> happens is that forwardPos can put you at the end of a paragraph, and
>> that it is not a good idea to ask for the character which is at this
>> position.
> Does r33052 fix this ?
I'll check t
Jean-Marc Lasgouttes schreef:
"Vincent van Ravesteijn - TNW" writes:
I tried to compare the Intro from trunk and branch
and got the following. Vincent?
Can you reproduce it ? I don't see it.
It comes from gcc vector-index checks, so you may not see it. What
happens is
"Vincent van Ravesteijn - TNW" writes:
>
>>I tried to compare the Intro from trunk and branch
>>and got the following. Vincent?
>
> Can you reproduce it ? I don't see it.
It comes from gcc vector-index checks, so you may not see it. What
happens is that forwardPos can put you at the end of a
>I tried to compare the Intro from trunk and branch
>and got the following. Vincent?
Can you reproduce it ? I don't see it.
Are these by accident the same docs ? (The assertion is already there
before the algorithm is even started).
Maybe I should change "to.backwardPos()" to "step(to, Backwa
Jean-Marc Lasgouttes writes:
> I tried to compare the Intro from trunk and branch and got the
> following. Vincent?
> #4 0x083323a2 in lyx::Paragraph::getChar (this=0x9765780, pos=19)
> at ../../lyx-devel/src/Paragraph.cpp:3003
> #5 0x080bd00e in traverseSnake (p...@0xb6181f04, range=,
>
I tried to compare the Intro from trunk and branch and got the
following. Vincent?
JMarc
/usr/lib/gcc/i586-mandriva-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:709:
typename _Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_Cha
27 matches
Mail list logo
