AltME groups: search

__libc_csu_init calls _init which in turn calls two more functions: 
call_gmon_start and __do_global_ctors_aux

call_gmon_start is support for the gnu profiler

It seems float to integer is not allowed. Maybe some library call 
wrappers will be needed for that?

I made a donation to Red Project via PayPal, and 10% (50 Euro) of 
my payment was missing (excluding any fees). I made a phone call 
to PayPal to find out why they "swallowed" my money, They checked 
the records and told me indeed 10% was gone, and they were not sure 
why. They gonna investigate it and give the the answer. Well, How 
luck I am that I check with Doc, or the money is just gone. Shame 
on PayPal.

Can you call all the series navigation actions on R3 ports?

Steeve: first, second and so on are not actions in R3, they just 
call PICK. PICK is implemented for ports.

Red/System has no memory manager. You need to use the allocate/free 
wrappers provided by the runtime (see %Red/red-system/runtime/libc.reds). 


Once Red's memory manager will be stable, we could easily add some 
simple functions to make it available from Red/System too, so you'll 
be able to either manually manage memory or rely on Red's memory 
manager (including being able to call the GC).

Giuseppe, those are called properties. The getter/setter functions 
you often find in GUIs are basically the same thing, but properties 
hide that in regular assignment syntax. We don't need getter properties 
in REBOL-like languages because we don't use parentheses to call 
functions, but setter functions appearing to be assignment statements 
might appeal to some.


I've had a lot of experience with properties in languages like Delphi; 
most of the popular languages that currently have property support, 
either in syntax or as a convention, are derived from Delphi. It 
makes code a little easier to write, and a lot harder to debug. The 
main advantage to implementing them in Red or R3 would be to make 
it easier to interoperate with .NET or COM objects.


Automatic delegation is something else. With automatic delegation, 
you automatically forward a method call from one object to another, 
just by declaring it as such. That doesn't really work in REBOL-style 
direct-bound functions because we don't have an implicit self parameter 
(we have self, but it's not a parameter). Red would need to have 
a completely different function binding model for that kind of thing 
to work; which it would likely have anyways, due to it being compiled 
rather than interpreted.

For people wondering what I was working on these last couple of month, 
here's a screenshot of the customer app I'm finishing now: http://sidl.fr/tmp/generator01.png


It's a visual editor for trading strategies that emits MQL4 code 
for Metatrader-based solutions (FOREX trading). The tree is editable 
and redraws itself automatically (no need to drag all the nodes around 
manually). This app also relies on an intermediary DSL for serializing 
the strategy on disk or before compiling it to MQL4. Here's an extract 
from the corresponding dialect representation of the tree from screenshot: 

start on 1 
if 1 buy 5 take 10 stop 10 on-profit [
    buy 6 take 10 stop 10 on-profit [
        buy 10 take 10 stop 10 loop
    ]
] on-loss [
    sell 7 take 10 stop 10 on-profit [
        buy 4 take 10 stop 10 loop
    ]
] 


All is done in REBOL/View 2.7.6 (to avoid CALL bug in 2.7.8) and 
all the source code is 47KB (25KB for the custom styles and VID events 
callbacks).


I'm at 99% completion of that app, so I've resume the work on Red 
since a couple of days.

(CALL is required for this app to invoke the MQL4 to EX4 native compiler)

In case, you wonder why Red needs both UTF formats, well, it's simple, 
 Windows and UNIX worlds use different encodings, so we need to support 
both. Red will use by default UTF-8 for string values, but on Windows 
platform, it will convert the string to UTF-16 on first call to an 
OS API, and will keep that encoding later on (and avoid the overhead 
of converting it each time). 


We might want to make the UTF-16 related code platform-depend and 
not include it for other platforms, but I think that some text processing 
algorithms might benefit from a fixed-size encoding, so for now, 
I'm for including both encoding for all targets.


It will be also possible for users to check and change the encoding 
of a Red string! value at runtime.

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

What we want is ability to call %rsc.r from anywhere, compiling a 
program from working dir (or relative to working dir) and producing 
the binary in the working dir.

What we want is ability to call %rsc.r from anywhere, compiling a 
program from working dir (or relative to working dir) and producing 
the binary in the working dir.


Please can we also supply a second argument to rsc.r for the output 
dir/file name (the gcc -o option with improvements).


If the second argument is a dir then the executable is written to 
that dir instead of the current working dir.


If the second argument is a file then the executable is saved with 
that name.

MagnussunC: did you try to call the function::

>>f1 123

What I still think is, that we need strong parse. It is very cool 
technology. Yes, I dare to call it a technology. We need r3 level 
parse. Then we can create dialects, and show other guys, that dialecting 
is a cool concept. Pity we were not able to capitalise on it more, 
mainly due to closed nature of R2 possibilities to bind to other 
environments .... you imo :-)

