World: r4wp

On Windows, it works the same as yours

Endo, people without cookies can't see anything on Trello

red>> [w:]
== 
*** Runtime Error 1: access violation
*** at: 084980F3h

Oh, that's probably the missing load/all

Yes, but:

red>> do [w:]
== 
*** Runtime Error 32: segmentation fault
*** at: 096F70F2h

I get here:

red>> do [z:]
==
*** Script error: action 6 not defined for type: 0

Can't you just return unset! from an undefined path, like for an 
undefined word?

I will give it a try.

Nenad - Happy Birthday to you, and so to your brain-child - Red :-)

Thanks Peter! :-)

If it's Doc's birthday, we should give him a present and donate to 
his child's future. 

Happy Birthday Doc.

HBD, doc. :-)

Thanks guys! :-)

Made a little donation - happy birthday!

I will donate in few days, once my salary arrives :-)

Remember, I'm matching donations, birthday or not, until the end 
of the month, so Doc gets double presents.

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