1. Bug in 2.5 for linux?
I've written a program and tested it on several versions of eu on both windows
and linux and it runs fine, except linux 2.5.
The program is pretty big, so I haven't been able to isolate the bug yet, but it
seems that some sequence elements are not retaining their data.
I've traced the program and the data is being set correctly (afterall the
program runs fine in other environments) but when it comes to reading the data
it's always 0.
I suspect it's something to do with $ and side-effects maybe.
Has this problem been addressed already?
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
2. Re: Bug in 2.5 for linux?
- Posted by Robert Craig <rds at RapidEuphoria.com>
Oct 12, 2006
-
Last edited Oct 13, 2006
Chris Bensler wrote:
> I've written a program and tested it on several versions of eu on both windows
> and linux and it runs fine, except linux 2.5.
>
> The program is pretty big, so I haven't been able to isolate the bug yet, but
> it seems that some sequence elements are not retaining their data.
>
> I've traced the program and the data is being set correctly (afterall the
> program
> runs fine in other environments) but when it comes to reading the data it's
> always 0.
>
> I suspect it's something to do with $ and side-effects maybe.
>
> Has this problem been addressed already?
It hasn't been reported for 2.5 official,
(See: http://www.rapideuphoria.com/future.htm )
but there was a bug in 2.5 alpha, fixed in 2.5 beta:
"A complex expression on the left hand side of an assignment,
involving nested use of $, could crash. Thanks to Andy Serpa."
I hope you are using 2.5 official.
In any case, wait a few days for 3.0 and let me know
if it still happens. Of course, if you are doing any bad peeks
or pokes into memory or calls to C routines,
then any kind of corruption could happen.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Bug in 2.5 for linux?
- Posted by Chris Bensler <bensler at nt.net>
Oct 12, 2006
-
Last edited Oct 13, 2006
Robert Craig wrote:
>
> It hasn't been reported for 2.5 official,
> (See: <a
> href="http://www.rapideuphoria.com/future.htm">http://www.rapideuphoria.com/future.htm</a>
> )
> but there was a bug in 2.5 alpha, fixed in 2.5 beta:
> "A complex expression on the left hand side of an assignment,
> involving nested use of $, could crash. Thanks to Andy Serpa."
>
> I hope you are using 2.5 official.
> In any case, wait a few days for 3.0 and let me know
> if it still happens. Of course, if you are doing any bad peeks
> or pokes into memory or calls to C routines,
> then any kind of corruption could happen.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
I dl'd the 2.5/linux from the rds site a few days ago.
My code was developed with Eu 2.3 so it's not using any 2.5 specific code that
might contribute to the bug. I only mentioned $ because I'm aware that there was
some issues when dealing with side effects.
My prog does do RAM access, but I've tested with safe.e
I'll have to isolate the problem to see exactly what's going on.
I'll wait for v3.0 in the meantime.
Was just hoping someone else already found the bug for me.
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
4. Re: Bug in 2.5 for linux?
- Posted by Chris Bensler <bensler at nt.net>
Oct 12, 2006
-
Last edited Oct 13, 2006
Chris Bensler wrote:
>
> Robert Craig wrote:
> >
> > It hasn't been reported for 2.5 official,
> > (See: <a
> > href="http://www.rapideuphoria.com/future.htm">http://www.rapideuphoria.com/future.htm</a>
> )</font></i>
> > but there was a bug in 2.5 alpha, fixed in 2.5 beta:
> > "A complex expression on the left hand side of an assignment,
> > involving nested use of $, could crash. Thanks to Andy Serpa."
> >
> > I hope you are using 2.5 official.
> > In any case, wait a few days for 3.0 and let me know
> > if it still happens. Of course, if you are doing any bad peeks
> > or pokes into memory or calls to C routines,
> > then any kind of corruption could happen.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
> I dl'd the 2.5/linux from the rds site a few days ago.
>
> My code was developed with Eu 2.3 so it's not using any 2.5 specific code that
> might contribute to the bug. I only mentioned $ because I'm aware that there
> was some issues when dealing with side effects.
>
> My prog does do RAM access, but I've tested with safe.e
> I'll have to isolate the problem to see exactly what's going on.
> I'll wait for v3.0 in the meantime.
>
> Was just hoping someone else already found the bug for me.
>
> Chris Bensler
> ~ The difference between ordinary and extraordinary is that little extra ~
I've isolated the bug and this is the culprit statement:
SymTab[id][SYM_HASH] = symLink(lph,id)
lph = Symtab[id][SYM_NEXT] -- test line, should be 397, but is always 0
The value at SYM_NEXT is assigned in symLink(), and I've verified it is being
set. In the test line above, it keeps returning 0. Presumably the preset/original
value.
Changing the code so that the function result is not directly assigned corrects
the problem:
lph = symLink(lph,id)
SymTab[id][SYM_HASH] = lph
-- SymTab[id][SYM_HASH] = symLink(lph,id)
lph = Symtab[id][SYM_NEXT] -- test line, reports 397 correctly now
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
5. Re: Bug in 2.5 for linux?
Chris Bensler wrote:
> I've isolated the bug and this is the culprit statement:
> }}}
<eucode>
> SymTab[id][SYM_HASH] = symLink(lph,id)
> lph = Symtab[id][SYM_NEXT] -- test line, should be 397, but is always 0
> </eucode>
{{{
>
> The value at SYM_NEXT is assigned in symLink(), and I've verified it is being
> set. In the test line above, it keeps returning 0. Presumably the
> preset/original
> value.
>
> Changing the code so that the function result is not directly assigned
> corrects
> the problem:
> }}}
<eucode>
> lph = symLink(lph,id)
> SymTab[id][SYM_HASH] = lph
> -- SymTab[id][SYM_HASH] = symLink(lph,id)
> lph = Symtab[id][SYM_NEXT] -- test line, reports 397 correctly now
> </eucode>
{{{
I think you have run into a quirky situation where
the semantics changed slightly between 2.5 and earlier releases.
Does this section of the 2.5 manual apply to you?
"Subscripting and function side-effects: In an assignment statement,
with left-hand-side subscripts:
lhs_var[lhs_expr1][lhs_expr2]... = rhs_expr
the expressions are evaluated, and any subscripting is performed,
from left to right. It is possible to have function calls in the
right-hand-side expression, or in any of the left-hand-side expressions.
If a function call has the side-effect of modifying the lhs_var,
it is not defined whether those changes will appear in the
final value of the lhs_var, once the assignment has been completed.
To be sure about what is going to happen, perform the function call
in a separate statement, i.e. do not try to modify the lhs_var in two
different ways in the same statement. Where there are no left-hand-side
subscripts, you can always assume that the final value of the lhs_var
will be the value of rhs_expr, regardless of any side-effects that
may have changed lhs_var."
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: Bug in 2.5 for linux?
Robert Craig wrote:
>
> I think you have run into a quirky situation where
> the semantics changed slightly between 2.5 and earlier releases.
> Does this section of the 2.5 manual apply to you?
>
> "Subscripting and function side-effects: In an assignment statement,
> with left-hand-side subscripts:
>
> lhs_var[lhs_expr1][lhs_expr2]... = rhs_expr
>
> the expressions are evaluated, and any subscripting is performed,
> from left to right. It is possible to have function calls in the
> right-hand-side expression, or in any of the left-hand-side expressions.
> If a function call has the side-effect of modifying the lhs_var,
> it is not defined whether those changes will appear in the
> final value of the lhs_var, once the assignment has been completed.
> To be sure about what is going to happen, perform the function call
> in a separate statement, i.e. do not try to modify the lhs_var in two
> different ways in the same statement. Where there are no left-hand-side
> subscripts, you can always assume that the final value of the lhs_var
> will be the value of rhs_expr, regardless of any side-effects that
> may have changed lhs_var."
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Yes, SymTab[id][SYM_NEXT] is being assigned in symLink()
Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
