Jürgen Spitzmüller wrote:
also see this problem reported by Anders:
http://bugzilla.lyx.org/show_bug.cgi?id=3958#c44
Which turned out to be another critical bug :-(
http://bugzilla.lyx.org/show_bug.cgi?id=4046
Jürgen
OK?
Jürgen
Index: lib/unicodesymbols
===
--- lib/unicodesymbols (Revision 19151)
+++ lib/unicodesymbols (Arbeitskopie)
@@ -35,7 +35,7 @@
0x00a6 \\textbrokenbar textcomp # BROKEN BAR
0x00a7 \\textsection
Jürgen Spitzmüller wrote:
Which turned out to be another critical bug :-(
http://bugzilla.lyx.org/show_bug.cgi?id=4046
Here's the fix. José, this was introduced with your latest cleanup.
Jürgen
Index: lib/lyx2lyx/lyx_1_5.py
===
Jürgen Spitzmüller wrote:
Here's the fix. José, this was introduced with your latest cleanup.
Turns out the other removed linebreaks are needed as well (see attached
patch). Don't know what about this change:
- math_outro='$\n\\end_inset\n'
+ math_outro='$\n\\end_inset'
Jürgen
Index:
Guillaume Pothier wrote:
Abdel, I tried your patch and it actually makes things noticeably slower!
Too bad! I guess the performance depends on the pixmap painting
capabilities of your system. On Windows and I think Mac, it is
definitely faster.
Abdel.
Darren Freeman wrote:
On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any
difference.
Could you please try this patch?
No noticeable effect, on the same document both with and without the
On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
Guillaume Pothier wrote:
Abdel, I tried your patch and it actually makes things noticeably slower!
Too bad! I guess the performance depends on the pixmap painting
capabilities of your system. On Windows and I think Mac, it is
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing
where the slowdown is. We need profile results! So, if you want to have
a faster 1.5, please try to provide some.
I would love that but I'm currently without
[EMAIL PROTECTED] schrieb:
Modified: lyx-devel/trunk/src/Paragraph.cpp
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.cpp?rev=19150
==
--- lyx-devel/trunk/src/Paragraph.cpp (original)
+++
Darren Freeman schrieb:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing
where the slowdown is. We need profile results! So, if you want to have
a faster 1.5, please try to provide some.
Unfortunately
Darren Freeman wrote:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing
where the slowdown is. We need profile results! So, if you want to have
a faster 1.5, please try to provide some.
I would love that but I'm
Hi,
I just uploaded a patch for the flashcards package to make it work with newer
latex versions. It solves the a4paper issue.
Uwe, which other stuff do you have to specify? Do you mean using lyx or just
latex? I try to help out where I can here... (at last something where I can
help maybe
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside deleted insets is
displayed as unchanged text), I would like you to reconsider the patch
On Friday 20 July 2007 07:33:20 Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Which turned out to be another critical bug :-(
http://bugzilla.lyx.org/show_bug.cgi?id=4046
Here's the fix. José, this was introduced with your latest cleanup.
Jürgen
OK. I suspected about this fix but I
On Friday 20 July 2007 07:17:30 Jürgen Spitzmüller wrote:
OK?
Jürgen
Sure.
--
José Abílio
On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
Hmpf wasn't the removal of the const-ness the major reason why my
change tracking patch was rejected?
Michael
You are right. It seems that we need some kind of state machine to run across
latex/docbook generation. And the OutputParams
Michael Gerz schrieb:
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside deleted insets
is displayed as unchanged text), I would like you to
I don't know if it is related but with the svn version compiled
yesterday there is a very noticeable lag in typing. Attached is a
file that is causing problems.
i have tried your file with rc2 (on linux) and dont see any typing lag.
cant try it on svn now - but is it with rc2 better for you ?
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
IMHO 14 parameters are enough. Don't you think that a container like
OutputParams is the better solution?
Michael
But not OutputParams. OutputParams are parameters used to control the output,
as I said before you want something like
Uwe Stöhr wrote:
-0x00a9 \textcopyright textcomp # COPYRIGHT SIGN
+0x00a9 \\textcopyright textcomp # COPYRIGHT SIGN
Should be
-0x00a9 \textcopyright textcomp # COPYRIGHT SIGN
+0x00a9 \\textcopyright textcomp # COPYRIGHT SIGN
Pardon?
Jürgen
José Matos schrieb:
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
IMHO 14 parameters are enough. Don't you think that a container like
OutputParams is the better solution?
Michael
But not OutputParams. OutputParams are parameters used to control the output,
as I said before
José Matos wrote:
On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
Hmpf wasn't the removal of the const-ness the major reason why my
change tracking patch was rejected?
Michael
You are right. It seems that we need some kind of state machine to run across
latex/docbook generation. And
Hi!
This should be added to the release notes. The problem was first
reported here http://permalink.gmane.org/gmane.editors.lyx.devel/88806,
it turned out to be related to the fact that we have now turned on the
RTL option by default. I just opened a bug report for this now (bug 4051).
I
[EMAIL PROTECTED] wrote:
On Tue, 3 Jul 2007, Dov Feldstern wrote:
3) With a keymap, we (the LyX programmers) are in control. Two examples:
(a) Almost always, a keymap switch should be accompanied by a language
switch, or vice-versa.
I'm not sure I agree about with the assumption about
Jean-Marc Lasgouttes wrote:
Dov == Dov Feldstern dfeldstern-rhxOsnTko2JWk0Htik3J/[EMAIL PROTECTED]
writes:
Dov 1) As I said, this issue has come up on a few separate occasions
Dov in the past few months (mainly in connection with RTL languages),
Dov and each time there have been voices
Jürgen Spitzmüller wrote:
-0x00a9 \textcopyright textcomp # COPYRIGHT SIGN
+0x00a9 \\textcopyright textcomp # COPYRIGHT SIGN
Pardon?
Oh, I see. Fixed.
Jürgen
Dov Feldstern wrote:
As far as the .lyx file is concerned: languages remain in effect until
explicitly switched; the exception, though, is insets: inside an inset,
the language is assumed to revert to the document language, unless
explicitly told otherwise.
Just a correction, in case anyone
Michael Gerz wrote:
José Matos schrieb:
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
IMHO 14 parameters are enough. Don't you think that a container like
OutputParams is the better solution?
Michael
But not OutputParams. OutputParams are parameters used to control the
output,
Michael Gerz wrote:
Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen)
be willing with a temporary fix like the one posted before and find an
elegant solution for 1.6.0?
If it's well tested, I wouldn't be opposed to it. But for 1.5.0, it's José's
call.
Jürgen
José Matos wrote:
The remaining tasks are:
- convert layout files to utf8
- convert documentation to latest file format version
- update documentation
- other (?)
The current state is, AFAICS:
- the above and some lyx2lyx issues that might be considered:
On Friday 20 July 2007 13:37:36 Dov Feldstern wrote:
I hope to solve this problem eventually, see discussion at
http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I
think that adding this comment the the release notes should be enough.
Dov
OK.
--
José Abílio
On Friday 20 July 2007 12:46:47 Michael Gerz wrote:
Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen)
be willing with a temporary fix like the one posted before and find an
elegant solution for 1.6.0?
Yes. This can go in 1.5.0 assuming the code has been tested (coming
José Matos wrote:
On Friday 20 July 2007 13:37:36 Dov Feldstern wrote:
I hope to solve this problem eventually, see discussion at
http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I
think that adding this comment the the release notes should be enough.
Dov
OK.
Done.
On Thursday 19 July 2007 19:10:26 Enrico Forestieri wrote:
Yes, that's it. What about the attached patch?
--
Enrico
I am not sure that affects all systems but technically you are correct, this
was fixed just for 2.3.4, right?
OK.
--
José Abílio
If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).
Ok I'll try it.
Where are profiling results going to be output?
g
Where are profiling results going to be output?
i thought gprof should be used.
however i didnt succeeded when running it - lyx
immediately ends and gprof makes only analysis
of that run. maybe some additional parameter
sould be given, but i dont know which one.
pavel
On Friday 20 July 2007 14:27:56 Jürgen Spitzmüller wrote:
- the above and some lyx2lyx issues that might be considered: 4048, 4050
(oneliner from Anders available), 3313 (ordered in decreasing severity,
IMHO). Plus eventually Michael's patch.
Concerning the lyx2lyx issues, I'd say since you
Abdelrazak Younes wrote:
Darren Freeman wrote:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without
nothing where the slowdown is. We need profile results! So, if you
want to have a faster 1.5, please try to provide some.
On Fri, Jul 20, 2007 at 06:35:52PM +1000, Darren Freeman wrote:
On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
Guillaume Pothier wrote:
Abdel, I tried your patch and it actually makes things noticeably slower!
Too bad! I guess the performance depends on the pixmap painting
On Fri, Jul 20, 2007 at 11:34:38AM +0200, Michael Gerz wrote:
Michael Gerz schrieb:
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside
On Fri, Jul 20, 2007 at 02:42:35PM +0300, Dov Feldstern wrote:
José Matos wrote:
On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
Hmpf wasn't the removal of the const-ness the major reason why my
change tracking patch was rejected?
Michael
You are right. It seems that we need some
José Matos wrote:
OK. I have just committed a fix for 4048, it follows the idea proposed by
Georg in bug 3985.
I have tried my best (to obfuscate the code). ;-)
Great!
Please test.
Looks good from my first test (fixes Georg's test case, and the UserGuide
still seems to compile fine).
However, while testing with the EmbeddedObjects document, I stumbled over
another bug in revert_listings_inset (unrelated to unicode): revert the
attached example to 1.4 and see how the line
# Example listing float
in the listing has disappeared
Thanks. I will have a look.
Bo
Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the document I already sent, typing random stuff within
floats, in paragraphs containing math insets, and in new paragraphs.
Please tell me if I can provide more info.
g
On 7/20/07, Abdelrazak Younes
However, while testing with the EmbeddedObjects document, I stumbled over
another bug in revert_listings_inset (unrelated to unicode): revert the
attached example to 1.4 and see how the line
# Example listing float
in the listing has disappeared
I just committed a patch, please test.
Bo
Guillaume Pothier wrote:
Here are the profiling results:
http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the document I already sent, typing random stuff within
floats, in paragraphs containing math insets, and in new paragraphs.
Please tell me if I can provide more info.
g
Lyx 1.5.0 has a new feature that you can open a lyx file with local
.layout and .cls files. That is to say, if someone sends you a zip
file with a lyx file and some foreign .cls and .layout files you can
simply unpack and open the .lyx file.
This is the result of my now-stopped 'local .layout
Sorry, I forgot that flag when I compiled with profiling enabled...
I'm compiling with both now, I'll report soon.
g
On 7/20/07, Peter Kümmel [EMAIL PROTECTED] wrote:
Guillaume Pothier wrote:
Here are the profiling results:
http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the
On Fri, Jul 20, 2007 at 03:46:32PM +0300, Dov Feldstern wrote:
[EMAIL PROTECTED] wrote:
On Tue, 3 Jul 2007, Dov Feldstern wrote:
3) With a keymap, we (the LyX programmers) are in control. Two examples:
(a) Almost always, a keymap switch should be accompanied by a language
switch, or
On Fri, Jul 20, 2007 at 03:11:47PM +0100, José Matos wrote:
I am not sure that affects all systems but technically you are correct, this
was fixed just for 2.3.4, right?
Right: http://www.python.org/download/releases/2.3.4/NEWS.txt
Apparently, it was affecting all systems.
OK.
I committed
Hi, so I compiled lyx with profiling enabled and without debug info,
and I updated the gprof.out (same URL:
http://www.dcc.uchile.cl/~gpothier/gprof.out)
g
On 7/20/07, Peter Kümmel [EMAIL PROTECTED] wrote:
Guillaume Pothier wrote:
Here are the profiling results:
Bo Peng wrote:
I just committed a patch, please test.
The line is there, but there's a linebreak missing:
\begin{lstlisting}[language=Python,caption={Example Listing
float},label={lst:Example-Listing}]# Example listing float
def func(param):
'this is a python function'
pass
A user informed me that utf8-plain (for XeTeX) doesn't work because \inputenc
is called (which is exactly what utf8-plain shouldn't do).
It turned out that we use the wrong encoding check (the one of the document
language's default encoding, not the actual selected encoding), which breaks
The line is there, but there's a linebreak missing:
\begin{lstlisting}[language=Python,caption={Example Listing
float},label={lst:Example-Listing}]# Example listing float
So I did not have an extra \end_layout, but missed a \begin_layout.
This should have been fixed now.
Thanks.
Bo
Bo Peng wrote:
This should have been fixed now.
Yes. Thanks.
Jürgen
Jürgen Spitzmüller wrote:
> also see this problem reported by Anders:
> http://bugzilla.lyx.org/show_bug.cgi?id=3958#c44
Which turned out to be another critical bug :-(
http://bugzilla.lyx.org/show_bug.cgi?id=4046
Jürgen
OK?
Jürgen
Index: lib/unicodesymbols
===
--- lib/unicodesymbols (Revision 19151)
+++ lib/unicodesymbols (Arbeitskopie)
@@ -35,7 +35,7 @@
0x00a6 "\\textbrokenbar" "textcomp" "" # BROKEN BAR
0x00a7 "\\textsection"
Jürgen Spitzmüller wrote:
> Which turned out to be another critical bug :-(
> http://bugzilla.lyx.org/show_bug.cgi?id=4046
Here's the fix. José, this was introduced with your latest cleanup.
Jürgen
Index: lib/lyx2lyx/lyx_1_5.py
===
Jürgen Spitzmüller wrote:
> Here's the fix. José, this was introduced with your latest cleanup.
Turns out the other removed linebreaks are needed as well (see attached
patch). Don't know what about this change:
- math_outro='$\n\\end_inset\n'
+ math_outro='$\n\\end_inset'
Jürgen
Index:
Guillaume Pothier wrote:
Abdel, I tried your patch and it actually makes things noticeably slower!
Too bad! I guess the performance depends on the pixmap painting
capabilities of your system. On Windows and I think Mac, it is
definitely faster.
Abdel.
Darren Freeman wrote:
On Thu, 2007-07-19 at 22:27 +0200, Abdelrazak Younes wrote:
Guillaume Pothier wrote:
Ok, I also tried with --disable-stdlib-debug and I don't notice any
difference.
Could you please try this patch?
No noticeable effect, on the same document both with and without the
On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
> Guillaume Pothier wrote:
> > Abdel, I tried your patch and it actually makes things noticeably slower!
>
> Too bad! I guess the performance depends on the pixmap painting
> capabilities of your system. On Windows and I think Mac, it
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
> I am sorry to hear that but we have no way to help you without nothing
> where the slowdown is. We need profile results! So, if you want to have
> a faster 1.5, please try to provide some.
I would love that but I'm currently without
[EMAIL PROTECTED] schrieb:
Modified: lyx-devel/trunk/src/Paragraph.cpp
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.cpp?rev=19150
==
--- lyx-devel/trunk/src/Paragraph.cpp (original)
+++
Darren Freeman schrieb:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing
where the slowdown is. We need profile results! So, if you want to have
a faster 1.5, please try to provide some.
Unfortunately
Darren Freeman wrote:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without nothing
where the slowdown is. We need profile results! So, if you want to have
a faster 1.5, please try to provide some.
I would love that but I'm
Hi,
I just uploaded a patch for the flashcards package to make it work with newer
latex versions. It solves the a4paper issue.
Uwe, which other stuff do you have to specify? Do you mean using lyx or just
latex? I try to help out where I can here... (at last something where I can
help maybe
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside deleted insets is
displayed as unchanged text), I would like you to reconsider the patch
On Friday 20 July 2007 07:33:20 Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
> > Which turned out to be another critical bug :-(
> > http://bugzilla.lyx.org/show_bug.cgi?id=4046
>
> Here's the fix. José, this was introduced with your latest cleanup.
>
> Jürgen
OK. I suspected about this
On Friday 20 July 2007 07:17:30 Jürgen Spitzmüller wrote:
> OK?
>
> Jürgen
Sure.
--
José Abílio
On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
> Hmpf wasn't the removal of the const-ness the major reason why my
> change tracking patch was rejected?
>
> Michael
You are right. It seems that we need some kind of state machine to run across
latex/docbook generation. And the
Michael Gerz schrieb:
Guys,
with Dov's latest patch (#1820) committed, I was able to produce a CT
patch that does not touch the present (non-)const-ness of OutputParams.
Since I consider this bug a major CT bug (text inside deleted insets
is displayed as unchanged text), I would like you to
> I don't know if it is related but with the svn version compiled
> yesterday there is a very noticeable lag in typing. Attached is a
> file that is causing problems.
i have tried your file with rc2 (on linux) and dont see any typing lag.
cant try it on svn now - but is it with rc2 better for
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
> IMHO 14 parameters are enough. Don't you think that a container like
> OutputParams is the better solution?
>
> Michael
But not OutputParams. OutputParams are parameters used to control the output,
as I said before you want something like
Uwe Stöhr wrote:
> -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN
> +0x00a9 "\\textcopyright" "textcomp" "" # COPYRIGHT SIGN
>
> Should be
>
> -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN
> +0x00a9 "\\textcopyright" "textcomp" "" #
José Matos schrieb:
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
IMHO 14 parameters are enough. Don't you think that a container like
OutputParams is the better solution?
Michael
But not OutputParams. OutputParams are parameters used to control the output,
as I said before
José Matos wrote:
On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
Hmpf wasn't the removal of the const-ness the major reason why my
change tracking patch was rejected?
Michael
You are right. It seems that we need some kind of state machine to run across
latex/docbook generation. And
Hi!
This should be added to the release notes. The problem was first
reported here http://permalink.gmane.org/gmane.editors.lyx.devel/88806,
it turned out to be related to the fact that we have now turned on the
RTL option by default. I just opened a bug report for this now (bug 4051).
I
[EMAIL PROTECTED] wrote:
On Tue, 3 Jul 2007, Dov Feldstern wrote:
3) With a keymap, we (the LyX programmers) are in control. Two examples:
(a) Almost always, a keymap switch should be accompanied by a language
switch, or vice-versa.
I'm not sure I agree about with the assumption about
Jean-Marc Lasgouttes wrote:
"Dov" == Dov Feldstern
writes:
Dov> 1) As I said, this issue has come up on a few separate occasions
Dov> in the past few months (mainly in connection with RTL languages),
Dov> and each time there have been voices dismissing the keymap as
Dov> unimportant, or even
Jürgen Spitzmüller wrote:
> > -0x00a9 "\textcopyright" "textcomp" "" # COPYRIGHT SIGN
> > +0x00a9 "\\textcopyright" "textcomp" "" # COPYRIGHT SIGN
>
> Pardon?
Oh, I see. Fixed.
Jürgen
Dov Feldstern wrote:
As far as the .lyx file is concerned: languages remain in effect until
explicitly switched; the exception, though, is insets: inside an inset,
the language is assumed to revert to the document language, unless
explicitly told otherwise.
Just a correction, in case anyone
Michael Gerz wrote:
José Matos schrieb:
On Friday 20 July 2007 10:34:38 Michael Gerz wrote:
IMHO 14 parameters are enough. Don't you think that a container like
OutputParams is the better solution?
Michael
But not OutputParams. OutputParams are parameters used to control the
output,
Michael Gerz wrote:
> Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen)
> be willing with a temporary fix like the one posted before and find an
> elegant solution for 1.6.0?
If it's well tested, I wouldn't be opposed to it. But for 1.5.0, it's José's
call.
Jürgen
José Matos wrote:
> The remaining tasks are:
> - convert layout files to utf8
> - convert documentation to latest file format version
> - update documentation
> - other (?)
The current state is, AFAICS:
- the above and some lyx2lyx issues that might be
On Friday 20 July 2007 13:37:36 Dov Feldstern wrote:
> I hope to solve this problem eventually, see discussion at
> http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I
> think that adding this comment the the release notes should be enough.
>
> Dov
OK.
--
José Abílio
On Friday 20 July 2007 12:46:47 Michael Gerz wrote:
> Just to make sure: Is OutputState 1.5.X stuff or would you (and Jürgen)
> be willing with a temporary fix like the one posted before and find an
> elegant solution for 1.6.0?
Yes. This can go in 1.5.0 assuming the code has been tested
José Matos wrote:
On Friday 20 July 2007 13:37:36 Dov Feldstern wrote:
I hope to solve this problem eventually, see discussion at
http://permalink.gmane.org/gmane.editors.lyx.devel/88939. But for now, I
think that adding this comment the the release notes should be enough.
Dov
OK.
Done.
On Thursday 19 July 2007 19:10:26 Enrico Forestieri wrote:
> Yes, that's it. What about the attached patch?
>
> --
> Enrico
I am not sure that affects all systems but technically you are correct, this
was fixed just for 2.3.4, right?
OK.
--
José Abílio
If you can find the time to compile from a svn, compiling with profiling
enabled is supposed to be easy on linux (with --enable-profile or
something).
Ok I'll try it.
Where are profiling results going to be output?
g
> Where are profiling results going to be output?
i thought gprof should be used.
however i didnt succeeded when running it - lyx
immediately ends and gprof makes only analysis
of that run. maybe some additional parameter
sould be given, but i dont know which one.
pavel
On Friday 20 July 2007 14:27:56 Jürgen Spitzmüller wrote:
> - the above and some lyx2lyx issues that might be considered: 4048, 4050
> (oneliner from Anders available), 3313 (ordered in decreasing severity,
> IMHO). Plus eventually Michael's patch.
>
> Concerning the lyx2lyx issues, I'd say since
Abdelrazak Younes wrote:
Darren Freeman wrote:
On Fri, 2007-07-20 at 10:32 +0200, Abdelrazak Younes wrote:
I am sorry to hear that but we have no way to help you without
nothing where the slowdown is. We need profile results! So, if you
want to have a faster 1.5, please try to provide some.
On Fri, Jul 20, 2007 at 06:35:52PM +1000, Darren Freeman wrote:
> On Fri, 2007-07-20 at 10:29 +0200, Abdelrazak Younes wrote:
> > Guillaume Pothier wrote:
> > > Abdel, I tried your patch and it actually makes things noticeably slower!
> >
> > Too bad! I guess the performance depends on the pixmap
On Fri, Jul 20, 2007 at 11:34:38AM +0200, Michael Gerz wrote:
> Michael Gerz schrieb:
> >Guys,
> >
> >with Dov's latest patch (#1820) committed, I was able to produce a CT
> >patch that does not touch the present (non-)const-ness of OutputParams.
> >
> >Since I consider this bug a major CT bug
On Fri, Jul 20, 2007 at 02:42:35PM +0300, Dov Feldstern wrote:
> José Matos wrote:
> >On Friday 20 July 2007 09:42:40 Michael Gerz wrote:
> >>Hmpf wasn't the removal of the const-ness the major reason why my
> >>change tracking patch was rejected?
> >>
> >>Michael
> >
> >You are right. It
José Matos wrote:
> OK. I have just committed a fix for 4048, it follows the idea proposed by
> Georg in bug 3985.
>
> I have tried my best (to obfuscate the code). ;-)
Great!
> Please test.
Looks good from my first test (fixes Georg's test case, and the UserGuide
still seems to compile fine).
However, while testing with the EmbeddedObjects document, I stumbled over
another bug in revert_listings_inset (unrelated to unicode): revert the
attached example to 1.4 and see how the line
# Example listing float
in the listing has disappeared
Thanks. I will have a look.
Bo
Here are the profiling results: http://www.dcc.uchile.cl/~gpothier/gprof.out
This was using the document I already sent, typing random stuff within
floats, in paragraphs containing math insets, and in new paragraphs.
Please tell me if I can provide more info.
g
On 7/20/07, Abdelrazak Younes
However, while testing with the EmbeddedObjects document, I stumbled over
another bug in revert_listings_inset (unrelated to unicode): revert the
attached example to 1.4 and see how the line
# Example listing float
in the listing has disappeared
I just committed a patch, please test.
Bo
1 - 100 of 110 matches
Mail list logo
