World: r4wp

Nick: got it, thank you very much!

Happy Birthday Doc!

I thought it was last month, Doc, but if it was today, happy birthday!

Thanks!

With the latest version, I still get

red>> do [z:]
== 
*** Runtime Error 1: access violation
*** at: 0851C0F3h

That's in console-pro. Oddly, in your console, it indeed gives the 
action error

Would it be hard to have the undefined warnings print the name of 
the undefined word/path?

Actually, that's part of error! handling, I can't do it right now 
it would delay the release too much...

I can have a quick look at it though, if it's just a few lines of 
code, I'll add it.

Doc, what is your opinion about what FOR and FOREACH should do for 
the obviously never advancing case? Error triggered or nothing done?

Is there a CC ticket about that?

At first look, I'd say nothing done as it can be useful to disable 
a code block in a loop passing 0 as looping number (or empty block 
in case of FOREACH).

Are we talking about never advancing or never executing?

Never executing. Never advancing means executing endlessly.

That method of disabling a loop block would be in addition to passing 
none as the data (for foreach)?

In that case, it seems obvious to me to do nothing. That's a regular 
construct in programs

red>> do *
Error: feature not implemented yet!
bash-4.0#

I tried avoiding the error propagatin, but it's too complex, so it 
will stay as is until error! is implemeted.

The changes I made in the interpreter for not exiting the console 
on errors have a very bad side-effect: some errors are passing silently 
through the unit tests and are not reported! :-/

Hm, well, I suppose it's good practice for implementing error! ;-)

I can't on error! until next week, my planning is full.

<work>

This one has an assortment of effects:

red>> do [z:]
== 
*** Runtime Error 23: illegal operand
*** at: 09DB50F2h

I simply get an "*** Script error: action..." message here.

Again, in console-pro

red>> load x 
*** Error: word has no value!

*** Runtime Error 1: access violation
*** at: 08079DD7h

red>> load x/y
*** Error: word in path has no value!

*** Runtime Error 1: access violation
*** at: 08079DD7h

Kaj, I'm really don't see this approach working. The HALTs in the 
runtime code *do* have a purpose, they protect the user from running 
its code after an error that sets the stack in an undetermined state. 
It's a (temporary) protection barrier until we have proper error 
handling. Removing them will just make me chase false errors.  I 
can't patch the whole runtime code to make it look like it has error 
recovering while it has not...

I told you that the cleaner option would be: write a input data validation 
routine to, at least, catch those undefined words.

I think I'll put the HALT back to avoid making the runtime code unstable 
(and avoid those nasty silent errors in unit tests).

I have no idea what you're talking about. What approach? What HALTS? 
What input validation?

I'm just reporting crashes that I observe

Is there any point to continuing testing at the moment? I'm not sure 
now what reports you want

My point is: an undefined word error is a user error, and exiting 
the interpreter with an error message is currently the best thing 
to do. I've removed the exit points after such errors because you've 
asked me to for making your demos run without exiting. But I shouldn't 
have done that.

I don't really understand. The interpreter never halted on undefined 
words, only undefined paths

Same thing.

Paths error out because there's an undefined word in them.

I know, but you didn't remove a HALT from word evaluation because 
I asked

Well, actually, I did. :)

But I will them all back, user errors should make the app exit, currently 
it's the best way.

That's why I told you before to validate the user input in order 
to avoid errors as much as possible.

(Until we can catch them properly with TRY)

I don't remember you saying that, but I'm looking into it

But it seems we misunderstood each other. :)

Obviously

See my post on Sun 23:49

Oh, I see, you were going to implement VALUE? for validation. I just 
didn't think you meant checking the entire input; I thought you were 
talking about the result

I meant the whole user input, mainly for catching undefined words/paths 
and hanlding the error out of DO.