Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Bug of TRY was bug of function error?

 [1/18] from: rotenca::telvia::it at: 22-Jul-2002 19:10


Gregg, my problem is that given this code: b: tail a: "a" remove a b ; -> error this is OK! ;then error? try [b] ; -> false type? try [b] ;== string! the bug, it is a bug, should be in Try not in error?, like i thought at the start. Also this is strange: type? try [do b] ;== unset! --- Ciao Romano

 [2/18] from: anton:lexicon at: 23-Jul-2002 4:32


Well, not really strange, given that you have found:
> type? try [b] ;== string! > Also this is strange: > > type? try [do b] ;== unset!
You see also: type? do "" ;== unset!
> Romano
Anton.

 [3/18] from: mh983:attbi at: 22-Jul-2002 18:23


It's interesting that in your example, b ; gives "** Script Error: Out of range or past end" but x: "123" fourth x gives same error but also includes a "near: fourth x" message, and: error? try [fourth x] ; gives true, as you expected. Seems like the first example is just printing the string but not actually causing an error.

 [4/18] from: greggirwin:mindspring at: 22-Jul-2002 12:20


Hi Romano, Now that I've had a little more coffee, and Anton go me on track...
>> do b >> type? do b
== unset!
>> type? try [do b]
== unset!
>> type? try [b]
== string!
>> type? b
== string! I have no idea why it returns the datatype of the value in this case. Probably worth a feedback, if only to get clarification (hopefully). It says that TRY tries to DO the block, but if you just DO the block yourself, you get the error. Something else has to be going on inside TRY. Given: b 1 ; == 1 is the error only triggered if the data is accessed in some way (e.g. to print in the console, assign, etc.)? If the data is not used, no error is triggered. --Gregg

 [5/18] from: ammon:rcslv at: 22-Jul-2002 6:39


Hi, Is it possible that if you type b at the console it attempts to re-evaluate its value, but in a try block it takes the value that it already is? Let's see:
>> a: "a"
== "a"
>> b: copy tail a
== ""
>> remove a
== ""
>> b
== "" Aha! I think we are onto something here? Ammon A short time ago, Anton Rolls, sent an email stating:

 [6/18] from: ammon:rcslv at: 22-Jul-2002 13:37


Hi, This one only gets stranger:
>> b
== ** Script Error: Out of range or past end ** Where: connect-to-link ** Near: try [b] anybody notice the == at the top of that? A normal error doesn't do that! Take for instance my quick typo here:
>> error? try b
** Script Error: try expected block argument of type: block ** Where: connect-to-link ** Near: error? try b Huh? Ammon === Original Message === Hi Romano, Now that I've had a little more coffee, and Anton go me on track...
>> do b >> type? do b
== unset!
>> type? try [do b]
== unset!
>> type? try [b]
== string!
>> type? b
== string! I have no idea why it returns the datatype of the value in this case. Probably worth a feedback, if only to get clarification (hopefully). It says that TRY tries to DO the block, but if you just DO the block yourself, you get the error. Something else has to be going on inside TRY. Given: b 1 ; == 1 is the error only triggered if the data is accessed in some way (e.g. to print in the console, assign, etc.)? If the data is not used, no error is triggered. --Gregg

 [7/18] from: rotenca:telvia:it at: 22-Jul-2002 21:47


Hi Anton, Ladislav
> > Also this is strange: > > > > type? try [do b] ;== unset! > > You see also: > > type? do "" ;== unset!
What i want to say that also 'do accept the string like it was a "good" string: do b ; another example: type? do does [b] ;== string! Ladislav in this case, is not used like a result? --- Ciao Romano

 [8/18] from: lmecir:mbox:vol:cz at: 22-Jul-2002 22:37


Hi Romano, the issue is simple, but I didn't see it at the first time. See the following: print b ; ** Script Error: Out of range or past end If we look carefully, we see, that in the original case PRINT is used implicitly too. Actually, the error occurs *after* Rebol computes the result during implicit PRINT. Ciao -L ----- Original Message ----- From: "Romano Paolo Tenca" Hi Anton, Ladislav
> > Also this is strange: > > > > type? try [do b] ;== unset! > > You see also: > > type? do "" ;== unset!
What i want to say that also 'do accept the string like it was a "good" string: do b ; another example: type? do does [b] ;== string! Ladislav in this case, is not used like a result? --- Ciao Romano

 [9/18] from: rotenca:telvia:it at: 23-Jul-2002 14:10


Hi Ladislav,
> If we look carefully, we see, that in the original case PRINT is used > implicitly too. Actually, the error occurs *after* Rebol computes the result > during implicit PRINT.
the conclusion is that this string fails with some functions and works with others Right? Is not clear to me why this happens. --- Ciao Romano

 [10/18] from: anton:lexicon at: 24-Jul-2002 0:01


