Many thanks for your input Ryszard.
Brgds,
Viktor
On 2008.06.04., at 14:27, Ryszard Glab wrote:
On 2 Jun 2008 at 20:13, Szakáts Viktor wrote:
Probably Ryszard should answer for this.
Now upper letters are used to disable some features.
In the future we may need more combinations so maybe it'
On 2 Jun 2008 at 20:13, Szakáts Viktor wrote:
> > Probably Ryszard should answer for this.
> > Now upper letters are used to disable some features.
> > In the future we may need more combinations so maybe it's
> > good idea to keep it case sensitive.
>
> Well, I really hope so we won't need that m
On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> >Clipper does not make any optimizations for macro compiled
> >code so it gives correct results executing RT functions or
> >evaluating PCODE. We are making the optimizations but for
> >macro compiler Harbour calculates correct results so th
Plus, rather than saying 'lowercase/uppercase significant'
it would be more intuitive to just use lowercase
for 'J' and 'M', and make casing not to matter, like
for the rest of Harbour switches. I can make this, but
I wonder if there was any special reason doing it like
this?
Probably Ryszard sh
On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> One thing I forgot: To do this we'd need a switch
> which would toggle the parenthesised expression
> optimization only.
OK, I can add it.
> BTW, for me it's unclear by looking at the 'harbour /k?'
> help, which options are enabled by defa
Hi Przemek,
It's not possible to make a perfect decision here,
unless investing extreme energy (like those flags)
to keep bug compatibility, not to mention what an
ugly inconsistency this is. My personal opinion in this
case is to fix this Clipper bug in Harbour, and make it
available using a
On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> It's not possible to make a perfect decision here,
> unless investing extreme energy (like those flags)
> to keep bug compatibility, not to mention what an
> ugly inconsistency this is. My personal opinion in this
> case is to fix this Clipp
Hi Przemek,
In general there is a problem with compile time optimizations for
CHR( * 256 )
and $ operator in expressions like:
"" $
caused by bugs in Clipper compiler. It gives different results then
runtime functions/operations. Keeping strict Clipper compatibility
is hard in complex expr
Hi Przemek,
We currently also use the '()' non-optimization for
HB_SYMBOL_UNUSED().
It is and was optimized. For all expressions like:
(exp) (exp)
our expression optimizer strips parenthesis.
It's also not Clipper compatible and maybe we should disable
this optimization when -kc is used.
On Mon, 02 Jun 2008, Szakáts Viktor wrote:
Hi Viktor,
> We currently also use the '()' non-optimization for
> HB_SYMBOL_UNUSED().
It is and was optimized. For all expressions like:
(exp) (exp)
our expression optimizer strips parenthesis.
It's also not Clipper compatible and maybe we should d
Hi Przemek,
We currently also use the '()' non-optimization for
HB_SYMBOL_UNUSED().
If we can resolve the above, and make it possible to disable
the feature using -k switch, I think we are fine with it.
If this involves any complexities though, I'd leave it for after RC1.
Brgds,
Viktor
On 200
2008-06-02 16:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbexprb.c
! do not optimize HB_BIAND(), HB_BITOR() and HB_BITXOR() when only
one parameter is passed to keep RT error compatibility
* use hb_compExprListStrip() to optimize function calls also wh
12 matches
Mail list logo
