Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Abdelrazak Younes]

[EMAIL PROTECTED] wrote:

Author: sanda
Date: Sat Nov 10 01:21:42 2007
New Revision: 21536


Very good. Welcome on board Pavel!

Abdel.

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Hello,

I'd like to know what is the purpose of these two LyXAction values:

LyXAction {
NoUpdate cid:part1.03070604.07060105@sssup.it 
= 8, // Does not (usually) require update
SingleParUpdate 
cid:part2.08020706.07090501@sssup.it = 16 // 
Usually only requires this par updated

};


and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?

Abdel.

Re: trunk compile problem

[Pavel Sanda]

   yes, that works.
  
  Whoahey.
  
  Now you could do me a favour: Could you run that file through the 
  preprocessor
  only (i.e. g++ -E instead of g++ -c) and figure out who pulls in X.h (or
  Xlib.h)?

GuiApplication.cpp, 56.line

pavel

Re: Scrollfix patch

[Pavel Sanda]

 -) the boxes example now works correctly, except it is somewhat slow
   because with SinglePar I'm updating and redrawing the outer Par,
   not the inner one, so with such a great box (or even table, etc...),
   it gets slow -- here I should add a further parameter to UpdateScope
   specifying the Text where the update starts from;

yes, scrolling is ok and typing is slow.

moreover this patch breaks pg/up-down inside insets - which is slightly broken
even now as noted in regression list. (by this i dont mean it shouldnt go in,
as i suppose you'll work on the bugs further).

pavel

Re: Scrollfix patch

[Abdelrazak Younes]

Martin Vermeer wrote:

On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:



 As it is somewhat growing, I wouldn't like to keep working on it for too
 much time further, as the operation of merging with trunk may become
 cumbersome. Now it seems to me sufficiently stable.

T.


I think this is the time to check it in -- with the trivial
renames you propose.


I hope you mean _without_ the trivial renames...


We're not close to a trunk release so any
bugs will get ironed out in a timely manner.


I'd prefer that the patch is incrementally integrated. This patch should 
serve as a reference goal implementation. I am talking about how I would 
personally proceed but I am not Tommaso.


It this patch goes as-is you have to promise to fixed all bugs and 
regressions Tommaso (I would help you of course).


I'll to do a review of the patch in the coming days.

Abdel.

Re: Scrollfix patch

[Abdelrazak Younes]

Abdelrazak Younes wrote:


It this patch goes as-is you have to promise to fixed all bugs and 
regressions Tommaso (I would help you of course).


If this patch goes in as-is you have to promise to fix all bugs and 
regressions Tommaso (I would help you of course).




I'll to do a review of the patch in the coming days.


I'll try to do a review of the patch in the coming days.

Looking at the state of my spelling, obviously not today :-)

Abdel.

Re: update links on wiki

[Jürgen Spitzmüller]

Andre Poenitz wrote:
  Which means the design is lame.

 Wasn't the intention to have a weak 'protection' only to save us from
 spam bots?

I think in the case were someone could link to an evil binary as LyX 1.5.2 
installer, we should be much more restrictive.

Jürgen

Re: trunk compile problem

[Andre Poenitz]

On Sat, Nov 10, 2007 at 11:54:32PM +0100, Pavel Sanda wrote:
 are you talking about all occurences of X/lib/.h ?
 i'm bit confused what all the numbers mean, eg # 1 /usr/include/X11/Xatom.h 
 1 3 4

The first one is the line number, I don't know about the others.

I specifically meant the file X.h, but basically nothing from
/usr/include/X11/ should show up.

Urm... I just see it's our doing, not Qt's:

#ifdef Q_WS_X11
#include X11/Xatom.h
#include X11/Xlib.h
#endif

and it seems to be used in the selection handling...

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 07:49:54AM +0200, Martin Vermeer wrote:
 On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:
   Hi all,
  
   please, find attached an improved version of the scrollfix patch.
  
   Summary of the further changes:
   -) most optimizations for updating a single par are back
   -) actually, it is possible to specify a par range with Update::SinglePar
 -- actually, should be renamed as Update::Paragraphs;
 -- actually, Update::Force should be renamed as Update::Screen ?
   -) class UpdateScope encapsulates the scope of an update (updateFlags
 plus parameters, e.g. the par range to be updated if SinglePar is used)
   -) the boxes example now works correctly, except it is somewhat slow
 because with SinglePar I'm updating and redrawing the outer Par,
 not the inner one, so with such a great box (or even table, etc...),
 it gets slow -- here I should add a further parameter to UpdateScope
 specifying the Text where the update starts from;
   -) probably it adheres slightly more to the coding rules;
   -) updated to trunk revision 21533;
   -) needs testing to check if there are any further crashes;
  
   As it is somewhat growing, I wouldn't like to keep working on it for too
   much time further, as the operation of merging with trunk may become
   cumbersome. Now it seems to me sufficiently stable.
  
  T.
 
 I think this is the time to check it in -- with the trivial
 renames you propose. We're not close to a trunk release so any
 bugs will get ironed out in a timely manner.

I'd like to see some performance measures first, lest we paint
ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the 
current one for performance reasons when e.g. loading/resizing
inserting in big docments.

If we blindly apply fundamental changes to the paint strategy 
it might well be that there are some problems with the strategy
that are _conceptually_ not solvable.

Andre'

Re: trunk compile problem

[Pavel Sanda]

  are you talking about all occurences of X/lib/.h ?
  i'm bit confused what all the numbers mean, eg # 1 
  /usr/include/X11/Xatom.h 1 3 4
 
 The first one is the line number, I don't know about the others.

i learnt meanwhile
`1'  indicates the start of a new file.
`2'  indicates returning to a file (after having included another file).
`3'  indicates that the following text comes from a system header file, so 
certain warnings should be suppressed.
`4'  indicates that the following text should be treated as being wrapped in an 
implicit extern C block. 

btw in addition i use --enable-monolithic-insets
and still see many insets/Inset*.cpp compiled individually. is it supposed to 
be this way ?

pavel

Re: trunk compile problem

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:27:13PM +0100, Pavel Sanda wrote:
   are you talking about all occurences of X/lib/.h ?
   i'm bit confused what all the numbers mean, eg # 1 
   /usr/include/X11/Xatom.h 1 3 4
  
  The first one is the line number, I don't know about the others.
 
 i learnt meanwhile
 `1'  indicates the start of a new file.
 `2'  indicates returning to a file (after having included another file).
 `3'  indicates that the following text comes from a system header file, so 
 certain warnings should be suppressed.
 `4'  indicates that the following text should be treated as being wrapped in 
 an implicit extern C block. 

Ah... thanks for the explanation.

 btw in addition i use --enable-monolithic-insets and still see many
 insets/Inset*.cpp compiled individually. is it supposed to be this way?

For some reason the feature seems to be gone?

Andre'

Approaching LyX 1.5.3 [status update #2]

[Jürgen Spitzmüller]

We are already pretty close to a release: we have fixed the regressions 
introduced with 1.5.2 (pixmap cache, AMS classes) and several other things, 
including 9 critical bugs. So 1.5.3svn is significantly ahead of 1.5.2, IMHO.

Therefore, I don't want to hold back the release very much longer. However, 
there are still some things left to do.

On bugzilla, there are five open critical bugs. I think at least these two 
should be fixed:

4333   cri   lyx crashes when opening 1.4.3. file with index containin... 
4346   cri   Synchronizing insets crash when two windows open

I hope that Abdel and José, as the experts in the respective area, will find 
time to have a look.

Furthermore, there are several bugs related to encoding switches and CJK, and 
it turned out that CJK doesn not work at all (and probably never worked) in 
some circumstances (in non-CJK documents):

3561   cri   crash when changing document encoding
4349   cri   assert with CJK in non-CJK paragraph
4337   maj   LaTeX file has no \end{CJK} if it contains multiple langu...

I had a look at these issues over the weekend. As I see it, the encoding 
switch mechanism needs a major overhaul. It includes some hacks for CJK (most 
notably the ascii/open_encoding_ hack in latexWriteEndChanges) that should 
be replaced by something sane. This is a prerequisite (if not the solution) 
to fix the above bugs.
However, I'm sceptical that we can achieve this for 1.5.3, and I'm also 
reluctant to do it now, since it touches very sensitive parts of the code. So 
it would be good if anyone of the few people who really understand the 
encoding mechanism thoroughly (I don't count myself to those) could fix this 
in trunk, so that we can backport the fixes for 1.5.4.

There are still some other bugs left, if you are feeling adventurous(TM). 
Here is my personal chart:

2178   maj   create empty layout in all text classes
4081   nor   Char style is not set properly when switching through doc...
4260   nor   RMB opening of outliner doesn't select correct list
4302   nor   changes lost in settings window on focus of main window

feel free to pick out a different one from those bugs targetted to 1.5.3.

Regarding Michael's list, I think only these are relevant for the time being:

http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify(): 
  don't crash with abort() but exit gracefully when an exception is 
  caught. try to catch LyX specific exceptions.
http://www.lyx.org/trac/changeset/20531 - Gives the user some 
  information about the crash.
http://www.lyx.org/trac/changeset/20437 - Remove redundant 
  AlignPossible? lines
http://www.lyx.org/trac/changeset/20438 - Disallow setting of alignment 
  in protected environments, where it is broken.

(all these can go in).


Jürgen
-*- text -*-

This file describes what has been done in the preparation of LyX 1.5.3
All comments are welcome.

I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked into the BRANCH_1_5_X branch, which you
can get with the command
  svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_5_X lyx-1.5.x

Juergen

[In this list, I try to group things by topic and in decreasing
order of importance. This is, of course, subjective...]


What's new
==


** Updates:
***

* DOCUMENTATION AND LOCALIZATION

- Update Czech, French, Japanese, Spanish and Traditional Chinese 
  translations of the user interface.

- Spanish translation of the example file ItemizeBullets.lyx.

- Updated French introduction manual.


* USER INTERFACE

- The way collapsable insets (footnotes, comments etc) are widen has seen
  a complete overhaul in order to speedup painting when typing within
  insets. Now these insets are widen as soon as they contain more than one
  row of text. Users of Mac/PPC and of Unixes with slow X11 server should
  feel a significant boost in performance thanks to this change.

- The pixmap cache that was introduced in LyX 1.5.2 to improve performance
  can now be switched on and off in Preferences, since it might decrease
  on-screen display quality of fonts (subpixel hinting). By default, the
  cache is disabled. If you experience performance problems, turn in on
  (Mac and Windows only).

- The behaviour of Return and M-Return has changed: they now allow to either
  keep current paragraph and depth or to nesting paragraph (bug 2445).

- Add the esint font to the private math fonts. This font assures a
  consistent on screen looking for all kinds of supported integral signs.

- The slides/foils of presentation classes such as beamer, powerdot, foils
  and slides are now displayed in the outliner. This makes it easy to navigate
  to specific slides or move them up and down (bug 78).

- It is now possible to enter greek and cyrillic characters and have them
  typesetted without switching to the proper language.

- Inset-dissolve now works in mathed.

- Add 

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
  I think this is the time to check it in -- with the trivial
  renames you propose. We're not close to a trunk release so any
  bugs will get ironed out in a timely manner.
 
 I'd like to see some performance measures first, lest we paint
 ourselves into a corner here.

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:53:52PM +0100, Andre Poenitz wrote:
 On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
   I think this is the time to check it in -- with the trivial
   renames you propose. We're not close to a trunk release so any
   bugs will get ironed out in a timely manner.
  
  I'd like to see some performance measures first, lest we paint
  ourselves into a corner here.
 
 An entirely unscientific test (sitting in front of the computer and
 counting) yields ~4s for loading the UserGuide before applying the patch
 and ~13s afterwards. There is some additional debug output, but I don't
 think the resulting scrolling in the terminal accounts for all of those
 nine extra seconds.

Looks better with the debug output disabled. Still:
 
 So please: Produce some numbers showing that there are no inacceptable
 regressions wrt to performance. A performance degradation by a factor of
 3 for loading documents does not look like a good start.

Also, loading the UserGuide and keeping PageDown pressed gets stuck at
some point of time. Also, on the way there the cursor is sometimes
off-screen.

Maybe you can also get in touch with Alfredo. He spent quite some time
with the current architecture so he might be aware of more pitfalls than
I am.

Andre'

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the 
current one for performance reasons when e.g. loading/resizing

inserting in big docments.
  

My feeling is that, even with hundreds of outer paragraphs,
the process of summing their heights up should not be
even perceivable on modern CPUs (provided that the heights
are directly available within a vector, like it is now -- ParMetricsCache
is not a map anymore, but a vector). And, more importantly,
such process would be triggered only as a response to:
1) change of height of currently edited par
  1.a) break of currently edited par (Enter)
