Am 09.09.2010 um 08:35 schrieb Cyrille Artho:
> Dear Stephan,
> I think that fink also uses qt4 by default; qt3 may have been left on my
> system for providing compatibility with old programs. I may have used
> one such old program in the past, which was why qt3 was still there.
>
> I had added t
Dear Stephan,
I think that fink also uses qt4 by default; qt3 may have been left on my
system for providing compatibility with old programs. I may have used
one such old program in the past, which was why qt3 was still there.
I had added the option --build=x86 to the ./configure flags for LyX as
Am 09.09.2010 um 07:32 schrieb Cyrille Artho:
> Hi Stephan,
> in the earlier attempt from my previous e-mail, I unfortunately still had
> remnants of a system-wide installation of qt3 left. I have since then removed
> that, and the number of linking problems has gone down significantly.
I canno
Hi Stephan,
in the earlier attempt from my previous e-mail, I unfortunately still
had remnants of a system-wide installation of qt3 left. I have since
then removed that, and the number of linking problems has gone down
significantly.
I am using fink, but for the purpose of using LyX, I use a
Am 08.09.2010 um 23:59 schrieb Jean-Marc Lasgouttes:
> Le 8 sept. 10 à 17:27, [Ricardo Rodriguez] eBioTIC. a écrit :
>> I guess that information concerning LyX in the R-project will be updated
>> when LyX 2.0.0 is on the can.
>> The same will be true with "LyX with R through Sweave" in the LyX wi
Le 8 sept. 10 à 18:42, Uwe Stöhr a écrit :
I need mi.base.textwidth in LineInset::draw. JMarc told me how to
acces it via text_metrics_.width() in rowpainter.cpp. But
text_metrics_.width() gives 684
while mi.base.textwidth gives 630
Therefore I added as workaround the factor 684/630.
Ugh. I d
Le 8 sept. 10 à 17:27, [Ricardo Rodriguez] eBioTIC. a écrit :
I guess that information concerning LyX in the R-project will be
updated when LyX 2.0.0 is on the can.
The same will be true with "LyX with R through Sweave" in the LyX
wiki. But, please, why Sweave.sty is
not included with LyX 2.0.
> Do you have a simple recipe to reproduce this?
- start LyX 2.0svn from a console
- create a LyX file and export it to LyX 1.6.x format
result: you will see lyx2lyx warnings if there are some (you can
testwise change the lyx2lyx code to output a simple warning)
- now open a file created with
Am 08.09.2010 20:08, schrieb Pavel Sanda:
i was going to look what are the values here, but my lyx crashes when i go to
horizontal line dialog, backtrace below.
#2 0xb6f8d348 in abort () from /lib/libc.so.6
#3 0x087c224c in lyx::frontend::GuiLine::dialogToParams() const ()
#4 0x0867cf9f in ly
On 09/08/2010 10:43 AM, Pavel Sanda wrote:
Richard Heck wrote:
If so, I think we could restore the call when needed. The question would be
when it breaks. But, as I say in the FIXME, it's hard to see how the macros
need updating if the buffer doesn't.
i dont use macros myself so its j
Uwe Stöhr wrote:
>> Uwe can you give a more precise description where from are the numbers 684
>> / 630
>> inside the following code? :
i was going to look what are the values here, but my lyx crashes when i go to
horizontal line dialog, backtrace below.
#2 0xb6f8d348 in abort () from /lib/libc.
Am 08.09.2010 16:50, schrieb Pavel Sanda:
Thanks this works so far, but text_metrics_.width() is always bigger than
mi.base.textwidth (on my PC it is 1.08 times bigger).
Uwe can you give a more precise description where from are the numbers 684 / 630
inside the following code? :
+ // FIXME: t
[Ricardo Rodriguez] eBioTIC. wrote:
>> on my box Sweave.sty is installed by R.
>>
> Just to be sure before jumping to R lists. What Mac OS X release are you
> using?
linux here.
pavel
Pavel Sanda wrote:
[Ricardo Rodriguez] eBioTIC. wrote:
one. If it is now (with the new 2.0.0 release) possible to use Sweave out
of the box, why not include Sweave.sty with the LyX distribution?
on my box Sweave.sty is installed by R.
Just to be sure before jumping to R lists. W
On Tue, Sep 7, 2010 at 6:48 PM, Pavel Sanda wrote:
> e.g. go to section 7.2.1 of additional lyx manual, having outliner
> uncollapsed.
> even typing is slower than displaying, not to speak about cursor movement
> which
> is just impossible.
>
> looking at top i see most of cpu usage is taken ins
[Ricardo Rodriguez] eBioTIC. wrote:
> one. If it is now (with the new 2.0.0 release) possible to use Sweave out
> of the box, why not include Sweave.sty with the LyX distribution?
on my box Sweave.sty is installed by R.
> Don't you think that it could be worth in the "What is new in LyX 2.0"
>
Am 02.09.2010 um 09:38 schrieb Jean-Marc LASGOUTTES:
> Stephan Witt writes:
>
>> The point is to catch all possibilities to change paragraph contents.
>> But that holds true for change tracking either. Perhaps a common
>> method can simplify that... But every change of content has to go
>> throu
Stephan, Pavel, all,
Sorry for not being clear enough. In my original post talked about
"Noweb based" documents, but I was not clear enough about the properties
of the in trouble documents.
I've messed up things and I would like to explain how and why. The key
of the problem is that I've mis
Uwe Stöhr wrote:
> Am 06.09.2010 17:14, schrieb Jean-Marc LASGOUTTES:
>
>>> I do need it because my patch currently only works for real units.
>>> Length::inPixels calculates the length for non-real units via the
>>> textwidth. offset and height can have all kind of units, e.g. a height
>>> of 1\te
Richard Heck wrote:
> If so, I think we could restore the call when needed. The question would be
> when it breaks. But, as I say in the FIXME, it's hard to see how the macros
> need updating if the buffer doesn't.
i dont use macros myself so its just guessing, but when i leave macro inset
by th
On 09/08/2010 09:19 AM, Pavel Sanda wrote:
Richard Heck wrote:
I don't really understand this either, but it certainly look as if the
updateMacros() calls are eating a lot of time. Just on general grounds, we
need to call it only when we must. There is surely no need to call
updateMacros jus
Abdelrazak Younes wrote:
>
> Maybe the outliner triggers a resize event? That could kill the performance
> indeed...
no its not triggered.
pavel
Richard Heck wrote:
> I just had a quick look at this. I think we should try commenting out the
> line:
> buffer_.updateMacros();
fyi i tried to kill this line and its still deadly slow. the bottleneck must be
somewhere inside Qt/X.
pavel
On 09/08/2010 03:40 PM, Pavel Sanda wrote:
Jean-Marc Lasgouttes wrote:
forgot to add - i went in the middle of additional manual, switched on the
outliner and just hold right arrow key for two paragraphs...
Note that gprof does not show you X usage, only what happens inside LyX
(not
Jean-Marc Lasgouttes wrote:
>> forgot to add - i went in the middle of additional manual, switched on the
>> outliner and just hold right arrow key for two paragraphs...
>
> Note that gprof does not show you X usage, only what happens inside LyX
> (not even Qt). It is better to compile a release b
Le 08/09/2010 14:46, Pavel Sanda a écrit :
Pavel Sanda wrote:
i tried to make profile. the output is gigantic and don't fully understand the
output right now...
http://195.113.26.193/~sanda/junk/gprof.txt
(9mb)
forgot to add - i went in the middle of additional manual, switched on the
outline
Pavel Sanda wrote:
i made shorter summary from the flat part of the profile, ie cumulative time
spent inside the functions, subcalls included; cut below 5%:
with ouliner:
[1] 87.80.002.54 722 lyx::dispatch(lyx::FuncRequest
const&) [1]
[2] 87.80.002.54 722
On 09/08/2010 03:19 PM, Pavel Sanda wrote:
Richard Heck wrote:
FIXME there when working on updateBuffer(). This is the ONLY call to this
routine that is neither (a) inside the read and export routines nor (b)
inside updateBuffer(). That will sharply limit the number of calls to
updateMacros(
Richard Heck wrote:
> I don't really understand this either, but it certainly look as if the
> updateMacros() calls are eating a lot of time. Just on general grounds, we
> need to call it only when we must. There is surely no need to call
> updateMacros just when you are moving the cursor.
>
> I
On 09/08/2010 08:46 AM, Pavel Sanda wrote:
Pavel Sanda wrote:
i tried to make profile. the output is gigantic and don't fully understand the
output right now...
http://195.113.26.193/~sanda/junk/gprof.txt
(9mb)
forgot to add - i went in the middle of additional manual, switched on th
Pavel Sanda wrote:
> now i want to create second profiling output when outliner is off...
http://195.113.26.193/~sanda/junk/gprof_nooutliner.txt
> pavel
Abdelrazak Younes wrote:
> On 09/08/2010 02:46 PM, Pavel Sanda wrote:
>> Pavel Sanda wrote:
>>
>>> i tried to make profile. the output is gigantic and don't fully
>>> understand the output right now...
>>> http://195.113.26.193/~sanda/junk/gprof.txt
>>> (9mb)
>>>
>> forgot to add - i wen
On 09/08/2010 02:46 PM, Pavel Sanda wrote:
Pavel Sanda wrote:
i tried to make profile. the output is gigantic and don't fully understand the
output right now...
http://195.113.26.193/~sanda/junk/gprof.txt
(9mb)
forgot to add - i went in the middle of additional manual, switched on th
Pavel Sanda wrote:
> i tried to make profile. the output is gigantic and don't fully understand
> the output right now...
> http://195.113.26.193/~sanda/junk/gprof.txt
> (9mb)
forgot to add - i went in the middle of additional manual, switched on the
outliner and just hold right arrow key for two
Abdelrazak Younes wrote:
> Please make some profiling before attacking this or this field. Threads are
> nice but must be used with care.
i tried to make profile. the output is gigantic and don't fully understand the
output right now...
http://195.113.26.193/~sanda/junk/gprof.txt
(9mb)
pavel
Abdelrazak Younes wrote:
> Maybe this is somewhat related.
>
> http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/
so i upgraded everything from kernel to xorg and the drivers around to the
newest packages and except that google earth became unusable flashing circus
On 09/06/2010 11:39 AM, Jean-Marc LASGOUTTES wrote:
Pavel Sanda writes:
Jean-Marc Lasgouttes wrote:
There is however a problem with this change: in old documents, a paragraph
break would generate an empty line, but now it will be a single line break.
Also, it would be nice to remove
On 09/08/2010 02:10 AM, Abdelrazak Younes wrote:
On 09/07/2010 05:48 PM, Pavel Sanda wrote:
hi,
while typing some docs into our manuals i must admit that lyx editing
performance
when outliner is simultaneously opened is really horrible.
e.g. go to section 7.2.1 of additional lyx manual, havi
On Tuesday 07 September 2010 14:09:38 Uwe Stöhr wrote:
> Yes, warnings in convert routines are not output to the LyX console
> window. For reversion routines this works.
>
> regards Uwe
Do you have a simple recipe to reproduce this?
I don't see it in linux (Fedora 14 devel) whith python 2.7
--
Stephan Witt wrote:
> In the message below LyX tries to open the produced .tex file with "editor" -
> don't know why.
did you really reconfigured?
pavel
Am 08.09.2010 um 10:45 schrieb [Ricardo Rodriguez] eBioTIC.:
> Hi!
>
> Stephan Witt wrote:
>> No idea yet. Are you able to save that file and post it here, please?
>>
>>
>>
>
> Of course.
>
> This simple file generates this error:
>
> http://ftp.ebiotic.net/onLyX/justATest.lyx
But this fi
Hi!
Stephan Witt wrote:
No idea yet. Are you able to save that file and post it here, please?
Of course.
This simple file generates this error:
http://ftp.ebiotic.net/onLyX/justATest.lyx
*
08/09/10 10:41:59 [0x0-0x79079].org.lyx.lyx[2800] Writing to file
justATest.tex
08/09/10 10:
Abdelrazak Younes wrote:
> Here with Linux/Qt4.7/gcc4.4.3/KDE4.5 compiled with
>
> -O3 -DNDEBUG (cmake release option), there no issue. Everything's very
> fast.
>
> When typing really fast, Xorg takes 30% cpu and lyx2.0 takes 22%. I have a
> Core2 Duo centrino @ 2GHz.
thanks for the response. t
Am 08.09.2010 um 10:25 schrieb [Ricardo Rodriguez] eBioTIC.:
> Hi,
>
> I've just installed and reconfigured LyX 2.0.0alpha5 (as per
> LyX-2.0.0alpha5+qt4.dmg installed in a Mac OS X 10.5.8, MacTeX) and I am
> facing some weird problem when trying to view newly created files. I'm not
> able to
44 matches
Mail list logo