Andre Poenitz wrote:
> Tell you what. When I had my first monster best-thing-since-sliced-bread
> patch ready and everybody (as in "everybody-of-this-bunch-of-ignorant
> -people-that-think-their-ugly-mess-of-useless-and-completely-broken
> -'code'-makes-them-special") was either ignoring it or dec
Abdel wrote:
To summarize my point: you will have to spend time studying the old
code before any comment becomes useful.
Not sure how to take that, but I agree if you only comment/document the
_differences_ as e.g. commit messages, instead of documenting the new
(intended) design. Then my be
On Tue, 14 Aug 2007, Asger Ottar Alstrup wrote:
In the last 5 years of LyX, at most 50% of the code was understood by
more than one person. It's ridiculous to think that quality and
maintainability is only dependent on how many people understand the code
or how well it was reviewed.
It is ri
[EMAIL PROTECTED] wrote:
In my case, I can get distracted if I early on encounter discrepancies
or other unexplained issues. One reason is that without knowing the
overall structure/purpose/design in advance, how can I know what's
important and what is not? So I'd ask questions about it.
A
On Tue, 14 Aug 2007, Abdelrazak Younes wrote:
> > > > Remember that this discussion started with "if you have 10
> > > > minutes, please merge my branch".
> > And you still think code review is bullshit.
>
> Never said that, I am still waiting the review...
FYI: Regardless of your ex
On Wed, Aug 15, 2007 at 12:52:17AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >We (well, not actually me, but "The LyX Team") were about to release
> >something.
>
> Obviously you include yourself in this "LyX Team" and you don't include me.
This obviousness escapes me.
> >All this
Andre Poenitz wrote:
We (well, not actually me, but "The LyX Team") were about to release
something.
Obviously you include yourself in this "LyX Team" and you don't include me.
All this multiple buffer stuff was actually accepted only
with reservations, so I would have been somewhat surprised
On Tue, Aug 14, 2007 at 09:57:50PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
> >>Abdel tested his code, and is confident in it. He has proven his
> >>skills many times. He makes mistake, just like everyone else. This has
> >>nev
> Some think that the quality of LyX is increased best by any combination
> of code reviews, the fact that more than one person understand the code,
> that changes are only done in small, incremental steps that are
> well-documented and discussed before hand, and that everyone does works
> in the s
You are certainly right that fixing a bug is a better way to spend time
than arguing pointlessly. However, sometimes there is hope that a
clarification of team members different points of view will help make
the team work better.
In this case, it is clear that people have different point of vi
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
JMarc, I asked if someone was willing to help me before the trunk
diverge too much. I had zero proposal for help. So I had to do it
myself. For this I had to sync my branch with trunk and unfortunately
I forgot one or two
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Bo Peng wrote:
>
>> PS: Abdel, you should definitely go to the development meeting (next
>> time). Talking or even fighting in person will definitely help.
>
> Managing an internet project should not require physical appearance,
> even if it helps.
Bo Peng wrote:
PS: Abdel, you should definitely go to the development meeting (next
time). Talking or even fighting in person will definitely help.
Managing an internet project should not require physical appearance,
even if it helps.
Abdel.
"Bo Peng" <[EMAIL PROTECTED]> writes:
> PS: Abdel, you should definitely go to the development meeting (next
> time). Talking or even fighting in person will definitely help.
Yes.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> JMarc, I asked if someone was willing to help me before the trunk
> diverge too much. I had zero proposal for help. So I had to do it
> myself. For this I had to sync my branch with trunk and unfortunately
> I forgot one or two revision because this b
> > I guess what makes things difficult is more a problem of attitude.
>
> Maybe you (not only you) should question your attitude as well?
This discussion has taken way too much time and emotion. Could you
two, and everyone involved, stop right here? Helping me fix bug 4108
could be a much better
Andre Poenitz wrote:
On Tue, Aug 14, 2007 at 07:14:33PM +0100, John Levon wrote:
On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote:
It seems people have the priorities wrong. I think you need to rank
efforts based on how much it brings thing forward per time unit, because
LyX
On Tue, Aug 14, 2007 at 09:46:12PM +0200, Andre Poenitz wrote:
> > >>It seems people have the priorities wrong. I think you need to rank
> > >>efforts based on how much it brings thing forward per time unit, because
> > >>LyX is chronically resource starved.
> > >
> > >Which is why it's a huge p
Jean-Marc Lasgouttes wrote:
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
Abdel tested his code, and is confident in it. He has proven his
skills many times. He makes mistake, just like everyone else. This has
never stopped LyX from progressing, and will not now.
I do not think the problem i
On Tue, Aug 14, 2007 at 09:44:07PM +0200, Andre Poenitz wrote:
> > Which is why it's a huge problem when uncontrolled development is
> > allowed (see pretty much ever major LyX release, ever, but *especially*
> > the huge quagmire 1.4cvs got itself into).
>
> I come home and find myself in a para
Asger Ottar Alstrup wrote:
For what it is worth, I agree with Abdel.
And I 100% agree with your analysis ;-)
Abdel.
On Tue, Aug 14, 2007 at 08:22:50PM +0200, Asger Ottar Alstrup wrote:
> John Levon wrote:
> >On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote:
> >
> >>It seems people have the priorities wrong. I think you need to rank
> >>efforts based on how much it brings thing forward per tim
On Tue, Aug 14, 2007 at 07:14:33PM +0100, John Levon wrote:
> On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote:
> > It seems people have the priorities wrong. I think you need to rank
> > efforts based on how much it brings thing forward per time unit, because
> > LyX is chroni
Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
> Abdel tested his code, and is confident in it. He has proven his
> skills many times. He makes mistake, just like everyone else. This has
> never stopped LyX from progressing, and will not now.
I do not think the problem is in this area. Nobody que
John Levon wrote:
On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote:
It seems people have the priorities wrong. I think you need to rank
efforts based on how much it brings thing forward per time unit, because
LyX is chronically resource starved.
Which is why it's a huge pr
On Tue, Aug 14, 2007 at 08:10:10PM +0200, Asger Ottar Alstrup wrote:
> It seems people have the priorities wrong. I think you need to rank
> efforts based on how much it brings thing forward per time unit, because
> LyX is chronically resource starved.
Which is why it's a huge problem when unco
For what it is worth, I agree with Abdel.
Of course, a code review is always good, but testing is better, and
coding & bug-fixing is best.
It seems people have the priorities wrong. I think you need to rank
efforts based on how much it brings thing forward per time unit, because
LyX is chron
[EMAIL PROTECTED] wrote:
On Tue, 14 Aug 2007, Abdelrazak Younes wrote:
> > Remember that this discussion started with "if you have 10 minutes,
> > please merge my branch".
And you still think code review is bullshit.
Never said that, I am still waiting the review...
FYI: Regardless of
On Tue, 14 Aug 2007, Abdelrazak Younes wrote:
> > Remember that this discussion started with "if you have 10 minutes,
> > please merge my branch".
And you still think code review is bullshit.
Never said that, I am still waiting the review...
FYI: Regardless of your exact words[1], my i
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Remember that this discussion started with "if you have 10 minutes,
please merge my branch".
And that's exactly what it would have taken without all these
unfruitful discussions.
And Dov's patch would have been reverte
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Remember that this discussion started with "if you have 10 minutes,
>> please merge my branch".
>
> And that's exactly what it would have taken without all these
> unfruitful discussions.
And Dov's patch would have been reverted
And some weird ref
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I simply forgot one or two revision in my last synch with trunk. No
big deal. Don't worry, I won't revert anything.
Remember that this discussion started with "if you have 10 minutes,
please merge my branch".
And that
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I simply forgot one or two revision in my last synch with trunk. No
> big deal. Don't worry, I won't revert anything.
Remember that this discussion started with "if you have 10 minutes,
please merge my branch".
JMarc
Dov Feldstern wrote:
Abdelrazak Younes wrote:
But why don't you review the branch instead? The incremental commit
are much more easier to grasp. Why do you insist on reviewing the
final patch?
For one thing, because the final patch is what's going to go in in the end.
Do you think I am
Abdelrazak Younes wrote:
But why don't you review the branch instead? The incremental commit are
much more easier to grasp. Why do you insist on reviewing the final patch?
For one thing, because the final patch is what's going to go in in the end.
Secondly, almost as important as what goes
Abdelrazak Younes wrote:
Here is the patch. I think it is easy to understand.
So objection?
Err.., there are at least two changes that I have committed in the past
few weeks (totally unrelated to MVC) which this patch is undoing:
Index: Font.cpp
===
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > So pre-load == load the buffer but do not show it
> > and load == actually show the file?
> No, pre-load do the same as loadIfneeded() but do it in a centralised
> p
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
But why do we need loadIfNeeded at all, then?
It is needed for LFUN_LOAD_CHILD_DOCUMENT I think, and it is of course
needed in my new loadChildDocuments() method.
1. you always load the child documents
2. inset will l
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> But why do we need loadIfNeeded at all, then?
>
> It is needed for LFUN_LOAD_CHILD_DOCUMENT I think, and it is of course
> needed in my new loadChildDocuments() method.
1. you always load the child documents
2. inset will load them _if_needed_. Wh
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I think they should be visible maybe in a 'child' sub-menu?
Yes maybe.
JMarc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
So pre-load == load the buffer but do not show it
and load == actually show the file?
No, pre-load do the same as loadIfneeded() but do it in a centralised
place (in Buffer). loadIfNeeded will still be called by the inse
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
When my patch is in, I think we should (optionally) load all child
document automatically when opening the master document. This has the
benefits that the numbering and label will be immediately correct. So
will be the ou
[EMAIL PROTECTED] wrote:
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
When the loading happen matters to a user, it's not just a question of
total loading time.
The loading of child documents happens automatically (my patch
doesn't change this) when you do one of the following:
- latex e
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> So pre-load == load the buffer but do not show it
>> and load == actually show the file?
>
> No, pre-load do the same as loadIfneeded() but do it in a centralised
> place (in Buffer). loadIfNeeded will still be called by the inset. The
> difference
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
For those action no. All what my patch is doing is to pre-load *all*
the child documents. The relevant inset will still check if the child
document is already loaded or not, and load it if not. This doesn't
change.
So p
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> For those action no. All what my patch is doing is to pre-load *all*
> the child documents. The relevant inset will still check if the child
> document is already loaded or not, and load it if not. This doesn't
> change.
So pre-load == load the buff
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> When my patch is in, I think we should (optionally) load all child
> document automatically when opening the master document. This has the
> benefits that the numbering and label will be immediately correct. So
> will be the outline and navigate menu
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> For those action no. All what my patch is doing is to pre-load *all*
> the child documents. The relevant inset will still check if the child
> document is already loaded or not, and load it if not. This doesn't
> change.
The difference between pre-l
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
Thanks, nice summary. Pretty please tell me the above is documented in
the code?
No, the idea is that the loading now happens only when it is needed.
However, this means that numbering is off until the child documents
get loaded.
When my
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Yes. And this has always been like this. The difference is that we
load all the child documents at the same time instead of waiting that
the loading is asked by some insets.
and then later
A child document cannot (and
[EMAIL PROTECTED] wrote:
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
When the loading happen matters to a user, it's not just a question of
total loading time.
The loading of child documents happens automatically (my patch doesn't
change this) when you do one of the following:
- latex e
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Yes. And this has always been like this. The difference is that we
> load all the child documents at the same time instead of waiting that
> the loading is asked by some insets.
and then later
> The loading of child documents happens automatically
[EMAIL PROTECTED] writes:
> Thanks, nice summary. Pretty please tell me the above is documented in
> the code?
No, the idea is that the loading now happens only when it is needed.
However, this means that numbering is off until the child documents
get loaded.
>> No, the child loading will happen
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
When the loading happen matters to a user, it's not just a question of
total loading time.
The loading of child documents happens automatically (my patch doesn't change
this) when you do one of the following:
- latex export of the master docume
[EMAIL PROTECTED] wrote:
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
* Buffer: load all child documents in one go where it makes sense.
This has the advantage to call updateLabels() only once for the
master buffer and to get rid of the LyXView dependency. We can think
of maintaining
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
* Buffer: load all child documents in one go where it makes sense.
This has the advantage to call updateLabels() only once for the
master buffer and to get rid of the LyXView dependency. We can think
of maintaining a child document list in
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
Look at loadChildDocuments(). It's all in the commit logs.
Being somewhat lazy and ignorant, is there a link to the commit logs?
And you will learn they say
* Buffer: load all child documen
[EMAIL PROTECTED] wrote:
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
Look at loadChildDocuments(). It's all in the commit logs.
Being somewhat lazy and ignorant, is there a link to the commit logs?
Alternatively, what svn commands should be used to show them?
(I'm not on Windows, so Tortois
On Mon, 13 Aug 2007, Lars Gullik Bjønnes wrote:
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
|
| > On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
| >
| >> Look at loadChildDocuments(). It's all in the commit logs.
| >
| > Being somewhat lazy and ignorant, is there a
[EMAIL PROTECTED] writes:
> On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
>
>> Look at loadChildDocuments(). It's all in the commit logs.
>
> Being somewhat lazy and ignorant, is there a link to the commit logs?
And you will learn they say
* Buffer: load all child documents in one go where it ma
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] wrote:
|
| > On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
| >
| >> Look at loadChildDocuments(). It's all in the commit logs.
| >
| > Being somewhat lazy and ignorant, is there a link to the commit logs?
| > Alternatively, what
[EMAIL PROTECTED] wrote:
> On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
>
>> Look at loadChildDocuments(). It's all in the commit logs.
>
> Being somewhat lazy and ignorant, is there a link to the commit logs?
> Alternatively, what svn commands should be used to show them?
> (I'm not on Windows
On Mon, 13 Aug 2007, Abdelrazak Younes wrote:
Look at loadChildDocuments(). It's all in the commit logs.
Being somewhat lazy and ignorant, is there a link to the commit logs?
Alternatively, what svn commands should be used to show them?
(I'm not on Windows, so TortoiseSVN isn't an alternative)
On Mon, 13 Aug 2007, Jean-Marc Lasgouttes wrote:
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Jean-Marc Lasgouttes wrote:
I'll stop there, not because I think I proved a point, but because it
is late
So what? We don't pay you this costly trip to Finland for sleeping!
I did not say I wa
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> I'll stop there, not because I think I proved a point, but because it
>> is late
>
> So what? We don't pay you this costly trip to Finland for sleeping!
I did not say I was going to sleep. What do you know about th
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Here is the patch. I think it is easy to understand.
So objection?
Index: Bidi.cpp
===
--- Bidi.cpp(revision 19485)
+++ Bidi.cpp(working copy)
@@
Jean-Marc Lasgouttes wrote:
> I'll stop there, not because I think I proved a point, but because it
> is late
So what? We don't pay you this costly trip to Finland for sleeping!
A/
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Here is the patch. I think it is easy to understand.
>
> So objection?
>
>
> Index: Bidi.cpp
> ===
> --- Bidi.cpp (revision 19485)
> +++ Bidi.cpp (working copy)
> @@ -227,14 +227,14 @@
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Here is the patch. I think it is easy to understand.
So objection?
82 files changed, 1171 insertions(+), 1389 deletions(-)
50% (just guessing) of it seems the change buffer* -> buffer&,
Yes.
so it would
help already if that could be don
Abdelrazak Younes wrote:
> Here is the patch. I think it is easy to understand.
>
> So objection?
82 files changed, 1171 insertions(+), 1389 deletions(-)
50% (just guessing) of it seems the change buffer* -> buffer&, so it would
help already if that could be done separately...
A/
70 matches
Mail list logo
