World: r3wp

(unset! or none! values having no such "payload data", for example.)

And now of course the problem is, that we refer to different entities 
as "value", depending on context. Amongst those entities often referred 
to as "value" are:
- the "REBOL value", as defined above
- the "payload data" of a "REBOL value"
- the "value slot" implementation detail

Is there a way how to mold error into nice looking string?

I mean... I can do:
>> if error? err: try [1 / 0][probe err false]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== false


but what if I would like to form the error message to look like if 
the error is really evaluated:

>> do err
** Math error: attempt to divide by zero
** Where: / try
** Near: / 0

Can we have the error message formater available or is it hidden 
for some security or other reason?

I format them myself

how... do you have a list of all available error ids?

is there any idea how to place an break point int code for debugging 
reason, and release it (continue)?

int = into

Oldes - you can try to grab them out of here, but not sure how easy 
that will be:
   probe system/catalog/errors

thanks... that's what I was looking for.

Pavel... I usually use ASK with any value/message as a break point 
while debugging. Or just PROBE is I don't need to stop the evaluation.

Sunanda: not so easy, require some binding.

So far I have this:
my-attempt: funct[code /local val][
	either error? set/any 'val try code [
		val: to-object val 
		do bind [
			print rejoin [

    "!! " val/type  " error: " reduce system/catalog/errors/(val/type)/(val/id) 
    #"^/"
				"!! Where: " val/where #"^/"
				;"!! Near: " val/near  #"^/"
			]
		] val
		false
	][
		:val
	]
] 

my-attempt [debase #ff]
my-attempt [1 / 0]

but not perfect... the Near and Where info is modified :-/

How to convert issue! to binary! in R3? I was using debase in R2, 
but it's not working anymore (I guess because of unicode).

small observation:

>> any-word? #a
== true

that is possibly why it no longer works.

hm.. so debase/base next to-string  #ff 16

2 Oldes Great idea thanks

Oldes, wasn't there a function in R3 which allows you to get the 
string from an error...directly?

I was using this function in R2:
parse-error:  func[
    error [object!]
    /local type id arg1 arg2 arg3 where err-desc
][
    type: error/type
    id: error/id
    where: mold get/any in error 'where
    either any [
        unset? get/any in error 'arg1
        unset? get/any in error 'arg2
        unset? get/any in error 'arg3
    ][
        arg1: arg2: arg3: "(missing value)"
    ][
        arg1: error/arg1
        arg2: error/arg2
        arg3: error/arg3
    ]
    err-desc: system/error/:type
    rejoin [
        "** " err-desc/type ": "
        reduce either block? err-desc/:id [
            bind system/error/:type/:id 'arg1
        ][
            err-desc/:id
        ]
        newline
        "** Where: " where
        newline
        "** Near: " mold error/near
    ]
]

>> f: does [1 / 0]
>> if error? err: try [f][print parse-error disarm err]
** Math Error: Attempt to divide by zero
** Where: f
** Near: [1 / 0]

In R3 the WHERE and NEAR report is different

Plus, there is a long-term CC ticket about the off-by-one Near for 
operator-generated errors.

Yes.. I just wanted to write, that the NEAR is the main problem.

I just have this:

unless rebol3? [result: disarm :result]

unless silent [
	print "ERROR"
	prin "ID: "  probe result/id
	prin "In: "  probe result/arg1
	prin "Near: "  probe result/near
	if rebol3? [prin "Where: "  probe result/where]
]

With REBOL3? predefined

Seems I'm only missing the textual description

Oldes, a perhaps simpler version for R2 is: http://www.rebol.it/power-mezz/mezz/form-error.html

I thought FORM was supposed to be able to do the same thing on R3, 
not implemented yet?

You are right... simple FORM err works:

>> error? err: try [1 / 0]
== true

>> form err
== {** Math error: attempt to divide by zero
** Where: / try
** Near: / 0
}

Oh, cool

Anyone happens to know whether UNIQUE is guaranteed to be stable 
for blocks? I.e. if we're guaranteed that the result block has the 
elements in the same order they first appeared in the original block?

in my tests (which I did this week) it was stable in R2.

This is R3.

SORT isn't stable in R3, but UNIQUE uses hash tables, not SORT.

>> unique reduce [use [c] [a: 'c] use [c] [b: 'c]]
== [c]
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] a
== true
>> same? first unique reduce [use [c] [a: 'c] use [c] [b: 'c]] b
== false

This seems to be pretty consistent.

It currently seems to be stable, yes.

My question is if anyone knows whether we are actually guaranteed 
that it is.

(In which case it should be mentioned in the docs.)

Given how it's implemented, I don't see how it could be other than 
first-come-first-included.

What about if it's implemented differently?

In other words:

Is it a bug if UNIQUE is not stable.

?

That would end up with bug reports like the ones for SORT not being 
stable. I would consider it a bug.

If it would be a bug otherwise, it is safe to document this behaviour.

The SORT not stable bug http://issue.cc/r3/1152is currently considered 
a "should fix before release" priority, btw.

Yes, SORT sucks, sort-a...

it would be nice to have a few sort algorythms out of the box.

That, too

The only way I can currently use R3 is by replacing SORT