• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

Kaj
11-Mar-2013
[6265x2]
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#
DocKimbel
12-Mar-2013
[6267x2]
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! :-/
Kaj
12-Mar-2013
[6269]
Hm, well, I suppose it's good practice for implementing error! ;-)
DocKimbel
12-Mar-2013
[6270x2]
I can't on error! until next week, my planning is full.
<work>
Kaj
12-Mar-2013
[6272x2]
This one has an assortment of effects:
red>> do [z:]
== 
*** Runtime Error 23: illegal operand
*** at: 09DB50F2h
DocKimbel
12-Mar-2013
[6274]
I simply get an "*** Script error: action..." message here.
Kaj
12-Mar-2013
[6275x3]
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
DocKimbel
12-Mar-2013
[6278x3]
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).
Kaj
12-Mar-2013
[6281x3]
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
DocKimbel
12-Mar-2013
[6284]
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.
Kaj
12-Mar-2013
[6285]
I don't really understand. The interpreter never halted on undefined 
words, only undefined paths
DocKimbel
12-Mar-2013
[6286x2]
Same thing.
Paths error out because there's an undefined word in them.
Kaj
12-Mar-2013
[6288]
I know, but you didn't remove a HALT from word evaluation because 
I asked
DocKimbel
12-Mar-2013
[6289x4]
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)
Kaj
12-Mar-2013
[6293]
I don't remember you saying that, but I'm looking into it
DocKimbel
12-Mar-2013
[6294]
But it seems we misunderstood each other. :)
Kaj
12-Mar-2013
[6295]
Obviously
DocKimbel
12-Mar-2013
[6296]
See my post on Sun 23:49
Kaj
12-Mar-2013
[6297]
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
DocKimbel
12-Mar-2013
[6298x2]
I meant the whole user input, mainly for catching undefined words/paths 
and hanlding the error out of DO.
Maybe I will do it myself in the console script...
Kaj
12-Mar-2013
[6300x8]
Thinking about it, that would reject any user code that uses words 
as symbols, wouldn't it?
I have a loop written that does the evaluation, even without VALUE? 
but it doesn't seem like a good idea to me
red>> x: load "view button" forall x [print unset? get x/1]      
     
false
true
Undefined single words were never a problem in the interpreter before. 
That's why I could write Redpages with a header:
Red []
They were simply ignored. After I requested the warning message, 
the Red word produces such a warning, so for now I write:
'Red []
By the way, are get-paths supposed to work?
DocKimbel
12-Mar-2013
[6308x3]
Nope, not yet.
DO doesn't support a Red header yet.
You should strip it from a LOADed block before passing it to DO.
Kaj
12-Mar-2013
[6311]
I know, but it worked
DocKimbel
12-Mar-2013
[6312x3]
I need to fix some interpreter issues revealed by Peter's port of 
~2500 tests to the interpreter. There's about a dozen failing tests 
to fix.
Once that done, I will have a look again at those error reporting 
issues.
I agree that it is not yet possible to deeply validate user input. 
I'll see if I can find a cheap workaround for the release.