2) cut and paste operations
3) width resize of screen

If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a summing (balanced) tree, that would exhibit O(log n)
complexity for little updates like needed in 1) [not sure about
1.a], but probably you won't avoid the O(n) updates in case of
2) or 3).

If you look at the patch code, you'll notice that many times
(not all, though) paragraph heights are managed through
dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
instead of using the standard par_metrics_[p].height(), just
in view of such possibility.


   T.

Re: LyXAction and updates ?

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?

Yep, thx, and I'd like to eliminate the LyXAction::func_attrib / UpdateFlags
enums redundancy, by either:
-) specifying differently LyXActions and UpdateFlags for LFUNs
-) or letting the two concepts collaps, i.e. UpdateFlags go away, and their
  enums are incorporated into LyXAction

Personally, I would prefer the first one, as the func_attrib enum is 
documented

like this:

   /// possible permissions for an action
   enum func_attrib {
   Noop = 0, // nothing special about this func
   ReadOnly = 1, // can be used in RO mode (perhaps this 
should ch

ange)
   NoBuffer = 2, // Can be used when there is no document open
   Argument = 4, // Requires argument
   NoUpdate = 8, // Does not (usually) require update
   SingleParUpdate = 16 // Usually only requires this par 
updated

   };

As you can see, the last two ones are not permissions at all, i.e. they do
not help specifying when the action is allowed or not.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.


Thanx, I'll try to figure it out...

Looks better with the debug output disabled. Still:
  

Did you get the same numbers with debug output disabled ?

   T.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.
  

Well, I'm verifying on my laptop. But I want to be sure to have
two LyX compiled exactly with the same options, and debug
disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
recompilation of LyX, so I guess I'll have numbers within one
hour or so (and I'm also deleting a couple of kernel source
trees to accomodate for the needed space).

Anyway, please note that, with the current patch, *all* par
metrics and heights are pre-computed on a document load
(full metrics are discarded for all pars but the visible ones),
so I expect anycase a slow-down on document opening. As
already mentioned on the list, I'd like to switch to an
incremental computation of the document height that is
made in the background while the user is already able to
work on the document.

I'd make such change as a further incremental patch, but if
you prefer the all-in-one approach, I can go further to such
step.

   T.

any known problems with gcc-4.2?

[Mikhail Teterin]

Hello!

A user of FreeBSD-7.0-BETA2 has just reported a problem with lyx seg-faulting 
at start-up:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117963

(the crash is inside calloc() suggesting a memory corruption).

It seems to work for me here, on FreeBSD-6.2. The most pronounced difference 
between the OS-releases is the version of the compiler tool-chain. On 7.x we 
use gcc-4.2 and on 6.x it is still 3.4.6.

Were there any known problems with lyx-1.4.4 and gcc-4.2 or do I need to dig 
deeper into it? Thanks!

-mi

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?
Yep, thx, and I'd like to eliminate the LyXAction::func_attrib / 
UpdateFlags

enums redundancy, by either:
-) specifying differently LyXActions and UpdateFlags for LFUNs
-) or letting the two concepts collaps, i.e. UpdateFlags go away, and their
  enums are incorporated into LyXAction


Well I don't think these two enums are redundant at all. They are simply 
two unrelated different things. I'd rather get rid of the UpdateFlags 
altogether and let BufferView/TextMetrics automatically decides what 
needs drawing or not. A bit like what we have now with the Row signatures.


But that is another story Tommaso. Please try to put the par height 
cache patch into good shape first. Your last patch is full of 
cleanups/redesigns in addition to the par height cache. So I suggest to 
either put in these first and delay the scrolling part for after, or the 
opposite.


Abdel.

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:
 Andre Poenitz ha scritto:
 ourselves into a corner here. We had this kind of approach (all
 paragraph heights known) for a long time and switched to the current one 
 for performance reasons when e.g. loading/resizing
 inserting in big docments.
   
 My feeling is that, even with hundreds of outer paragraphs,
 the process of summing their heights up should not be
 even perceivable on modern CPUs (provided that the heights
 are directly available within a vector, like it is now -- ParMetricsCache
 is not a map anymore, but a vector). And, more importantly,
 such process would be triggered only as a response to:
 1) change of height of currently edited par
   1.a) break of currently edited par (Enter)
 2) cut and paste operations
 3) width resize of screen

4) Loading of a document.

 If you have serious concerns about this (probably due to the
 past experience on developing LyX), the best solution would
 be a summing (balanced) tree, that would exhibit O(log n)
 complexity for little updates like needed in 1) [not sure about
 1.a], but probably you won't avoid the O(n) updates in case of
 2) or 3).

I think loading/resizing in 4 second is ok. 20 is rather not.
I know, it's not that bad, I am exaggerating. And of course
one could provide some more versose status message (as in 23/5490
paragraphs done) giving the impression that 'something' happens...

 If you look at the patch code, you'll notice that many times
 (not all, though) paragraph heights are managed through
 dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
 instead of using the standard par_metrics_[p].height(), just
 in view of such possibility.

The patch as such looks like a sensible implementation of the idea
(plus/minus some minor quirks). However, as this is quite intrusive
change of concept I'd rather make sure the concept is sound. And I
do not really want to rely on gut feelings only here (my gut says:
Id shoul be ok as we used to o it like that for a while and the
lazy rebreaking was not too much of a  success and machines are 
faster tofday then five years ago).

Andre'

Re: Scrollfix patch

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:



If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a summing (balanced) tree, that would exhibit O(log n)
complexity for little updates like needed in 1) [not sure about
1.a], but probably you won't avoid the O(n) updates in case of
2) or 3).


I think loading/resizing in 4 second is ok.


I disagree with that. Loading should be as fast as possible and resizing 
should be instantaneous. Or we just switch to implement a WISIWIG 
processor. There are a lot of good things in Tommaso's patch but the 
initial calculation of all ParMetrics is not one of those. The 
TextMetrics API additions are nice but are orthogonal to our scrolling 
problem.



20 is rather not.
I know, it's not that bad, I am exaggerating. And of course
one could provide some more versose status message (as in 23/5490
paragraphs done) giving the impression that 'something' happens...


That's the thing I hate most about MSWords: continuously waiting for the 
re-pagination to complete. We don't need a *perfect* scrolling 
behaviour, just a sensible one. A simple cache of paragraph height would 
do the job and I wish Tommaso had followed this direction instead.


Abdel.

Re: Scrollfix patch

[Alfredo Braunstein]

Andre Poenitz wrote:

 1) change of height of currently edited par
   1.a) break of currently edited par (Enter)
 2) cut and paste operations
 3) width resize of screen
 
 4) Loading of a document.
 
 If you have serious concerns about this (probably due to the
 past experience on developing LyX), the best solution would
 be a summing (balanced) tree, that would exhibit O(log n)
 complexity for little updates like needed in 1) [not sure about
 1.a], but probably you won't avoid the O(n) updates in case of
 2) or 3).
 
 I think loading/resizing in 4 second is ok. 20 is rather not.
 I know, it's not that bad, I am exaggerating. And of course
 one could provide some more versose status message (as in 23/5490
 paragraphs done) giving the impression that 'something' happens...

Mmm... I think this would be pretty bad.

 If you look at the patch code, you'll notice that many times
 (not all, though) paragraph heights are managed through
 dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
 instead of using the standard par_metrics_[p].height(), just
 in view of such possibility.
 
 The patch as such looks like a sensible implementation of the idea
 (plus/minus some minor quirks). However, as this is quite intrusive
 change of concept I'd rather make sure the concept is sound. And I
 do not really want to rely on gut feelings only here (my gut says:
 Id shoul be ok as we used to o it like that for a while and the
 lazy rebreaking was not too much of a  success and machines are
 faster tofday then five years ago).

My main concern is that is much more difficult to go the nonlazy - lazy
route as we have done (and Andre' and myself invested a good deal of time
doing it) than the other way around. So we should make this decision very
carefully. 

PS: I *think* I agree with Andre on this point, but I rather not say
it 'cause lately I'm not guessing right ;-)

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Abdelrazak Younes wrote:

 If you have serious concerns about this (probably due to the
 past experience on developing LyX), the best solution would
 be a summing (balanced) tree, that would exhibit O(log n)
 complexity for little updates like needed in 1) [not sure about
 1.a], but probably you won't avoid the O(n) updates in case of
 2) or 3).
 
 I think loading/resizing in 4 second is ok.
 
 I disagree with that. Loading should be as fast as possible and resizing
 should be instantaneous. 

Exactly

 Or we just switch to implement a WISIWIG 
 processor. There are a lot of good things in Tommaso's patch but the
 initial calculation of all ParMetrics is not one of those. The
 TextMetrics API additions are nice but are orthogonal to our scrolling
 problem.
 
 20 is rather not.
 I know, it's not that bad, I am exaggerating. And of course
 one could provide some more versose status message (as in 23/5490
 paragraphs done) giving the impression that 'something' happens...
 
 That's the thing I hate most about MSWords: continuously waiting for the
 re-pagination to complete. We don't need a *perfect* scrolling
 behaviour, just a sensible one. A simple cache of paragraph height would
 do the job and I wish Tommaso had followed this direction instead.

I agree 100%. 

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Andre Poenitz wrote:

 On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
  I think this is the time to check it in -- with the trivial
  renames you propose. We're not close to a trunk release so any
  bugs will get ironed out in a timely manner.
 
 I'd like to see some performance measures first, lest we paint
 ourselves into a corner here.
 
 An entirely unscientific test (sitting in front of the computer and
 counting) yields ~4s for loading the UserGuide before applying the patch
 and ~13s afterwards. There is some additional debug output, but I don't
 think the resulting scrolling in the terminal accounts for all of those
 nine extra seconds.
 
 So please: Produce some numbers showing that there are no inacceptable
 regressions wrt to performance. A performance degradation by a factor of
 3 for loading documents does not look like a good start.

A small point: when testing we should not limit ourselves to the Userguide.
IMO one of the really strong points of LyX is to be able to deal with huge
documents, like books. (the UG has just 150 pages, it is like a small
book). Btw, we used to test performance with UG20 (just 20 copies of
UserGuide) some time (but I agree that this is kind of extreme, though).

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Tommaso Cucinotta wrote:

 Andre Poenitz ha scritto:
 ourselves into a corner here. We had this kind of approach (all
 paragraph heights known) for a long time and switched to the
 current one for performance reasons when e.g. loading/resizing
 inserting in big docments.
   
 My feeling is that, even with hundreds of outer paragraphs,
 the process of summing their heights up should not be
 even perceivable on modern CPUs (provided that the heights
 are directly available within a vector, like it is now -- ParMetricsCache
 is not a map anymore, but a vector). And, more importantly,
 such process would be triggered only as a response to:
 1) change of height of currently edited par
1.a) break of currently edited par (Enter)
 2) cut and paste operations
 3) width resize of screen

3) document loading
4) graphics updating - this is particular important with math previews on a
document full of them.


 If you have serious concerns about this (probably due to the
 past experience on developing LyX), the best solution would
 be a summing (balanced) tree, that would exhibit O(log n)
 complexity for little updates like needed in 1) [not sure about
 1.a], but probably you won't avoid the O(n) updates in case of
 2) or 3).

This could be a good idea (if needed of course, numbers should tell).

A/

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
 Andre Poenitz ha scritto:
 An entirely unscientific test (sitting in front of the computer and
 counting) yields ~4s for loading the UserGuide before applying the patch
 and ~13s afterwards. There is some additional debug output, but I don't
 think the resulting scrolling in the terminal accounts for all of those
 nine extra seconds.

 So please: Produce some numbers showing that there are no inacceptable
 regressions wrt to performance. A performance degradation by a factor of
 3 for loading documents does not look like a good start.
   
 Well, I'm verifying on my laptop. But I want to be sure to have
 two LyX compiled exactly with the same options, and debug
 disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
 recompilation of LyX, so I guess I'll have numbers within one
 hour or so (and I'm also deleting a couple of kernel source
 trees to accomodate for the needed space).

 Anyway, please note that, with the current patch, *all* par
 metrics and heights are pre-computed on a document load
 (full metrics are discarded for all pars but the visible ones),
 so I expect anycase a slow-down on document opening.

Some performance decrease for loading will be acceptable...

 As already mentioned on the list, I'd like to switch to an
 incremental computation of the document height that is
 made in the background while the user is already able to
 work on the document.

 I'd make such change as a further incremental patch, but if
 you prefer the all-in-one approach, I can go further to such
 step.

