Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see beforeDispatch members).
I've
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that we use my solution for
trunk. Opinion Jurgen?
For branch, your solution is not an
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that we use my solution for
trunk. Opinion Jurgen?
^^^
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos
() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos()
call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution,
On Aug 27, 2007, at 9:13 AM, Abdelrazak Younes wrote:
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the
getPos() call
above at the beginning of the LFUN
Abdelrazak Younes wrote:
Martin Vermeer wrote:
I expect you will have to do the rowpainter cleanup
at the same time.
I'd like to do it in three steps: first remove the hack, then put in
place a better design, then optimize if need be.
When I say better design, I mean that the rowpainter
Abdelrazak Younes [EMAIL PROTECTED] writes:
Alfredo Braunstein wrote:
I did a bit of research, and I think I found something, and it seems
a mess. Please correct me if I'm wrong, this is what I understand:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
On Mon, Aug 27, 2007 at 07:36:43PM +, Alfredo Braunstein wrote:
// store some values to be used inside of the handlers
getPos(beforeDispX_, beforeDispY_);
For trunk, I think we should replace all occurence of
cur.dispatch() with this-dispatch() in Text3::dispatch().
This
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way to
enforce this so we don't have to check manually (even some assert at run time
would be nice). Moreover, I don't see what do we gain by using a lyxfunc
internally, probably we should just put
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way
to enforce this so we don't have to check manually (even some assert at
run time would be nice). Moreover, I don't see what
Andre Poenitz wrote:
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way
to enforce this so we don't have to check manually (even some assert at
run time would be nice).
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see beforeDispatch members).
I've
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see
Abdelrazak Younes wrote:
> > For BRANCH_1_5 I think the simpler solution is to move the getPos() call
> > above at the beginning of the LFUN machinery: LyXFunc::dispatch().
>
> I'll try that solution, but I'd prefer that we use my solution for
> trunk. Opinion Jurgen?
For branch, your solution is
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that we use my solution for
trunk. Opinion Jurgen?
^^^
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos
() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos()
call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution,
On Aug 27, 2007, at 9:13 AM, Abdelrazak Younes wrote:
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the
getPos() call
above at the beginning of the LFUN
Abdelrazak Younes wrote:
Martin Vermeer wrote:
I expect you will have to do the rowpainter cleanup
at the same time.
I'd like to do it in three steps: first remove the hack, then put in
place a better design, then optimize if need be.
When I say better design, I mean that the rowpainter
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Alfredo Braunstein wrote:
> > I did a bit of research, and I think I found something, and it seems
> > a mess. Please correct me if I'm wrong, this is what I understand:
> >
> > Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
> >
On Mon, Aug 27, 2007 at 07:36:43PM +, Alfredo Braunstein wrote:
> > // store some values to be used inside of the handlers
> > getPos(beforeDispX_, beforeDispY_);
> >
> > For trunk, I think we should replace all occurence of
> > cur.dispatch() with this->dispatch() in
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way to
enforce this so we don't have to check manually (even some assert at run time
would be nice). Moreover, I don't see what do we gain by using a lyxfunc
internally, probably we should just put
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> >This seems good indeed. In the long run, however, we should think of a way
> >to enforce this so we don't have to check manually (even some assert at
> >run time would be nice). Moreover, I don't
Andre Poenitz wrote:
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way
to enforce this so we don't have to check manually (even some assert at
run time would be nice).
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
read.
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the wide_inset_ value
is used before
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells that otherwise the
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the
Abdelrazak Younes wrote:
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells that otherwise the
wide_inset_ value is used before initialized.
Sure, go ahead.
I'll do on tuesday for branch if Juergen agrees. The rationale is
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... I am _not_ sure...
Actually that's what I've read for some reason ;-) I would nevertheless
Martin Vermeer wrote:
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This wide stuff is really bad...
Yes, I think we should get rid of it now in trunk. The pixmap cache is good
enough that Mac plaftform don't need this hack anymore. Moreover I
Abdelrazak Younes wrote:
Any objection that I remove the wide hack now?
I surely won't miss it.
Jürgen
On Sun, Aug 26, 2007 at 12:32:21PM +0200, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Any objection that I remove the wide hack now?
I surely won't miss it.
Famous last words ;-)
- Martin
Martin Vermeer wrote:
I surely won't miss it.
Famous last words ;-)
Indeed ;-)
Jürgen
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
read.
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for
Abdelrazak Younes wrote:
>> Nope... unfortunately. I am sure this is a metrics problem actually.
>
> Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the wide_inset_ value
is used
Alfredo Braunstein wrote:
> Abdelrazak Younes wrote:
>
>
>>> Nope... unfortunately. I am sure this is a metrics problem actually.
>>
>> Hum... "I am _not_ sure..."
>
> Actually that's what I've read for some reason ;-) I would nevertheless
> like to commit the patch, as valgrind tells that
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the
Abdelrazak Younes wrote:
>> Actually that's what I've read for some reason ;-) I would nevertheless
>> like to commit the patch, as valgrind tells that otherwise the
>> wide_inset_ value is used before initialized.
>
> Sure, go ahead.
I'll do on tuesday for branch if Juergen agrees. The
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> > Abdelrazak Younes wrote:
> >>> Nope... unfortunately. I am sure this is a metrics problem actually.
> >> Hum... "I am _not_ sure..."
> > Actually that's what I've read for some reason ;-) I would
Martin Vermeer wrote:
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This wide stuff is really bad...
Yes, I think we should get rid of it now in trunk. The pixmap cache is good
enough that Mac plaftform don't need this hack anymore. Moreover I
Abdelrazak Younes wrote:
> Any objection that I remove the wide hack now?
I surely won't miss it.
Jürgen
On Sun, Aug 26, 2007 at 12:32:21PM +0200, Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
> > Any objection that I remove the wide hack now?
>
> I surely won't miss it.
Famous last words ;-)
- Martin
Martin Vermeer wrote:
> > I surely won't miss it.
>
> Famous last words ;-)
Indeed ;-)
Jürgen
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
read. :-/
I am able to
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Alfredo Braunstein wrote:
>>
>>
> Ouch! Confirmed on WinXP too! Please fill-it in.
>>> What's the exact recipe? I cannot reproduce here (linux)
>>
>> Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
>> read. :-/
54 matches
Mail list logo
