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_[]
Abdelrazak Younes wrote:
> You can check out any time
except when aussie is down ;-)
Jürgen
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.
[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
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
> Very good. Welcome on board Pavel!
just for sure... where are the lifeboats ?
pavel
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 u
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
#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 >::
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.
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 fo
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 prec
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
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 mo
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-incrementa
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 readi
#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 >:
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 trie
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.
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
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
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 apply
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
>
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'
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 ou
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
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 p
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], bu
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 de
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 upd
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
>> ins
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
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 dif
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
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
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
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 pa
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
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, le
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. How
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 lea
> > 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 return
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 upda
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
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
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 p
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.
> -) 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
> specifyin
> > > 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
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 U
[EMAIL PROTECTED] wrote:
Author: sanda
Date: Sat Nov 10 01:21:42 2007
New Revision: 21536
Very good. Welcome on board Pavel!
Abdel.
51 matches
Mail list logo