Incremental is fine if the direction is ok and each step
leaves us with a usable code base.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 06:21:45PM +0100, Abdelrazak Younes wrote:
 20 is rather not.
 I know, it's not that bad, I am exaggerating. And of course
 one could provide some more versose status message (as in 23/5490
 paragraphs done) giving the impression that 'something' happens...

 That's the thing I hate most about MSWords: continuously waiting for the 
 re-pagination to complete. We don't need a *perfect* scrolling behaviour, 
 just a sensible one. A simple cache of paragraph height would do the job 
 and I wish Tommaso had followed this direction instead.

So looks like Tommasso and you will need to talk to each other ;-)

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:
 Andre Poenitz wrote:
 
  On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
   I think this is the time to check it in -- with the trivial
   renames you propose. We're not close to a trunk release so any
   bugs will get ironed out in a timely manner.
  
  I'd like to see some performance measures first, lest we paint
  ourselves into a corner here.
  
  An entirely unscientific test (sitting in front of the computer and
  counting) yields ~4s for loading the UserGuide before applying the patch
  and ~13s afterwards. There is some additional debug output, but I don't
  think the resulting scrolling in the terminal accounts for all of those
  nine extra seconds.
  
  So please: Produce some numbers showing that there are no inacceptable
  regressions wrt to performance. A performance degradation by a factor of
  3 for loading documents does not look like a good start.
 
 A small point: when testing we should not limit ourselves to the Userguide.
 IMO one of the really strong points of LyX is to be able to deal with huge
 documents, like books. (the UG has just 150 pages, it is like a small
 book). Btw, we used to test performance with UG20 (just 20 copies of
 UserGuide) some time (but I agree that this is kind of extreme, though).

But if a concept does not scale up well it's usually a bad concept. 
So checking with ug20 is certainly still a vaild approach.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 08:08:52PM +0100, Andre Poenitz wrote:
 On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
  Andre Poenitz ha scritto:
  An entirely unscientific test (sitting in front of the computer and
  counting) yields ~4s for loading the UserGuide before applying the patch
  and ~13s afterwards. There is some additional debug output, but I don't
  think the resulting scrolling in the terminal accounts for all of those
  nine extra seconds.
 
  So please: Produce some numbers showing that there are no inacceptable
  regressions wrt to performance. A performance degradation by a factor of
  3 for loading documents does not look like a good start.

  Well, I'm verifying on my laptop. But I want to be sure to have
  two LyX compiled exactly with the same options, and debug
  disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
  recompilation of LyX, so I guess I'll have numbers within one
  hour or so (and I'm also deleting a couple of kernel source
  trees to accomodate for the needed space).
 
  Anyway, please note that, with the current patch, *all* par
  metrics and heights are pre-computed on a document load
  (full metrics are discarded for all pars but the visible ones),
  so I expect anycase a slow-down on document opening.
 
 Some performance decrease for loading will be acceptable...

But it looks like Abdel and Alfredo disagree. So maybe some kind of
discussion is needed.

Andre'

Re: Scrollfix patch

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:

A small point: when testing we should not limit ourselves to the Userguide.
IMO one of the really strong points of LyX is to be able to deal with huge
documents, like books. (the UG has just 150 pages, it is like a small
book). Btw, we used to test performance with UG20 (just 20 copies of
UserGuide) some time (but I agree that this is kind of extreme, though).


Yes, this plus the fact that one often loads many documents at startup.



But if a concept does not scale up well it's usually a bad concept. 
So checking with ug20 is certainly still a vaild approach.


And it is always my approach when testing file loading or label/toc updates.

Abdel.

Re: Scrollfix patch

[Tommaso Cucinotta]

Ok, I have my own numbers. This is what I obtained launching
LyX from the shell asking to open a document, and hitting Alt-F4
(close application) as soon as I see the LyX window. Note that,
before LyX is closed, I can see clearly the loaded document showing
on the screen, then the pressed sequence closes LyX (therefore
in the patched case, full par metrics and heights computation is done).

Note also that I didn't report numbers from the *first* execution,
but I repeated the process 3 or 4 times, then I reported the last
numbers. This is done to reach a fair condition in which all files
are basically cached in the Linux disk cache when launching the
program.

This is trunk, as checked out ~2 hour ago (USERGUIDE.LYX):

[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/UserGuide.lyx  /dev/null 21

real0m3.057s
user0m2.127s
sys 0m0.112s

This is my scrollfix patch, as sent to the list tonight:

[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/UserGuide.lyx  /dev/null 21

real0m2.611s
user0m1.719s
sys 0m0.110s

And now again trunk for EMBEDDEDOBJECTS.LYX:

[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx  /dev/null 21

real0m2.887s
user0m1.912s
sys 0m0.141s

and again my scrollfix patch:

[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx  /dev/null 21


real0m3.156s
user0m2.269s
sys 0m0.106s

Conclusions: the unscientific experiment of Andre Poenits was really 
non-scientific.
I guess he must have left debug enabled when trying the scrollfix, and 
disabled in the
other case :-) Another possibility could be he tried the scrollfix with 
an empty disk
cache, then trunk with a filled disk-cache. The difference is enormous, 
as shown below:


This is what happens to trunk if I clear the disk cache:

[EMAIL PROTECTED]:~# sync  echo 3  /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx  /dev/null 21

real0m18.461s
user0m1.952s
sys 0m0.195s

and this is my scrollfix after the same process:

[EMAIL PROTECTED]:~# sync  echo 3  /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx  /dev/null 21

real0m19.146s
user0m2.268s
sys 0m0.187s

As you can see, ~20 seconds are needed to load LyX along with all the 
shared libraries
it uses, configuration files, and the document itself. The time actually 
spent by the

CPU does not change that much (~2 sec.).

If anyone has a longer file (a Master  thesis, PhD thesis or something 
like that), I
can try to see what is the doc length at which things start really 
slowing down

inaccpetably.

   T.

Tommaso Cucinotta ha scritto:

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.
  

Well, I'm verifying on my laptop. But I want to be sure to have
two LyX compiled exactly with the same options, and debug
disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
recompilation of LyX, so I guess I'll have numbers within one
hour or so (and I'm also deleting a couple of kernel source
trees to accomodate for the needed space).

Anyway, please note that, with the current patch, *all* par
metrics and heights are pre-computed on a document load
(full metrics are discarded for all pars but the visible ones),
so I expect anycase a slow-down on document opening. As
already mentioned on the list, I'd like to switch to an
incremental computation of the document height that is
made in the background while the user is already able to
work on the document.

I'd make such change as a further incremental patch, but if
you prefer the all-in-one approach, I can go further to such
step.

   T.




--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso

Re: LyXAction and updates ?

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

or not. A bit like what we have now with the Row signatures.

Anyone explaining what are row signatures ? Thx.

   T.

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 08:59:01PM +0100, Tommaso Cucinotta wrote:
 Conclusions: the unscientific experiment of Andre Poenits was really
 non-scientific.  I guess he must have left debug enabled when trying
 the scrollfix, and disabled in the other case :-) Another possibility
 could be he tried the scrollfix with an empty disk cache, then trunk
 with a filled disk-cache. The difference is enormous, as shown below:

Note that your patch created lots of output by itself. So when I test
trunk vs patch I magically get more debug output.

 If anyone has a longer file (a Master  thesis, PhD thesis or something
 like that), I can try to see what is the doc length at which things
 start really slowing down inaccpetably.

Just copy the UserGuide 20 times into itself.

Andre'

crash when scrolling through the userguide

[Andre Poenitz]

#0  0xe410 in __kernel_vsyscall ()
#1  0xb7123875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7125201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb72c09e6 in __gnu_debug::_Error_formatter::_M_error ()
   from /usr/lib/libstdc++.so.6
#4  0x083a4c42 in __gnu_debug_def::vectorlyx::CursorSlice,
std::allocatorlyx::CursorSlice ::operator[] (this=0x917e264,
__n=4294967295)
at /usr/include/c++/4.1.3/debug/vector:192
#5  0x084d6859 in lyx::MathData::attachMacroParameters (this=0x93ae6f0, 
[EMAIL PROTECTED], macroPos=0, macroNumArgs=3, macroOptionals=0, 
fromInitToNormalMode=false, greedy=true)
at ../../trunk/src/DocIterator.h:48
#6  0x084d6d54 in lyx::MathData::updateMacros (this=0x93ae6f0,
[EMAIL PROTECTED])
at ../../trunk/src/mathed/MathData.cpp:392
#7  0x084d7189 in lyx::MathData::metrics (this=0x93ae6f0,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/MathData.cpp:256
#8  0x084b855a in lyx::InsetMathNest::metrics (this=0x93ae5c8,
[EMAIL PROTECTED])
at ../../trunk/src/mathed/InsetMathNest.cpp:152
#9  0x08546ec2 in lyx::InsetMathGrid::metrics (this=0x93ae5c8,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/InsetMathGrid.cpp:372
#10 0x0849755f in lyx::InsetMathHull::metrics (this=0x93ae5c8,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/InsetMathHull.cpp:296
#11 0x0827fe1a in lyx::TextMetrics::redoParagraph (this=0x916e044,
pit=964)
at ../../trunk/src/TextMetrics.cpp:496
#12 0x083222b9 in lyx::BufferView::updateMetrics (this=0x9527b90)
at ../../trunk/src/BufferView.cpp:1614
#13 0x08324359 in lyx::BufferView::processUpdateScope (this=0x9527b90, 
[EMAIL PROTECTED]) at ../../trunk/src/BufferView.cpp:394
#14 0x0815dc53 in lyx::LyXFunc::dispatch (this=0x8d4e798,
[EMAIL PROTECTED])
at ../../trunk/src/LyXFunc.cpp:2091
#15 0x0815f2ef in lyx::LyXFunc::processKeySym (this=0x8d4e798, 
[EMAIL PROTECTED], state=lyx::NoModifier)
at ../../trunk/src/LyXFunc.cpp:496
#16 0x086d5999 in lyx::frontend::WorkArea::processKeySym
(this=0x916ce34, 
[EMAIL PROTECTED], mod=lyx::NoModifier)
at ../../../trunk/src/frontends/WorkArea.cpp:178
#17 0x088c46ce in lyx::frontend::GuiWorkArea::keyPressEvent
(this=0x916ce20, 
ev=0xbff629f4) at
../../../../trunk/src/frontends/qt4/GuiWorkArea.cpp:434
#18 0xb790f272 in QWidget::event () from /usr/lib/libQtGui.so.4
#19 0xb7be0924 in QFrame::event () from /usr/lib/libQtGui.so.4
#20 0xb7c6cc51 in QAbstractScrollArea::event () from
/usr/lib/libQtGui.so.4
#21 0xb78c2ea0 in QApplicationPrivate::notify_helper ()


Stefan, it mentions attachMacroParameters()... Could you have a look?

Andre'

Re: Scrollfix patch

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

We don't need a *perfect* scrolling behaviour, just a sensible one.

I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a precise behaviour, while reading you doc,
searching for places to improve/change and editing.
A simple cache of paragraph height would do the job and I wish Tommaso 
had followed this direction instead.

Well, this is actually what I did, except I'm caching also the width,
the ascent and the descent, along with the height. Thought they could
have turned out to be useful, someday.
Basically, first I added a vector of heights, but immediately after I
realized it was sufficient to reuse the ParagraphMetrics type, with
the rows_ field cleared. So, the par_metrics_[] vector contains width,
height, asc and desc of all *outer* paragraphs in the document, while
only visible ones have the .rows() collection filled in.

Well, it is not really a cache in the cache sense...

   T.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

Just copy the UserGuide 20 times into itself.
  

Done. I get a time roughly doubled:

trunk: 5.5 secs
scrollfix: 10.5 secs

Well, I guess nobody really works with so large documents,
but you have at least one file per chapter. Though, I can
add the background-incremental height computation behaviour
to my patch, in an attempt to make everybody happy.

   T.

Re: update links on wiki

[christian . ridderstrom]

On Sun, 11 Nov 2007, Jürgen Spitzmüller wrote:


Andre Poenitz wrote:

Which means the design is lame.


Wasn't the intention to have a weak 'protection' only to save us from 
spam bots?


I think in the case were someone could link to an evil binary as LyX 
1.5.2 installer, we should be much more restrictive.


With lame by design, I was actually referring to the password for 
uploading files which has been published on the list repeatedly.