That seems to make sense. Also I noticed:
>> print b
** Script Error: Out of range or past end ** Near: print b
>> b
== ** Script Error: Out of range or past end ** Near: print b It "remembers" and reports the same "Near" code. Anton.

 [11/18] from: lmecir:mbox:vol:cz at: 23-Jul-2002 15:49


Hi Romano, <<Romano Paolo Tenca">> ...snip... the conclusion is that this string fails with some functions and works with others Right? Is not clear to me why this happens. --- Ciao Romano <</Romano>> <<L>> Yes, exactly! I don't know why the script fails with MOLD or PRINT, I would prefer it to work smoothly. Some time ago I discussed a related thing with feedback: b: next "a" clear head b index? b ; ** Script Error: Out of range or past end I would prefer to get the information instead of an error. To get the number I had to write my own function MINDEX in http://www.rebolforces.com/~ladislav/identity.html My function works hard to compute something that should be easily obtainable from the native IMO. Another example of the behaviour is: same? b b ; ** Script Error: Out of range or past end instead of the result I prefer, which is TRUE in this case. RT prefer to catch the (supposed) error, but they aren't able to catch it when it occurs, i.e. when the code (clear head b) is evaluated. My philosophy is different: because the value can be obtained legally (it is almost impossible to detect it when it occurs), I would rather treat is as a legal value, e.g. as an empty series. A curiosity: append b "a" empty? b ; == true is undetectable for the interpreter. Ciao -L

 [12/18] from: nitsch-lists:netcologne at: 23-Jul-2002 18:56


Am Dienstag, 23. Juli 2002 14:10 schrieb Romano Paolo Tenca:
> Hi Ladislav, > > If we look carefully, we see, that in the original case PRINT is used
<<quoted lines omitted: 4>>
> Right? > Is not clear to me why this happens.
I think if you access the content, it gives an error. if you only pass it around, its ok. The error is triggered when console tries to display it, not before. 'error? avoids the displaying.
> --- > Ciao > Romano
-Volker

 [13/18] from: rotenca:telvia:it at: 23-Jul-2002 18:43


> My philosophy is different: because the value can be obtained legally (it is > almost impossible to detect it when it occurs), I would rather treat is as a > legal value, e.g. as an empty series. A curiosity: >
The solution, for me, is to transform every "Out of range" reference to a series, when evaluated, in a tail reference.
> append b "a"
tail b works, so works append which uses tail To catch a little more errors, tail and head should trigger an error. Try this: clear head b: next "a" ;== "" join "a" b ; ->>>>>> CRASH "expand series overflow" --- Ciao Romano

 [14/18] from: nitsch-lists:netcologne at: 23-Jul-2002 19:03


Am Dienstag, 23. Juli 2002 15:49 schrieb Ladislav Mecir:
<snip>
A curiosity:
> append b "a" > empty? b ; == true > > is undetectable for the interpreter. >
Ah! so 'tail works with "broken" indices. hmm, is this a bug?
> Ciao > -L
-Volker

 [15/18] from: anton:lexicon at: 24-Jul-2002 3:33


Type 1 in the console and press enter:
>> 1
== 1 That's where it comes from. Anton.

 [16/18] from: lmecir:mbox:vol:cz at: 24-Jul-2002 0:35


Hi Romano, <<Romano>> ...snip... The solution, for me, is to transform every "Out of range" reference to a series, when evaluated, in a tail reference.
> append b "a"
tail b works, so works append which uses tail To catch a little more errors, tail and head should trigger an error. Try this: clear head b: next "a" ;== "" join "a" b ; ->>>>>> CRASH "expand series overflow" --- Ciao Romano <</Romano>> I am not sure I understand your point. Your latest sample is equivalent to: clear head b: next "a" ;== "" insert tail copy "a" b ; ->>>>>> CRASH "expand series overflow" Interesting is, that it isn't an overflow, although the interpreter thinks it is. I can understand this result, but it signals, that the programmer didn't consider this special case. Ciao -L

 [17/18] from: lmecir:mbox:vol:cz at: 24-Jul-2002 0:41


Hi Volker, ----- Original Message ----- From: "Volker Nitsch" ...snip... Ah! so 'tail works with "broken" indices. hmm, is this a bug? <</Volker>> I prefer to get the tail instead of an error message. Tschuss -L

 [18/18] from: rotenca:telvia:it at: 24-Jul-2002 2:16


Hi Ladislav,
>> clear head b: next "a" ;== "" >> join "a" b ; ->>>>>> CRASH "expand series overflow" > I am not sure I understand your point.
I wanted only to signal the crash and the fact that: - some functions works - some functions trig an error - some functions crash
> Your latest sample is equivalent to: > clear head b: next "a" ;== "" > insert tail copy "a" b ; ->>>>>> CRASH "expand series overflow" > > Interesting is, that it isn't an overflow, although the interpreter thinks > it is. I can understand this result, but it signals, that the programmer > didn't consider this special case.
The interpret never reach the end of serie, because it is already beyond it? --- Ciao Romano

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted