On 08/09/2010 07:11 PM, Jean-Marc Lasgouttes wrote:
OK, this patch is a new version of the PassThru patch that uses
ParbreakIsNewline.
With this patch, the changes that are needed in lyx2lyx qre only:
In the following layouts
* Chunk from module sweave
* Scrap from module noweb
* Scrap f
On 08/09/2010 05:24 PM, Jean-Marc Lasgouttes wrote:
Le 9 août 10 à 23:15, Richard Heck a écrit :
http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp12pt.pdf
Like with Wiles, we have to wait until we knows what holes are in there
and how easy it is to fix them.
Yes, things could fall a
OK, this patch is a new version of the PassThru patch that uses
ParbreakIsNewline.
With this patch, the changes that are needed in lyx2lyx qre only:
In the following layouts
* Chunk from module sweave
* Scrap from module noweb
* Scrap from classes literate-article, literate-book, literat
Le 9 août 10 à 23:15, Richard Heck a écrit :
http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp12pt.pdf
Like with Wiles, we have to wait until we knows what holes are in there
and how easy it is to fix them.
But there is hope.
JMarc
PS: and BTW P is NOT equal to NP!
http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp12pt.pdf
Le 9 août 10 à 21:55, Richard Heck a écrit :
On 08/09/2010 03:36 PM, Jean-Marc Lasgouttes wrote:
This causes a crash, because doc_it seems not to be properly
initialized or something.
What's weird is that when it was called like this:
it->fillWithBibKeys(d->bibinfo_, it)
it was fine. So the
On 08/09/2010 03:36 PM, Jean-Marc Lasgouttes wrote:
This causes a crash, because doc_it seems not to be properly
initialized or something.
What's weird is that when it was called like this:
it->fillWithBibKeys(d->bibinfo_, it)
it was fine. So the doc_it constructed here is not equivalent to t
Am Montag 09 August 2010 schrieb Richard Heck:
> On 08/09/2010 03:31 PM, Kornel Benko wrote:
> > Am Montag 09 August 2010 schrieb Jean-Marc Lasgouttes:
> >> Le 9 août 10 à 20:31, BH a écrit :
> >>> I'm trying to test, but when I try to open the User's Guide, I get a
> >>> crash (see below for backt
This causes a crash, because doc_it seems not to be properly
initialized or something.
What's weird is that when it was called like this:
it->fillWithBibKeys(d->bibinfo_, it)
it was fine. So the doc_it constructed here is not equivalent to the
one we get from the
code in Buffer::checkBibin
On 08/09/2010 03:31 PM, Kornel Benko wrote:
Am Montag 09 August 2010 schrieb Jean-Marc Lasgouttes:
Le 9 août 10 à 20:31, BH a écrit :
I'm trying to test, but when I try to open the User's Guide, I get a
crash (see below for backtrace). Is this related to your work here,
Richard?
Am Montag 09 August 2010 schrieb Jean-Marc Lasgouttes:
> Le 9 août 10 à 20:31, BH a écrit :
> > I'm trying to test, but when I try to open the User's Guide, I get a
> > crash (see below for backtrace). Is this related to your work here,
> > Richard?
>
> As far as lag is concerned, the bug is about
So this didn't work (segfault). But if we're to do fillWithBibKeys()
from updateBuffer(),
something like it has to be done. I.e., we will not have an
InsetIterator at this point.
Modified: lyx-devel/trunk/src/insets/InsetBibitem.cpp
===
Le 9 août 10 à 21:17, rgh...@lyx.org a écrit :
Help needed here. Why isn't this equivalent?
-void InsetBibitem::fillWithBibKeys(BiblioInfo & keys) const
+void InsetBibitem::fillWithBibKeys(BiblioInfo & keys, InsetIterator
const & it) const
{
docstring const key = getParam("key");
-
Le 9 août 10 à 20:31, BH a écrit :
I'm trying to test, but when I try to open the User's Guide, I get a
crash (see below for backtrace). Is this related to your work here,
Richard?
As far as lag is concerned, the bug is about very big files (and
without bibliography).
I am not sure the userg
Le 9 août 10 à 17:23, Uwe Stöhr a écrit :
I don't agree that every program should inherit the system-wide
colors. Every
program has its own purpose and thus needs different ergonomics
settings.
I agree that some programs require that, but the point where we
disagree is that
LyX is so `spe
On Mon, Aug 9, 2010 at 2:22 PM, Jean-Marc Lasgouttes wrote:
> Le 9 août 10 à 19:46, Richard Heck a écrit :
>>
>> It was kind of a silly mistake. But there's more for later.
>>
>> Can you confirm that these changes help?
>
> Yes, they do. I have no lag now on my iMac.
I'm trying to test, but when
Le 9 août 10 à 19:55, Richard Heck a écrit :
So I've had a look at this and made some more changes. But I've got
two concerns about doing things via updateBuffer().
As I wrote in the bug, I think calling updateBuffer is not a problem.
It is not supposed to do weird stuff
(but I am not sure
Le 9 août 10 à 19:46, Richard Heck a écrit :
It was kind of a silly mistake. But there's more for later.
Can you confirm that these changes help?
Yes, they do. I have no lag now on my iMac.
JMarc
On 08/09/2010 01:48 PM, Jean-Marc Lasgouttes wrote:
Le 9 août 10 à 19:01, rgh...@lyx.org a écrit :
Log:
More work toward speeding up the bibfile caching stuff.
This looks good.
From bug 6846:
So I've had a look at this and made some more changes. But I've got two
concerns about doing
Le 9 août 10 à 19:01, rgh...@lyx.org a écrit :
Log:
More work toward speeding up the bibfile caching stuff.
This looks good.
JMarc
On 08/09/2010 01:43 PM, Jean-Marc Lasgouttes wrote:
Le 9 août 10 à 18:18, rgh...@lyx.org a écrit :
Log:
Do not invalidate cache unless we find some BibTeX insets. Part of
#6846.
Wow. That was fast!
It was kind of a silly mistake. But there's more for later.
Can you confirm that these change
Le 9 août 10 à 18:18, rgh...@lyx.org a écrit :
Log:
Do not invalidate cache unless we find some BibTeX insets. Part of
#6846.
Wow. That was fast!
JMarc
Richard Heck writes:
> If you tell me exactly what needs doing, I can do it for you. I take
> it that it is something like:
> 1. Check if we're using certain classes; if not, we're OK. Which ones?
> 2. Check if we're in a certain sort of layout; if not, we're OK. Which?
> 3. If we are
I repost here what I just added to bug #6846, because I think this has
general interest in terms of large documents. This is a bug where very
large documents with math insets become very slow when deleting text.
JMarc
gprof points to Buffer::checkBibInfoCache:
{{{
0.88 21.72
While we are at the color stuff, there is a general issue we should try
to solve to support per-document color settings:
http://www.lyx.org/trac/ticket/6626
regards Uwe
> If you try to google for this problem, you will also find people who
> explain that using a dark background is a better solution (not that I
> agree with that, sincerely I do not know). A nice property of my
> patch is that, if you select such an inverted theme in gnome, LyX
> will inherit it
On 08/09/2010 08:46 AM, Jean-Marc LASGOUTTES wrote:
Richard Heck writes:
Hmm. Well, short of trying to make lyx2lyx layout-aware, I have no
idea what to do about this. That said, the old behavior is surely
broken.
I could hardcode the names of layouts that need it (Chunk, Scrap, the
Richard Heck writes:
> I see what this does now, and I like it. I'm not sure if this feature
> should be independent of passthru or not. Are there or might there be
> cases where one might be wanted but not the other? I guess I'd be
> inclined to separate them, i.e., do the other patch, too, unles
Pavel Sanda writes:
> * There has been some work on dispatch results, unfinished now as bugs
> reveal. (bug #6417).
As far as #6417 is concerned, we could keep a stack of ongoing dispatch
actions in this way:
void dispatch(...)
{
// pushes a DispatchResult on a stack at creation, po
Richard Heck writes:
> I take it the former should have been RC_USE_SYSTEM_COLORS.
Yes, but since the code is not compiled... I wonder whether we should
just nuke it.
JMarc
Jürgen Spitzmüller writes:
> This is OK from my POV. Now we should probably find out what colors can be
> derived from the system settings.
The list is here:
http://doc.trolltech.com/4.6/qpalette.html#ColorRole-enum
Things I did not try is for example use tootltip background for
InsetNote or us
Am 09.08.2010 um 00:43 schrieb Abdelrazak Younes:
> On Wed, Aug 4, 2010 at 8:02 AM, Stephan Witt wrote:
> Am 04.08.2010 um 00:51 schrieb Jean-Marc Lasgouttes:
>>
>> > The problem with this approach is that I am not even sure that it will be
>> > enough. I am not sure
>> > whether the time is s
32 matches
Mail list logo