Was anyone actually able to find the password for Windows.Windows etc 
online? That password (for editing the page) is supposed to be kept more 
restrictive, i.e. it's written down in the following file on aussie:


-rw-rw  1 chr wiki 501 Oct  8 14:15 /home/lyx/www/pmwiki/passwords.txt

Please let me know if that password is lose.

/Christian

PS. According to notes in the file, these pages are edit protected
Pages that should be password protected:
* http://wiki.lyx.org/LyX/Welcome
* http://wiki.lyx.org/Windows/Windows
* http://wiki.lyx.org/Windows/LyX145
* http://wiki.lyx.org/Windows/LyX151
* http://wiki.lyx.org/Windows/LyX152

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: update links on wiki

[Joost Verburg]

Jürgen Spitzmüller wrote:
I think in the case were someone could link to an evil binary as LyX 1.5.2 
installer, we should be much more restrictive.


In my opinion the links to binaries should be on the main LyX site, not 
on the wiki.


Joost

Re: Scrollfix patch

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

We don't need a *perfect* scrolling behaviour, just a sensible one.

I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a precise behaviour, while reading you doc,
searching for places to improve/change and editing.


I think that updating the par height the moment it is displayed on 
screen would be enough.


A simple cache of paragraph height would do the job and I wish Tommaso 
had followed this direction instead.

Well, this is actually what I did, except I'm caching also the width,
the ascent and the descent, along with the height. Thought they could
have turned out to be useful, someday.


I don't think this is useful. In any case, it is not useful now so why 
the memory waste?



Basically, first I added a vector of heights, but immediately after I
realized it was sufficient to reuse the ParagraphMetrics type, with
the rows_ field cleared.


I understand your reasoning but I disagree, sorry... see below.


So, the par_metrics_[] vector contains width,
height, asc and desc of all *outer* paragraphs in the document, while
only visible ones have the .rows() collection filled in.


I don't like this distinction. I prefer all or nothing. Actually I 
planned to have partial metrics also for non-main Insets. You are doing 
the other way around: full metrics for the main Inset.




Well, it is not really a cache in the cache sense...


Not in your patch no.

Abdel.

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

or not. A bit like what we have now with the Row signatures.

Anyone explaining what are row signatures ? Thx.


Look at ParagraphMetrics::computeRowSignature(). This is basically 
computing a signature of the Row based on its content and formatting. 
The Row will be redrawn only if this signature changes.


Abdel.

lyx - GuiWorkArea.cpp dependencies

[Tommaso Cucinotta]

If I change GuiWorkArea.cpp, then type 'make lyx' from the
src folder, then I get:

