On Thu, 31 May 2007, Andre Poenitz wrote:
On Thu, May 31, 2007 at 09:53:31PM +0200, Alfredo Braunstein wrote:
Andre Poenitz wrote:
I know the rules and I am sometimes even follow them.
You do?
There are some rules that are really hard to break...
Is that the rule about not following rul
Andre Poenitz wrote:
We want to get 1.5 out of the door.
we all agree on that one
Multiple views make LyX crash. Nobody is seemingly able to fix it in
a reasonable time frame.
you provided a reproducable way to crash lyx (being the responsible
grown-up you are ;) let's see whether abdel or
On Thu, May 31, 2007 at 09:53:31PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > I know the rules and I am sometimes even follow them.
>
> You do?
There are some rules that are really hard to break...
Andre'
Andre Poenitz wrote:
> I know the rules and I am sometimes even follow them.
You do?
> I said 'I will prepare a patch', not 'I will disable multiple views'.
I know, just teasing you. :-)
A/
Andre Poenitz wrote:
> On Thu, May 31, 2007 at 09:35:25PM +0200, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > We want to get 1.5 out of the door. Multiple views make LyX crash.
>> > Nobody is seemingly able to fix it in a reasonable time frame.
>> > So the only sensibly solution is t
On Thu, May 31, 2007 at 09:35:25PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > We want to get 1.5 out of the door. Multiple views make LyX crash.
> > Nobody is seemingly able to fix it in a reasonable time frame.
> > So the only sensibly solution is to disable the feature. Note t
On Thu, May 31, 2007 at 09:30:29PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Best thing I can do now is to plead guilty on either not reading your
> > patch or not noticing the added signal. In any case the signal can't
> > be left in. So either someone comes up with a real fi
Andre Poenitz wrote:
> We want to get 1.5 out of the door. Multiple views make LyX crash.
> Nobody is seemingly able to fix it in a reasonable time frame.
> So the only sensibly solution is to disable the feature. Note that
> I said 'disable', not 'remove'.
I proposed a reasonable fix avoid the c
Andre Poenitz wrote:
> Best thing I can do now is to plead guilty on either not reading your
> patch or not noticing the added signal. In any case the signal can't
> be left in. So either someone comes up with a real fix or I'll prepare
> a patch to remove the signal and disable multiple views at
On Thu, May 31, 2007 at 07:13:49PM +0200, Edwin Leuven wrote:
> Andre Poenitz wrote:
> >So either someone comes up with a real fix
>
> you're volunteering andre?
No. If it were that easy I propbably would have found the time to do so
when I had more time then now.
> >or I'll prepare a patch to r
Andre Poenitz wrote:
On Thu, May 31, 2007 at 06:55:38PM +0200, Abdelrazak Younes wrote:
I _never_ said that Angus endorsed the patch, just that he helped me. I
just said that *nobody* commented the approach, period.
Which in the time of an upcoming release plainly means 'rejected'.
Accepte
On Thu, May 31, 2007 at 06:55:38PM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >>>Also "fully" and "patch" does not help. And not "angus", "2007",
> >>>"abdel" (or "signal") and a lot of other combinations.
> >
> >I also see that Angus solved your C++ related problem. No less, no
> >mo
Andre Poenitz wrote:
So either someone comes up with a real fix
you're volunteering andre?
or I'll prepare a patch to remove the signal and disable multiple
views at the weekend.
small kids act like this with their even smaller brothers...
Andre Poenitz wrote:
Also "fully" and "patch" does not help. And not "angus", "2007",
"abdel" (or "signal") and a lot of other combinations.
I also see that Angus solved your C++ related problem. No less, no
more. Specifically it does not comment on the general sanity of the
signal-in-InsetBase
On Thu, May 31, 2007 at 09:04:11AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Wed, May 30, 2007 at 11:39:16PM +0200, Abdelrazak Younes wrote:
> >>I proposed the patch last week and it was available for comment for a
> >>few days. I even had some help from Angus so I don't think t
On Thu, 31 May 2007, Leuven, E. wrote:
Andre Poenitz wrote:
On Wed, May 30, 2007 at 11:39:16PM +0200, Abdelrazak Younes wrote:
I proposed the patch last week and it was available for comment for
a few days. I even had some help from Angus so I don't think this
thread went unoticed. Look for so
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Had you any intentions to make a wider audience aware of these
>> side-effects?
Abdelrazak> Anybody who tried the multiview with the same Buffer has
Abdelrazak> certainly noticed that. I noticed, Alfredo noticed, JMarc
Abdelr
Andre Poenitz wrote:
On Wed, May 30, 2007 at 11:39:16PM +0200, Abdelrazak Younes wrote:
I proposed the patch last week and it was available for comment for a
few days. I even had some help from Angus so I don't think this thread
went unoticed. Look for something with [FULLY WORKING PATCH] in th
Andre Poenitz wrote:
> On Wed, May 30, 2007 at 11:39:16PM +0200, Abdelrazak Younes wrote:
>> I proposed the patch last week and it was available for comment for
>> a few days. I even had some help from Angus so I don't think this
>> thread went unoticed. Look for something with [FULLY WORKING PATCH
On Wed, May 30, 2007 at 11:39:16PM +0200, Abdelrazak Younes wrote:
> I proposed the patch last week and it was available for comment for a
> few days. I even had some help from Angus so I don't think this thread
> went unoticed. Look for something with [FULLY WORKING PATCH] in the subject.
"2007
Andre Poenitz wrote:
On Wed, May 30, 2007 at 08:37:09AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote:
I enabled stdlib-debug and then were surprised about the slowness.
Some profiling was full of signal/slot stuff in co
Andre Poenitz wrote:
On Wed, May 30, 2007 at 02:30:37PM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I am not sure that registering every single DocIterator would be any
more efficient that my signal/slot solution. At the end you will have to
go through a
Andre Poenitz wrote:
On Wed, May 30, 2007 at 05:44:39PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak> I won't say random because as you found out you can
Abdelrazak> predict the behaviour.
After I have edited during 10 minutes in one part of the document, the
locati
Andre Poenitz wrote:
On Wed, May 30, 2007 at 05:46:46PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
These problems do not mean that you implemented badly, just that it is
a bigger task than you thought.
An by the way, the additional work required to properly handling these
cur
On Wed, May 30, 2007 at 09:27:18PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Wed, May 30, 2007 at 03:26:04PM +0200, Alfredo Braunstein wrote:
> >> Just a though... why do we need the invalidation signals at all?
> >> ...couldn't we go in fixIfBroken from the top to the tip o
Andre Poenitz wrote:
> On Wed, May 30, 2007 at 03:26:04PM +0200, Alfredo Braunstein wrote:
>> Just a though... why do we need the invalidation signals at all?
>> ...couldn't we go in fixIfBroken from the top to the tip of the
>> DocIterator checking that there is an inset an the given position in
On Wed, May 30, 2007 at 08:16:12PM +0200, Alfredo Braunstein wrote:
> Abdelrazak Younes wrote:
>
> > I did not think of that :-(. That could work indeed. I don't have the
> > time to implement this right now, maybe this could be the occasion of a
> > patch from you to signal that your come back is
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, May 30, 2007 at 02:37:43PM +0200, Jean-Marc Lasgouttes wrote:
| > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| >
| > Abdelrazak> I agree but it's more work than my signal based solution
| > Abdelrazak> which is assured t
On Wed, May 30, 2007 at 05:46:46PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
>
> >These problems do not mean that you implemented badly, just that it is
> >a bigger task than you thought.
>
> An by the way, the additional work required to properly handling these
> cursors is
On Wed, May 30, 2007 at 05:44:39PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Abdelrazak> I won't say random because as you found out you can
> >Abdelrazak> predict the behaviour.
> >
> >After I have edited during 10 minutes in one part of the document, the
> >location in the
On Wed, 30 May 2007 19:20:50 +0200
Andre Poenitz <[EMAIL PROTECTED]> wrote:
...
> >
> > >an in-inset Dimension cache (12 bytes)
> >
> > About the same situation as above.
>
> Again wrong. The most commonly used math inset (InsetMathChar)
> had no dimension cache. For a very good reason that
On Wed, May 30, 2007 at 03:26:04PM +0200, Alfredo Braunstein wrote:
> Just a though... why do we need the invalidation signals at all? ...couldn't
> we go in fixIfBroken from the top to the tip of the DocIterator checking
> that there is an inset an the given position in the paragraph, and that the
Abdelrazak Younes wrote:
> I did not think of that :-(. That could work indeed. I don't have the
> time to implement this right now, maybe this could be the occasion of a
> patch from you to signal that your come back is real? :-)
My come back? What, did I accidentally left? ;-)
A/
On Wed, May 30, 2007 at 02:42:14PM +0200, Alfredo Braunstein wrote:
> Abdelrazak Younes wrote:
>
> > Alfredo Braunstein wrote:
> >> Abdelrazak Younes wrote:
> >>
> >>> I am not sure that registering every single DocIterator would be any
> >>> more efficient that my signal/slot solution. At the en
On Wed, May 30, 2007 at 02:37:43PM +0200, Jean-Marc Lasgouttes wrote:
> > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> Abdelrazak> I agree but it's more work than my signal based solution
> Abdelrazak> which is assured to work in all cases. I tell you what, in
> Abdelrazak
On Wed, May 30, 2007 at 02:30:37PM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> >Abdelrazak Younes wrote:
> >
> >>I am not sure that registering every single DocIterator would be any
> >>more efficient that my signal/slot solution. At the end you will have to
> >>go through a table
On Wed, May 30, 2007 at 08:37:09AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote:
> >>I enabled stdlib-debug and then were surprised about the slowness.
> >>Some profiling was full of signal/slot stuff in copying cursor
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> As I said and using Alfredo's words, I was well aware of
Abdelrazak> this side-effect and I already accepted it. It would be
Abdelrazak> nice to properly track the cursor location but personall
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> As I said and using Alfredo's words, I was well aware of
Abdelrazak> this side-effect and I already accepted it. It would be
Abdelrazak> nice to properly track the cursor location but personally
Abdelrazak> I can live
Jean-Marc Lasgouttes wrote:
These problems do not mean that you implemented badly, just that it is
a bigger task than you thought.
An by the way, the additional work required to properly handling these
cursors is basically *nothing* compared to what I've done to support
multipleviews ;-)
A
Jean-Marc Lasgouttes wrote:
Abdelrazak> I won't say random because as you found out you can
Abdelrazak> predict the behaviour.
After I have edited during 10 minutes in one part of the document, the
location in the other place will really seem random.
Abdelrazak> We could think of the solution
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> But of course, this is not the correct solution,
Abdelrazak> This is as good as one can make it ;-), at least it is
Abdelrazak> better than the old Cursor::fixIsBroken() don't you
Abdelrazak> reckon?
Sure, but I think that,
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
For instance, put a cursor inside an inset, then
in another window add or remove some text before the inset so the
position of the inset changes... no destruction occurs, but is the cursor
still valid? (sorry don't have svn to check here.)
No,
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I am not sure that registering every single DocIterator would be any
more efficient that my signal/slot solution. At the end you will have to
go through a table.
Small remark: note that not all DocIterators need to b
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>>
>>> Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
> I am not sure that registering every single DocIterator would be any
> more efficient that my signal/slot solution. At the end you will ha
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> No, and that is the purpose of the new method
Abdelrazak> DocIterator::FixIfBroken(). This will first validate the
Abdelrazak> validity of the CursorSlice (thus the existence of the
Abdelrazak>
Jean-Marc Lasgouttes wrote:
>> "Abdelrazak" == Abdelrazak Younes
>> <[EMAIL PROTECTED]> writes:
>
> Abdelrazak> No, and that is the purpose of the new method
> Abdelrazak> DocIterator::FixIfBroken(). This will first validate the
> Abdelrazak> validity of the CursorSlice (thus the existenc
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> No, and that is the purpose of the new method
Abdelrazak> DocIterator::FixIfBroken(). This will first validate the
Abdelrazak> validity of the CursorSlice (thus the existence of the
Abdelrazak> insets) then the validit
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I am not sure that registering every single DocIterator would be any
more efficient that my signal/slot solution. At the end you will have to
go through a table.
Small remark: note that not
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I agree but it's more work than my signal based solution
Abdelrazak> which is assured to work in all cases. I tell you what, in
Abdelrazak> order to save the bits Andre is worried about I am go
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>>
>>> I am not sure that registering every single DocIterator would be any
>>> more efficient that my signal/slot solution. At the end you will have to
>>> go through a table.
>>
>> Small remark: note that not all
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I agree but it's more work than my signal based solution
Abdelrazak> which is assured to work in all cases. I tell you what, in
Abdelrazak> order to save the bits Andre is worried about I am going
Abdelrazak> to remove
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I am not sure that registering every single DocIterator would be any
more efficient that my signal/slot solution. At the end you will have to
go through a table.
Small remark: note that not all DocIterators need to be stable (mainly
cursors,
Abdelrazak Younes wrote:
> I am not sure that registering every single DocIterator would be any
> more efficient that my signal/slot solution. At the end you will have to
> go through a table.
Small remark: note that not all DocIterators need to be stable (mainly
cursors, maybe also bookmarks & e
Andre Poenitz wrote:
On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote:
I enabled stdlib-debug and then were surprised about the slowness.
Some profiling was full of signal/slot stuff in copying cursors
Well, I am not complaining about slowness (which hardly can be judged
On Tue, May 29, 2007 at 10:11:16PM +0200, Stefan Schimanski wrote:
> I enabled stdlib-debug and then were surprised about the slowness.
> Some profiling was full of signal/slot stuff in copying cursors
Well, I am not complaining about slowness (which hardly can be judged
by a non-optimized b
On Tuesday 29 May 2007 21:11:16 Stefan Schimanski wrote:
>
> I enabled stdlib-debug and then were surprised about the slowness.
> Some profiling was full of signal/slot stuff in copying cursors
Profiling with stdlib-debug is unfair and probably useless. :-)
> Stefan
--
José Abílio
Am 29.05.2007 um 22:03 schrieb Andre Poenitz:
On Tue, May 29, 2007 at 07:29:56PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Can you send me the full backtrace? What you sent suggests that the
crash is being caused when the destroyed() signal is sent by the
On Tue, May 29, 2007 at 07:29:56PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> >Richard Heck wrote:
> >>Can you send me the full backtrace? What you sent suggests that the
> >>crash is being caused when the destroyed() signal is sent by the new
> >>buffer's text inset, and the only
Abdelrazak Younes wrote:
Richard Heck wrote:
Can you send me the full backtrace? What you sent suggests that the
crash is being caused when the destroyed() signal is sent by the new
buffer's text inset, and the only thing that seems to connect to it is
the CursorSlice, at lines 45 and 64 of Curs
Abdelrazak Younes wrote:
> Richard Heck wrote:
>> Can you send me the full backtrace? What you sent suggests that the
>> crash is being caused when the destroyed() signal is sent by the new
>> buffer's text inset, and the only thing that seems to connect to it is
>> the CursorSlice, at lines 45 and
Richard Heck wrote:
Can you send me the full backtrace? What you sent suggests that the
crash is being caused when the destroyed() signal is sent by the new
buffer's text inset, and the only thing that seems to connect to it is
the CursorSlice, at lines 45 and 64 of CursorSlice.cpp.
If that is
62 matches
Mail list logo
