I think that's an implementation detail. EXIT and RETURN are implemented in the exact same way as THROW or causing an error.
You can imagine EXIT as causing a special error. The function catches that special error. If no function catches it, it then gets to you as
>> exit ** Throw Error: Return or exit not in function ** Near: exit
Endo
Thanks for the reply.
Maxim
Marco, actually, its very easy to build extensions in C for R3.
In fact, in many cases, its easier to build an extension in C for R3 than trying to wrap one in R2. simply because many of the dll types do not match R2 at all. also many of the systems now have 64 bit types which is very awkward to manage in R2.
if you use the starter project that Carl had done, showing how to manipulate Rebol series you should be able to make stubs for any dll.
SWhite
Some of us are slow, but we do get there eventually (wherever "there" is). I was re-reading the short essay by Carl on the REBOL web site about "REBOL overview for Scientists, Engineers, Professors, Programmers." Had a couple "aha!" moments. When I got to the end, I saw the comment, "Coming up next...storage, context, interpretation." It looks like that follow-up essay is one of those things that never got done. It would be nice to see it. If anyone has access to Carl, you might mention it to see if he ever wants to visit that topic again. I suppose that as time passes he becomes more detached from REBOL.
Tomc
Ha ! it is kinda fiun to be a newbie again. I'm porting a r2 script to r3 and find all my hyphenated (script) argument flags are missing that is I get the word after the hyphenated flag but not the flag itself in system/script/args
i.e. with > script.reb -i this.file -o that.file
I end up with args being [ this.file that.file] with no flags
is this expected behavior these days or something I have mangled myself?
this is on 64b linux built a month or two ago
Tomc
think I got it
> script.reb --args "-i this.file -o that.file"
Marco
Is there a shorter, more generic way of doing this:
if ob has more set-words then ob it does not work :(
Marco
if ob has more set-words then items in bl it does not work :(
Henrik
Marco, does the /PAD refinement to SET give you anything?
Gregg
What doesn't work Marco?
Endo
I use the following function:
build-object: func [ "Builds an object from a block" names [block!] "Field names" /values val [block!] "Initial values" /local o name value ] [ o: copy [] names: compose names o: either values [ parse names [some [set name [word! | set-word!] (append o to-set-word name) | skip]] set/pad reflect o: context append o none 'words val o ] [ if any [ parse names [some [set name [word! | set-word!] (append o reduce [to-set-word name none])]] parse names [(clear o) some [set name [word! | set-word!] set value any-type! (append o reduce [to-set-word name :value])]] ] [context o] ] o ]
It supports following uses: build-object [a b c] [1 2 3] build-object/values [a b c] [1 2 3] build-object/values [a b c] [1 2] build-object/values [a b c] [1 2 3 4] build-object [a: 1 b: 2] build-object [a: 2 b: 2 c] build-object/values [a: 1 b: 2 c d] [3 4 5] x: 3 probe build-object [a: 1 b (x)]
It's for R2 but can be update to run on R3.
The first example should be: build-object [a b c] ; == context [a: b: c: none]
Endo
I found a difference between (R2.7.6 + r2-forward) and R2.7.8, SELECT doesn't accept object! type in 2.7.6. Is it not possible to make it compatible with 2.7.8s SELECT function in r2-forward? As R3s SELECT accepts object! type too.
Maxim
you shoudn't use 2.7.6 there are quite a few things improved and a few crashes too.
"improved since"
Endo
Is there any change log?
Maxim
I am sure there is one somewhere on the Rebol.com site.
Marco
I do not want to create a new object, nor pad "empty" values with none(s). I want to assign some strings (or something else) found in a block to some specific set-words of an existing object.
PatrickP61
What am I doing wrong with this code in r3:
start: func [block-name] [ print rejoin ["start " block-name] do block-name print rejoin ["stop " block-name] ] count-to-10: [ for x 1 10 1 [prin x prin " "] print " " ] print "ready to start" start count-to-10
I get this:
ready to start start for x 1 10 1 prin x prin print 1 2 3 4 5 6 7 8 9 10 stop for x 1 10 1 prin x prin print
-- how do I pass to START the string of the block to eventually DO? I want the function to expect a string -- even if that string has already been defined as a block. i.e. I don't want the block to be evaluated just yet.
If I use START 'COUNT-TO-10 instead, and then use DO REDUCE BLOCK-NAME, It still doesn't work right.