make: `lyx' is up to date.

Simply typing 'make' rebuilds it. Is that normal ?

   T.

Re: crash when scrolling through the userguide

[Stefan Schimanski]

#0  0xe410 in __kernel_vsyscall ()
#1  0xb7123875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7125201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb72c09e6 in __gnu_debug::_Error_formatter::_M_error ()
  from /usr/lib/libstdc++.so.6
#4  0x083a4c42 in __gnu_debug_def::vectorlyx::CursorSlice,
std::allocatorlyx::CursorSlice ::operator[] (this=0x917e264,
__n=4294967295)
   at /usr/include/c++/4.1.3/debug/vector:192
#5  0x084d6859 in lyx::MathData::attachMacroParameters  
(this=0x93ae6f0,

   [EMAIL PROTECTED], macroPos=0, macroNumArgs=3, macroOptionals=0,
   fromInitToNormalMode=false, greedy=true)
   at ../../trunk/src/DocIterator.h:48
#6  0x084d6d54 in lyx::MathData::updateMacros (this=0x93ae6f0,
[EMAIL PROTECTED])
   at ../../trunk/src/mathed/MathData.cpp:392

Stefan, it mentions attachMacroParameters()... Could you have a look?


Sure, will do it tomorrow. Can you reproduce it? Where does it happen?

From the backtrace it seems to be the code which tries to keep the  
cursor as a reasonable position when folding/unfolding.


Stefan

Re: Scrollfix patch

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

I don't like this distinction. I prefer all or nothing.

Well, if you really think it is preferreable, then it would
probably be a matter of a few minutes to create a new vector
TextMetrics::par_heights_[], in addition to the par_metrics_[]
one, and let the parHeight() / computeHeight() methods rely on
the new vector, rather than par_metrics_[].

   T.

www

[Pavel Sanda]

hi,

i have been searching something in our web and its like visiting archaeological
museum.

i'd like to to put few things back into more fresh outlook, see attachment.
the current version (background and other pictures can be broken) is on
http://195.113.31.123/~sanda/junk/wwlyx/www/

because i understand many changes are matter of taste, i'm waiting
for your comments or objections. also native speaker can look it over ;)

pavel
Index: navbar.inc
===
--- navbar.inc  (revision 21547)
+++ navbar.inc  (working copy)
@@ -21,7 +21,7 @@
 $ty[]=0; $na[]=Morenbsp;Aboutnbsp;LyX;   $sh[]=About;  
$li[]=$LYX/about/;
 $ty[]=0; $na[]=LyXnbsp;Graphicalnbsp;Tour;   $sh[]=LGT;  
$li[]=$LYX/LGT/;
 $ty[]=0; $na[]=Mailingnbsp;Lists; $sh[]=Mail Lists; 
$li[]=$LYX/internet/mailing.php;
-$ty[]=0; $na[]=Tipsnbsp;amp;nbsp;Tricks;$sh[]=Tips;   
$li[]=http://www.texnik.de/;;
+$ty[]=0; $na[]=Tipsnbsp;amp;nbsp;Tricks;$sh[]=Tips;   
$li[]=http://wiki.lyx.org/Tips/Tips;;
 $ty[]=0; $na[]=LyXnbsp;Wiki;  $sh[]=Wiki;   
$li[]=http://wiki.lyx.org/;;
 $ty[]=0; $na[]=Givenbsp;Feedback; $sh[]=Feedback;   
$li[]=$LYX/feedback.php;
 $ty[]=0; $na[]=Developmentnbsp;News;  $sh[]=LDN;
$li[]=$LYX/news/;
Index: internet/mailing.php
===
--- internet/mailing.php(revision 21547)
+++ internet/mailing.php(working copy)
@@ -78,7 +78,9 @@
 /ul
 
  pThe list is archived at a
-a href=http://www.mail-archive.com/[EMAIL PROTECTED]/new 
archive/a and an
+a href=http://www.mail-archive.com/[EMAIL PROTECTED]/
+new archive at mail-archive/a
+or a href=http://dir.gmane.org/gmane.editors.lyx.devel;GMANE/a 
and an
 a href=http://www.mail-archive.com/[EMAIL PROTECTED]/old 
archive/a.
 
 /p
@@ -105,7 +107,10 @@
  pThe list is archived at 
 a 
href=http://www.mail-archive.com/lyx-devel@lists.lyx.org/;mail-archive.com/a
 and at
- a href=http://marc.info/?l=lyx-devel;MARC/a.
+ a href=http://marc.info/?l=lyx-devel;MARC/a
+and at
+ a href=http://dir.gmane.org/gmane.editors.lyx.devel;GMANE/a
+.
 /p
 
   a name=lyx-docs/a
@@ -140,7 +145,6 @@
 /ul
  
 
-
 a name=digests/a
   h3Digests/h3
 
Index: devel/cvs.php
===
--- devel/cvs.php   (revision 21547)
+++ devel/cvs.php   (working copy)
@@ -41,16 +41,17 @@
 a href=/index.phpLyX Home Page/a. Kept
 in this repository for ease for updating./dd
 
+pWhile they are not in use anymore, these ones are kept for their
+historical interest:/p
+
+dl
+
 dt a href=http://www.lyx.org/trac/browser/lyx-tests;lyx-tests/a
 /dt dd This repository contains various code.lyx/code files
 that may be useful for testing purposes./dd 
 /dl
 
-pWhile they are not in use anymore, these ones are kept for their
-historical interest:/p
 
-dl
-
 dt a href=http://www.lyx.org/trac/browser/lyx-1_0_x;lyx-1_0_x/a /dt
 dd This is the old strongstable/strong release branch.
 No more work is being done on this branch./dd
@@ -97,7 +98,7 @@
 /pre
 
 pThis will make a directory codelyx-devel/code and download lots of files
-into that directory. (A fresh copy will need about 270MB. However, depending 
on which frontends you are compiling, you will need a lot more space for the 
compiled version, up to 1.1GB if you built in all three frontends)./p 
+into that directory. (A fresh copy will need about 150MB. However, depending 
on which frontends you are compiling, you will need a lot more space for the 
compiled version, up to 1.1GB if you built in all three frontends)./p 
 
 pOf course you can say codesvn co svn://svn.lyx.org/lyx/www-user/trunk 
www-user/code
 instead, depending on which module you'd like to download./p
@@ -146,8 +147,11 @@
 documentation, and new features will always be looked at carefully, and will
 usually be accepted, with a number of exceptions. New features will rarely be
 accepted for the stable release version. Documentation which does not follow
-the requirements of the codeDocStyle/code document will not be accepted.
-Aside from that, though, we love getting new contributions! /p
+the requirements of the 
+a href=http://www.lyx.org/trac/browser/lyx-devel/trunk/development/coding;
+codeDocStyle/code/a document will not be accepted.  
+Aside from that, though, we love getting new
+contributions! /p
 
 p If you'd like to make changes to LyX, it will make everyone's life easier
 if you change the latest SVN sources rather than the latest release. Here's a
Index: devel/guii.php
===
--- devel/guii.php  (revision 21547)
+++ devel/guii.php  (working copy)
@@ -13,6 +13,12 @@
 ?
 
 p
+The current status is the support 

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Pavel Sanda]

 Very good. Welcome on board Pavel!

just for sure... where are the lifeboats ?
pavel

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Martin Vermeer]

On Mon, Nov 12, 2007 at 02:47:12AM +0100, Pavel Sanda wrote:
  Very good. Welcome on board Pavel!
 
 just for sure... where are the lifeboats ?
 pavel

We don't do lifeboats. Think 'Hotel California'

- Martin

Re: update links on wiki

[Jürgen Spitzmüller]

[EMAIL PROTECTED] wrote:
 Was anyone actually able to find the password for Windows.Windows etc
 online?

Sure. Just go here
http://www.mail-archive.com/lyx-docs%40lists.lyx.org/
and enter windows wiki password.

It's the 3rd hit.

Jürgen

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Abdelrazak Younes]

Martin Vermeer wrote:

On Mon, Nov 12, 2007 at 02:47:12AM +0100, Pavel Sanda wrote:

Very good. Welcome on board Pavel!

just for sure... where are the lifeboats ?
pavel


We don't do lifeboats. Think 'Hotel California'


You can check out any time but you can never laaave...

Abdel.

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Jürgen Spitzmüller]

Abdelrazak Younes wrote:
 You can check out any time

except when aussie is down ;-)

Jürgen

Re: Scrollfix patch

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

I don't like this distinction. I prefer all or nothing.

Well, if you really think it is preferreable, then it would
probably be a matter of a few minutes to create a new vector
TextMetrics::par_heights_[], in addition to the par_metrics_[]
one,


Well, I don't think par_metrics_ should become a vector... I used a map 
to minimize memory and simplify access (no worry about resize etc). The 
inset metrics, the CoordCache and the Rows all behave in a consistent 
way. I fixed an unbelievable number of bugs thanks to this consistency. 
This is a simple mental model that works well now and I'd prefer it to 
stay that way. IMO, the TextMetrics class should not be aware of 
scrolling, it's the job of BufferView.


 and let the parHeight() / computeHeight() methods rely on

the new vector, rather than par_metrics_[].


On the other hand par_heights_[] should definitely be a vector but I am 
not sure it should be in TextMetrics; BufferView is probably better.


But this is only my opinion, you are doing the work so your opinion 
matters too.


FYI I've also tried many times to rewrite from scratch this whole stuff. 
But at the end, incremental cleanups was much more beneficial and the 
result is increased stability and performance. As you've probably 
noticed this metrics and drawing business is very touchy and crash prone...


Abdel.

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Abdelrazak Younes]

[EMAIL PROTECTED] wrote:

Author: sanda
Date: Sat Nov 10 01:21:42 2007
New Revision: 21536


Very good. Welcome on board Pavel!

Abdel.

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Hello,

I'd like to know what is the purpose of these two LyXAction values:

LyXAction {
NoUpdate  
= 8, //< Does not (usually) require update
SingleParUpdate 
 = 16 //< 
Usually only requires this par updated

};


and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?

Abdel.

Re: trunk compile problem

[Pavel Sanda]

> > > yes, that works.
> > 
> > Whoahey.
> > 
> > Now you could do me a favour: Could you run that file through the 
> > preprocessor
> > only (i.e. g++ -E instead of g++ -c) and figure out who pulls in X.h (or
> > Xlib.h)?

GuiApplication.cpp, 56.line

pavel

Re: Scrollfix patch

[Pavel Sanda]

> -) the boxes example now works correctly, except it is somewhat slow
>   because with SinglePar I'm updating and redrawing the outer Par,
>   not the inner one, so with such a great box (or even table, etc...),
>   it gets slow -- here I should add a further parameter to UpdateScope
>   specifying the Text where the update starts from;

yes, scrolling is ok and typing is slow.

moreover this patch breaks pg/up-down inside insets - which is slightly broken
even now as noted in regression list. (by this i dont mean it shouldnt go in,
as i suppose you'll work on the bugs further).

pavel

Re: Scrollfix patch

[Abdelrazak Younes]

Martin Vermeer wrote:

On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:



 As it is somewhat growing, I wouldn't like to keep working on it for too
 much time further, as the operation of merging with trunk may become
 cumbersome. Now it seems to me sufficiently stable.

T.


I think this is the time to check it in -- with the trivial
renames you propose.


I hope you mean _without_ the trivial renames...


We're not close to a trunk release so any
bugs will get ironed out in a timely manner.


I'd prefer that the patch is incrementally integrated. This patch should 
serve as a reference goal implementation. I am talking about how I would 
personally proceed but I am not Tommaso.


It this patch goes as-is you have to promise to fixed all bugs and 
regressions Tommaso (I would help you of course).


I'll to do a review of the patch in the coming days.

Abdel.

Re: Scrollfix patch

[Abdelrazak Younes]

Abdelrazak Younes wrote:


It this patch goes as-is you have to promise to fixed all bugs and 
regressions Tommaso (I would help you of course).


If this patch goes in as-is you have to promise to fix all bugs and 
regressions Tommaso (I would help you of course).




I'll to do a review of the patch in the coming days.


I'll try to do a review of the patch in the coming days.

Looking at the state of my spelling, obviously not today :-)

Abdel.

Re: update links on wiki

[Jürgen Spitzmüller]

Andre Poenitz wrote:
> > Which means the design is lame.
>
> Wasn't the intention to have a weak 'protection' only to save us from
> spam bots?

I think in the case were someone could link to an evil binary as "LyX 1.5.2 
installer", we should be much more restrictive.

Jürgen

Re: trunk compile problem

[Andre Poenitz]

On Sat, Nov 10, 2007 at 11:54:32PM +0100, Pavel Sanda wrote:
> are you talking about all occurences of X/lib/.h ?
> i'm bit confused what all the numbers mean, eg # 1 "/usr/include/X11/Xatom.h" 
> 1 3 4

The first one is the line number, I don't know about the others.

I specifically meant the file X.h, but basically nothing from
/usr/include/X11/ should show up.

Urm... I just see it's our doing, not Qt's:

#ifdef Q_WS_X11
#include 
#include 
#endif

and it seems to be used in the selection handling...

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 07:49:54AM +0200, Martin Vermeer wrote:
> On Sun, Nov 11, 2007 at 05:24:36AM +0100, Tommaso Cucinotta wrote:
> >  Hi all,
> > 
> >  please, find attached an improved version of the scrollfix patch.
> > 
> >  Summary of the further changes:
> >  -) most optimizations for updating a single par are back
> >  -) actually, it is possible to specify a par range with Update::SinglePar
> >-- actually, should be renamed as Update::Paragraphs;
> >-- actually, Update::Force should be renamed as Update::Screen ?
> >  -) class UpdateScope encapsulates the scope of an update (updateFlags
> >plus parameters, e.g. the par range to be updated if SinglePar is used)
> >  -) the boxes example now works correctly, except it is somewhat slow
> >because with SinglePar I'm updating and redrawing the outer Par,
> >not the inner one, so with such a great box (or even table, etc...),
> >it gets slow -- here I should add a further parameter to UpdateScope
> >specifying the Text where the update starts from;
> >  -) probably it adheres slightly more to the coding rules;
> >  -) updated to trunk revision 21533;
> >  -) needs testing to check if there are any further crashes;
> > 
> >  As it is somewhat growing, I wouldn't like to keep working on it for too
> >  much time further, as the operation of merging with trunk may become
> >  cumbersome. Now it seems to me sufficiently stable.
> > 
> > T.
> 
> I think this is the time to check it in -- with the trivial
> renames you propose. We're not close to a trunk release so any
> bugs will get ironed out in a timely manner.

I'd like to see some performance measures first, lest we paint
ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the 
current one for performance reasons when e.g. loading/resizing
inserting in big docments.

If we blindly apply fundamental changes to the paint strategy 
it might well be that there are some problems with the strategy
that are _conceptually_ not solvable.

Andre'

Re: trunk compile problem

[Pavel Sanda]

> > are you talking about all occurences of X/lib/.h ?
> > i'm bit confused what all the numbers mean, eg # 1 
> > "/usr/include/X11/Xatom.h" 1 3 4
> 
> The first one is the line number, I don't know about the others.

i learnt meanwhile
`1'  indicates the start of a new file.
`2'  indicates returning to a file (after having included another file).
`3'  indicates that the following text comes from a system header file, so 
certain warnings should be suppressed.
`4'  indicates that the following text should be treated as being wrapped in an 
implicit extern "C" block. 

btw in addition i use --enable-monolithic-insets
and still see many insets/Inset*.cpp compiled individually. is it supposed to 
be this way ?

pavel

Re: trunk compile problem

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:27:13PM +0100, Pavel Sanda wrote:
> > > are you talking about all occurences of X/lib/.h ?
> > > i'm bit confused what all the numbers mean, eg # 1 
> > > "/usr/include/X11/Xatom.h" 1 3 4
> > 
> > The first one is the line number, I don't know about the others.
> 
> i learnt meanwhile
> `1'  indicates the start of a new file.
> `2'  indicates returning to a file (after having included another file).
> `3'  indicates that the following text comes from a system header file, so 
> certain warnings should be suppressed.
> `4'  indicates that the following text should be treated as being wrapped in 
> an implicit extern "C" block. 

Ah... thanks for the explanation.

> btw in addition i use --enable-monolithic-insets and still see many
> insets/Inset*.cpp compiled individually. is it supposed to be this way?

For some reason the feature seems to be gone?

Andre'

Approaching LyX 1.5.3 [status update #2]

[Jürgen Spitzmüller]

We are already pretty close to a release: we have fixed the regressions 
introduced with 1.5.2 (pixmap cache, AMS classes) and several other things, 
including 9 critical bugs. So 1.5.3svn is significantly ahead of 1.5.2, IMHO.

Therefore, I don't want to hold back the release very much longer. However, 
there are still some things left to do.

On bugzilla, there are five open critical bugs. I think at least these two 
should be fixed:

4333   cri   lyx crashes when opening 1.4.3. file with index containin... 
4346   cri   Synchronizing insets crash when two windows open

I hope that Abdel and José, as the experts in the respective area, will find 
time to have a look.

Furthermore, there are several bugs related to encoding switches and CJK, and 
it turned out that CJK doesn not work at all (and probably never worked) in 
some circumstances (in non-CJK documents):

3561   cri   crash when changing document encoding
4349   cri   assert with CJK in non-CJK paragraph
4337   maj   LaTeX file has no \end{CJK} if it contains multiple langu...

I had a look at these issues over the weekend. As I see it, the encoding 
switch mechanism needs a major overhaul. It includes some hacks for CJK (most 
notably the "ascii"/open_encoding_ hack in latexWriteEndChanges) that should 
be replaced by something sane. This is a prerequisite (if not the solution) 
to fix the above bugs.
However, I'm sceptical that we can achieve this for 1.5.3, and I'm also 
reluctant to do it now, since it touches very sensitive parts of the code. So 
it would be good if anyone of the few people who really understand the 
encoding mechanism thoroughly (I don't count myself to those) could fix this 
in trunk, so that we can backport the fixes for 1.5.4.

There are still some other bugs left, "if you are feeling adventurous"(TM). 
Here is my personal chart:

2178   maj   create empty layout in all text classes
4081   nor   Char style is not set properly when switching through doc...
4260   nor   RMB opening of outliner doesn't select correct list
4302   nor   changes lost in settings window on focus of main window

feel free to pick out a different one from those bugs targetted to 1.5.3.

Regarding Michael's list, I think only these are relevant for the time being:

http://www.lyx.org/trac/changeset/20419 - GuiApplication::notify(): 
  don't crash with abort() but exit gracefully when an exception is 
  caught. try to catch LyX specific exceptions.
http://www.lyx.org/trac/changeset/20531 - Gives the user some 
  information about the crash.
http://www.lyx.org/trac/changeset/20437 - Remove redundant 
  AlignPossible? lines
http://www.lyx.org/trac/changeset/20438 - Disallow setting of alignment 
  in protected environments, where it is broken.

(all these can go in).


Jürgen
-*- text -*-

This file describes what has been done in the preparation of LyX 1.5.3
All comments are welcome.

I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked into the BRANCH_1_5_X branch, which you
can get with the command
  svn co svn://svn.lyx.org/lyx/lyx-devel/branches/BRANCH_1_5_X lyx-1.5.x

Juergen

[In this list, I try to group things by topic and in decreasing
order of importance. This is, of course, subjective...]


What's new
==


** Updates:
***

* DOCUMENTATION AND LOCALIZATION

- Update Czech, French, Japanese, Spanish and Traditional Chinese 
  translations of the user interface.

- Spanish translation of the example file "ItemizeBullets.lyx".

- Updated French introduction manual.


* USER INTERFACE

- The way collapsable insets (footnotes, comments etc) are widen has seen
  a complete overhaul in order to speedup painting when typing within
  insets. Now these insets are widen as soon as they contain more than one
  row of text. Users of Mac/PPC and of Unixes with slow X11 server should
  feel a significant boost in performance thanks to this change.

- The pixmap cache that was introduced in LyX 1.5.2 to improve performance
  can now be switched on and off in Preferences, since it might decrease
  on-screen display quality of fonts (subpixel hinting). By default, the
  cache is disabled. If you experience performance problems, turn in on
  (Mac and Windows only).

- The behaviour of Return and M-Return has changed: they now allow to either
  keep current paragraph and depth or to nesting paragraph (bug 2445).

- Add the esint font to the private math fonts. This font assures a
  consistent on screen looking for all kinds of supported integral signs.

- The slides/foils of presentation classes such as beamer, powerdot, foils
  and slides are now displayed in the outliner. This makes it easy to navigate
  to specific slides or move them up and down (bug 78).

- It is now possible to enter greek and cyrillic characters and have them
  typesetted without switching to the proper language.

- Inset-dissolve now works in mathed.

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> > I think this is the time to check it in -- with the trivial
> > renames you propose. We're not close to a trunk release so any
> > bugs will get ironed out in a timely manner.
> 
> I'd like to see some performance measures first, lest we paint
> ourselves into a corner here.

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 01:53:52PM +0100, Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> > > I think this is the time to check it in -- with the trivial
> > > renames you propose. We're not close to a trunk release so any
> > > bugs will get ironed out in a timely manner.
> > 
> > I'd like to see some performance measures first, lest we paint
> > ourselves into a corner here.
> 
> An entirely unscientific test (sitting in front of the computer and
> counting) yields ~4s for loading the UserGuide before applying the patch
> and ~13s afterwards. There is some additional debug output, but I don't
> think the resulting scrolling in the terminal accounts for all of those
> nine extra seconds.

Looks better with the debug output disabled. Still:
 
> So please: Produce some numbers showing that there are no inacceptable
> regressions wrt to performance. A performance degradation by a factor of
> 3 for loading documents does not look like a good start.

Also, loading the UserGuide and keeping  pressed gets stuck at
some point of time. Also, on the way there the cursor is sometimes
off-screen.

Maybe you can also get in touch with Alfredo. He spent quite some time
with the current architecture so he might be aware of more pitfalls than
I am.

Andre'

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the 
current one for performance reasons when e.g. loading/resizing

inserting in big docments.
  

My feeling is that, even with hundreds of outer paragraphs,
the process of summing their heights up should not be
even perceivable on modern CPUs (provided that the heights
are directly available within a vector, like it is now -- ParMetricsCache
is not a map anymore, but a vector). And, more importantly,
such process would be triggered only as a response to:
1) change of height of currently edited par
  1.a) break of currently edited par (Enter)
2) cut and paste operations
3) width resize of screen

If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a "summing (balanced) tree", that would exhibit O(log n)
complexity for little updates like needed in 1) [not sure about
1.a], but probably you won't avoid the O(n) updates in case of
2) or 3).

If you look at the patch code, you'll notice that many times
(not all, though) paragraph heights are managed through
dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
instead of using the "standard" par_metrics_[p].height(), just
in view of such possibility.


   T.

Re: LyXAction and updates ?

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?

Yep, thx, and I'd like to eliminate the LyXAction::func_attrib / UpdateFlags
enums redundancy, by either:
-) specifying differently LyXActions and UpdateFlags for LFUNs
-) or letting the two concepts collaps, i.e. UpdateFlags go away, and their
  enums are incorporated into LyXAction

Personally, I would prefer the first one, as the func_attrib enum is 
documented

like this:

   /// possible "permissions" for an action
   enum func_attrib {
   Noop = 0, //< nothing special about this func
   ReadOnly = 1, //< can be used in RO mode (perhaps this 
should ch

ange)
   NoBuffer = 2, //< Can be used when there is no document open
   Argument = 4, //< Requires argument
   NoUpdate = 8, //< Does not (usually) require update
   SingleParUpdate = 16 //< Usually only requires this par 
updated

   };

As you can see, the last two ones are not "permissions" at all, i.e. they do
not help specifying when the action is allowed or not.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.


Thanx, I'll try to figure it out...

Looks better with the debug output disabled. Still:
  

Did you get the same numbers with debug output disabled ?

   T.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.
  

Well, I'm verifying on my laptop. But I want to be sure to have
two LyX compiled exactly with the same options, and debug
disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
recompilation of LyX, so I guess I'll have numbers within one
hour or so (and I'm also deleting a couple of kernel source
trees to accomodate for the needed space).

Anyway, please note that, with the current patch, *all* par
metrics and heights are pre-computed on a document load
(full metrics are discarded for all pars but the visible ones),
so I expect anycase a slow-down on document opening. As
already mentioned on the list, I'd like to switch to an
incremental computation of the document height that is
made in the background while the user is already able to
work on the document.

I'd make such change as a further incremental patch, but if
you prefer the all-in-one approach, I can go further to such
step.

   T.

any known problems with gcc-4.2?

[Mikhail Teterin]

Hello!

A user of FreeBSD-7.0-BETA2 has just reported a problem with lyx seg-faulting 
at start-up:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117963

(the crash is inside calloc() suggesting a memory corruption).

It seems to work for me here, on FreeBSD-6.2. The most pronounced difference 
between the OS-releases is the version of the compiler tool-chain. On 7.x we 
use gcc-4.2 and on 6.x it is still 3.4.6.

Were there any known problems with lyx-1.4.4 and gcc-4.2 or do I need to dig 
deeper into it? Thanks!

-mi

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

and, if they are used to trigger automatically Update::Force and
Update::SinglePar, where is the point in the code that is supposed
to do such triggering action ? Should be in the neighbour of
processUpdateFlags(), but I'm not figuring that out.


I guess you figured out by yourself by now, don't you?
Yep, thx, and I'd like to eliminate the LyXAction::func_attrib / 
UpdateFlags

enums redundancy, by either:
-) specifying differently LyXActions and UpdateFlags for LFUNs
-) or letting the two concepts collaps, i.e. UpdateFlags go away, and their
  enums are incorporated into LyXAction


Well I don't think these two enums are redundant at all. They are simply 
two unrelated different things. I'd rather get rid of the UpdateFlags 
altogether and let BufferView/TextMetrics automatically decides what 
needs drawing or not. A bit like what we have now with the Row signatures.


But that is another story Tommaso. Please try to put the par height 
cache patch into good shape first. Your last patch is full of 
cleanups/redesigns in addition to the par height cache. So I suggest to 
either put in these first and delay the scrolling part for after, or the 
opposite.


Abdel.

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> ourselves into a corner here. We had this kind of approach (all
>> paragraph heights known) for a long time and switched to the current one 
>> for performance reasons when e.g. loading/resizing
>> inserting in big docments.
>>   
> My feeling is that, even with hundreds of outer paragraphs,
> the process of summing their heights up should not be
> even perceivable on modern CPUs (provided that the heights
> are directly available within a vector, like it is now -- ParMetricsCache
> is not a map anymore, but a vector). And, more importantly,
> such process would be triggered only as a response to:
> 1) change of height of currently edited par
>   1.a) break of currently edited par (Enter)
> 2) cut and paste operations
> 3) width resize of screen

4) Loading of a document.

> If you have serious concerns about this (probably due to the
> past experience on developing LyX), the best solution would
> be a "summing (balanced) tree", that would exhibit O(log n)
> complexity for little updates like needed in 1) [not sure about
> 1.a], but probably you won't avoid the O(n) updates in case of
> 2) or 3).

I think loading/resizing in 4 second is ok. 20 is rather not.
I know, it's not that bad, I am exaggerating. And of course
one could provide some more versose status message (as in 23/5490
paragraphs done) giving the impression that 'something' happens...

> If you look at the patch code, you'll notice that many times
> (not all, though) paragraph heights are managed through
> dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
> instead of using the "standard" par_metrics_[p].height(), just
> in view of such possibility.

The patch as such looks like a sensible implementation of the idea
(plus/minus some minor quirks). However, as this is quite intrusive
change of concept I'd rather make sure the concept is sound. And I
do not really want to rely on gut feelings only here (my gut says:
Id shoul be ok as we used to o it like that for a while and the
lazy rebreaking was not too much of a  success and machines are 
faster tofday then five years ago).

Andre'

Re: Scrollfix patch

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote:



If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a "summing (balanced) tree", that would exhibit O(log n)
complexity for little updates like needed in 1) [not sure about
1.a], but probably you won't avoid the O(n) updates in case of
2) or 3).


I think loading/resizing in 4 second is ok.


I disagree with that. Loading should be as fast as possible and resizing 
should be instantaneous. Or we just switch to implement a WISIWIG 
processor. There are a lot of good things in Tommaso's patch but the 
initial calculation of all ParMetrics is not one of those. The 
TextMetrics API additions are nice but are orthogonal to our scrolling 
problem.



20 is rather not.
I know, it's not that bad, I am exaggerating. And of course
one could provide some more versose status message (as in 23/5490
paragraphs done) giving the impression that 'something' happens...


That's the thing I hate most about MSWords: continuously waiting for the 
re-pagination to complete. We don't need a *perfect* scrolling 
behaviour, just a sensible one. A simple cache of paragraph height would 
do the job and I wish Tommaso had followed this direction instead.


Abdel.

Re: Scrollfix patch

[Alfredo Braunstein]

Andre Poenitz wrote:

>> 1) change of height of currently edited par
>>   1.a) break of currently edited par (Enter)
>> 2) cut and paste operations
>> 3) width resize of screen
> 
> 4) Loading of a document.
> 
>> If you have serious concerns about this (probably due to the
>> past experience on developing LyX), the best solution would
>> be a "summing (balanced) tree", that would exhibit O(log n)
>> complexity for little updates like needed in 1) [not sure about
>> 1.a], but probably you won't avoid the O(n) updates in case of
>> 2) or 3).
> 
> I think loading/resizing in 4 second is ok. 20 is rather not.
> I know, it's not that bad, I am exaggerating. And of course
> one could provide some more versose status message (as in 23/5490
> paragraphs done) giving the impression that 'something' happens...

Mmm... I think this would be pretty bad.

>> If you look at the patch code, you'll notice that many times
>> (not all, though) paragraph heights are managed through
>> dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
>> instead of using the "standard" par_metrics_[p].height(), just
>> in view of such possibility.
> 
> The patch as such looks like a sensible implementation of the idea
> (plus/minus some minor quirks). However, as this is quite intrusive
> change of concept I'd rather make sure the concept is sound. And I
> do not really want to rely on gut feelings only here (my gut says:
> Id shoul be ok as we used to o it like that for a while and the
> lazy rebreaking was not too much of a  success and machines are
> faster tofday then five years ago).

My main concern is that is much more difficult to go the nonlazy -> lazy
route as we have done (and Andre' and myself invested a good deal of time
doing it) than the other way around. So we should make this decision very
carefully. 

PS: I *think* I agree with Andre on this point, but I rather not say
it 'cause lately I'm not guessing right ;-)

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Abdelrazak Younes wrote:

>>> If you have serious concerns about this (probably due to the
>>> past experience on developing LyX), the best solution would
>>> be a "summing (balanced) tree", that would exhibit O(log n)
>>> complexity for little updates like needed in 1) [not sure about
>>> 1.a], but probably you won't avoid the O(n) updates in case of
>>> 2) or 3).
>> 
>> I think loading/resizing in 4 second is ok.
> 
> I disagree with that. Loading should be as fast as possible and resizing
> should be instantaneous. 

Exactly

> Or we just switch to implement a WISIWIG 
> processor. There are a lot of good things in Tommaso's patch but the
> initial calculation of all ParMetrics is not one of those. The
> TextMetrics API additions are nice but are orthogonal to our scrolling
> problem.
> 
>> 20 is rather not.
>> I know, it's not that bad, I am exaggerating. And of course
>> one could provide some more versose status message (as in 23/5490
>> paragraphs done) giving the impression that 'something' happens...
> 
> That's the thing I hate most about MSWords: continuously waiting for the
> re-pagination to complete. We don't need a *perfect* scrolling
> behaviour, just a sensible one. A simple cache of paragraph height would
> do the job and I wish Tommaso had followed this direction instead.

I agree 100%. 

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Andre Poenitz wrote:

> On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
>> > I think this is the time to check it in -- with the trivial
>> > renames you propose. We're not close to a trunk release so any
>> > bugs will get ironed out in a timely manner.
>> 
>> I'd like to see some performance measures first, lest we paint
>> ourselves into a corner here.
> 
> An entirely unscientific test (sitting in front of the computer and
> counting) yields ~4s for loading the UserGuide before applying the patch
> and ~13s afterwards. There is some additional debug output, but I don't
> think the resulting scrolling in the terminal accounts for all of those
> nine extra seconds.
> 
> So please: Produce some numbers showing that there are no inacceptable
> regressions wrt to performance. A performance degradation by a factor of
> 3 for loading documents does not look like a good start.

A small point: when testing we should not limit ourselves to the Userguide.
IMO one of the really strong points of LyX is to be able to deal with huge
documents, like books. (the UG has just 150 pages, it is like a small
book). Btw, we used to test performance with UG20 (just 20 copies of
UserGuide) some time (but I agree that this is kind of extreme, though).

A/

Re: Scrollfix patch

[Alfredo Braunstein]

Tommaso Cucinotta wrote:

> Andre Poenitz ha scritto:
>> ourselves into a corner here. We had this kind of approach (all
>> paragraph heights known) for a long time and switched to the
>> current one for performance reasons when e.g. loading/resizing
>> inserting in big docments.
>>   
> My feeling is that, even with hundreds of outer paragraphs,
> the process of summing their heights up should not be
> even perceivable on modern CPUs (provided that the heights
> are directly available within a vector, like it is now -- ParMetricsCache
> is not a map anymore, but a vector). And, more importantly,
> such process would be triggered only as a response to:
> 1) change of height of currently edited par
>1.a) break of currently edited par (Enter)
> 2) cut and paste operations
> 3) width resize of screen

3) document loading
4) graphics updating -> this is particular important with math previews on a
document full of them.


> If you have serious concerns about this (probably due to the
> past experience on developing LyX), the best solution would
> be a "summing (balanced) tree", that would exhibit O(log n)
> complexity for little updates like needed in 1) [not sure about
> 1.a], but probably you won't avoid the O(n) updates in case of
> 2) or 3).

This could be a good idea (if needed of course, numbers should tell).

A/

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
> Andre Poenitz ha scritto:
>> An entirely unscientific test (sitting in front of the computer and
>> counting) yields ~4s for loading the UserGuide before applying the patch
>> and ~13s afterwards. There is some additional debug output, but I don't
>> think the resulting scrolling in the terminal accounts for all of those
>> nine extra seconds.
>>
>> So please: Produce some numbers showing that there are no inacceptable
>> regressions wrt to performance. A performance degradation by a factor of
>> 3 for loading documents does not look like a good start.
>>   
> Well, I'm verifying on my laptop. But I want to be sure to have
> two LyX compiled exactly with the same options, and debug
> disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
> recompilation of LyX, so I guess I'll have numbers within one
> hour or so (and I'm also deleting a couple of kernel source
> trees to accomodate for the needed space).
>
> Anyway, please note that, with the current patch, *all* par
> metrics and heights are pre-computed on a document load
> (full metrics are discarded for all pars but the visible ones),
> so I expect anycase a slow-down on document opening.

Some performance decrease for loading will be acceptable...

> As already mentioned on the list, I'd like to switch to an
> incremental computation of the document height that is
> made in the background while the user is already able to
> work on the document.

> I'd make such change as a further incremental patch, but if
> you prefer the all-in-one approach, I can go further to such
> step.

"Incremental" is fine if the direction is ok and each step
leaves us with a usable code base.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 06:21:45PM +0100, Abdelrazak Younes wrote:
>> 20 is rather not.
>> I know, it's not that bad, I am exaggerating. And of course
>> one could provide some more versose status message (as in 23/5490
>> paragraphs done) giving the impression that 'something' happens...
>
> That's the thing I hate most about MSWords: continuously waiting for the 
> re-pagination to complete. We don't need a *perfect* scrolling behaviour, 
> just a sensible one. A simple cache of paragraph height would do the job 
> and I wish Tommaso had followed this direction instead.

So looks like Tommasso and you will need to talk to each other ;-)

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
> 
> > On Sun, Nov 11, 2007 at 01:21:03PM +0100, Andre Poenitz wrote:
> >> > I think this is the time to check it in -- with the trivial
> >> > renames you propose. We're not close to a trunk release so any
> >> > bugs will get ironed out in a timely manner.
> >> 
> >> I'd like to see some performance measures first, lest we paint
> >> ourselves into a corner here.
> > 
> > An entirely unscientific test (sitting in front of the computer and
> > counting) yields ~4s for loading the UserGuide before applying the patch
> > and ~13s afterwards. There is some additional debug output, but I don't
> > think the resulting scrolling in the terminal accounts for all of those
> > nine extra seconds.
> > 
> > So please: Produce some numbers showing that there are no inacceptable
> > regressions wrt to performance. A performance degradation by a factor of
> > 3 for loading documents does not look like a good start.
> 
> A small point: when testing we should not limit ourselves to the Userguide.
> IMO one of the really strong points of LyX is to be able to deal with huge
> documents, like books. (the UG has just 150 pages, it is like a small
> book). Btw, we used to test performance with UG20 (just 20 copies of
> UserGuide) some time (but I agree that this is kind of extreme, though).

But if a concept does not scale up well it's usually a bad concept. 
So checking with ug20 is certainly still a vaild approach.

Andre'

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 08:08:52PM +0100, Andre Poenitz wrote:
> On Sun, Nov 11, 2007 at 05:25:20PM +0100, Tommaso Cucinotta wrote:
> > Andre Poenitz ha scritto:
> >> An entirely unscientific test (sitting in front of the computer and
> >> counting) yields ~4s for loading the UserGuide before applying the patch
> >> and ~13s afterwards. There is some additional debug output, but I don't
> >> think the resulting scrolling in the terminal accounts for all of those
> >> nine extra seconds.
> >>
> >> So please: Produce some numbers showing that there are no inacceptable
> >> regressions wrt to performance. A performance degradation by a factor of
> >> 3 for loading documents does not look like a good start.
> >>   
> > Well, I'm verifying on my laptop. But I want to be sure to have
> > two LyX compiled exactly with the same options, and debug
> > disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
> > recompilation of LyX, so I guess I'll have numbers within one
> > hour or so (and I'm also deleting a couple of kernel source
> > trees to accomodate for the needed space).
> >
> > Anyway, please note that, with the current patch, *all* par
> > metrics and heights are pre-computed on a document load
> > (full metrics are discarded for all pars but the visible ones),
> > so I expect anycase a slow-down on document opening.
> 
> Some performance decrease for loading will be acceptable...

But it looks like Abdel and Alfredo disagree. So maybe some kind of
discussion is needed.

Andre'

Re: Scrollfix patch

[Abdelrazak Younes]

Andre Poenitz wrote:

On Sun, Nov 11, 2007 at 06:46:38PM +0100, Alfredo Braunstein wrote:

A small point: when testing we should not limit ourselves to the Userguide.
IMO one of the really strong points of LyX is to be able to deal with huge
documents, like books. (the UG has just 150 pages, it is like a small
book). Btw, we used to test performance with UG20 (just 20 copies of
UserGuide) some time (but I agree that this is kind of extreme, though).


Yes, this plus the fact that one often loads many documents at startup.



But if a concept does not scale up well it's usually a bad concept. 
So checking with ug20 is certainly still a vaild approach.


And it is always my approach when testing file loading or label/toc updates.

Abdel.

Re: Scrollfix patch

[Tommaso Cucinotta]

Ok, I have my own numbers. This is what I obtained launching
LyX from the shell asking to open a document, and hitting Alt-F4
(close application) as soon as I see the LyX window. Note that,
before LyX is closed, I can see clearly the loaded document showing
on the screen, then the pressed sequence closes LyX (therefore
in the patched case, full par metrics and heights computation is done).

Note also that I didn't report numbers from the *first* execution,
but I repeated the process 3 or 4 times, then I reported the last
numbers. This is done to reach a "fair" condition in which all files
are basically cached in the Linux disk cache when launching the
program.

This is trunk, as checked out ~2 hour ago (USERGUIDE.LYX):

[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/UserGuide.lyx > /dev/null 2>&1

real0m3.057s
user0m2.127s
sys 0m0.112s

This is my scrollfix patch, as sent to the list tonight:

[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/UserGuide.lyx > /dev/null 2>&1

real0m2.611s
user0m1.719s
sys 0m0.110s

And now again trunk for EMBEDDEDOBJECTS.LYX:

[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1

real0m2.887s
user0m1.912s
sys 0m0.141s

and again my scrollfix patch:

[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1


real0m3.156s
user0m2.269s
sys 0m0.106s

Conclusions: the unscientific experiment of Andre Poenits was really 
non-scientific.
I guess he must have left debug enabled when trying the scrollfix, and 
disabled in the
other case :-) Another possibility could be he tried the scrollfix with 
an empty disk
cache, then trunk with a filled disk-cache. The difference is enormous, 
as shown below:


This is what happens to trunk if I clear the disk cache:

[EMAIL PROTECTED]:~# sync && echo 3 > /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-trunk$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1

real0m18.461s
user0m1.952s
sys 0m0.195s

and this is my scrollfix after the same process:

[EMAIL PROTECTED]:~# sync && echo 3 > /proc/sys/vm/drop_caches
[EMAIL PROTECTED]:~/lyx-devel$ time sudo nice ./src/lyx 
lib/doc/EmbeddedObjects.lyx > /dev/null 2>&1

real0m19.146s
user0m2.268s
sys 0m0.187s

As you can see, ~20 seconds are needed to load LyX along with all the 
shared libraries
it uses, configuration files, and the document itself. The time actually 
spent by the

CPU does not change that much (~2 sec.).

If anyone has a longer file (a Master  thesis, PhD thesis or something 
like that), I
can try to see what is the doc length at which things start really 
slowing down

inaccpetably.

   T.

Tommaso Cucinotta ha scritto:

Andre Poenitz ha scritto:

An entirely unscientific test (sitting in front of the computer and
counting) yields ~4s for loading the UserGuide before applying the patch
and ~13s afterwards. There is some additional debug output, but I don't
think the resulting scrolling in the terminal accounts for all of those
nine extra seconds.

So please: Produce some numbers showing that there are no inacceptable
regressions wrt to performance. A performance degradation by a factor of
3 for loading documents does not look like a good start.
  

Well, I'm verifying on my laptop. But I want to be sure to have
two LyX compiled exactly with the same options, and debug
disabled. On my laptop ([EMAIL PROTECTED]), it takes ~30min. a full
recompilation of LyX, so I guess I'll have numbers within one
hour or so (and I'm also deleting a couple of kernel source
trees to accomodate for the needed space).

Anyway, please note that, with the current patch, *all* par
metrics and heights are pre-computed on a document load
(full metrics are discarded for all pars but the visible ones),
so I expect anycase a slow-down on document opening. As
already mentioned on the list, I'd like to switch to an
incremental computation of the document height that is
made in the background while the user is already able to
work on the document.

I'd make such change as a further incremental patch, but if
you prefer the all-in-one approach, I can go further to such
step.

   T.




--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso

Re: LyXAction and updates ?

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

or not. A bit like what we have now with the Row signatures.

Anyone explaining what are row signatures ? Thx.

   T.

Re: Scrollfix patch

[Andre Poenitz]

On Sun, Nov 11, 2007 at 08:59:01PM +0100, Tommaso Cucinotta wrote:
> Conclusions: the unscientific experiment of Andre Poenits was really
> non-scientific.  I guess he must have left debug enabled when trying
> the scrollfix, and disabled in the other case :-) Another possibility
> could be he tried the scrollfix with an empty disk cache, then trunk
> with a filled disk-cache. The difference is enormous, as shown below:

Note that your patch created lots of output by itself. So when I test
trunk vs patch I "magically" get more debug output.

> If anyone has a longer file (a Master  thesis, PhD thesis or something
> like that), I can try to see what is the doc length at which things
> start really slowing down inaccpetably.

Just copy the UserGuide 20 times into itself.

Andre'

crash when scrolling through the userguide

[Andre Poenitz]

#0  0xe410 in __kernel_vsyscall ()
#1  0xb7123875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7125201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb72c09e6 in __gnu_debug::_Error_formatter::_M_error ()
   from /usr/lib/libstdc++.so.6
#4  0x083a4c42 in __gnu_debug_def::vector::operator[] (this=0x917e264,
__n=4294967295)
at /usr/include/c++/4.1.3/debug/vector:192
#5  0x084d6859 in lyx::MathData::attachMacroParameters (this=0x93ae6f0, 
[EMAIL PROTECTED], macroPos=0, macroNumArgs=3, macroOptionals=0, 
fromInitToNormalMode=false, greedy=true)
at ../../trunk/src/DocIterator.h:48
#6  0x084d6d54 in lyx::MathData::updateMacros (this=0x93ae6f0,
[EMAIL PROTECTED])
at ../../trunk/src/mathed/MathData.cpp:392
#7  0x084d7189 in lyx::MathData::metrics (this=0x93ae6f0,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/MathData.cpp:256
#8  0x084b855a in lyx::InsetMathNest::metrics (this=0x93ae5c8,
[EMAIL PROTECTED])
at ../../trunk/src/mathed/InsetMathNest.cpp:152
#9  0x08546ec2 in lyx::InsetMathGrid::metrics (this=0x93ae5c8,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/InsetMathGrid.cpp:372
#10 0x0849755f in lyx::InsetMathHull::metrics (this=0x93ae5c8,
[EMAIL PROTECTED], 
[EMAIL PROTECTED]) at ../../trunk/src/mathed/InsetMathHull.cpp:296
#11 0x0827fe1a in lyx::TextMetrics::redoParagraph (this=0x916e044,
pit=964)
at ../../trunk/src/TextMetrics.cpp:496
#12 0x083222b9 in lyx::BufferView::updateMetrics (this=0x9527b90)
at ../../trunk/src/BufferView.cpp:1614
#13 0x08324359 in lyx::BufferView::processUpdateScope (this=0x9527b90, 
[EMAIL PROTECTED]) at ../../trunk/src/BufferView.cpp:394
#14 0x0815dc53 in lyx::LyXFunc::dispatch (this=0x8d4e798,
[EMAIL PROTECTED])
at ../../trunk/src/LyXFunc.cpp:2091
#15 0x0815f2ef in lyx::LyXFunc::processKeySym (this=0x8d4e798, 
[EMAIL PROTECTED], state=lyx::NoModifier)
at ../../trunk/src/LyXFunc.cpp:496
#16 0x086d5999 in lyx::frontend::WorkArea::processKeySym
(this=0x916ce34, 
[EMAIL PROTECTED], mod=lyx::NoModifier)
at ../../../trunk/src/frontends/WorkArea.cpp:178
#17 0x088c46ce in lyx::frontend::GuiWorkArea::keyPressEvent
(this=0x916ce20, 
ev=0xbff629f4) at
../../../../trunk/src/frontends/qt4/GuiWorkArea.cpp:434
#18 0xb790f272 in QWidget::event () from /usr/lib/libQtGui.so.4
#19 0xb7be0924 in QFrame::event () from /usr/lib/libQtGui.so.4
#20 0xb7c6cc51 in QAbstractScrollArea::event () from
/usr/lib/libQtGui.so.4
#21 0xb78c2ea0 in QApplicationPrivate::notify_helper ()


Stefan, it mentions attachMacroParameters()... Could you have a look?

Andre'

Re: Scrollfix patch

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

We don't need a *perfect* scrolling behaviour, just a sensible one.

I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a precise behaviour, while reading you doc,
searching for places to improve/change and editing.
A simple cache of paragraph height would do the job and I wish Tommaso 
had followed this direction instead.

Well, this is actually what I did, except I'm caching also the width,
the ascent and the descent, along with the height. Thought they could
have turned out to be useful, someday.
Basically, first I added a vector of heights, but immediately after I
realized it was sufficient to reuse the ParagraphMetrics type, with
the rows_ field cleared. So, the par_metrics_[] vector contains width,
height, asc and desc of all *outer* paragraphs in the document, while
only visible ones have the .rows() collection filled in.

Well, it is not really a cache in the "cache" sense...

   T.

Re: Scrollfix patch

[Tommaso Cucinotta]

Andre Poenitz ha scritto:

Just copy the UserGuide 20 times into itself.
  

Done. I get a time roughly doubled:

trunk: 5.5 secs
scrollfix: 10.5 secs

Well, I guess nobody really works with so large documents,
but you have at least one file per chapter. Though, I can
add the background-incremental height computation behaviour
to my patch, in an attempt to make everybody happy.

   T.

Re: update links on wiki

[christian . ridderstrom]

On Sun, 11 Nov 2007, Jürgen Spitzmüller wrote:


Andre Poenitz wrote:

Which means the design is lame.


Wasn't the intention to have a weak 'protection' only to save us from 
spam bots?


I think in the case were someone could link to an evil binary as "LyX 
1.5.2 installer", we should be much more restrictive.


With lame by design, I was actually referring to the password for 
uploading files which has been published on the list repeatedly.


Was anyone actually able to find the password for Windows.Windows etc 
online? That password (for editing the page) is supposed to be kept more 
restrictive, i.e. it's written down in the following file on aussie:


-rw-rw  1 chr wiki 501 Oct  8 14:15 /home/lyx/www/pmwiki/passwords.txt

Please let me know if that password is "lose".

/Christian

PS. According to notes in the file, these pages are "edit protected"
Pages that should be password protected:
* http://wiki.lyx.org/LyX/Welcome
* http://wiki.lyx.org/Windows/Windows
* http://wiki.lyx.org/Windows/LyX145
* http://wiki.lyx.org/Windows/LyX151
* http://wiki.lyx.org/Windows/LyX152

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: update links on wiki

[Joost Verburg]

Jürgen Spitzmüller wrote:
I think in the case were someone could link to an evil binary as "LyX 1.5.2 
installer", we should be much more restrictive.


In my opinion the links to binaries should be on the main LyX site, not 
on the wiki.


Joost

Re: Scrollfix patch

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

We don't need a *perfect* scrolling behaviour, just a sensible one.

I agree we may accept a non-perfect scrolling right after having opened
a document, or having made great changes. But, IMHO, after a while
it would be better to have a precise behaviour, while reading you doc,
searching for places to improve/change and editing.


I think that updating the par height the moment it is displayed on 
screen would be enough.


A simple cache of paragraph height would do the job and I wish Tommaso 
had followed this direction instead.

Well, this is actually what I did, except I'm caching also the width,
the ascent and the descent, along with the height. Thought they could
have turned out to be useful, someday.


I don't think this is useful. In any case, it is not useful now so why 
the memory waste?



Basically, first I added a vector of heights, but immediately after I
realized it was sufficient to reuse the ParagraphMetrics type, with
the rows_ field cleared.


I understand your reasoning but I disagree, sorry... see below.


So, the par_metrics_[] vector contains width,
height, asc and desc of all *outer* paragraphs in the document, while
only visible ones have the .rows() collection filled in.


I don't like this distinction. I prefer all or nothing. Actually I 
planned to have partial metrics also for non-main Insets. You are doing 
the other way around: full metrics for the main Inset.




Well, it is not really a cache in the "cache" sense...


Not in your patch no.

Abdel.

Re: LyXAction and updates ?

[Abdelrazak Younes]

Tommaso Cucinotta wrote:

Abdelrazak Younes ha scritto:

or not. A bit like what we have now with the Row signatures.

Anyone explaining what are row signatures ? Thx.


Look at ParagraphMetrics::computeRowSignature(). This is basically 
computing a signature of the Row based on its content and formatting. 
The Row will be redrawn only if this signature changes.


Abdel.

lyx <- GuiWorkArea.cpp dependencies

[Tommaso Cucinotta]

If I change GuiWorkArea.cpp, then type 'make lyx' from the
src folder, then I get:

make: `lyx' is up to date.

