On Mon, 13 Oct 2003, Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 04:44:26PM +0200, Jean-Marc Lasgouttes wrote:
> > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> >
> > Lars> Baby steps, never allow a patch that introduces regressions,
> > Lars> stay stable at all times. Bett
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 05:33:50PM +0200, Andre Poenitz wrote:
>
>> I don't see all the black shadows you see. There is no need to abandon
>> anything.
>
| Who are the people who are going to fix all the nasty problems ?
>
| I can see one candidate now: Lar
On Mon, Oct 13, 2003 at 05:33:50PM +0200, Andre Poenitz wrote:
> I don't see all the black shadows you see. There is no need to abandon
> anything.
Who are the people who are going to fix all the nasty problems ?
I can see one candidate now: Lars. Is it really likely he'll be able to
sort out th
On Mon, Oct 13, 2003 at 04:29:06PM +0100, John Levon wrote:
> On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bj?nnes wrote:
>
> > Because the core still stinks, are close to impossible to understand
> > etc. Millions of hidden dependencies, not to mention all the new and
> > old bugs, that
On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bj?nnes wrote:
> Because the core still stinks, are close to impossible to understand
> etc. Millions of hidden dependencies, not to mention all the new and
> old bugs, that makes non-guru visits to this part of the code _very_
> hard.
Besides
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Baby steps, never allow a patch that introduces regressions,
| Lars> stay stable at all times. Better to move slow than to fall.
>
| When was the last time you saw a baby wal
On Mon, Oct 13, 2003 at 04:44:26PM +0200, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Baby steps, never allow a patch that introduces regressions,
> Lars> stay stable at all times. Better to move slow than to fall.
>
> When was the last
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Baby steps, never allow a patch that introduces regressions,
Lars> stay stable at all times. Better to move slow than to fall.
When was the last time you saw a baby walking?
JMarc
PS: OK, OK...
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Baby steps, never allow a patch that introduces regressions, stay
>> stable at all times. Better to move slow than to fall.
>
| Ok...
>
| So what's next now?
Well since we did a giant step instead of a baby step, we must fix the
problems resulting from
On Mon, Oct 13, 2003 at 11:24:05AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Yes. The LyX core is the domain of a few people right now when it comes
> | to contributions. Even worse, most are 'retired' (at least
> | de-facto...) and the situation is not im
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Yes. The LyX core is the domain of a few people right now when it comes
| to contributions. Even worse, most are 'retired' (at least
| de-facto...) and the situation is not improving. The only solution I see
| is to lower the bar as much as possible, and
ult
> >> | of '*var_' is when the variable is not set, I think it is always true
> >> | that 'T()' is a perfectly valid result here. See how we use cached
> >> | variables.
> >>
> >> CachedVar cache_;
> >>
&
On Mon, Oct 13, 2003 at 10:56:41AM +0200, Lars Gullik Bjønnes wrote:
> | But it is not. You are fending against problems that are obvious to
> | solve once they occur. A broken xy cache would mean the cursor is
> | completely off after clicking in a formula.
>
> Not everything is about mathed and
Andre Poenitz wrote:
>> Slightly miffed.
> Sorry.
Apology accepted. And I'll try and get a thicker skin ;-)
--
Angus
s true
>> | that 'T()' is a perfectly valid result here. See how we use cached
>> | variables.
>>
>> CachedVar cache_;
>>
>> Really non-usable, but has a value that should not be used. Perfect
>> use of optional. I am very sure.
>
| Wha
On Mon, Oct 13, 2003 at 09:38:02AM +, Angus Leeming wrote:
> > So please use whatever is needed there and leave the xo_, yo_ cache
> > as-is.
>
> I'll certainly remember not to use examples of mathed code to
> illustrate my point in the future.
I thought your reason for your code was some ma
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 10:24:10AM +0200, Lars Gullik Bjønnes wrote:
>> | We'd never, ever need to know whether this is set or not. You can put in
>> | arbitrary values in this variable at any point of time _except_ at the
>> | end of 'metrics'.
>>
>> T
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
>>> There are several examples of places where we do not want these
>>> variables to be copied. Indeed, there are examples where the
>>> default copy constructor fai
On Mon, Oct 13, 2003 at 09:27:03AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
> >> I even think boost::optional should be used for the Cached vars
> >> type, then you can easily know if the cached var is set or not.
>
On Mon, Oct 13, 2003 at 10:24:10AM +0200, Lars Gullik Bjønnes wrote:
> | We'd never, ever need to know whether this is set or not. You can put in
> | arbitrary values in this variable at any point of time _except_ at the
> | end of 'metrics'.
>
> The you need to be pretty sure that is it never use
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>>> Cached variables are a royal pain in the butt.
>>>
>>> Writing explicit copy constructors simply so that we don't copy
>>> mutable int xo_;
>>> is a real
Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
>> There are several examples of places where we do not want these
>> variables to be copied. Indeed, there are examples where the
>> default copy constructor fails to compile. For example, any class
>> holding a
On Mon, Oct 13, 2003 at 09:22:55AM +, Angus Leeming wrote:
> There are several examples of places where we do not want these
> variables to be copied. Indeed, there are examples where the default
> copy constructor fails to compile. For example, any class holding a
> boost::signal. These der
On Mon, Oct 13, 2003 at 10:18:26AM +0200, Lars Gullik Bjønnes wrote:
> | I'm not so sure. Apart from the fact that I don't know what the result
> | of '*var_' is when the variable is not set, I think it is always true
> | that 'T()' is a perfectly v
Andre Poenitz wrote:
> On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
>> I even think boost::optional should be used for the Cached vars
>> type, then you can easily know if the cached var is set or not.
>
> We'd never, ever need to know whether this is set or not. You can
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
>> I even think boost::optional should be used for the Cached vars type,
>> then you can easily know if the cached var is set or not.
>
| We'd never, ever need to know whether this is s
Andre Poenitz wrote:
>> Cached variables are a royal pain in the butt.
>>
>> Writing explicit copy constructors simply so that we don't copy
>> mutable int xo_;
>> is a real bore. I'm sure that the author of formulabase.[Ch] would
>> agree
var_; }
>> private:
>> boost::optional var_;
>> };
>
| I'm not so sure. Apart from the fact that I don't know what the result
| of '*var_' is when the variable is not set, I think it is always true
| that 'T()' is a perfectly valid re
On Mon, Oct 13, 2003 at 12:10:06AM +0200, Lars Gullik Bjønnes wrote:
> I even think boost::optional should be used for the Cached vars type,
> then you can easily know if the cached var is set or not.
We'd never, ever need to know whether this is set or not. You can put in
arbitrary values in this
On Sun, Oct 12, 2003 at 08:56:59PM +, Angus Leeming wrote:
> Cached variables are a royal pain in the butt.
>
> Writing explicit copy constructors simply so that we don't copy
> mutable int xo_;
> is a real bore. I'm sure that the author of formulabase.[C
the fact that I don't know what the result
of '*var_' is when the variable is not set, I think it is always true
that 'T()' is a perfectly valid result here. See how we use cached
variables.
--
Angus
Angus Leeming <[EMAIL PROTECTED]> writes:
| Cached variables are a royal pain in the butt.
>
| Writing explicit copy constructors simply so that we don't copy
| mutable int xo_;
| is a real bore. I'm sure that the author of formulabase.[Ch] would
| agree with me ther
Cached variables are a royal pain in the butt.
Writing explicit copy constructors simply so that we don't copy
mutable int xo_;
is a real bore. I'm sure that the author of formulabase.[Ch] would
agree with me there ;-)
Why don't we have a CachedVar class template. Some
33 matches
Mail list logo
