>> probe arr/:ind ** Script Error: Invalid path value: a ** Where: halt-view ** Near: probe arr/:ind >> probe arr/(ind) 11 == 11
<word>/<get-word!>but it can do it with
1) Both languages can get value based on a number:
2) Both languages can get value based on a word:
3) Both languages can get value using
paren! based on a number/word:
arr/(0 + 1),
4) Only the Red can get value based on both a number and a word using
w is a word or a number.
So based on 3
paren! can acts as numeric/word selector (value from a
Based on 4 the Rebol has the "problem" with getting value from a
In my opinion
get-word! is in the centre of the problem.
get-word!evaluates correctly, but Rebol fails to interpret
lit-word!as a valid selector. Red in this case correctly coerces all
any-word!values. So, no, problem is not with
get-word!, problem is with
lit-word!(or any other possible
any-word!value) to which it evaluates. Same holds for
paren!expressions - they are not selectors, but the result of their evaluation is.
** Script Error: Invalid path value: a ** Near: probe arr/:ind
Yes, it seems that
get-word! evaluates correctly but it seems that we cannot use
word! as path's value. "invalid path value: a" - I assume that
a is a
word! here... but it can be
lit-word! as well. In my opinion that error message is not as clean as you said.
Putting that aside, this answer fully explain differences. Thank you for this.
replace/all read/binary file crlf lf
How do you deal with time-consuming computation in the gui?
make-random-image: has [img ] [ img: make image! 200x200 forall img [img/1: random 255.255.255] wait 2 img ] view [i: image [i/image: make-random-image]]
Let's suppose that
make-random-image just takes at least 2 seconds to compute. In those 2 seconds I'm left with unresponsive window. Is there anything I can do to make user experience better such in cases?
ps. I know about memoization and I'm not sure if I can translate this part of code to Red/System.
call "red my-heavy-script.red"that will write result to some file
on-timecheck periodically if second process finished (result file exists, or something like that)