Simply typing 'make' rebuilds it. Is that normal ?

   T.

Re: crash when scrolling through the userguide

[Stefan Schimanski]

#0  0xe410 in __kernel_vsyscall ()
#1  0xb7123875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7125201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb72c09e6 in __gnu_debug::_Error_formatter::_M_error ()
  from /usr/lib/libstdc++.so.6
#4  0x083a4c42 in __gnu_debug_def::vector::operator[] (this=0x917e264,
__n=4294967295)
   at /usr/include/c++/4.1.3/debug/vector:192
#5  0x084d6859 in lyx::MathData::attachMacroParameters  
(this=0x93ae6f0,

   [EMAIL PROTECTED], macroPos=0, macroNumArgs=3, macroOptionals=0,
   fromInitToNormalMode=false, greedy=true)
   at ../../trunk/src/DocIterator.h:48
#6  0x084d6d54 in lyx::MathData::updateMacros (this=0x93ae6f0,
[EMAIL PROTECTED])
   at ../../trunk/src/mathed/MathData.cpp:392

Stefan, it mentions attachMacroParameters()... Could you have a look?


Sure, will do it tomorrow. Can you reproduce it? Where does it happen?

From the backtrace it seems to be the code which tries to keep the  
cursor as a reasonable position when folding/unfolding.