The main drawback right now to support direct Red script execution 
is REBOL inability to execute native code from memory. The workaround 
would be to provide a DLL to pass the memory pointer and call the 
Red code, but as I aim at a single Red binary, this option wouldn't 
be very satisfying.

Syscalls: given how much a programming language has to call OS services, 
I don't see why we shouldn't try to avoid an unnecessary layer. But 
I'm pragmatic, if we get more troubles than benefits, we'll adopt 
a more classical approach.

Race condition on return value from mmap call. If address was too 
high, it was failing the safety check (testing for negative values) 
and wrongly triggering the error. ;-)

I've been very busy since yesterday on a new tool for Red: I've built 
a proper REBOL code profiler! (I wonder why I haven't done that since 
a long time...). I went through the profiler scripts on rebol.org 
and couldn't one suitable for my needs or that works with complex 
code, so I wrote one. It is able to deal with complex code, all datatypes, 
recursive calls and it's very simple to use.


Here's a demo profiling Red compiler (output is properly aligned 
when monospace font is used):

-= Red Compiler =-
Compiling red/tests/test.red ...

...compilation time:     40 ms

Compiling to native code...

...compilation time:     10189 ms
...linking time:         60 ms
...output file size:     37888 bytes
>> profiler/report/time


Function                       Count      Elapsed Time         % 
of ET

------------------------------------------------------------------------

compile                        1          0:00:10.249          100.0

comp-dialect                   205        0:00:09.659          94.24

fetch-expression               7505       0:00:09.628          93.94

comp-word                      5668       0:00:08.209          80.09

fetch-into                     427        0:00:07.519          73.36

comp-assignment                597        0:00:07.049          68.77

run                            3          0:00:06.492          63.34

comp-context                   21         0:00:06.398          62.42

comp-with                      1          0:00:05.565          54.29

comp-expression                3172       0:00:04.479          43.70

ns-find-with                   24277      0:00:03.962          38.65

finalize                       1          0:00:03.327          32.46

comp-natives                   1          0:00:03.274          31.94

comp-func-body                 180        0:00:03.271          31.91

comp-call                      2775       0:00:02.732          26.65

comp-func-args                 2861       0:00:01.862          18.16

find-aliased                   9650       0:00:01.86           18.14

resolve-type                   8032       0:00:01.799          17.55

get-type                       10758      0:00:01.546          15.08

ns-prefix                      21765      0:00:01.518          14.81

check-enum-symbol              7509       0:00:01.241          12.10

comp-block                     283        0:00:01.05           10.24

comp-variable-assign           417        0:00:01.034          10.08

Arnold - 'set example is one trick you can use in REBOL. Normally, 
when you enclose the function in the object/context, it is accessible 
via a path notation, e.g. context/make-profitable. When you use 'set 
aproach, it lives inside the context, but is exposed to the global 
context, so you can call it directly, or something like that :-)

Can we call it E: like on my Atari 8-bit? ;-)

