1. Still no better trace eval
Why is still not a such trace evaluation such as x[20]?
I think it is not very difficult for Rob to implement...
Even that the sequence can be fully viewed but the index is not shown
so I must count myself which is the 20th element.
I think support for x[number] is already enough, the tracer does not
need to evaluate x[y[z+1]] etc
btw I haven't get my reg. version of 2.4, please send the URL to me.
Thanks!
2. Re: Still no better trace eval
aku saya wrote:
> Why is still not a such trace evaluation such as x[20]?
> I think it is not very difficult for Rob to implement...
It's not too hard, but in 2.4 you can display/scroll
entire large sequences in pretty print mode.
If I did implement x[20], you'd probably ask
why x[i] doesn't work. Then I'd do x[i], and you'd
ask why x[i+1] doesn't work. It would be
hard to evaluate general expressions in the middle
of debugging, without a major change to the interpreter.
Maybe some day...
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Still no better trace eval
On Tue, 25 Feb 2003 19:20:33 -0500, Robert Craig <rds at RapidEuphoria.com>
wrote:
>
>
> aku saya wrote:
>> Why is still not a such trace evaluation such as x[20]?
>> I think it is not very difficult for Rob to implement...
>
> It's not too hard, but in 2.4 you can display/scroll
> entire large sequences in pretty print mode.
>
> If I did implement x[20], you'd probably ask
> why x[i] doesn't work. Then I'd do x[i], and you'd
> ask why x[i+1] doesn't work. It would be
> hard to evaluate general expressions in the middle
> of debugging, without a major change to the interpreter.
> Maybe some day...
Then maybe as a first step you do the form "<sequence>[<literal>]" because
we can get the other forms interactively.
? i
--> i = 3
? x[3]
--> x[3] = "Hello"
? x[4] --> x[4] = "World"
--
cheers,
Derek Parnell
4. Re: Still no better trace eval
- Posted by gertie at visionsix.com
Feb 26, 2003
On 25 Feb 2003, at 19:20, Robert Craig wrote:
>
>
> aku saya wrote:
> > Why is still not a such trace evaluation such as x[20]?
> > I think it is not very difficult for Rob to implement...
>
> It's not too hard, but in 2.4 you can display/scroll
> entire large sequences in pretty print mode.
>
> If I did implement x[20], you'd probably ask
> why x[i] doesn't work. Then I'd do x[i], and you'd
> ask why x[i+1] doesn't work. It would be
> hard to evaluate general expressions in the middle
> of debugging, without a major change to the interpreter.
Like string execution. Or threads and having a way to know where the vars
are stored and their names and contents so a new thread can go take care
of evaluatng things.
> Maybe some day...
/me sighs wistfully.
Kat
5. Re: Still no better trace eval
On Tue, 25 Feb 2003 19:20:33 -0500, Robert Craig
<rds at RapidEuphoria.com> wrote:
>If I did implement x[20], you'd probably ask
>why x[i] doesn't work. Then I'd do x[i], and you'd
>ask why x[i+1] doesn't work.
I'd want to know why
? find(upper(line[i]),map[myFunc(j)])
doesn't work
)
I know it doesn't work this way (yet), but I'd like to see in say
if <expr1> op <expr2>
some way to select "op", or an inbuilt or user-defined function or
procedure name, and the debugger trap showing the actual parameter
values it is about to apply it to (each and every time "op" is
applied, until I cancel the trap).
Would that be feasible at all?
Pete
6. Re: Still no better trace eval
On Wed, 26 Feb 2003 05:25:19 +0000, Robert Craig
<rds at RapidEuphoria.com> wrote:
>There's no easy way to add the more automated
>feature you are suggesting.
Shame. Nevermind then.
>Don't you have enough
>debugging capability in Euphoria already?
Mostly.
Often though I find I need to quit the program and before the line:
if <expr1> op <expr2>
insert:
debug=3Dexpr1
debug2=3Dexpr2
and then re-run the program only to find there is no problem on that
line, it is somewhere else. It can be done, but there is always room
for improvement :)
Pete
7. Re: Still no better trace eval
aku saya wrote:
> Why is still not a such trace evaluation such as x[20]?
>I think it is not very difficult for Rob to implement...
aku:
If you set a temporary sequence variable to a slice of the sequence you
are interested in looking at just before your program crashs
then you can look at that sequence variable in the ex.err to
see what it contains. At least in 2.4 we can now get to the
values that are contained in the sequence.
Bernie