Stefan

Re: Scrollfix patch

[Tommaso Cucinotta]

Abdelrazak Younes ha scritto:

I don't like this distinction. I prefer all or nothing.

Well, if you really think it is preferreable, then it would
probably be a matter of a few minutes to create a new vector
TextMetrics::par_heights_[], in addition to the par_metrics_[]
one, and let the parHeight() / computeHeight() methods rely on
the new vector, rather than par_metrics_[].

   T.

www

[Pavel Sanda]

hi,

i have been searching something in our web and its like visiting archaeological
museum.

i'd like to to put few things back into more fresh outlook, see attachment.
the current version (background and other pictures can be broken) is on
http://195.113.31.123/~sanda/junk/wwlyx/www/

because i understand many changes are matter of taste, i'm waiting
for your comments or objections. also native speaker can look it over ;)

pavel
Index: navbar.inc
===
--- navbar.inc  (revision 21547)
+++ navbar.inc  (working copy)
@@ -21,7 +21,7 @@
 $ty[]=0; $na[]="MoreAboutLyX";   $sh[]="About";  
$li[]="$LYX/about/";
 $ty[]=0; $na[]="LyXGraphicalTour";   $sh[]="LGT";  
$li[]="$LYX/LGT/";
 $ty[]=0; $na[]="MailingLists"; $sh[]="Mail Lists"; 