I'm working on it, the fix is fine, but it seems it doesn't work 
with __libc_start_main call (and only that one).

It's like this call doesn't respect the ARM EABI...

cURL binding should now work correctly (except the ending segfault 
caused by bad libc init call...I'm working on it).

Removing `gtk-append-container` call makes it work.

Not exactly, I read rsc.r as if system-dialect is not set then start 
with the compiler.r script. (after that or else the rest of the script 
follows) but then is has some do other scripts and a modular part 
and the other scripts are modular too. It look all very sound bu 
somewhere <there must be/I expect> a first action or function call.

Oh, the particular quality of the R3 extension dispatch model that 
makes it well-suited to JIT compiler implementation is that a command 
function contains an indirect reference to the dispatch function, 
and an index integer. When the command is called, the runtime calls 
the dispatch function and passes the integer and a marshalled stack 
frame. For a JIT compiler dispatch function, the index of the command 
can be an index into an array of function pointers or something like 
that, and the dispatch function can just pass the stack frame to 
the appropriate function, then return the results. This means that 
the hard part of JIT compiling - getting the regular runtime to call 
the created functions - is something that you essentially get for 
free with the existing command mechanism.


You could also use the dispatch function to marshall arguments into 
another runtime with a different call model. You could, for instance, 
have a dispatch function that pushes the contents of a marshalled 
stack frame onto a Lua stack and calls Lua functions. Or you could 
do something similar for LLVM functions, or ActiveScripting languages, 
or V8, or ODBC queries, or even Red's JIT.


This all depends on having a good marshalling model in the first 
place that can handle the datatypes you need to support, and it would 
also help if there was a good task-safe callback mechanism that actually 
works (R3's needs a bit of work at the moment). Still, the principle 
is sound.

It's helpful to make a conceptual distinction between the host interface 
and the extension interface, even though for R3 they are currently 
related to each other and share a lot of the same code.


For the host interface, the host is the OS (more or less) and provides 
an execution environment that the R3 runtime runs on like a program 
(this is all metaphorical, but I'm sure you get it). The OS in this 
case could be something like Windows, Linux, some microkernel, whatever, 
or it could be an application or application plugin like Eclipse, 
Visual Studio, Notepad++, Excel, Firefox, whatever.


For the extension interface, R3 is the OS, the extension-embedded 
module is the program that runs on the OS, and that program calls 
the extension's native code like a library. The program source is 
returned by the extension's RX_Init function, and that program then 
wraps the native library code. The module source is loaded like a 
normal script (slightly hacked after loading to make it a better 
wrapper), so the script could be embedded in binary data along with 
non-Rebol stuff just like with normal scripts. You could even have 
Red and Rebol scripts in the same file (if they use the same embedding 
method) so you the data the init function returns can be like a Red/Rebol 
fat binary, metaphorically.


Given this, Red could either be (or compile) a host for R3; or it 
could be (or compile) a runtime library that implements the same 
host interface as r3lib, making it a drop-in replacement for R3; 
or it could be (or compile) an extension that R3 is a client of, 
returning R3 code that calls calls the compiled Red code; or it could 
be an alternate extension container, for extensions that return both 
Red and R3 code from the same init function, which would call the 
Red code returned, which would in turn call the same native code. 
The two languages could be integrated at any point in the stack, 
along with other languages.

Call it DOS. But the MSDOS target name still annoys me. I don't want 
a legitimate, common target build to bring back such bad memories 
:(

I meant call the real DOS target DOS. No Windows-based target should 
have DOS or MSDOS in its name :(

The %run-all.r script in root folder runs all the Red + Red/System 
unit tests. It does use CALL command which might need some permission 
under Win8? (just raw guessing, haven't tried Win8 yet). Can you 
try to run it using Admin priliveges?

It's probably a CALL issue, we had similar issues a year ago, and 
it was CALL-related IIRC. I and Peter need to install a Win8 system 
to be able to debug that.

What do you call "unboxed intermediate values"?

So, we get both worlds. If we manage to call R3 code from the Red 
section and vice versa, that would be great. We could use the compiled 
speed for inner loops and let the interpreter do all the non-speed 
relevant things.

Pekr: the difference between AOT and JIT compilation is much thiner 
than you think. Just load Red/System compiler code to your R2 app, 
pass it any source code at runtime, use the link?: no option and 
you get compiled code and related data in form of binary! values...and 
voilà! :-) The rest is same as for Cyphre's JIT, you need a way to 
call native code in memory, something that is hardly possible in 
R2, but maybe Cyphre found a hole to achieve it anyway.

You wouldn't need to implement PICKZ and POKEZ as actions. Just implement 
them as regular functions that call PICK and POKE, like the ordinal 
functions are in R3.

If we do R2's behavior, make sure that PICKZ and POKEZ exist so I 
have something to use. They can call PICK and POKE internally. I 
need something that does computed indexes/offsets, and I can't afford 
to have a hole in the list (0 for R2), and I can't count on the port 
scheme supporting SKIP.

In that case, it would help if PICKZ/POKEZ were the actions because 
they don't have the 0 hole, and we can add PICK/POKE optimizations 
that apply an algebraic transformation to change the call to PICKZ/POKEZ. 
Implementing the hole in the action has overhead that the optimizer 
wouldn't be able to undo. It would be able to undo the hole implementation 
in a wrapper function though by inlining the code then optimizing 
it away. That would make up for the problems caused by putting the 
0 hole in there in the first place.

My Understanding of Series:
A contiguous collection of boxes sequentially 
numbered in ascending order starting at 1.

 - this is correct only for series I would call "Head Series", i.e. 
 such series that are their own heads.

(that is what I call "working index arithmetic")

I am trying to write a test red-system program but it is a pain:

I write it in my editor, then open a Rebol console and do change-dir... 
do/args ... then:

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. Which is the right method?

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. 


I don't get this part...Your program seems to be still running while 
you think it has finished.

Does call/console work under Windows 7?


call/console "ver" causes REBOL to hang on my machine after printing 
"The handle is invalid twice."

A first pass at accessing the Etsy API: http://reb4.me/r/etsy


Works similarly to my Twitter API script (a few OAuth differences 
here and there). You can download it, or run it in place (do/args 
... [...Settings...]). As with Twitter, you start with etsy/as and 
go through the authorization process.  It has a few example methods, 
and an open method - etsy/api-call - that can call (as far as I can 
tell) every api function. Will try to document at some point.

It's not completely tested yet. The do-string call into R3 doesn't 
seem to work. We don't know yet whether this is a bug in Red/System 
or a bug in R3

For more of the FSF's interpretation, also have a look at:

https://gnu.org/licenses/old-licenses/gpl-2.0-faq#IfInterpreterIsGPL


Another similar and very common case is to provide libraries with 
the interpreter which are themselves interpreted. For instance, Perl 
comes with many Perl modules, and a Java implementation comes with 
many Java classes. These libraries and the programs that call them 
are always dynamically linked together.

You don't call intepreted libraries, you use an intepreter. It's 
different.

MaxV: whenever you use FUNC in your scripts, you call an interpreted 
library function.

Oh, weirdly enough, DELECT and DO-COMMANDS are also interpreters. 
There is an additional gotcha though.


Though DO, PARSE, DELECT and DO-COMMANDS are interpreters, they are 
implemented as library functions. This means that the code that you 
pass to these functions can be closed-source, but the code that *calls* 
these functions needs to be GPL-compatible. If you make a REBOL-in-REBOL 
interpreter or compiler that treats the code it runs as data, and 
the code it runs doesn't call any REBOL functions at all, even indirectly, 
then the code it runs can be closed source. This is basically what 
Red is, so Red would be legal.

Let me make a few remarks:


- "MaxV, REBOL isn't really an interpreter." - stated this way it 
looks correct, but:

-- specifically, the couple of r3.exe and r3lib.dll (speaking about 
the Windows case here) are two parts of the R3 interpreter (in my 
opinion, of course, but this looks quite legitimate)

--- the R3 interpreter consisting of the r3.exe and r3lib.dll interprets 
such expressions as:
    do ...
    func ...
    etc.

-- the collection of the above (DO, FUNC, ...) is not a library, 
the r3lib.dll is

-- your program typically does not call the r3lib.dll library, the 
r3.exe does

-- your program is actually just data for the R3 interpreter, the 
data is what you are bundling with the interpreter when encapping

Hmm, in another thread I can see you don't call encapping a linking, 
but mostly a bundling with data?

Hmm, in another thread I can see you don't call encapping a linking, 
but mostly a bundling with data?

your program typically does not call the r3lib.dll library, the r3.exe 
does

For example: "The JNI or Java Native Interface is an example of such 
a binding mechanism; libraries that are accessed in this way are 
linked dynamically with the Java programs that call them. These libraries 
are also linked with the interpreter. If the interpreter is linked 
statically with these libraries, or if it is designed to link dynamically 
with these specific libraries, then it too needs to be released in 
a GPL-compatible way." - this refers to the following situation when 
transposed to the REBOL case:


R3 can be dynamically linked with REBOL extensions. If the extensions 
are GPL'd, then r3.exe has to be GPL'd as well.

These libraries and the programs that call them are always dynamically 
linked together.

First enable programmers, then teachers, business people, artists. 
 Donald Norman does a nice job of articulating this vision in "Things 
that Make us Smart."  Human centered technology could become the 
clarion call of R3.

Yes, but there already are some Rebol scripts examining system/version 
to "know how to call system libraries" or some such. I guess it may 
be a good reason to define a platform?

It won't be like CALL/SHOW breaking all kinds of stuff. :-)

I guess i should just make a rule for each type of call and then 
combine them.

Still probably a local call from Scott Base though. ;-)

Or give a name to your window:
view lay: layout [...]

and call "show lay" when you make changes. This will refresh the 
whole widgets in the window.

It's better to refresh what you've updated, not the whole window, 
as it is much more slower. But when you are testing it is easier.

Let us know whether you find that it's safe to unset 'path and reuse 
it for other stuff. There's no reason to think that the action! mechanism 
would call the function through its name (that's more of an R3 intrinsics 
thing), but any unpredictable behavior you find would be good to 
know.

Sunanda: Thanks again for issuing the World invitation. Everyone 
thanks for the continuing help.


I have read the cited document, but it just leaves me with more questions.

Is the following literal?

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


 That is to say should I type exactly that? Or is cgi-string for example 
 a theoretical variable assignment that I could call anything? Are 
 they all proper commands, or is any part of that just for example 
 purposes?  I am thinking I should copy and paste it verbatium. I 
 am also thinking I mispelt verbatum.


 I am stuck with GET. Does this mean I can leave out some code that 
 makes up for  not knowing if the original data is POST vs GET? These 
 are hypothetical questions for better long term learning. I for now 
 will go with the idea that everything is as straight fowarrd as it 
 seems. I know that my GET stream will have "trnEmailAddress" in it 
 which is a field that will contains an email address.


 So will the following  generate a random number, extract the address 
 and email the same random number to that email address?

token: random/seed now/percise

cgi-string: read-cgi
cgi-block: decode-cgi cgi-string
cgi-obj: make object! cgi-block 


send trnEmailAddress rejoin [ "Thank you. Your number is" token "." 
]


 Graham: Thank you for the extra info on GUID, but Windows is not 
 involved here. I realize that random number generating really isn't 
 unless you have a monkey throwing darts at a numbered board. Regardless 
 extra effort to 
make a number unique is useful and your advice appreciated. 


 I do not think the corner cases will come up and the people who control 
 the original form assured me that web page issues warnings if the 
 form is not filled out correct which should help. I do realize that 
 people are idiots, systems are not fool proof, etc. What I am saying 
 is my basic needs are basic and I should be OK so I am not fretting 
 over those examples. It is great though to know the solutions are 
 out there when I need them.

 Tahnks.

Hi, I have a small problem playing an mp3 file 
I have so far
player: "/Applications/Vox.app/Contents/MacOS/Vox"
thissong: "/Users/Arnold/Music/A song.mp3" 
thatsong: "/Users/Arnold/Music/A-song.mp3"       
And then 
call reform [player thissong]  
call reform [player thatsong] 

Playing thissong will start the musicplayer, but no music was found 
and playing  thatsong starts the player and is being played without 
problem.

Because most of my mp3's and directories they are in have spaces 
in their names so starting to play them from REBOL gets hard this 
way.

I tried to-file thissong but this produces "%/......&20song.mp3" 
so it was not successful. (Allthough thatsong just played without 
a problem) :(
Any ideas please?

Found the answer to my first task:

Had to read the documentation a little further and needed a function 
localize-file: func [file] [
    rejoin [{"} to-local-file clean-path file {"}]
]

Now call reform [player localize-file to-file thissong] does play 
the song!

I am trying now. I somehow lost interest in R3, as it is non-finished, 
and dead product. But probably still easier than to use iconv together 
with R2, although I did it in the past that way, using CALL

Rebolek - thanks, I forgot about it. I needed it only once in the 
past, and so I used iconv command line tool  via CALL ....

Sometimes you want to allow someone to pass in functions and then 
let them evaluate, as long as you have a good semantic model for 
what is supposed to happen and are careful about how you call them. 
The ARRAY, EXTRACT and REPLACE functions in R3 and R2 2.7.7+ are 
a good example of this.

the local values are reset to none at each execution
 - that should have been:


the local variables are reset to NONE at every function call. After 
the function returns, the local variables are:
- in R2 they 
remember" the last (outermost call) value
- in R3 their values are inaccessible

IIRC in R3 closures do a BIND/copy of their bodies at every call, 
then execute the copy. As soon as the USE is finished executing its 
context and body are no longer referenced, at least if you didn't 
save a reference elsewhere. The context containing the 'f and the 
function it references would be able to be GC'd as soon as the USE 
returns.

It's a stack frame. Stack frames are automatically available for 
collection after the particular function call returns. All function 
words are referenced stack-relative.

Closures are different; the contexts that they create when they are 
called are basically the same as object contexts, with no stack-relative 
indirection needed, but the whole body and context are unreferenced 
after the call.

IIRC they had some success with the pattern of using a callback to 
signal R3 to grab data using a synchronous call.

steeve: right, the call has to be in tail position; thought i'd mentioned 
that in the docs but evidently not

The usage comment in the third version is very nice. 


On doc strings, try to keep them short, leaving detailed notes to 
the usage or other comments. e.g.

rfunc: func [

    {Defines a tail-call optimized user function, using RECUR for self-calls.}
    spec [block!] "Function spec (see: func)"
    body [block!] "Function body (modified) (see: func)"
    /local wrapped
] [
    ...
] 

Short doc strings are nicer with HELP.

that was originally _args_ but i switched it out so that you could 
get a more readable recur call (i.e., cheekily make use of 'with' 
so that it read better)

well, it has to be a tail call

it's a tail call but it can be anywhere in the function body

i mean this: http://en.wikipedia.org/wiki/Tail_call

It's tail call recursion yes, but tail position usualy means "physically 
placed" at the tail (in our context, at the end of the body of the 
function)
Anyway...

not be pedantic, but i linked to that for the opening two sentences:


In computer science, a tail call is a subroutine call that happens 
inside another procedure as its final action; it may produce a return 
value which is then immediately returned by the calling procedure. 
The call site is then said to be in tail position, i.e. at the end 
of the calling procedure.

Marc, to no pollute this group I posted a private conversation mentioning 
how to define a TAIL-CALL function using the function spec and how 
to handle the situation even if the function spec is "more complicated" 
than just a block of words.

OK, this is the long version:

tail-func: func [
    {

  Define a recursive user function with the supplied SPEC and BODY.
     	The function can use a special TAIL-CALL local function
     	to perform a tail-recursive function call.
    }
    [catch]


 spec [block!] {Help string (opt) followed by arg words (and opt type 
 and string)}
    body [block!] {The body block of the function}
    /local the-function tail-call context-word
] [
	; define a new 'tail-call local variable
	tail-call: use [tail-call] ['tail-call]
	
	; bind the given BODY to "know" the 'tail-call variable
	body: bind/copy body tail-call
	
	; find a local word in SPEC
	context-word: find spec word!
	if context-word [context-word: first context-word]
	
	; define the TAIL-CALL function
	set tail-call func spec compose [
		(
			either context-word [
				; set parameters to the new arguments
				compose [set parameters values? (context-word)]
			] [[]]
		)
		throw/name none 'tail-call
	]
	
	; define the function
	the-function: throw-on-error [
		func spec compose/deep [
			(either context-word [context-word] [[]])
			while [true] [
				catch/name [
					return do [(body)]
				] 'tail-call
			]
		]
	]
	
	if context-word [
		; get the function context
		context-word: bind? first second :the-function
		
		; replace the context word in the function body by NONE
		change second :the-function none

		; adjust the TAIL-CALL body
		; replace the 'parameters word

  change/only at second get tail-call 2 bind first context-word context-word
	]

    :the-function
]

values?: func ['word] [second bind? word]

example:

            safe: tail-func [x] [
                if x > 20000 [print x exit]
                tail-call x + 1
            ]

however, I noticed that even my version would need to use one more 
THROW-ON-ERROR call

One more problem with all the versions mentioned except for my last 
version:


- e.g the last Steeve's version "reserves" 'bind?, 'quote, 'forever, 
'catch, 'set, 'return and 'do (and 'recur, but that is by design), 
while my last version does not "reserve" any word except for 'tail-call, 
which is by design.

re "any spec accepted", here are differences:

>> safe: rfunc [throw] [if x < 20000 [recur x + 1]]
** Script Error: throw has no value
** Where: throw-on-error
** Near: rfunc [throw] [if x < 20000 [recur x + 1]]

, while:


>> safe: tail-func [throw] [if throw < 20000 [tail-call throw + 1]]
>> safe 0
== none

Not really fair, you redefine the throw word and expect it to work 
as is ?

Your function got the same problem on my pc, except it occurs at 
the execution time.
** Script Error: Cannot use path on integer! value
** Where: tail-call
** Near: throw/name none 'tail-cal
or maybe you have a new version right now

(Actually I have problems with Altme to synchronize with some recent 
posts I can't see all of them currenly)

(no "reserved words" at all, except that the 'tail-call word has 
got a special meaning as a function to make the tail call, however, 
it still *can* be redefined at the cost that the tail call cannot 
be made in such case since it is redefined)

Doc, regarding your question, see this example:


>> safe2: tail-func [/local throw] [if throw < 20000 [tail-call/local 
throw + 1] throw]
>> safe2/local 0
== 20000

Ladislav: would you be interested in improving the 'proxify function 
from the REBOL profiler I've built for Red project, it has the same 
kind of constraints as 'tail-call? The current code is a bit "rough", 
I don't have time to make a cleaner and simpler version of it.


See code at: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r

However, Steeve, you probably do not understand what the problem 
with the

    f: rfunc [x] [if x = 2 [g/recur 3 5]]


code is. The problem in a nutshell is that the G/RECUR call uses 
G/RECUR calling convention and "expects" the G/RECUR call to be used; 
however, the CATCH/NAME+THROW/NAME pair does not respect that and 
actually would do the call of F/RECUR.

This time it's really really my final version T_T
- Both f/recur and recur allowed
- Catch/throw interferences ok.

NB: The code would be simpler in R3 since several workarounds are 
used to correct misbehaviors of object related natives of R2.

Also the lack of the reflexive capability for a function to read 
its own context in a easy way is definitivly a huge miss.

(On can't create anonymous functions without analysing their specs 
first. What a pain)

One would need a reserved word holding the context (like SELF for 
objects).

These shortcomings are making the code too much obfuscated and huge 
for my taste.
I hope it will be corrected in R3..

rfunc: func [
    [catch] spec [block!] body [block!] 
    /local ctx args call-tail
][
    ctx: bind? first second throw-on-error [
        func spec: append copy spec /recur [recur]
    ]
    args: bind head remove back tail to-block form first ctx ctx
    call-tail: func ['word] compose/deep [
        set/any [(args)] second bind? word 
        throw/name (ctx) 'recur
    ]
    ctx/recur: func spec reduce [:call-tail 'recur]
    func spec reduce [
        quote #[function! [
            [throw] 'recur 'call-tail ctx args body /local ret
        ][
            if get/any recur [call-tail :recur]
            set recur get in ctx 'recur
            while [true][
                set/any 'ret catch/name [return do body] 'recur
                unless all [value? 'ret same? :ret ctx][
                    throw/name get/any 'ret 'recur
                ]
                set/any args second ctx
            ]
        ]]
        'recur :call-tail ctx args body
    ]
]

ChristianE implements an R2-like API in an R3 port model, and it 
just feels alien, though it does allow me to have more portable code 
between R2 and R3. This helps when i have to have a script extract 
data in R2 because it needs to get text or numeric type data, but 
then close and call itself in R3 to parse that data. My %rebol.r 
is R2 and R3 compatible.

Nowadays I mostly write SQL, sometimes calling that SQL using R3, 
or others call it with ASP.NET, PHP or Java (merger code collection).

Back in 2001 I created an intranet site for a local celebrity by 
making the database tables, then having R2 use the 'columns command 
to generate column lists that were used to autogenerate the server-side 
pages for the intranet. All it took was one function call per table 
to generate the whole site. Restyling the site just meant editing 
the HTML template in the function (this was before CSS was practical).

Had to do more than one project with scripts that call themselves 
in R2 to do data extraction from text fields, then call themselves 
in R3 to do processing.

Create 2 files. Call the first one e.g. cgi-test.html, and upload 
it to your server. The only thing you have to change is the link 
to your .cgi script in there:

<HTML>
<TITLE>Simple Web Form</TITLE>
<BODY>
<b>Simple Web Form</b><p>
<FORM ACTION="http://www.xidys.com/cgi-bin/cgi-test.cgi">
<INPUT TYPE="TEXT" NAME="Field" SIZE="25"><BR>
<INPUT TYPE="SUBMIT" NAME="Submit" VALUE="Submit">
</FORM>
</BODY>
</HTML>



Create a second file, called cgi-test.cgi (it has to align to how 
you name it in the above source file). Upload it to your cgi working 
directory. Remember to change the first line to contain the path, 
where your REBOL executable is placed:

#!/usr/local/bin/rebcmd -sqc

REBOL []

print join "Content-type: text/plain" newline
start: now/time/precise

submitted: decode-cgi read-cgi
values: construct submitted

prin "Submitted: " print mold submitted
prin "values: " print mold values
prin "values/field: " print mold values/field

print now/time/precise - start
print newline
 

Now go to your URL, and try to submit some values. You can test it 
on my site at: http://www.xidys.com/cgi-test.html

I needed it now because call/output is broken in ORCA