Andre Poenitz wrote:
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that
Andre Poenitz wrote:
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that and got rid of
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >
> >Good in theory but it looks as if this is the kind of infomration that
> >would be useful for a 'non-drawing real painter' (as opposed to the
> >original nullpainter)
>
> I have implemented that and
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
- bool const inside = (y + rit-descent() = 0
- y - rit-ascent() ww);
RowPainter rp(pi, text, pit, *rit, x, y);
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -,
[EMAIL PROTECTED] wrote:
-bool const inside = (y + rit-descent() = 0
-y - rit-ascent() ww);
RowPainter rp(pi, text, pit, *rit, x, y);
//
-devel/trunk/src/frontends/Makefile.am
lyx-devel/trunk/src/frontends/Painter.h
lyx-devel/trunk/src/frontends/qt4/QLPainter.C
lyx-devel/trunk/src/insets/insettabular.C
lyx-devel/trunk/src/mathed/InsetMathNest.C
lyx-devel/trunk/src/rowpainter.C
Modified: lyx-devel/trunk/development
Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that and got rid of the NullPainter altogether:
Shit... Some of
altogether:
Shit... Some of my LyXText changes got in there. I will clean that up
immediately, should compilable again soon.
Here is the real rawpainter.C diff:
Index: D:/devel/lyx/trunk/src/rowpainter.C
===
--- D:/devel/lyx/trunk/src
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration
that would be useful for a 'non-drawing real painter' (as opposed
to the original nullpainter)
Abdelrazak I have implemented that and
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
- bool const inside = (y + rit->descent() >= 0
- && y - rit->ascent() < ww);
RowPainter rp(pi, text, pit, *rit, x, y);
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -,
[EMAIL PROTECTED] wrote:
-bool const inside = (y + rit->descent() >= 0
- && y - rit->ascent() < ww);
RowPainter rp(pi, text, pit, *rit, x, y);
-devel/trunk/src/frontends/Makefile.am
lyx-devel/trunk/src/frontends/Painter.h
lyx-devel/trunk/src/frontends/qt4/QLPainter.C
lyx-devel/trunk/src/insets/insettabular.C
lyx-devel/trunk/src/mathed/InsetMathNest.C
lyx-devel/trunk/src/rowpainter.C
Modified: lyx-devel/trunk/development
Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that and got rid of the NullPainter altogether:
Shit... Some of
altogether:
Shit... Some of my LyXText changes got in there. I will clean that up
immediately, should compilable again soon.
Here is the real rawpainter.C diff:
Index: D:/devel/lyx/trunk/src/rowpainter.C
===
--- D:/devel/lyx/trunk/src
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Andre Poenitz wrote:
>> Good in theory but it looks as if this is the kind of infomration
>> that would be useful for a 'non-drawing real painter' (as opposed
>> to the original nullpainter)
Abdelrazak> I have
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
Author: schmitt
Date: Sun Oct 29 17:39:51 2006
New Revision: 15605
URL: http://www.lyx.org/trac/changeset/15605
Log:
* rowpainter.C: remove unused variable 'inside',
a leftover from the axed nullpainter
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
> Author: schmitt
> Date: Sun Oct 29 17:39:51 2006
> New Revision: 15605
>
> URL: http://www.lyx.org/trac/changeset/15605
> Log:
> * rowpainter.C: remove unused variable 'inside',
> a leftover f
Asger == Asger Ottar Alstrup [EMAIL PROTECTED] writes:
Asger Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const bool inside'
Asger, is it safe to remove the variable?
Asger Yes, and you can nuke the nullpainter as well while you are at
Asger
Jean-Marc Lasgouttes wrote:
Asger The nullpainter is no good, because it can not calculate the
Asger metrics of text, so it's basically useless. It was the cause of
Asger wrong metrics in the coordcache, which caused all sorts of
Asger problems.
what did you replace it with?
We use the real
Quoting Jean-Marc Lasgouttes [EMAIL PROTECTED]:
Asger == Asger Ottar Alstrup [EMAIL PROTECTED] writes:
Asger Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const bool inside'
Asger, is it safe to remove the variable?
Asger Yes, and you can
Andre == Andre Pönitz [EMAIL PROTECTED] writes:
Andre With the real one.
Could you point me to one or two commits that implement this?
Andre The problem was that the nullpainter did not compute positions
Andre correctly. If it did so, it would need to use almost the same
Andre logic as the
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is full of crap, and that causes
Asger Ottar Alstrup wrote:
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is
Quoting Jean-Marc Lasgouttes [EMAIL PROTECTED]:
Andre == Andre Pönitz [EMAIL PROTECTED] writes:
Andre With the real one.
Could you point me to one or two commits that implement this?
15455 maybe.
Andre The problem was that the nullpainter did not compute positions
Andre correctly. If it
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Asger Ottar Alstrup wrote:
| Jean-Marc Lasgouttes wrote:
| I see. Isn't there some performance price?
| Yes, but it is not noticeable in our testing. After all, we only
| paint two extra paragraphs.
|
| I guess this is not something I can
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Asger Ottar Alstrup wrote:
| Jean-Marc Lasgouttes wrote:
| I see. Isn't there some performance price?
| Yes, but it is not noticeable in our testing. After all, we only
| paint two extra paragraphs.
|
| I guess this
Quoting Abdelrazak Younes [EMAIL PROTECTED]:
This was exactly what I was investigation some months ago. But then
why not going to QPicture directly? This will need some changes to
the core but I really think that's the way to go.
I would be very surprised if recording the painter operations
Andre == Andre Pönitz [EMAIL PROTECTED] writes:
I guess this is not something I can consider for 1.4.
Andre If we don't get mispositioning/coordcache crashes in 1.4, then
Andre not.
I do have crashes with pageup in 1.4.
JMarc
Jean-Marc Lasgouttes wrote:
Andre == Andre Pönitz [EMAIL PROTECTED] writes:
I guess this is not something I can consider for 1.4.
Andre If we don't get mispositioning/coordcache crashes in 1.4, then
Andre not.
I do have crashes with pageup in 1.4.
Then the nullpainter fix is your
>>>>> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
Asger> Michael Gerz wrote:
>>>> /home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
>>>> variable `const bool inside'
>> Asger, is it safe to remove the
Jean-Marc Lasgouttes wrote:
Asger> The nullpainter is no good, because it can not calculate the
Asger> metrics of text, so it's basically useless. It was the cause of
Asger> wrong metrics in the coordcache, which caused all sorts of
Asger> problems.
what did you replace it with?
We use the
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>:
"Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
Asger> Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const bool inside'
Asger, is it safe to remove t
> "Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
Andre> With the real one.
Could you point me to one or two commits that implement this?
Andre> The problem was that the nullpainter did not compute positions
Andre> correctly. If it did so, it would need to use almost the same
Andre>
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is full of crap, and that causes
Asger Ottar Alstrup wrote:
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>:
"Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
Andre> With the real one.
Could you point me to one or two commits that implement this?
15455 maybe.
Andre> The problem was that the nullpainter did not compute positions
Andre>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Asger Ottar Alstrup wrote:
| > Jean-Marc Lasgouttes wrote:
| >> I see. Isn't there some performance price?
| > Yes, but it is not noticeable in our testing. After all, we only
| > paint two extra paragraphs.
| >
| >> I guess this is not something I
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Asger Ottar Alstrup wrote:
| > Jean-Marc Lasgouttes wrote:
| >> I see. Isn't there some performance price?
| > Yes, but it is not noticeable in our testing. After all, we only
| > paint two extra paragraphs.
| >
| >> I
Quoting Abdelrazak Younes <[EMAIL PROTECTED]>:
This was exactly what I was investigation some months ago. But then
why not going to QPicture directly? This will need some changes to
the core but I really think that's the way to go.
I would be very surprised if recording the painter operations
> "Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
>> I guess this is not something I can consider for 1.4.
Andre> If we don't get mispositioning/coordcache crashes in 1.4, then
Andre> not.
I do have crashes with pageup in 1.4.
JMarc
Jean-Marc Lasgouttes wrote:
"Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
I guess this is not something I can consider for 1.4.
Andre> If we don't get mispositioning/coordcache crashes in 1.4, then
Andre> not.
I do have crashes with pageup in 1.4.
Then the nullpainter fix is your
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably left behind when working
Martin Vermeer wrote:
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably left behind
Asger Ottar Alstrup wrote:
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calculate the metrics
of text, so it's basically useless. It was the cause of wrong metrics
in the coordcache, which caused all sorts of problems.
Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const
bool inside'
Asger, is it safe to remove the variable?
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calculate
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
> This one look suspicious:
>
> /home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
> `const
> bool inside'
>
> Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably lef
Martin Vermeer wrote:
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably left behind
Asger Ottar Alstrup wrote:
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calculate the metrics
of text, so it's basically useless. It was the cause of wrong metrics
in the coordcache, which caused all sorts of problems.
Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const
bool inside'
>
Asger, is it safe to remove the variable?
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calcul
On Thu, Jul 13, 2006 at 11:14:06AM +0200, Lars Gullik Bjønnes wrote:
| Maybe you should do so.
If 10G is all you can spare on lyx
Not on LyX. That's to be shared with a full SuSE 10.0 installation.
when the cheapest disks out there is 200G then I am not so sure.
I have not closely followed
On Thu, Jul 13, 2006 at 11:14:06AM +0200, Lars Gullik Bjønnes wrote:
> | Maybe you should do so.
>
> If 10G is all you can spare on lyx
Not on LyX. That's to be shared with a full SuSE 10.0 installation.
> when the cheapest disks out there is 200G then I am not so sure.
I have not closely
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
| Andre Poenitz [EMAIL PROTECTED] writes:
|
| | On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| | | Nope there is a big difference. You are basically asking
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| > | > | Nope there is a big difference. You are
On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| | Nope there is a big difference. You are basically asking me to have 3
| | trees.
|
| Actually I am
On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
> | > | Nope there is a big difference. You are basically asking me to have 3
> | > | trees.
> | >
> | >
On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| Nope there is a big difference. You are basically asking me to have 3
| trees.
Actually I am asking you to have as many trees as necessary.
(branches really...)
Have you ever considered that there are people running
Andre Poenitz [EMAIL PROTECTED] writes:
| On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| | Nope there is a big difference. You are basically asking me to have 3
| | trees.
|
| Actually I am asking you to have as many trees as necessary.
| (branches really...)
|
|
On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
> | Nope there is a big difference. You are basically asking me to have 3
> | trees.
>
> Actually I am asking you to have as many trees as necessary.
> (branches really...)
Have you ever considered that there are people running
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| > | Nope there is a big difference. You are basically asking me to have 3
| > | trees.
| >
| > Actually I am asking you to have as many trees as necessary.
| > (branches really...)
Andre Poenitz wrote:
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
| | I cannot at the same time do
| | very small patches so that everyone can understand and wait tomorrow
| | for committing to trunk and then merging trunk with my branch.
|
| Sure you can.
And to
Andre Poenitz wrote:
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
| | I cannot at the same time do
| | very small patches so that everyone can understand and wait tomorrow
| | for committing to trunk and then merging trunk with my branch.
|
| Sure you can.
And to
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do not
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
|
| | Georg Baum wrote:
| | Abdelrazak Younes wrote:
| |
| | I will commit to my branch to let Lars the time to review this patch. I
| | hope he will not be upset to
Abdelrazak Younes [EMAIL PROTECTED] writes:
| then point us either at the patch or the revision number.
| Then patches can (as long as they are not dependent on eacy other) be
| cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's too complicated for me, so no
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| then point us either at the patch or the revision number.
| Then patches can (as long as they are not dependent on eacy other) be
| cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's too
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | then point us either at the patch or the revision number.
| | Then patches can (as long as they are not dependent on eacy other) be
| | cherry picked and merged easily
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | then point us either at the patch or the revision number.
| | Then patches can (as long as they are not dependent on eacy other) be
| |
Abdelrazak Younes [EMAIL PROTECTED] writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously not true. (Other than from an
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
|
| | From what I've read, the merging algorithms of git are much more
| | powerful than those of svn. But that is not really my point. Working
| | with SVN means either that one guy controls
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | From what I've read, the merging algorithms of git are much more
| | powerful than those of svn. But that is not really my point. Working
| | with SVN means either that
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
| | I cannot at the same time do
| | very small patches so that everyone can understand and wait tomorrow
| | for committing to trunk and then merging trunk with my branch.
|
| Sure you can.
And to expand a bit:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Georg Baum wrote:
| | > Abdelrazak Younes wrote:
| | >
| | >> I will commit to my branch to let Lars the time to review this patch. I
| | >> hope he will not be
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > then point us either at the patch or the revision number.
| > Then patches can (as long as they are not dependent on eacy other) be
| > cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's too complicated for me, so no
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > then point us either at the patch or the revision number.
| > Then patches can (as long as they are not dependent on eacy other) be
| > cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > then point us either at the patch or the revision number.
| > | > Then patches can (as long as they are not dependent on eacy other) be
| > | > cherry picked and
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > then point us either at the patch or the revision number.
| > | > Then patches can (as long as they are not dependent on eacy other) be
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously not true. (Other than from an
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | From what I've read, the merging algorithms of git are much more
| | powerful than those of svn. But that is not really my point. Working
| | with SVN means either that one guy controls
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | From what I've read, the merging algorithms of git are much more
| > | powerful than those of svn. But that is not really my point. Working
| > | with SVN means
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
> | | I cannot at the same time do
> | | very small patches so that everyone can understand and wait tomorrow
> | | for committing to trunk and then merging trunk with my branch.
> |
> | Sure you can.
>
> And to expand a bit:
>
Abdelrazak Younes wrote:
Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always when I don't have
time to track
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always
Abdelrazak Younes wrote:
They are related to the API changing I am doing so I cannot reproduce
them either for trunk or for 1.4.2. FWIW, I am not even sure that they
are still needed for my branch. But I think they should be applied anyway.
OK. Just in case you have the feeling a crash is
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Georg Baum wrote:
| Abdelrazak Younes wrote:
|
| I will commit to my branch to let Lars the time to review this patch. I
| hope he will not be upset to have multiple fix in the same branch.
| I fear he will, because this has nothing to do with
Abdelrazak Younes [EMAIL PROTECTED] writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do not wait at all before
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
|
| | Georg Baum wrote:
| | Abdelrazak Younes wrote:
| |
| | I will commit to my branch to let Lars the time to review this patch. I
| | hope he will not be upset to have multiple fix in the same
Abdelrazak Younes wrote:
> Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always when I don't have
time to track
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always
Abdelrazak Younes wrote:
> They are related to the API changing I am doing so I cannot reproduce
> them either for trunk or for 1.4.2. FWIW, I am not even sure that they
> are still needed for my branch. But I think they should be applied anyway.
OK. Just in case you have the feeling a crash is
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Abdelrazak Younes wrote:
| >
| >> I will commit to my branch to let Lars the time to review this patch. I
| >> hope he will not be upset to have multiple fix in the same branch.
| > I fear he will, because this has nothing to
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do not wait at all before
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Georg Baum wrote:
| | > Abdelrazak Younes wrote:
| | >
| | >> I will commit to my branch to let Lars the time to review this patch. I
| | >> hope he will not be upset to have multiple fix in the
Hello,
I came across this bug while playing with the painting. As the emptyness
check is obviously correct I guess I will have no objection but I am
asking anyway because I am good boy.
Any objection?
Abdel.
Index: rowpainter.C
Abdelrazak Younes [EMAIL PROTECTED] writes:
I came across this bug while playing with the painting. As the emptyness
check is obviously correct I guess I will have no objection but I am
asking anyway because I am good boy.
Why do you move
theCoords.parPos()[text][pit] = Point(x, y);
1 - 100 of 142 matches
Mail list logo