$li[]="$LYX/internet/mailing.php";
-$ty[]=0; $na[]="TipsTricks";$sh[]="Tips";   
$li[]="http://www.texnik.de/;;
+$ty[]=0; $na[]="TipsTricks";$sh[]="Tips";   
$li[]="http://wiki.lyx.org/Tips/Tips;;
 $ty[]=0; $na[]="LyXWiki";  $sh[]="Wiki";   
$li[]="http://wiki.lyx.org/;;
 $ty[]=0; $na[]="GiveFeedback"; $sh[]="Feedback";   
$li[]="$LYX/feedback.php";
 $ty[]=0; $na[]="DevelopmentNews";  $sh[]="LDN";
$li[]="$LYX/news/";
Index: internet/mailing.php
===
--- internet/mailing.php(revision 21547)
+++ internet/mailing.php(working copy)
@@ -78,7 +78,9 @@
 
 
  The list is archived at a
-http://www.mail-archive.com/[EMAIL PROTECTED]/">new 
archive and an
+http://www.mail-archive.com/[EMAIL PROTECTED]/">
+new archive at mail-archive
+or http://dir.gmane.org/gmane.editors.lyx.devel;>GMANE 
and an
 http://www.mail-archive.com/[EMAIL PROTECTED]/">old 
archive.
 
 
@@ -105,7 +107,10 @@
  The list is archived at 
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/;>mail-archive.com
 and at
- http://marc.info/?l=lyx-devel;>MARC.
+ http://marc.info/?l=lyx-devel;>MARC
+and at
+ http://dir.gmane.org/gmane.editors.lyx.devel;>GMANE
+.
 
 
   
@@ -140,7 +145,6 @@
 
  
 
-
 
   Digests
 
Index: devel/cvs.php
===
--- devel/cvs.php   (revision 21547)
+++ devel/cvs.php   (working copy)
@@ -41,16 +41,17 @@
 LyX Home Page. Kept
 in this repository for ease for updating.
 
+While they are not in use anymore, these ones are kept for their
+historical interest:
+
+
+
  http://www.lyx.org/trac/browser/lyx-tests;>lyx-tests
   This repository contains various .lyx files
 that may be useful for testing purposes. 
 
 
-While they are not in use anymore, these ones are kept for their
-historical interest:
 
-
-
  http://www.lyx.org/trac/browser/lyx-1_0_x;>lyx-1_0_x 
  This is the old stable release branch.
 No more work is being done on this branch.
@@ -97,7 +98,7 @@
 
 
 This will make a directory lyx-devel and download lots of files
-into that directory. (A fresh copy will need about 270MB. However, depending 
on which frontends you are compiling, you will need a lot more space for the 
compiled version, up to 1.1GB if you built in all three frontends). 
+into that directory. (A fresh copy will need about 150MB. However, depending 
on which frontends you are compiling, you will need a lot more space for the 
compiled version, up to 1.1GB if you built in all three frontends). 
 
 Of course you can say svn co svn://svn.lyx.org/lyx/www-user/trunk 
www-user
 instead, depending on which module you'd like to download.
@@ -146,8 +147,11 @@
 documentation, and new features will always be looked at carefully, and will
 usually be accepted, with a number of exceptions. New features will rarely be
 accepted for the stable release version. Documentation which does not follow
-the requirements of the DocStyle document will not be accepted.
-Aside from that, though, we love getting new contributions! 
+the requirements of the 
+http://www.lyx.org/trac/browser/lyx-devel/trunk/development/coding;>
+DocStyle document will not be accepted.  
+Aside from that, though, we love getting new
+contributions! 
 
  If you'd like to make changes to LyX, it will make everyone's life easier
 if you change the latest SVN sources rather than the latest release. Here's a
Index: devel/guii.php
===
--- devel/guii.php  (revision 21547)
+++ devel/guii.php  (working copy)
@@ -13,6 +13,12 @@
 ?>
 
 
+The current status is the support of Qt frontend only. Below you can find
+the state of support in previous versions of LyX. xforms frontend was dropped,
+Gtk has no active maintainer.
+
+
+
 The following is a matrix indicating which things still need
 porting to which GUIs. It does not include the "main window" itself
 

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Pavel Sanda]

> Very good. Welcome on board Pavel!

just for sure... where are the lifeboats ?
pavel

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Martin Vermeer]

On Mon, Nov 12, 2007 at 02:47:12AM +0100, Pavel Sanda wrote:
> > Very good. Welcome on board Pavel!
> 
> just for sure... where are the lifeboats ?
> pavel

We don't do lifeboats. Think 'Hotel California'

- Martin

Re: update links on wiki

[Jürgen Spitzmüller]

[EMAIL PROTECTED] wrote:
> Was anyone actually able to find the password for Windows.Windows etc
> online?

Sure. Just go here
http://www.mail-archive.com/lyx-docs%40lists.lyx.org/
and enter "windows wiki password".

It's the 3rd hit.

Jürgen

Re: r21536 - in /lyx-devel/trunk/src: LyXFunc.cpp LyXRC.cpp L...

[Abdelrazak Younes]

Martin Vermeer wrote:

On Mon, Nov 12, 2007 at 02:47:12AM +0100, Pavel Sanda wrote:

Very good. Welcome on board Pavel!

just for sure... where are the lifeboats ?
pavel


We don't do lifeboats. Think 'Hotel California'


You can check out any time but you can never laaave...

Abdel.